Common OPSEC Mistakes

Learning Objectives

• After this, students can list the most common ways investigators reveal themselves.
• After this, students can explain how “who viewed” features, tracking links, and canary tokens expose researchers.
• After this, students can use public scanning and archiving services without leaking their investigation.
• After this, students can find and remove metadata from their own files and reports.
• After this, students can describe real-world OPSEC failures and the lessons they teach.

Why Study Mistakes?

Most OPSEC failures are boring: one click, one reused username, one photo that wasn’t cleaned. They are also permanent, because logs, archives, and screenshots don’t forget. This file groups the most common mistakes into categories, explains how each one works, and pairs them with real cases. Many of these cases are also great OSINT examples, since one person’s OPSEC failure is another person’s investigative lead.

1. “Who Viewed” and Notification Features

Many platforms tell users who looked at their content. Platform features change often, so check current behavior before class.

Other patterns that tip targets off:
- Volume and timing: even anonymous “private mode” viewers stand out when 30 of them hit one company’s IT team in an hour.
- Search appearances: some platforms tell users how often they appeared in searches.

Countermeasures: use logged-out views when possible, use private mode or approved research accounts, check each platform’s visibility settings before you start, and spread out your activity.

2. Accidental Interactions

Mis-taps and autopilot habits are among the most common real-world slips:
- Liking a post, reacting to a story, or following an account while scrolling
- Sending a friend or connection request by accident
- Joining a group or event with the wrong account
- Tapping a call button in Messenger or WhatsApp
- “People You May Know” suggestions: platforms use phone contacts, email contacts, and location to suggest connections. A research account created with a phone number that’s in the target’s contacts (or vice versa) can be suggested to the target.

Countermeasures:
- Research on a desktop browser, not a phone app (fewer accidental taps)
- Slow down; don’t research while multitasking
- Never sync contacts on research accounts
- Stay logged out whenever possible

3. Your IP Address in Their Logs

Every website logs visitor IP addresses. An IP can be looked up to find the owning organization and approximate location.
- Corporate and university networks are publicly registered to the organization, so visiting a target from the office says “Company Y was here.”
- Home IPs point to your ISP and rough location, and can be tied to you through legal process.
- Email tracking pixels: if the target (or a threat actor) emails you, remote images in that email can report your IP and the time you opened it.
- Unusual patterns: repeated visits to obscure pages (staff directories, old PDFs) from the same IP stand out in logs.

Countermeasures: research through a non-attributable network (see 8.2-building-a-research-environment.md), block remote images in email clients, and prefer passive sources (search engines, archives) over the target’s own servers.

4. Tracking Links, IP Loggers, and Canary Tokens

Targets, threat actors, and defenders can set traps that reveal whoever touches them.

IP loggers

Services like Grabify create short links that log detailed information about anyone who clicks. According to Grabify’s own site, it can collect:
- IP address, ISP, and whether the visitor is using a VPN, proxy, or Tor
- Country, city, and time zone
- Operating system, browser, device type, and screen size
- With its “Smart Logger”: battery status, language, whether the browser is in private/incognito mode, ad-blocker use, and whether the visitor appears to be in a virtual machine

A short link posted in a forum, a channel, or a DM can tell its creator a lot about the researcher who clicked it.

Canary tokens

Canarytokens (free at canarytokens.org, created by the security company Thinkst) are digital tripwires that alert their creator when they’re touched. Token types include:
- Web bug / HTTP token: a unique URL; visiting it triggers an alert that includes the visitor’s public IP
- DNS token: a hostname that alerts when it is merely looked up, even from a machine without web access
- Document tokens: Word and PDF files that alert when opened
- Fake credentials: AWS API keys and other cloud or service credentials that alert when someone tries to use them
- QR codes, cloned-website tokens, and many more

Defenders plant canary tokens in places attackers look: a “passwords.docx” in an exposed folder, fake AWS keys in a public repo, a link in a “leaked” document. A curious investigator who opens the file or tries the key announces themselves, and trying found credentials is also potentially illegal (see Module 2).

Countermeasures:
- Don’t click unknown or shortened links from your normal environment. If a link matters, examine it safely (e.g., a private scan on a service like urlscan.io) and consider whether visiting it is necessary at all.
- Open found documents only in a disposable VM, ideally offline, or don’t open them at all. Record the file hash instead.
- Never test found credentials. Besides being a legal problem, they may be canaries.
- Assume anything that looks too good (an open “passwords” file) might be a trap.

5. Public Submissions to Scanners, Archives, and Online Tools

Many investigation tools are public by default, and what you submit can be seen by others, including the target.

Threat actors watch these services too. Phishing operators, for example, can search public scan results for their own domains to learn they’ve been spotted.

6. Metadata in Your Own Files and Reports

Metadata is data about data: who created a file, when, with what software, and sometimes where.
- Office documents: author name, company, username, last-modified-by, revision history, comments, tracked changes, and sometimes internal file paths
- PDFs: author, creator application, creation and modification dates
- Photos and screenshots from phones: EXIF data, which can include GPS coordinates, device model, and timestamps
- Improper redaction: drawing a black box over text in a PDF often leaves the text underneath intact and copyable. Use a real redaction tool, then verify by trying to select or copy the redacted area.

Inspecting and removing metadata

# View all metadata in a file
exiftool report.pdf
exiftool photo.jpg

# Remove all writable metadata from an image (exiftool keeps a backup named photo.jpg_original)
exiftool -all= photo.jpg

# Show only GPS-related tags
exiftool -gps:all photo.jpg

Case study: John McAfee’s location (2012)

While software entrepreneur John McAfee was avoiding authorities in Belize, VICE journalists traveling with him published a photo on December 3, 2012. The photo still contained EXIF metadata showing it was taken with an iPhone 4S, along with GPS coordinates placing it in Guatemala. Security researchers spotted the coordinates quickly. McAfee first claimed the data was faked, then admitted he was in Guatemala.
Lesson: the journalists’ OPSEC failure exposed the person they were protecting. Your files can expose your sources, subjects, and clients, not just you.

Case study: Higinio Ochoa, “w0rmer” (2012)

Higinio Ochoa, associated with the hacking group CabinCr3w, posted a photo of a woman holding a sign taunting authorities, linked to law enforcement website breaches. The photo, taken with an iPhone 4, contained GPS coordinates pointing to a house in Wantirna South, Australia. The FBI combined that with other online clues: the “w0rmer” name had been linked to Ochoa elsewhere, and his Facebook showed an Australian girlfriend. He was arrested in Galveston, Texas, in March 2012 and later served two years in federal prison.
Lesson: one uncleaned photo plus a few other public clues was enough.

7. Reusing Personal Accounts, Devices, and Usernames

Crossing the line between personal and research identities is the most damaging category, because it creates a direct link to you.
- Being logged into a personal Google account while researching (search history is tied to you)
- Browser sync copying research history into your personal profile
- Using a personal phone number or email to register a research account
- Reusing a personal username, gaming handle, or writing style
- Using the same device for personal accounts and personas

Case study: Ross Ulbricht and Silk Road

Silk Road was a dark web drug marketplace run by “Dread Pirate Roberts.”
- The early posts: IRS special agent Gary Alford, working with the DEA, searched Google for early mentions of Silk Road dated before the site’s launch at the end of January 2011. He found a January 29, 2011 post on the Bitcointalk forum by a user named “altoid” promoting the site. A Silk Road promotion on the Shroomery forum was also tied to an account registered with Ulbricht’s email address.
- The link to a real name: in an October 2011 Bitcointalk post, “altoid” advertised for an IT professional and told applicants to contact rossulbricht at gmail dot com.
- Stack Overflow: Ulbricht posted a question under his real name asking how to connect to a Tor hidden service using curl in PHP, then changed his username to “frosty” about a minute later. Investigators later found a public SSH key ending in frosty@frosty on the Silk Road server.
- Outcome: Ulbricht was arrested on October 1, 2013, at the Glen Park branch of the San Francisco Public Library. He was convicted and sentenced to life in prison, and was pardoned on January 21, 2025.
Lessons: early “unimportant” posts under a reused handle, a real-name email address, and a quick username change that archives still remembered. Alford’s key technique, a date-restricted search engine query, is basic OSINT.

Case study: Hector Monsegur, “Sabu” (2011)

Monsegur was a leader of the hacking group LulzSec. It was widely reported that the FBI identified him after he connected to an IRC chat server just once without Tor or a proxy, exposing his real IP address. Monsegur has disputed that account, saying investigators identified him through personal details leaked about him years earlier. He was arrested on June 7, 2011, and became an FBI informant.
Lessons: a single unprotected connection can be enough, and the case also shows why verification matters (Module 7). Popular accounts of an OPSEC failure aren’t always the full story.

8. Talking About It

• Posting about engagements (“Big recon week for a client in Denver!”)
• Conference talks or blog posts with identifiable client details
• Discussing cases in public places, or on calls in shared spaces
• Screen sharing and screenshots that show open tabs, bookmarks, usernames, or notifications
• Putting client names in file names, calendar invites, or commit messages in public repositories

Countermeasure: use code names for engagements, and review screenshots and shared screens before they leave your hands.

Checklists

Before an investigation

[ ] Rules of engagement reviewed (personas allowed? interaction allowed?)
[ ] Research environment reverted to a clean snapshot
[ ] Network: non-attributable connection active; leak test passed
[ ] Logged out of all personal accounts; no browser sync
[ ] Platform visibility settings checked (LinkedIn private mode, TikTok Profile View History off, etc.)
[ ] Scanner accounts set to private visibility by default
[ ] Evidence folder and log ready (see Module 7)

After an investigation

[ ] Evidence exported to encrypted, approved storage
[ ] Report metadata inspected and removed; redactions verified
[ ] No client names in public places (file names, posts, repos)
[ ] VM reverted; downloaded files removed from the host
[ ] Persona log updated (activity, status)
[ ] Data retention/deletion scheduled per contract

Key Terms

• Tracking pixel / web bug: a tiny remote resource that reports when and where content was opened.
• IP logger: a link service that records details about whoever clicks it.
• Canary token (honeytoken): a planted file, link, or credential that alerts its owner when touched.
• Metadata / EXIF: hidden data describing a file; EXIF is the metadata format used in photos.
• Scan visibility: whether a submission to a service like urlscan.io is public, unlisted, or private.
• File hash: a fingerprint of a file’s contents, used to look a file up without uploading it.
• Redaction: permanently removing sensitive content from a document (not just covering it).

Key Takeaways

• “Who viewed” features, story viewer lists, and read receipts can expose you; check settings first.
• Accidental likes, follows, and contact syncing are among the most common slips.
• Never research from corporate or campus IPs; your IP names your organization.
• Short links and “leaked” files may be IP loggers or canary tokens. Don’t click, don’t open, and never try found credentials.
• Public scanners and archives are public by default; use private scans and hash lookups.
• Clean metadata and verify redactions before sharing anything (McAfee and w0rmer were located by photo EXIF).
• Reused usernames and emails link identities for years (Ross Ulbricht’s “altoid”).

References

• Browsing Profiles in Private and Semi-Private Mode — LinkedIn Help
• Private mode viewers of profiles — LinkedIn Help
• Who’s viewed your profile basic and Premium features — LinkedIn Help
• Profile view history — TikTok Support
• Grabify IP Logger
• Canarytokens.org – Quick, Free, Detection for the Masses — Thinkst
• What are Canarytokens? — Thinkst Canary
• Scan Visibility Levels — urlscan Pro docs
• Scan Visibility Best Practices — urlscan.io blog
• How it works — VirusTotal docs
• Fugitive John McAfee’s location revealed by photo meta-data screw-up — Graham Cluley
• Betrayed by metadata, John McAfee admits he’s really in Guatemala — NPR
• A Picture is Worth a Thousand Words, Including Your Location — EFF
• Higinio Ochoa — Wikipedia
• IRS found accused Silk Road mastermind’s email by googling Silk Road — VICE
• Ross Ulbricht — Wikipedia
• Simple Google search outed alleged Silk Road founder — Computerworld
• It was DPR, in the Tor HS, with the BTC — the grugq
• The “one tiny slip” that put LulzSec chief Sabu in the FBI’s pocket — The Register
• Hector Monsegur — Wikipedia
• Profile of a Hacker: The Real Sabu, Part 2 — F5 Labs