Threat modeling, attribution risk, browser/account separation, and sock puppet discipline.
Online investigations reveal information, and that revelation is irreversible. Operational Security (OPSEC) is the discipline of protecting your identity, your methods, and your objectives while you work — whether that's OSINT, journalism, corporate due diligence, or law enforcement. The goal is simple to state and hard to execute: don't let your subject know they're being investigated, and don't expose yourself, your organization, or your sources in the process.
When OPSEC fails, a subject may notice unusual attention — a profile view, a suspicious follow — and destroy evidence, flee, or retaliate. You can also expose your own personal information (home address, family, workplace), creating real safety risk, especially when investigating people connected to crime or extremism. Poor OPSEC can compromise an entire case: if a target realizes law enforcement or a journalist is looking into them, they may lawyer up, tip off associates, or take legal action against you.
Before you open a browser or create a sock puppet, the most important step happens in your head: what could go wrong, who might notice, and how bad would the consequences be? A useful framework asks: who is the subject and what resources do they have (an individual with no technical sophistication poses a very different risk than a corporation with a legal team, or an organized crime group willing to use intimidation)? What happens if you're discovered — does the subject just lock down their accounts, or could they retaliate against you or your family? What's actually at stake — personal safety, the integrity of the investigation, organizational reputation, legal exposure?
The ENISA Cyber Threat Landscape methodology frames this as a structured set of questions: what type of data is being collected? Who is the target audience? How is data collected, processed, and analyzed? What's the process for collecting feedback and revising the assessment?
In practice, think in risk tiers. Low-risk research (public records, widely available social media) rarely needs more than a logged-out browser session. Medium-risk research (monitoring an active account, joining a public forum, researching someone with some incentive to notice attention) calls for dedicated sock puppets and VPN use. High-risk research (organized crime, extremist networks, hostile state actors) demands isolated devices or VMs, Tor or specialized anonymization, well-aged personas, and often legal consultation before proceeding. Revisit your threat model throughout an investigation, not just at the start — new information (discovering a subject has technical sophistication, or a support network) should trigger a reassessment.
Persona Non Grata (PnG): build a specific persona for a plausible attacker — name, history, skillset, goals. For example: "Attacker 1: a bored, technically unsophisticated individual, motivated to show off skills and embarrass institutions" versus "Attacker 2: state-sponsored, mission-focused, motivated by ideology, wants to spread disinformation and exfiltrate sensitive information." Giving an imaginary attacker concrete detail forces you to see vulnerabilities from their perspective.
Security ("baseball") cards: a structured deck across four categories — human impact, adversary motivations, adversary resources, adversary methods — randomized to inspire threat scenarios you wouldn't otherwise think of.
Attack trees: a diagram breaking an attack goal (say, "find the analyst's real location") down into its component paths — geolocation, IP address, metadata, social media disclosure, a canary token, photos on a personal website — each branch needing its own specific countermeasure.
| Step | What it means |
|---|---|
| 1. Define critical information | What needs protecting, at what level, at what cost the stakeholder accepts |
| 2. Analyze the threat | Who has means and motive? What are their capabilities? What do they already know? |
| 3. Determine vulnerabilities | Can the adversary detect your movements? Where are the weak points? |
| 4. Risk assessment | Cost-benefit: does the level of protection match the actual threat? |
| 5. Apply countermeasures | Sock puppets, VPN/Tor, minimizing identity footprint |
A concrete illustration of step 4: four analysts tasked with researching a state-sponsored APT group over 30 days might justify four research-only laptops, four burner phones, four VPN accounts, and four VPS accounts — several thousand dollars in cost, but justified given the high risk of retaliation. The same equipment list for four analysts researching low-level insurance fraud at a local firm would not be justified — low risk to the analysts means the cost outweighs the benefit. Matching the level of protection to the actual threat, not defaulting to maximum paranoia or minimum caution, is the whole point of doing this step deliberately.
altoid asking for an "IT Pro in the Bitcoin community," giving his personal email. In early 2013, he asked a technical question on Stack Overflow using his real name before quickly switching to a pseudonym — and the code from that question later matched code found on the Silk Road servers.The shared lesson: adversaries rarely need sophisticated hacking — they exploit the "low-hanging fruit" of human carelessness.
Attribution risk falls into three escalating levels. Institutional: the target realizes a specific company or agency is looking (a LinkedIn "X viewed your profile" notification). Campaign-level: the target senses a coordinated effort without knowing exactly who's behind it. Individual: the worst case — the target discovers your actual identity, opening the door to retaliation.
How exposure actually happens: digital fingerprints and metadata (a screenshot with embedded GPS, a document with your real author name); account/infrastructure reuse (logging into a personal account on the same browser used for investigative work, reusing a phone number across personas); behavioral patterns (a sock puppet active only during your employer's business hours in a specific timezone); platform notifications (profile-view alerts, story-viewer lists); and reverse image search on your own sock puppet's photo (if it's a real person's face — even a stock photo — a motivated target can discover it's not a genuine account).
Two illustrations of how far this can go wrong. Webcam hijacking (the 2013 case of Jared Abrahams, who hijacked webcams of several young women including Miss Teen USA Cassidy Wolf, to extort them) shows a scenario where a VM offers zero protection — the attack targets the device itself, not your browsing data. Browser fingerprinting collects font list, graphics card, drivers, browser and OS version, screen resolution, language packs, and extensions into a combination unique enough to re-identify a device — neither a VPN nor a VM defeats this without deliberate behavioral randomization or periodically rebuilding your VM from scratch.
This is one of the most fundamental — and most frequently violated — OPSEC practices. The principle: investigative activity should never share a browser, session, or account ecosystem with your personal digital life. Modern browsers and platforms are specifically built to recognize and connect users across sessions — cookies, cached logins, autofill data, and saved passwords all create linkages. If you use the same browser window for personal email and a sock puppet, a single autofill suggestion or leftover cookie can permanently link the two identities in a platform's backend, even if you never consciously "connect" them yourself.
Layers of separation, from lightest to heaviest: browser-level (separate browser profiles at minimum, ideally entirely different browser applications for personal vs. investigative use); session isolation (never stay logged into multiple personas at once, fully log out rather than just closing the tab); device-level (a dedicated investigation machine or VM for higher-risk work, configured with its own distinct fingerprint — timezone, language, resolution — from your real device); account-level (a dedicated email, phone number, and unique non-reused password per persona — password reuse is especially dangerous, since one breached account can expose every other account sharing that password); network-level (VPN, proxy, or Tor pairing with the above, so a shared IP doesn't become the thread tying personas together even when browser hygiene is otherwise solid).
Most breaches of this discipline aren't dramatic — they're small conveniences: quickly checking personal email mid-session, letting a browser autofill a personal address into a sock puppet's profile, or reusing a recognizable username or writing style across personal and investigative accounts. Because these lapses feel harmless in the moment, they need deliberate habits — and sometimes technical safeguards like separate devices — rather than relying on memory or willpower alone.
Metadata is a powerful tool for extracting intelligence about a subject (Chapter 6), but it's also a serious liability if you fail to manage the metadata attached to your own files. A screenshot, a downloaded document, or a shared file as part of your reporting may carry metadata pointing back to your own device, software, organization, or physical location. Sharing such a file — with a source, in a report, or inadvertently — can expose your identity or affiliation, undermining separation you worked hard to maintain elsewhere.
Practical hygiene: routinely strip metadata from any file before sharing or storing it, rather than assuming it's "clean." Check screenshots for embedded device or location data. Scrub author fields and organizational identifiers from documents you create for reports. Be cautious of metadata your own tools might add automatically (some archiving or annotation software embeds its own identifying data into output files). This category of risk is easy to overlook because it's invisible during normal use — a file looks identical whether or not it carries hidden data — which makes it one of the more common "silent" OPSEC failures, catching even experienced investigators who are otherwise careful about browser separation and network anonymization.
This discipline protects the investigation itself, distinct from protecting your identity — making sure the act of looking doesn't become visible to the person being looked at. Many platforms are built to notify users about attention they receive: LinkedIn shows profile viewers, some platforms show story viewers or "recently active" indicators. Browsing a subject's profile normally, logged in, risks triggering exactly the notification that tips them off.
Techniques: logged-out browsing wherever a platform allows it, since many notification features only trigger for logged-in views. Archive and cache tools (the Wayback Machine, cached page versions, specialized OSINT viewing tools) let you pull content without directly interacting with the live platform at all. Read-only, no-engagement discipline — avoid liking, commenting, following, or otherwise engaging with a subject's content unless it's a deliberate, considered decision, never an accidental click; even a stray "like" on an old post can alert a subject that someone unusual is looking through their history. Platform-specific knowledge matters because visibility features differ by platform — what triggers a notification on one may be silent on another. And test personas on lower-stakes targets before using them for anything sensitive, to confirm they don't stand out or trigger scrutiny.
The underlying goal across all of this is preserving the core asymmetry that makes investigation possible: you can observe the subject, but the subject cannot observe you. A single careless click can undo weeks of careful groundwork elsewhere.
Every action online leaves a trace somewhere. A digital footprint splits into an active part (what someone deliberately chose to publish) and a passive part (generated as a side effect of activity, often without the person realizing it — page-view logs, referrer headers, watch notifications). Investigators combine both: the active footprint tells you who someone wants to appear to be; the passive footprint reveals what they actually did — and the same logic applies just as much to protecting yourself as it does to researching a subject.
Referrer headers deserve special attention. When a user clicks a link on one site to reach another, most browsers automatically send an HTTP Referer header carrying the URL of the page the click came from. Website analytics routinely log this alongside a timestamp and approximate location. If you follow a link from a platform while logged into your real account, the destination site's analytics log will show exactly which page on that platform you came from — a passive record you almost certainly didn't realize you were generating, and one a sufficiently resourced target could potentially access.
Platform visibility features — profile-view notifications, repository watchers on code-hosting platforms, page analytics on personal sites — exist to serve the platform's users, but as a side effect also expose information about observers to the people being observed. Someone unaware of these systems may not realize they're leaving a record on every platform they visit.
The core discipline for cross-referencing evidence about a subject (and for understanding your own exposure) is triangulation: never conclude anything from a single match, but look for the same identifying detail appearing independently across multiple sources. Correlation is strongest when the confirming evidence is genuinely independent — generated by separate systems that couldn't have influenced each other.
A personal website's analytics log records every visit with a timestamp, the page viewed, the referring URL, and an approximate visitor location:
| Timestamp | Page | Referrer | Approx. location |
|---|---|---|---|
| 14:02 | /portfolio | (direct) | — |
| 14:03 | /contact | linkedin.com/in/[handle] | City A |
| 14:05 | /portfolio | (direct) | City A |
The subject in this scenario had publicly claimed to be traveling abroad at the time. The referrer field alone is the finding: a click arriving from a specific LinkedIn profile URL, at a timestamp during the claimed trip, geolocated to the subject's home city rather than the claimed destination. No single field proves the case on its own — the timestamp could be a scheduling quirk, the location estimate could be imprecise — but the combination of a referrer tied to a specific named profile, arriving at a time inconsistent with the claimed location, and repeating across more than one visit, is exactly the kind of independently-generated, hard-to-fake passive evidence this section describes. Note too what this example demonstrates about your own exposure: if you ever click a link into a subject's site while logged into a personal account, you are the row in someone else's version of this exact table.
| Tool | Pros | Cons |
|---|---|---|
| VPN | Hides your IP from the destination; simple to use | The VPN provider itself sees your traffic; using one can itself be a signal that you're concealing something |
| Tor | Strong anonymity via thousands of volunteer relays | Slow; flagged as suspicious by many sites; doesn't protect you if you log into a personal account through it |
| Freenet | Resilient to a single node going down; cross-platform | Risk of exposure if content reaches the live internet |
| I2P | "Garlic routing" splits messages into encrypted pieces; good performance | Difficult to install; not full anonymity on indexed sites |
Good practice: connect to a VPN first, then Tor — if your ISP treats Tor traffic as suspicious, the VPN hides that you're using it at all.
A convincing persona needs real detail: name, appearance, education, job, family status, location, hobbies, political leaning, pets — enough to plausibly answer security questions like "first pet's name" if needed. For a profile photo, using a real person's photo (even stock photography) is ethically fraught when investigating dangerous people — AI-generated faces are the common alternative, though platforms increasingly detect AI artifacts (centered eyes, distortions in ears/hairline/teeth); light editing (flipping, cropping, shifting the eyes off-center) helps evade detection. Accounts need aging before use — a brand-new account with no history raises flags. Use a prepaid SIM with a factory-reset cheap phone for verification rather than a VOIP number (platforms increasingly recognize and flag VOIP numbers). Maintenance means regular login, realistic activity (friends, likes, comments on current events) at the right local hours — automation tools can maintain a "living" presence without constant manual effort.
Organizations conducting investigations (newsrooms, NGOs, corporate security teams, law enforcement) typically establish standing protocols: procedures for creating and retiring personas, secure storage of investigative material, guidance on what can be discussed externally, and incident-response plans if an investigator's cover is blown. Most OPSEC failures don't come from sophisticated adversary countermeasures — they come from simple human error: accidentally logging into a personal account, reusing a password across personas, discussing a case on an unsecured channel.
For exercise 1, the most common mistake is defaulting to maximum precaution regardless of actual risk — a low-risk internal HR case doesn't justify burner phones and VPS accounts, and recognizing that is exactly the point of doing the cost-benefit step deliberately rather than skipping straight to "more security is always better." For exercise 3, if you can't find clear documentation, that uncertainty itself is a useful and realistic finding — treat any platform where you can't confirm the answer as higher-risk by default until proven otherwise. For exercise 4, if you can only find two of the three converging signals in practice, that's a realistic and still-useful result — the exercise is about recognizing convergence when it exists, not forcing three sources onto a case that doesn't have them.