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: keep the subject from learning an investigation exists, and keep yourself, your organization, and your sources unexposed while you do it.
When OPSEC fails, a subject may spot unusual attention (a profile view, an odd new follower) 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 sink an entire case: once a target realizes that law enforcement or a journalist is on them, they can retain a lawyer, warn their associates, or come after you legally.
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 severe would the fallout be? A useful framework asks: who is the subject and what resources can they bring to bear (a technically unsophisticated individual presents a very different kind of risk from 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 over the whole life of an investigation, not only at kickoff. New information (learning that a subject is technically sophisticated, or has a support network) should prompt 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. That is 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, where the target discovers your actual identity, opening the door to retaliation.
Exposure actually happens in several ways. Digital fingerprints and metadata are one: a screenshot with embedded GPS, or a document with your real author name. Account and infrastructure reuse is another, such as logging into a personal account on the same browser used for investigative work, or reusing a phone number across personas. Behavioral patterns can give you away too, such as a sock puppet active only during your employer's business hours in a specific timezone. Platform notifications matter as well, including profile-view alerts and story-viewer lists. And a reverse image search on your own sock puppet's photo can expose it: 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 shows a scenario where a VM offers zero protection: the attack targets the device itself, not your browsing data. In the 2013 case, Jared Abrahams hijacked webcams of several young women, including Miss Teen USA Cassidy Wolf, to extort them. 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 among the most basic (and most often violated) OPSEC practices. The principle: investigative activity must never share a browser, a session, or an account ecosystem with your personal digital life. Modern browsers and platforms are engineered to recognize users and tie their sessions together: 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, one autofill suggestion or leftover cookie can weld the two identities together in a platform's backend, even if you never consciously "connect" them yourself.
Layers of separation, from lightest to heaviest, look like this. Browser-level separation means separate browser profiles at minimum, ideally entirely different browser applications for personal vs. investigative use. Session isolation means never staying logged into multiple personas at once, and fully logging out rather than just closing the tab. Device-level separation means a dedicated investigation machine or VM for higher-risk work, configured with its own distinct fingerprint, differing in timezone, language, and resolution, from your real device. Account-level separation means a dedicated email, phone number, and unique non-reused password per persona, since password reuse is especially dangerous: one breached account can expose every other account sharing that password. Network-level separation means 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 violations of this discipline aren't dramatic. They're minor conveniences: a quick personal email check mid-session, an autofill that drops your personal address into a sock puppet's profile, or a familiar username or writing style reused between 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 kind of risk slips past people because it stays invisible in normal use: a file looks identical whether or not it carries hidden data. That makes it one of the most common "silent" OPSEC failures. It trips up even seasoned investigators who are otherwise disciplined 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, given that many notification features fire only 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 means avoiding liking, commenting, following, or any other engagement with a subject's content, unless that engagement is a deliberate, weighed decision rather than an accidental click. A single stray "like" on an old post can signal to a subject that someone unusual is digging 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 (produced automatically as a by-product of activity, usually without the person knowing: page-view logs, referrer headers, watch notifications). Investigators read the two together: the active footprint shows who someone wants to look like; the passive one shows what they really did. 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. That is 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 they also hand information about observers back to the people being observed. Anyone 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, and the location estimate could be imprecise. But the combination is telling: a referrer tied to a specific named profile, arriving at a time inconsistent with the claimed location, and repeating across more than one visit. That combination 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, such as centered eyes or distortions in the ears, hairline, or teeth. Light editing, such as flipping, cropping, or 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 covering how personas are created and retired, secure storage of investigative material, guidance about what may be discussed outside the team, and an incident-response plan for when an investigator's cover gets 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.