Tor and anonymizing proxies are used by attackers to obscure the true destination of exfiltration traffic, bypass DLP and proxy inspection, and route C2 communication through multiple hops that appear as legitimate exit node IPs. Detection relies on known exit node IP lists, relay port signatures (9001, 9030, 9050, 9150), and ASN-based identification of datacenter VPN providers.
This SOP covers two detection paths: exit node IP matching against a Sentinel watchlist of known Tor exit nodes, and relay port detection using ASimNetworkSession to identify Tor relay traffic patterns from internal hosts.
☰ Table of Contents
01 — BACKGROUND
TECHNIQUE OVERVIEWTor (The Onion Router) routes traffic through three relay nodes (Guard, Middle, Exit) before reaching the destination. From a network perspective, all connections appear to originate from the exit node IP, which is publicly listed in the Tor Project's consensus documents. Attackers use Tor to route C2 callbacks and exfiltration traffic, making attribution difficult. Unauthorized VPN usage similarly tunnels corporate traffic through commercial VPN provider ASNs (ExpressVPN, NordVPN, Mullvad) that should not appear in corporate outbound flows.
| Field | Value |
|---|---|
| MITRE Technique | T1090 — Proxy |
| Sub-technique | T1090.003 — Multi-hop Proxy |
| Log Sources | ASimNetworkSession, CommonSecurityLog (Palo Alto/ZScaler), DeviceNetworkEvents |
| Tor Relay Ports | 9001 (ORPort), 9030 (DirPort), 9050 (SOCKS proxy), 9150 (Tor Browser), 9051 (ControlPort) |
| Detection Method | Exit node IP watchlist match, relay port signature, VPN ASN identification |
| Detection Priority | HIGH — Tor usage violates AUP and may indicate active exfiltration or C2 |
Some legitimate privacy researchers and security professionals use Tor. Always check with the host's manager and review process context before escalating to a full incident — but do not delay action if C2 beacon or data exfiltration patterns are also present.
02 — IDENTIFICATION
2 INDICATORSThe Tor Project publishes a daily updated list of exit node IPs. Matching outbound connections against this list gives definitive confirmation of Tor usage — exit node IPs serve no legitimate corporate function.
- 1Verify a Tor exit node watchlist exists: Sentinel → Watchlists → look for a list named
TorExitNodesorThreatIntelIPs. - 2If no watchlist exists, create one: download the Tor exit node list from
check.torproject.org/torbulkexitlistand import as a Sentinel Watchlist with columnExitNodeIP. - 3Paste the KQL below; set time range to Last 24 hours.
- 4Review
SrcIpAddr— identify the internal host that connected to the Tor exit node IP. - 5Check if the Tor Browser binary (
tor.exe,firefox.exefrom Tor Browser folder) is visible in the Device Timeline for the source host.
| Field / Value | Meaning | Action |
|---|---|---|
| DstPort = 9050 | Tor SOCKS proxy port — local Tor client forwarding traffic | ESCALATE |
| DstPort = 9001 | Tor ORPort — connecting to an entry/relay node directly | ESCALATE |
| DstPort = 9150 | Tor Browser default port — Tor Browser installed and running | ESCALATE |
| Exit node IP match | Connection destination confirmed as a published Tor exit node IP | ESCALATE |
The Tor exit node list must be refreshed daily to remain accurate — exit nodes rotate frequently. Set up an automated Logic App or Azure Function to pull from check.torproject.org/torbulkexitlist and update the Sentinel Watchlist on a schedule.
Commercial VPN providers (NordVPN, ExpressVPN, Mullvad, ProtonVPN) operate under specific Autonomous System Numbers (ASNs). Connections from corporate hosts to these ASN ranges indicate unauthorized VPN tunnelling that bypasses proxy inspection and DLP controls.
- 1Navigate to security.microsoft.com → Hunting → Advanced Hunting.
- 2Paste the KQL below to identify hosts running known VPN client processes or connecting to VPN infrastructure ports (UDP 1194/OpenVPN, UDP 51820/WireGuard, TCP 443/SSTP).
- 3Review
InitiatingProcessFileName—openvpn.exe,wireguard.exe,nordvpn.exe,expressvpn.execonfirm VPN client installation. - 4Check if the VPN process was installed recently or is running from a non-standard path (Downloads folder, AppData) which indicates shadow IT or attacker-installed VPN.
- 5Determine if the user has an approved business justification for VPN usage — contact their manager if needed before blocking.
If an insider threat scenario is suspected (user attempting to exfiltrate data via Tor), preserve forensic evidence before blocking: export the Device Timeline, capture running process list via Live Response, and notify HR and Legal before confronting the user.
03 — CONTAINMENT
IMMEDIATE ACTIONIf Tor usage coincides with a sensitive data access event (SharePoint bulk download, email attachment exfiltration) — escalate immediately to SEV1 insider threat IR regardless of business justification claims.
- 1Add a network deny rule in Azure Firewall: block outbound TCP/UDP on ports
9001, 9030, 9050, 9150, 9051from all internal subnets. - 2Add Defender for Endpoint indicators to block VPN client binaries by hash: Settings → Endpoints → Indicators → Files.
- 3Run a Live Response session on the affected host: Device → Actions → Initiate Live Response → kill the Tor/VPN process and delete the binary.
- 4Check browser history on the source host for any dark web (.onion) URLs visited — this confirms intentional Tor usage rather than malware-installed Tor.
- 5Notify HR if the user intentionally installed Tor without authorization. Notify IR team if malware-installed Tor is suspected.
04 — ERADICATION
CLEANUP- 1Uninstall any Tor Browser, VPN client, or anonymizing proxy software from the affected host via Live Response or SCCM software deployment.
- 2Delete all Tor configuration files and profiles:
%APPDATA%\Tor Browser\,%APPDATA%\Roaming\tor\. - 3Add Tor executable hashes to Defender for Endpoint custom indicators as Block to prevent re-installation across all managed endpoints.
- 4Verify egress firewall rules block ports 9001, 9030, 9050, 9150 — confirm no bypass exists via HTTPS port 443 (used by obfs4 bridges).
- 5Review the Tor exit node watchlist freshness — if older than 24 hours, refresh from the Tor Project's bulk exit list.
- 6If malware-installed Tor is confirmed, run a full AV scan and treat as an active C2 scenario — escalate per SOP-34 (Outbound TI-Matched Connection).
- No ASimNetworkSession events on Tor relay ports from affected host in past 2 hours
- Tor Browser and VPN client binaries removed or quarantined
- Firewall rule blocking ports 9001/9030/9050/9150 confirmed active
- Tor executable hash added to Defender indicators as Block
- HR/manager notified if intentional policy violation confirmed
05 — ESCALATION
ESCALATION PATHS| Condition | Severity | Action | Notify |
|---|---|---|---|
| Tor + simultaneous bulk data access | SEV1 | Full IR, insider threat protocol, forensic hold | SOC Lead → CISO → HR → Legal |
| Malware-installed Tor (no user knowledge) | SEV1 | Treat as active C2, isolate host, IR ticket | SOC Lead → CISO → IR Team |
| User-installed Tor, no data staging | SEV3 | Remove software, policy warning, HR notification | SOC Lead → HR Manager |
| Authorized security researcher | INFO | Document approval, add exception, close ticket | None |
Tor usage by a privileged user (admin, finance, HR with PII access) must be treated as SEV1 insider threat regardless of whether data staging is confirmed — the risk of undetected exfiltration is too high to wait for further evidence.
Stay Threat-Ready
Follow CyberHawk Threat Intel for daily SOC analyst playbooks, detection engineering guides, and threat intelligence.