Mapping Dark Web Infrastructure

In October 2019, dark web researcher Vinny Troia uncovered an unsecured server containing of more than 4 TBytes of personal information , totaling about 1.2 billion records. The leaked data included names, phone numbers, social media profiles, work histories, and email addresses. They were traced to Google Cloud Services and linked to prominent data brokers like People Data Labs and Oxydata, despite neither party claiming responsibility for the exposure¹.

Intro to Dark Web Mapping

What is the dark web? First named in the early 2000s, the dark web is a hidden part of the internet that isn’t easily accessible and is mainly used by regular users. It is a section of the internet not indexed by standard search engines like Google and can only be reached through specialized tools like Tor (The Onion Router), I2P, or Freenet. Unlike the Deep Web – which includes legal, unindexed resources like medical databases, academic journals, or corporate intranets—the dark web primarily relies on encryption. It hosts encrypted hidden services, with routing masked to hide both the operators’ identities and the servers’ locations.

The services hidden by Tor use the .onion domain suffix, which operates through multilayered encryption and relay nodes. This makes traffic analysis and endpoint identification difficult. These services are primarily used to host forums, communication hubs, and illicit marketplaces, as they are difficult to track. However, they also support legal and legitimate use cases like privacy activism, secure whistleblowing, and journalism. Tor can be used by anyone with the Tor Browser.

Tor was first released in 2002 (v.01), and the Tor hidden services were introduced in Tor v0.2x around 2004. Version 3, or the next gen onion services with 56 – character addresses, was introduced in 2018, and the current Tor version is 0.4.8.17. Tor circuits are built using an incremental (telescoping) path – building design. This process involves the initiator negotiating independent session keys with each hop, ensuring perfect forward secrecy (PFS). Even if an intermediary key is compromised, previously transmitted data remains secure².

Why Mapping Matters for Security

Mapping dark web infrastructure involves the process of discovering and analyzing the technical backend that supports hidden services such as marketplaces, forums, or ransomware leak portals, without directly interacting with them. Mapping primarily focuses on servers, domains, and technical fingerprints that help us access these sites.

The dark web operates on anonymity, but for security or threat teams, this very anonymity creates a critical blind spot.

For Threat Intelligence (TI) teams, mapping dark web infrastructure gives them critical visibility in:

• Threat actor ecosystems Dark web marketplaces, leak portals, and forums are the hubs of dark web crimes. By mapping these infrastructures, threat intelligence teams can track where different actors involved in crime are engaged, including gathering, trading, and communicating. Mapping helps authorities create an ecosystem view of these actors to identify connections that might otherwise seem unrelated.

• Infrastructure Overlapping Not all actors are geniuses; some are beginners trying to make quick money. Despite the anonymity TOR provides, operators often reuse elements of their setup — such as a hosting server, a domain pattern, or a misconfigured certificate. TI teams identify these overlaps, which can link the hidden services to each other and sometimes even to clearnet resources. Booletprof hosting is used as infrastructure for multiple dark websites. It is a technical hosting service that remains unaffected by complaints about illegal activities, serving as a basic building block for running dark websites and cyberattacks³.

• Early warnings Monitoring provides organizations with an early warning system that helps defend against cyber threats. By tracking forums, marketplaces, and leak sites, security teams can identify the sale of exploits, compromised assets, and even discussions of planned attacks before they happen. For example, the Medusa ransomware group lists victims on its Tor-based leak sites, offering immediate visibility into data exposure. When such findings are combined with other threat intelligence feeds, analysts can distinguish background noise from genuine threats and improve their defensive strategies⁴.

Understanding Hidden Services & Hosting Servers

Unlike surface web websites that rely on DNS resolution, Onion services are resolved through Tor’s distributed hash table (DHT) system and function only within the Tor overlay. This design conceals both the server’s IP address and the client’s identity through multiple layers of encryption and onion routing.

Onion services enable users to set up their sites and other services without revealing their location, using onion routing instead of IP addresses. Onion services utilize onion addresses derived from the service’s cryptographic key, making them self-authenticating⁵.

Before a user can access a hidden service, the client first constructs a circuit to a randomly chosen Tor node, known as the rendezvous point. At this stage, the client sends an ESTABLISH_RENDEZVOUS cell to designate it as the meeting place. Then, the hidden service also builds its own circuit to the same node and sends a rendezvous cell. After both sides are present, the relay forwards the cell to the client and joins the two circuits together. We can say that the rendezvous point acts as a neural middleman linking both circuits without exposing the IP address of either⁶.

To complete a rendezvous, the hidden service host builds a circuit to the rendezvous point and sends a RENDEZVOUS1 cell containing:

RENDEZVOUS_COOKIE [20 bytes] HANDSHAKE_INFO [variable; depends on handshake type used.]

Once the client receives the RENDEZVOUS2 cell, it verifies that HANDSHAKE_INFO properly completes a handshake. To do this, the client parses SERVER_PK from HANDSHAKE_INFO and reverses the final operations of the section.

rend_secret_hs_input = EXP(Y,x) | EXP(B,x) | AUTH_KEY | B | X | Y | PROTOID NTOR_KEY_SEED = MAC(ntor_secret_input, t_hsenc) verify = MAC(ntor_secret_input, t_hsverify) auth_input = verify | AUTH_KEY | B | Y | X | PROTOID | "Server" AUTH_INPUT_MAC = MAC(auth_input, t_hsmac)

How Hosting Servers Support Dark Web Sites

Even though hidden services mask these server locations, the physical infrastructure of these services must exist somewhere, and many dark web operators use bulletproof hosting (BPH) providers. These providers do not care about complaints or the law.

Here are two related cases:

• Example 1: In 2019, Dutch police took down the bulletproof hosting provider KV Solutions BV, which had been hosting a Mirai (IoT-based) Botnet for several years. The operation resulted in the seizure of several servers and the arrest of two Dutch nationals involved in running the botnet.

“The authorities also arrested two Dutch nationals who had been running a Mirai botnet from the servers of KV Solutions BV (KV hereinafter) bulletproof hosting service.”
— SecurityAffairs, 2019⁷

• Example 2: In 2025, Dutch police carried out another major operation against Zservers/XHost, which was also a bulletproof hosting provider. The number of servers seized exceeded 120, used to host ransomware, botnets, and other malicious software, such as tools like Conti and Lockbit.

“The hosting company was called ZServers/XHost… During the raid, 127 servers were taken offline and seized by police officers… The investigation revealed that these servers contained ransomware, botnets, and other malicious software, including hacking tools from two infamous ransomware operations: Conti and LockBit.”
— Cybernews, 2025⁸

Risks Tied to These Infrastructures

Misconfiguration, attempts to outsmart law enforcement, and depending only on central servers can cause problems. These issues might lead to servers being taken down, identities being exposed, or services being interrupted.

1. Operational Security Failures
   Hidden services are only strong as their configurations. Misconfiguration can lead to reveal of real world IPs and other metadata which a analyst can exploit

   Example: In 2017, a hacker breached Freedom Hosting II, a major Tor-based hosting provider. The hacker found that many of its hosted sites contained illegal content. The attacker claimed to have discovered that 50% of the hosted sites were involved in illegal activities, and this breach led to the takedown of more than 10,000 dark web sites and the exposure of sensitive user data, such as email addresses, some of which were government-affiliated. This incident highlighted vulnerabilities in the security of dark web hosting services⁹.

2. Single Points of Failure
   Centralized bulletproof hosts have a critical vulnerability. If the hosts are seized, all hosted dark web services and sites go offline, making it easy to trace the operators. After seizing the physical servers, authorities can disrupt multiple illegal sites.

   Example: In 2019, German police seized CyberBunker, a hosting provider operating in an old NATO bunker that supported dozens of dark web markets, including Wall Street Market (a leading darknet drug marketplace at the time).¹⁰

How Hidden Services Leak Hosting Clues

While Tor’s onion services are designed to hide IP addresses and hosting details, operational mistakes and leftover metadata often cause issues. This usually happens because of misconfigurations and protocol-level metadata artifacts. These leaks are often revealed through the HTTP host header, Apache vhost directives, or reused certificates.

Clearnet Dependencies and HTTP Metadata

Many hidden services accidentally link to resources on the clearnet, such as fonts, analytics scripts, or image files. Each of these resource requests occurs through Tor, carrying metadata like the destination, IP address, handshake details, and timing information. Even if the content is encrypted, traffic patterns can help analysts connect a hidden service to a real-world server.

Headers like Server, X-Powered-By, and caching directives can also leak significant information about the web server’s software and configuration. For example, a unique server header can serve as a fingerprint for a specific hosting setup.

Request URI: http://www.example.com

HTTP/1.1 200 OK
Content-Encoding: gzip
Age: 521648
Cache-Control: max-age=604800
Content-Type: text/html; charset=UTF-8
Date: Fri, 06 Mar 2020 17:36:11 GMT
Etag: "3147526947+gzip"
Expires: Fri, 13 Mar 2020 17:36:11 GMT
Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
Server: ECS (dcb/7EC9)
Vary: Accept-Encoding
X-Cache: HIT
Content-Length: 648

Exploitation Techniques

• HTTP Header Fingerprinting: Compare headers (Server, X-Powered-By, X-Cache) with known clearnet server fingerprints to identify hosting infrastructure.
  Tools: Netlas, WhatWeb, Wappalyzer, custom Python scripts.

• Resource Request Analysis: Track clearnet resources loaded by a hidden service (images, fonts, scripts) to infer hosting patterns.
  Tools: Tor Browser network monitor, OnionScan, mitmproxy.

• Metadata Extraction from Files: Extract embedded identifiers or geolocation from images, PDFs, or DOCs.
  Tools: exiftool, pdf-parser

• Favicon / Asset Hashing: Compare hashes of favicons, scripts, or images between onion and clearnet sites to find matches.
  Tools: ssdeep, tlsh, Netlas favicon search.

• TORhunter: It uses traffic asymmetry and path selection to deanonymize hidden services by automating scanning, brute forcing, and metadata collection at endpoints.
  Tools: Torhunter

Example

In the Silk Road takedown (2013), the hidden marketplace’s login page had an embedded CAPTCHA that relied directly on a clearnet service. Because of this dependence on the surface web, some HTTP requests from users exposed the site’s real IP address in response headers instead of routing entirely through Tor. Investigators entered that IP into a regular browser and accessed the Silk Road login page, confirming the real hosting server¹¹.

Shared Hosting and Cryptographic Fingerprints

Operators often host multiple services on the same VPS or dedicated servers, which creates opportunities for correlation and deanonymization.

1. IP Reuse Hosting an onion service alongside surface web sites on the same IP or subnet can reveal a link between both of those sites. Even if the onion service is anonymous, specialized external observers can connect them with other hosted services using public data resources like Netlas

2. TLS Fingerprinting The TLS handshake reveals subtle server details like the order of cipher suites, supported extensions, and protocol options. These patterns can act as a cryptographic fingerprint, uniquely identifying a server across different services.

3. SSH and TLS Keys Every TLS or SSH service has a public cryptographic key during the handshake, such as SHA-256, which is a hash of the server’s RSA/Ed25519 key. If the same keypair is reused across multiple endpoints, like for an onion service and a surface web host, these fingerprints become a global identifier. Even with IP rotation, the certificates’ subjectPublicKeyInfo (TLS) or host key exchange (SSH) remains the same, allowing these services to be linked to the same machine.

Exploitation Techniques

Investigators can exploit these fingerprints to deanonymize and correlate multiple services:

• Passive scanning of public endpoints using ZGrab, masscan, nmap.
• Parsing Certificate Transparency logs with crt.sh, CertStream, or custom Python scripts to track reused TLS certificates.
• Collecting SSH fingerprints via ssh-keyscan or paramiko scripting.
• TLS fingerprinting using OpenSSL s_client or dedicated TLS-fingerprinter libraries.
• Automated correlation scripts to match TLS/SSH keys and fingerprint metadata across services.

Example

The CARNOTE project (CCS 2015) actively collected internet endpoints and extracted unique strings from onion service content and certificate chains. Using TLS and SSH fingerprints, CARNOTE successfully exposed hosting IPs, co-located services, and physical server locations, demonstrating how cryptographic fingerprints can be leveraged to deanonymize hidden services¹².

Recommended Reading

Proactive Threat Hunting: Techniques to Identify Malicious Infrastructure

Geolocation Leaks and Descriptor Timing

Even without IP address disclosure, onion services can sometimes leak information through network-level and application-level metadata.

1. Descriptor upload patterns Each onion service regularly uploads signed service descriptors to hidden service directories (HSDirs). The timing and pattern of the descriptor uploads can reveal geographic information. Not exact data, but it can indicate the time zones of the administrators or the specific zone they’re in.
2. Application-layer Metadata Sometimes, content uploaded to a dark website can reveal geographic information through default time zone headers in web pages, language or locale settings in HTTP headers, and references to Regional CDNs or third-party resources.

Exploitation Techniques

Attackers exploit these leaks using circuit timing and latency analysis. The main technique is the Sniper exploit path, operationalized by tools like HSDirSniper:

• Probe injection – Repeatedly build circuits to the same hidden service and inject controlled traffic bursts.
• Asymmetric path exploitation – Correlate entry guard identities across multiple attempts.
• Circuit congestion analysis – Send high-rate probes (padding vs bursts) to observe congestion fingerprints tied to specific relays.
• Deanonymization step – Combine timing signals with BGP-level observations or malicious relay activity to infer the hidden service’s real IP.

Example

In 2016, researcher Jose Carlos Norte identified an issue in onion services using HTTP GZIP compression headers. These headers include a compression date field, which some servers fill with local time instead of UTC. Norte tested real .onion sites and discovered leaks, such as the one dated Thu, 22 Aug 2016 14:00:00 PST. His PHP script extracted these timestamps and demonstrated that a time zone leak occurred in about 10% of the tested servers¹³.

Timezone Map

These hosting and metadata leaks show that onion services, although designed to be cryptographically anonymous, can still expose their infrastructure through side channels. Investigators analyze these weak signals to create a “fingerprint” that can identify the hosting provider and help locate the administrator.

Operational Mistake Exploitation

Hidden services often accidentally expose surface web artifacts, including misconfigured services, forgotten directories, debug endpoints, and metadata files. These bypass Tor’s anonymity because the application stack – like web servers, CMS, and file servers –remains vulnerable to operator mistakes.

Exploitation Techniques

1. Virtual host misconfiguration: Hidden services may answer requests sent with arbitrary HOST: headers. If the server also hosts a clearnet site, probing with controlled headers can elicit responses that reveal the true domain or IP.
2. Exposed Admin Interfaces: Apache /server-status, Nginx stubs, phpMyAdmin, or forgotten WordPress panels often run in parallel to onion sites. Investigators can map these to public-facing admin pages.
3. Backend Service Leakage: Banner grabbing against accidentally exposed services like FTP, SMTP, JSON-RPC can yield real hostnames or IPs. Investigators then pivot to surface web using tools like Netlas to locate same banners on the internet.
4. Tor-aware Crawling: Recursive enumeration with ahmia, OnionScan, and custom crawlers.
5. Host Header Injection: Testing server responses to mismatched Host: values to detect virtual host overlap.
6. Metadata Extraction: exiftool, strings, and PDF/DOC parsers to extract identifying metadata.

Example

In 2012 , the FBI conducted Operation Torpedo, they deployed malware known as Network Investigate Technique (NIT) . It identified users accessing tor hidden child abuse sites. The malware was delivered by drive-by downloads when users visited certain websites. This operation led to identification of several individuals .The operation highlighted how misconfigurations or vulnerabilities in hidden services can be exploited¹⁴.

Case Study – Demise of AlphaBay and Hansa Market

The rise and fall of dark web marketplaces like AlphaBay and Hansa marked a turning point in global cybercrime investigations. Both platforms thrived on the anonymity of the Tor network, enabling the trade of narcotics, malware, counterfeit documents, and other illicit goods at massive scale. However, despite their technological sophistication, both marketplaces were ultimately dismantled due to critical operational security failures and coordinated law enforcement actions.

AlphaBay

AlphaBay was a well-known dark web marketplace primarily involved in trading illicit goods and services. Despite operating within the anonymity provided by the Tor network, several failures in operational security and public data leaks led to the shutdown of AlphaBay.

AlphaBay’s downfall was not caused by a single fatal error but resulted from an accumulation of operational security leaks across multiple layers.

Email leakage

The first mistake occurred when the administrator Alpha02 reused the email address [email protected] during the setup of a marketplace and in automated emails. The Hotmail address was already linked to his LinkedIn, PayPal, merchant logs, and WHOIS records. Investigators obtained a definitive, searchable clue to the real-world identity of the Alpha02 user as Alexandre Cazes.

Handle Reuse

Alias Alpha02 appeared earlier in carding forums like Evolution and CardersMarket. This connection allowed investigators to link datasets that revealed past activity under the same name. They could now associate activity through account clustering and by analyzing linguistic fingerprints such as writing style and vocabulary, known as stylometry.

Infrastructure Trails

AlphaBay servers occasionally leaked backend fingerprints, such as misconfigured TLS certificates and mail headers, exposing surface web IPs. By continuously monitoring AlphaBay’s Tor hidden services, investigators identified instances of server-side misconfigurations where backend IPs leaked in error responses. These misconfigurations were cross-referenced against passive DNS databases, which provided a partial map of the infrastructure cluster, ultimately revealing servers connected to AlphaBay.

Laptop Exposure

At the time of Alexandre Cazes’s arrest in Thailand, Cazes’ laptop was still logged into both the AlphaBay admin panel and related cryptocurrency wallets. This enabled live forensic extraction of credentials, databases, and private keys without needing to bypass any disk encryption. Investigators used tools such as FTK Imager and Volatility to dump system memory and capture active sessions, including Bitcoin wallet seeds and PGP private keys.

Recommended Reading

Modern Cybercrime: Who’s Behind It and Who’s Stopping It

The Hansa Market Shutdown

Hansa Market was a dark web marketplace launched in 2015. It was believed to be a successor to earlier sites like the Silk Road and Evolution. It specialized in illegal goods, mainly narcotics, counterfeit documents, and malware kits. Hansa gained popularity for its multisig escrow system, mandatory PGP encryption, and low commission rates compared to other sites. At its peak, it was considered one of the top three darknet markets by transaction volume.

Unlike AlphaBay, Hansa’s downfall resulted from an extensive infiltration in June 2017 during Operation Bayonet, executed by Europol and the FBI in partnership with Dutch authorities. By operating the site for several weeks to collect intelligence, they turned the active marketplace into an information-gathering tool, akin to a controlled honeypot, before ultimately shutting it down¹⁵.

The Investigation

1. A security firm discovered a Hansa staging server that was accessible on the public internet in a Netherlands data center. Later, they reported the IP to the authorities (NHTCU). The server was not hidden or operated via Tor; it contained code, configs, and backups linking to a Tor frontend. The server was used for testing new features before deploying them on the live Hansa market site.
2. Dutch police contacted the hosting provider, installed monitoring on the data center connection, and observed that the staging server connected to a Tor-protected server, which was the server hosting Hansa’s live site.
3. Authorities made bit-for-bit copies of the Netherlands servers, linked the Hansa servers, and extracted transaction logs, user messages, and admin chat logs. On the German server hosting Hansa, they found long IRC transcripts containing admin names, crypto addresses, and a home address.
4. In April 2017, after a setback, the police made a big breakthrough. Using Chainanalysis, police traced a payment from the address mentioned in IRC transcripts to an office in the Netherlands, which led to the discovery of other Hansa servers.
5. In June 2017, German police arrested the two alleged Hansa admins and seized their unencrypted laptops, which contained admin credentials. Then, the Dutch police used those credentials to migrate Hansa’s data to police-controlled servers in the Netherlands and took administrative control of the Hansa site.

Covert Backend Instrumentation

While operating Hansa, authorities modified the Hansa site’s backend, enabling them to collect a vast amount of surveillance information. The changes the authorities made were:

• changed the way the passwords stored , from highly encrypted to plain text passwords
• they altered PGP wrapping so text messages were recorded before encryption
• they preserved EXIF metadata on uploads, to pull geolocation
• stage reupload event (like a glitch) to force sellers to re submit images

These changes in the backend provided authorities with users’ shipping addresses, message plain text, and geolocation metadata.

Beacon Bait

Investigators replaced a small “backup key” file offered to sellers with a crafted Excel file. This Excel file, when opened by sellers on a non-TOR device, caused their client to send an outbound request to an LE-controlled endpoint, helping the police to capture the sellers’ public IPs. Sixty-four sellers were identified using the Beacon bait.

Outcomes of Covert Control

Hansa market website was operated by the police for 27 days, recording 1000 transactions daily. Authorities collected data on 420,000 users, including 10,000 postal addresses, and seized up to 1,200 BTC¹⁶.

Public Seizure

After 27 days, the covert collection period ended, and Dutch police shut down Hansa and posted a seizure notice on the Tor site. The collected intelligence was forwarded to Europol and the FBI for arrests and referrals.

Ethical & Legal Guardrails in Dark Web Mapping

Mapping hidden services and investigating dark web infrastructure can be valuable for threat intelligence, but it must be guided by clear ethical and legal frameworks to prevent crossing into illegal conduct.

Traffic correlation attacks involve monitoring entry and exit traffic on the Tor network to deanonymize users, as in the Hansa Market case. Such surveillance requires warrants, as unauthorized monitoring may violate laws. Investigators can also exploit misconfigured hidden services leaking metadata, but unauthorized scanning could violate the CFAA. Cryptocurrency tracing, linking Bitcoin or Monero transactions through blockchain analytics like Chainalysis, provides attribution but needs exchange cooperation and legal subpoenas.

Chris Monterio’s story effectively illustrates why you need to be cautious with any kind of investigation.

Chris Monterio, a cybersecurity researcher, discovered a dark web hitman-for-hire site called Besa Mafia. The site listed potential targets for murder and other violent crimes. Trying to do the right thing and stop the crimes, Monterio accessed the site’s private data to see who the targets were.

Monteiro exploited a security vulnerability on the Besa Mafia site and accessed its database. He collected sensitive user information from the site and all the target lists. To investigate further, he also created a fake hitman profile to interact and gather more intelligence.

His main mistake was that he lacked any legal warrant or authorization to access the private site, even though his intentions were good, technically, what he was doing was considered a crime under computer misuse laws.

Monteiro was not criminally punished during the investigation but was arrested on charges of incitement to murder based on misinformation spread by Yura. His creation of a fake profile as a hitman and investigating a dark web site without a warrant led to the arrest, but the charges were later dropped¹⁷.

Conclusion

The dark web is a double-edged sword: it is a vital space for privacy, whistleblowing, and free expression, but at the same time, it is also a hub for illicit marketplaces, ransomware operations, and cybercrime. Mapping its hidden infrastructure offers critical insights for threat intelligence teams; it helps them track the criminal ecosystem and identify vulnerabilities in hosting setups.

In the cases of AlphaBay, Hansa, and Freedom Hosting, even small operational mistakes like misconfigured servers, reused cryptographic keys, or exposed metadata led to the fall of those services. For investigators, these opportunities come with legal and ethical responsibilities. All these techniques can yield actionable intelligence, but without proper authorization, such actions quickly enter criminal territory.

The dark web’s cryptographic and operational protections are complex but not foolproof. Mapping and monitoring enable investigators to uncover infrastructure overlaps, track threat actors, and receive early warnings of upcoming cyber threats.

I can show you how deep the Internet really goes

Discover exposed assets, infrastructure links, and threat surfaces across the global Internet.

Request Free Trial Explore Free Plan