Surface, deep, and dark web distinctions, safe access, and what's actually there.
The "dark web" gets more mystique than it deserves in popular coverage, and less rigor than it needs in practitioner training. This chapter treats it as what it actually is for an OSINT investigator: one more layer of the internet with its own access requirements, its own risks, and its own investigative value — not a separate universe with different rules of ethics or legality.
The surface web is what search engines index — the part covered in Chapters 3 and 6. The deep web is everything not indexed by ordinary search engines: paywalled content, private databases, content behind a login, internal company systems, academic journal archives. Most of the deep web is completely mundane — your online banking portal is "deep web" in this technical sense — and needs no special tooling beyond knowing where to look and, where appropriate, having lawful access.
The dark web is the much smaller subset that requires specific software to reach at all, because it runs on an overlay network rather than the ordinary DNS/HTTP stack. Tor (The Onion Router) is the dominant one — sites there use .onion addresses, reachable only through the Tor Browser or a Tor-aware client. I2P and Freenet are smaller alternatives with their own address schemes and communities (see Chapter 14 for how each actually works under the hood).
Despite the reputation, dark web investigation is a fairly narrow specialty within OSINT, useful for a specific set of questions: has a company's data appeared in a breach dump or a ransomware leak site? Is a stolen credential set or a piece of intellectual property being sold on a marketplace? Are threat actors discussing a specific target on a forum? Is a extremist or criminal network coordinating there? For the vast majority of OSINT work — identity verification, corporate due diligence, geolocation — you will never need to touch it at all, and reaching for it reflexively is usually a sign of chasing novelty rather than following the evidence.
The Tor Browser is the standard, free way in — it's a hardened Firefox build pre-configured to route traffic through the Tor network, with the fingerprinting-resistance settings already tuned. Never use a "regular" browser with a Tor proxy bolted on unless you specifically understand the tradeoffs — you lose most of the anti-fingerprinting protection the dedicated browser provides.
Before you go anywhere near a marketplace or forum: this should only ever be done from a dedicated, disposable investigation environment — a virtual machine you're prepared to wipe, never your daily machine, never logged into any personal account, ideally with a VPN feeding into Tor for an added layer (see Chapter 14 for the full OPSEC build-out). Assume every page you visit could be hostile: dark web forums are a favorite place to plant malware, browser exploits, and de-anonymization traps aimed specifically at researchers and law enforcement. Never enable JavaScript on the Tor Browser's default security settings unless you have a specific, understood reason to.
Marketplaces sell everything from stolen credit card data to drugs to counterfeit documents, generally paid for in cryptocurrency (see Chapter 10 for how to actually trace those payments). Ransomware leak sites — a relatively recent and, for corporate investigators, often more directly relevant category — are where ransomware gangs publish stolen data from victims who refuse to pay, frequently with a countdown timer and sample files as proof; these are usually reachable via Tor and are a legitimate, high-value source for confirming whether a specific breach actually happened and what was taken. Forums host discussion among cybercriminals, extremist groups, and hacktivist communities — often the best source for understanding motive and capability, not just artifacts. Paste sites and leak aggregators (some on the surface web, some not) are where dumped credentials and databases frequently surface first.
Dark web content is not indexed by Google — you need dedicated search engines (Ahmia and similar Tor-specific search tools) or, more reliably, purpose-built breach-and-leak monitoring services that continuously crawl marketplaces, forums, and paste sites and let you search by domain, email, or keyword without you personally visiting the raw site. For a company doing brand/breach monitoring, a subscription monitoring service is almost always the safer and more efficient choice over manual browsing — it removes the exposure risk of researchers visiting hostile infrastructure directly, and it catches mentions faster than any human could browse for them.
When you do need to search manually: treat every claimed data sample the same way you'd treat any unverified claim in Chapter 2's methodology — a "proof" screenshot of stolen data proves nothing about scale, freshness, or even whether the seller actually possesses what they claim. Cross-reference any sample against what's publicly known about the alleged victim, and never pay for or download bulk data — searching and viewing samples for verification purposes sits differently, legally and ethically, than acquiring the full stolen dataset (see Chapter 1's legal framework on hacked/leaked data).
Everything from Chapter 1 applies with extra weight here. Viewing publicly reachable content on a Tor site is generally the same legal category as viewing any other public content. Purchasing anything, even "just to verify," usually crosses into participating in a criminal marketplace. Downloading bulk stolen datasets — even for research — carries real legal risk in most jurisdictions, distinct from merely confirming a sample exists. If your work touches this space professionally, loop in legal counsel before establishing any kind of standing access or purchasing relationship, and keep a clear, written record of why each access was necessary and proportionate.
Section 8.5 mentioned purpose-built monitoring services as the safer alternative to manual browsing. For anyone who wants to understand — or build a lightweight version of — what those services actually do under the hood, a workable automated dark-web monitoring approach breaks into three layers: an anonymized connection layer, a detection layer, and an alerting layer.
On the connection side, one specific technical detail matters more than it sounds like it should: use a SOCKS5h proxy rather than plain SOCKS5 when routing through Tor. The trailing "h" means DNS resolution happens at the Tor exit node rather than on your own machine — plain SOCKS5 can leave your DNS queries visible outside the Tor tunnel even while the rest of your traffic is anonymized, which defeats much of the point. A monitoring script that queries many sites in sequence should also periodically request a fresh Tor circuit (Tor's control protocol supports this directly) rather than reusing one identity for an entire run — a long, stable pattern of requests from the same circuit is exactly the kind of signature anti-scraping defenses are built to catch.
On the detection side, plain keyword matching is fast but crude: a hit on a word like "leaked" or "credentials" doesn't distinguish an actual breach listing from an unrelated security discussion that happens to use the same words. Two refinements help substantially: tiering keywords by severity — a hit on something like "database dump" or a specific document type warrants immediate attention, while a hit on a vaguer word like "hacked" alone can wait for batch review — and capturing a short surrounding text snippet with every match, so a human reviewer can judge context immediately without revisiting the source page. In practice, the majority of false positives in this kind of system tend to come specifically from educational or discussion content that happens to contain a high-risk keyword — exactly the gap plain keyword matching can't close on its own, and the reason any automated flag here is a lead for a human to triage (Chapter 2's Admiralty Code discipline again), never a verdict on its own.
On the alerting side, the goal is minimizing the delay between detection and human review: route a match into a persistent log (a simple local database is enough for personal or small-scale use) and a push notification, rather than only a static report someone has to remember to check.
A few well-documented dark web law enforcement operations illustrate methods and pitfalls beyond the "textbook" description of how these investigations work.
The first major dark web marketplace was eventually traced back to its operator not through any flaw in Tor itself, but through a single early operational security mistake: a forum post seeking technical help was made under something close to a real identity before its author switched to a pseudonym, and the two were later connected. This generalizes well beyond one case — a single lapse early in a long-running operation can undo years of otherwise careful anonymity, which is exactly why an investigator building a timeline on a subject should specifically look for their earliest, least-careful posts rather than assuming later, more guarded behavior is representative of the whole history.
A separate, instructive case is what happens when one marketplace's takedown is used to compromise a second one. When the largest dark web marketplace at the time was taken offline, law enforcement had already covertly taken control of a smaller marketplace and quietly kept it running under their control for several weeks — deliberately capturing the wave of displaced vendors and buyers migrating there, along with their communications and transaction data, before shutting that one down too. The generalizable caution: an active, apparently-functioning marketplace or forum is never proof that it isn't already compromised or run by an investigating authority. Evaluate content on its own merits, not on the assumption that a platform's continued operation vouches for its legitimacy.
For monitoring your own organization's exposure specifically, without any paid subscription, Have I Been Pwned is a free, well-established service that lets anyone check whether an email address or domain has appeared in a known public breach — a genuinely useful, no-cost first check before reaching for a paid monitoring service (§8.5).
For exercise 2, look specifically for the verification step — professional reporting on ransomware leaks nearly always mentions the outlet or researcher cross-checking a sample against known internal details (employee names, specific project codenames) rather than taking the gang's claim at face value. That verification instinct is the whole point of this chapter: dark web content should be treated with the same skepticism as any other unverified source, not more credulously just because it feels "insider." For exercise 4, a "no match" result is a genuinely useful negative finding, not a failed exercise — it tells you the address hasn't appeared in any breach a service like this has indexed, which is itself worth recording.