2.3 Dark Web, Tor Network, Onion Routing & Hidden Services Forensics

2.3 Dark Web, Tor Network, Onion Routing & Hidden Services Forensics

The dark web represents a complex domain of digital investigations, frequently serving as the infrastructure for illicit marketplaces, ransomware leak sites, bulletproof hosting, cyber espionage coordination, and illicit data brokerage. When threat actors operate across anonymizing overlay networks, traditional investigative methods—such as tracking source IP addresses in web server access logs or issuing subpoenas to commercial Internet Service Providers (ISPs)—fail due to layered cryptographic isolation.

Forensic investigators must understand the underlying cryptographic architecture of onion routing, how Tor establishes circuits and hidden services, what digital footprints remain on client endpoints, and the advanced traffic analysis techniques used to correlate and de-anonymize illicit activities.

---

Web Categorization: Surface, Deep, and Dark Web

Digital forensics practitioners must accurately distinguish between the three primary tiers of internet-accessible information:

+---------------------------------------------------------------------------------+
|                            THE THREE TIERS OF THE WEB                           |
+---------------------------------------------------------------------------------+
|  Surface Web (~4-5%)                                                            |
|  - Indexed by standard web crawlers (Google, Bing, DuckDuckGo)                  |
|  - Publicly accessible without authentication or specialized proxy software     |
+---------------------------------------------------------------------------------+
|  Deep Web (~90-95%)                                                             |
|  - Unindexed content behind access controls, paywalls, or dynamic forms         |
|  - Examples: Online banking portals, corporate intranets, private databases,    |
|    medical records, academic research archives, webmail repositories            |
+---------------------------------------------------------------------------------+
|  Dark Web (<1%)                                                                 |
|  - Intentionally concealed overlay networks requiring specialized software,     |
|    specific configurations, or authorization protocols to access                |
|  - Networks: The Onion Router (Tor), Invisible Internet Project (I2P), Freenet  |
+---------------------------------------------------------------------------------+

---

Tor Circuit Construction & Onion Routing Architecture

The Onion Router (Tor) is a decentralized overlay network designed to provide online anonymity by routing internet traffic through a series of volunteer-operated relays. Tor protects privacy using onion routing, where data packets are wrapped in successive layers of symmetric encryption—analogous to the layers of an onion.

The Standard Three-Hop Tor Circuit

When a client connects to an external clearnet website through Tor, the Tor client negotiates an ephemeral 3-hop circuit:

+--------------------------------------------------------------------------------+
|                           STANDARD 3-HOP TOR CIRCUIT                           |
+--------------------------------------------------------------------------------+
|                                                                                |
|   [Client]  =====(Layer 1+2+3 Encrypted)=====>  [Guard / Entry Node]           |
|   Real IP: 198.51.100.25                        Sees: Client IP (198.51.100.25)|
|                                                 Peels: Layer 1 Encryption      |
|                                                             |                  |
|                                                (Layer 2+3 Encrypted)           |
|                                                             v                  |
|                                                 [Middle Relay]                 |
|                                                 Sees: Guard IP & Exit IP       |
|                                                 Peels: Layer 2 Encryption      |
|                                                             |                  |
|                                                   (Layer 3 Encrypted)          |
|                                                             v                  |
|   [Clearnet Web Server] <====(Plaintext/TLS)==== [Exit Node]                   |
|   Sees: Exit Node IP (203.0.113.88)             Sees: Destination IP           |
|                                                 Peels: Layer 3 Encryption      |
+--------------------------------------------------------------------------------+

1. Guard / Entry Node:

   • Negotiates an ephemeral symmetric key ($K_1$) with the client via Diffie-Hellman / Curve25519.
   • Visibility: Knows the client's real IP address. Peels off the outermost encryption layer ($K_1$). Knows it is forwarding traffic to the Middle Relay.
   • Isolation: Does not know the final destination web server or the plaintext contents of the payload.
   • Guard Pinning: To defend against profiling attacks, Tor clients pin their Guard Node, using the same 1 to 2 guard nodes continuously for 2 to 3 months.

2. Middle Relay (Transit Node):

   • Negotiates key $K_2$ with the client.
   • Visibility: Knows only the IP address of the Guard Node that preceded it and the Exit Node that succeeds it. Peels off the second encryption layer ($K_2$).
   • Isolation: Has zero visibility into the client's real IP address and zero visibility into the destination IP address.

3. Exit Node:

   • Negotiates key $K_3$ with the client.
   • Visibility: Peels off the final encryption layer ($K_3$). Forwards the raw traffic to the destination server. Sees the destination IP address.
   • Isolation: Has zero visibility into the client's real IP address.
   • Forensic Implication: The target web server's access logs record the Exit Node's IP address as the client source. If the user connects to an unencrypted HTTP site, the Exit Node operator can sniff or tamper with the unencrypted traffic. If HTTPS is used, the Exit Node observes only TLS-encrypted traffic and destination SNI.

---

Tor Hidden Services (.onion Rendezvous Protocol)

Tor Onion Services (formerly Hidden Services) allow servers to provide services (web, SSH, chat) without exposing their physical location, IP address, or network topology. Onion services exist entirely inside the Tor network, eliminating exit nodes.

Version 2 vs. Version 3 Onion Addresses

• v2 Onion Addresses (Deprecated): Utilized 16-character alphanumeric strings derived from an 80-bit truncated SHA-1 hash of an RSA-1024 public key (e.g., expyuzz5wqqfdgah.onion). Deprecated due to SHA-1 collision vulnerabilities and small key sizes.
• v3 Onion Addresses (Current Standard): 56-character Base32 strings (e.g., vww6ybal4bd7szmgncyruucpgfkqahzddi37ktceo3ah7ngmcopnpyyd.onion). The address encodes the full 32-byte Ed25519 public key, a 2-byte checksum, and a 1-byte version identifier (0x03). This eliminates hash-collision attacks and descriptor enumeration.

The 6-Hop Rendezvous Protocol Execution Chain

When a Tor client connects to a v3 Onion Service, an end-to-end 6-hop circuit is established using Introduction Points and a Rendezvous Point:

1. Publishing the Service: The Onion Service creates an Ed25519 keypair and selects 3 to 5 random relays to act as its Introduction Points (IPs). It builds a 3-hop circuit to each IP. It signs an Onion Service Descriptor (containing its public key and IP addresses) and uploads it to the Hidden Service Directory (HSDir) distributed hash table.
2. Client Request: The client enters the 56-character .onion address into Tor Browser. The client queries the HSDir to retrieve the service's signed descriptor and learns the Introduction Points.
3. Rendezvous Point Selection: The client selects a random Tor relay to act as the Rendezvous Point (RP). The client builds a 3-hop circuit to the RP and sends it an encrypted one-time random token called the Rendezvous Cookie.
4. Introduction: The client builds a 3-hop circuit to one of the service's Introduction Points and transmits an Introduce Message (encrypted with the Onion Service's public key). This message contains the identity of the Rendezvous Point and the Rendezvous Cookie.
5. Service Connection to RP: The Introduction Point passes the message to the Onion Service. The service decrypts the message, extracts the RP identity and cookie, and builds its own separate 3-hop circuit to the chosen Rendezvous Point, presenting the Rendezvous Cookie.
6. Circuit Splicing: The Rendezvous Point verifies the cookie matches and splices the two 3-hop circuits together. The client and service can now communicate through an end-to-end encrypted 6-hop tunnel (Client $\leftrightarrow$ Guard $\leftrightarrow$ Middle $\leftrightarrow$ RP $\leftrightarrow$ Middle $\leftrightarrow$ Guard $\leftrightarrow$ Onion Service). Neither entity learns the other's IP address.

---

Tor Client Forensic Artifacts on Endpoints

When investigating a suspect machine, forensicators must identify artifacts proving the installation, execution, and browsing activity of the Tor Browser.

+---------------------------------------------------------------------------------+
|                        TOR CLIENT ENDPOINT ARTIFACTS                            |
+---------------------------------------------------------------------------------+
|  Volatile Memory (RAM)                                                          |
|  - Process handles: tor.exe, firefox.exe                                        |
|  - Memory-resident SOCKS5 proxy: 127.0.0.1:9150                                 |
|  - Cleartext DOM tree, active onion URLs, private keys, unencrypted form data   |
+---------------------------------------------------------------------------------+
|  Configuration & State Files                                                    |
|  - Path: Tor Browser\Browser\TorBrowser\Data\Tor\                               |
|  - torrc: Custom configuration, bridge configurations, proxy settings           |
|  - state: Persistent Guard Node fingerprints, timestamps, circuit records       |
|  - cached-consensus & cached-microdescs: Tor network consensus snapshots       |
+---------------------------------------------------------------------------------+
|  Windows OS Residual Artifacts                                                  |
|  - Prefetch: TOR.EXE-[HASH].pf, FIREFOX.EXE-[HASH].pf                           |
|  - ShellBags & LNK files: Extraction folder paths, USB execution records        |
|  - Windows Registry: Amcache.hve, UserAssist, AppCompatCache (Shimcache)       |
+---------------------------------------------------------------------------------+

1. Volatile Memory Artifacts

Tor Browser is based on Firefox Extended Support Release (ESR) running in perpetual Private Browsing mode. It disables disk-based browser caching, history writing, and persistent cookies. However, all unencrypted activity must reside in volatile memory (RAM) while the application is active:

• Memory dumps contain plaintext HTML DOM structures, visited .onion addresses, session credentials, and downloaded file buffers.
• Inspect listening network sockets: Tor binds an internal SOCKS5 proxy to 127.0.0.1:9150 (or 127.0.0.1:9050 for the standalone Tor service) and a ControlPort on 127.0.0.1:9151.
• Memory analysis via strings:

  strings -a memdump.raw | grep -iE "[a-z2-7]{56}\.onion"
  

2. Configuration & State Files

Tor Browser stores runtime state within its local data directory (...\TorBrowser\Data\Tor\):

• torrc: The primary configuration file. Details custom SOCKS ports, bridge configurations (obfs4, meek, snowflake), and entry/exit node constraints (EntryNodes, ExitNodes).
• state: A critical forensic artifact. Records the client's assigned Guard Node fingerprints, IP addresses, and the exact timestamps when they were selected and validated. This proves which specific Tor relays the suspect machine communicated with.
• cached-consensus: A signed snapshot of all active relays in the Tor network, updated hourly.

3. Windows Operating System Artifacts

Even if Tor Browser is executed from a portable USB drive, the host Windows operating system records indirect execution traces:

• Prefetch (C:\Windows\Prefetch): TOR.EXE-[HASH].pf and FIREFOX.EXE-[HASH].pf record execution timestamps, run counts, volume serial numbers, and loaded DLL paths.
• Shimcache (AppCompatCache): Stored in SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache. Confirms execution date, time, and full file path.
• Amcache (C:\Windows\appcompat\Programs\Amcache.hve): Records SHA-1 file hashes, compile timestamps, and application install metadata.
• ShellBags (UsrClass.dat): Retains folder viewing preferences, proving the user navigated into a folder named Tor Browser on a specific storage volume.

---

Traffic Analysis, Timing Correlation & De-Anonymization

While breaking Tor's multi-layered encryption mathematically is computationally infeasible, adversaries and law enforcement agencies exploit statistical, operational, and network-level vectors to de-anonymize targets.

1. Statistical Traffic Analysis & Timing Correlation

Tor is a low-latency anonymity network. Because it does not introduce artificial delays or packet padding to normalize data streams, an adversary who can monitor both the ingress traffic to the Guard Node and the egress traffic from the Exit Node can correlate flows using statistical timing analysis:

$\text{Correlation Index} = f(\Delta t_{\text{packet}}, \; \text{Burst Size}, \; \text{Data Volume})$

By matching packet arrival intervals, burst durations, and total byte volumes between the user's local ISP uplink and the destination web server, analysts can correlate a specific suspect with a target connection with greater than 95% statistical confidence.

2. Guard-Exit Node Collusion (Sybil Attack)

If an attacker operates a substantial percentage of total network relays, the probability ($P$) that a randomly generated circuit chooses both an attacker-controlled Guard Node ($G$) and an attacker-controlled Exit Node ($E$) increases:

$P(\text{Compromise}) = \left( \frac{\text{Bandwidth}_G}{\text{Total Guard Bandwidth}} \right) \times \left( \frac{\text{Bandwidth}_E}{\text{Total Exit Bandwidth}} \right)$

When this occurs, the attacker observes the user's real IP address at the Guard Node and the destination IP address at the Exit Node, defeating onion routing.

3. Server Misconfigurations (OpSec Failures)

Historically, most dark web hidden service takedowns (e.g., Silk Road, AlphaBay, Hansa) resulted from operational security errors by administrators rather than cryptographic breaks in the Tor protocol:

• Cleartext IP Leaks in Error Pages: Web applications misconfigured with Apache mod_status or PHP phpinfo() exposing the server's public IPv4 address.
• Unproxied Outbound Traffic: A web application triggering outbound connections—such as sending administrative error emails via SMTP, querying an external NTP time server, or resolving DNS records via the system resolver instead of through Tor's SOCKS proxy (127.0.0.1:9050). These outbound packets route through the server's standard default gateway, exposing its true public IP to the destination.
• TLS Certificate Fingerprinting: Utilizing the same SSL/TLS certificate on both an onion service and a publicly accessible clearnet web server. Scanning platforms like Shodan or Censys index the certificate serial number and link the .onion address directly to the clearnet IPv4 host.

[!TIP] During dark web server seizures, investigators must perform live memory acquisition prior to disconnecting power. Shutting down the machine clears RAM, destroying active LUKS or BitLocker full-disk encryption keys and wiping ephemeral Tor circuit descriptors stored in memory.