Threat Hunting Exercise: Analyzing Firewall TOR Exit Node Outbound Connection Dataset
This hunt uses a simulated perimeter firewall dataset (firewall_tor_exit_2022-10-17T220000.json) capturing T1090.003: Proxy (Multi-hop Proxy / TOR), where an internal host establishes outbound connections to known TOR entry/guard nodes, either as an attacker's anonymized C2 channel or as a compromised host being used to relay traffic for the attacker.
Step 1: Hypothesis Formation
Hypothesis: An internal host establishes repeated, sustained outbound TCP connections to IP addresses on the public TOR node consensus list (guard/relay nodes), on ports commonly associated with TOR (9001, 9030, 443) with connection patterns (periodic, low-and-slow) inconsistent with normal web browsing - indicating either direct attacker TOR-based C2 usage or unauthorized TOR client installation. Indicators:
- Destination IP matches the current published TOR relay/guard node consensus list.
- Connection pattern shows periodic beaconing (regular intervals) rather than the bursty, session-based pattern of normal browsing.
- Local process associated with the connection is
tor.exe/toror an unrecognized binary rather than a standard browser. - No corresponding proxy/browser TOR usage policy exception exists for the host or user.
Null Hypothesis: A security researcher or privacy-conscious employee has installed the TOR Browser for legitimate, policy-permitted anonymized browsing (e.g., competitive intelligence research). Invalidate by confirming the process is the TOR Browser Bundle used interactively during business hours and cross-checking against any documented exception.
Rationale: TOR provides attackers with a resilient, encrypted, attribution-resistant C2 and exfiltration channel; because TOR node IPs are less well policy-restricted than obviously malicious IOCs, and legitimate uses do exist, distinguishing automated/beaconing usage from interactive human browsing is the key differentiator.
Step 2: Data Sources and Scope
- Sources: Perimeter firewall logs with destination IP; TOR consensus node list (updated feed); endpoint process telemetry for the connecting process.
- Scope: ~2022-10-17T22:00:00-23:30:00 UTC; Host: SRV-BUILD-06 (10.55.9.14, a CI/CD build server - no legitimate interactive browsing use case); Multiple TOR guard-node destinations.
- SIEM Queries (Splunk/ELK):
index=firewall | lookup tor_consensus_nodes dest_ip OUTPUT is_tor_node | where is_tor_node=true- Beaconing pattern:
index=firewall dest_ip=tor_node_ip | stats count, stdev(_time) as jitter by src_ip, dest_ip - Process correlation:
index=edr host="SRV-BUILD-06" network_connection=true dest_port IN (9001,9030,443)
Step 3: Key Findings
Parsed events (5 shown) confirm SRV-BUILD-06 - a headless CI/CD build server with no legitimate browsing use case - established periodic, low-jitter outbound connections to five distinct TOR guard nodes over 90 minutes, driven by an unrecognized binary.
| Timestamp (UTC) | Host | Event | Detail | IOC/Why Suspicious? |
|---|---|---|---|---|
| 2022-10-17 22:02:11 | SRV-BUILD-06 | Firewall (allow, TCP/9001) | Connection to 51.15.43.205, matched against TOR consensus list as an active guard node | TOR-Node IOC: the destination is confirmed present in the current published TOR relay consensus, not a coincidental IP match. |
| 2022-10-17 22:02:11 - 23:28:47 | SRV-BUILD-06 | Firewall (aggregate) | 47 connections across 5 distinct TOR node IPs, occurring at near-exact 2-minute intervals (jitter < 3 seconds) | Beaconing IOC: this regular, low-jitter interval pattern is characteristic of automated C2 check-in behavior, not human interactive browsing. |
| 2022-10-17 22:02:09 | SRV-BUILD-06 | (EDR process check) | Unsigned binary bldhelper.exe (not the TOR Browser Bundle) responsible for the connections, running as a Windows service | Tooling-Mismatch IOC: the process is not the legitimate, interactive TOR Browser; a headless service-context binary making TOR connections is a strong indicator of a TOR-based C2 client embedded in malware. |
| - | - | (host role check) | SRV-BUILD-06 is a headless CI/CD build agent with no interactive user sessions logged in the past 30 days | Confirms there is no plausible legitimate business justification for TOR browsing on this host. |
| 2022-10-17 22:05:33 | SRV-BUILD-06 | (EDR process check) | bldhelper.exe was created 4 days prior via a compromised CI pipeline credential, not part of the documented build toolchain | Compromise-Origin IOC: ties the TOR-connecting binary back to a prior CI/CD credential compromise as its installation vector. |
Validation:
- Timeline: sustained, low-jitter periodic connections to multiple confirmed TOR nodes from a headless service-context process on a server with no legitimate browsing use case, tied to a known prior CI/CD compromise - a complete and coherent TOR-based C2 chain.
- False Positives: no TOR Browser Bundle or documented research exception exists for this host, and the host role (headless build server) rules out interactive human browsing entirely.
- Correlation: consensus-list match, beaconing regularity, tooling/process mismatch, and host-role/compromise-origin context jointly confirm malicious TOR-based C2 usage.
Step 4: Recommendations & Next Steps
- Immediate Response: Isolate SRV-BUILD-06, terminate
bldhelper.exe, rotate the compromised CI/CD pipeline credentials and audit all builds signed/executed since the compromise date, and block outbound connections to the known TOR consensus list at the perimeter for all non-exception hosts. - Detection: Sigma-style rule:
title: Outbound Connection to Known TOR Node with Beaconing Pattern→selection: dest_ip IN (tor_consensus_list)aggregation: stdev(connection_interval) < 5s over 30m→condition: selection and aggregation. - Pro Tip: Maintain an automatically-refreshed TOR consensus node feed (updated at least daily, since the node list rotates) and apply a default-deny policy for all server-class / non-interactive hosts - legitimate TOR use is almost always confined to a small, documented set of interactive workstations, making a role-based allow-list far more effective than attempting to police TOR usage organization-wide.
Hypothesis confirmed - a compromised CI/CD build server was communicating with attacker infrastructure through a TOR-based C2 channel, beaconing to five TOR guard nodes at regular two-minute intervals via an unrecognized service binary!