Anonymity Networks for Defenders Guide: Tor and I2P Policy, Detection and Investigation

Anonymity networks such as Tor and I2P protect journalists, activists and researchers, and the same properties let attackers hide reconnaissance, intrusion, command and control and data theft behind addresses that cannot be traced to them. Defenders therefore face a policy question (should Tor be allowed to and from our network, and where?), a detection question (how do we see it?) and an investigation question (what can a Tor exit address in our logs actually tell us?). This guide explains how Tor and I2P work at the level a defender needs, sets out the restrictive, monitoring and blended approaches described by CISA and the FBI, lists the indicators and data sources to use, and covers legitimate organisational uses such as onion services and protected research. It is written for security operations, network and privacy teams. For the wider privacy toolset, see the Privacy-Enhancing Technologies Guide.

Key takeaways

• Anonymity hides origin, not content. Tor relays each know only the previous and next hop, so the destination sees the exit relay's address; the content is protected only if the application also uses TLS.
• Choose a deliberate stance. CISA advisory AA20-183A describes a most restrictive approach (block public entry and exit nodes), a monitoring-based approach and a blended approach that allows Tor only to specific services.
• Blocking is partial. Bridges are unlisted entry points and pluggable transports disguise traffic, so blocking public relays stops casual use and unsophisticated malware, not determined actors.
• A Tor exit address is not an attacker identity. Use the Tor Project's ExoneraTor to confirm an address was a relay on a given date, and treat it as an anonymised source in investigations.
• There are legitimate uses to support. Onion services give whistleblowers and users in hostile networks an authenticated, encrypted path to you, and some staff and researchers need anonymity under policy.

How Tor and I2P work, for defenders

Tor

The Tor Project describes Tor as building a circuit of encrypted connections through relays, one hop at a time, with separate encryption keys negotiated for each hop. Each relay knows only which relay handed it data and which relay it passes data to; no single relay knows the full path. A standard client circuit uses an entry (guard) relay, a middle relay and an exit relay. Tor carries TCP streams from any application that supports SOCKS, and connections made within about ten minutes share a circuit before a new one is used.

For defenders, three facts follow:

• Inbound to your services, Tor traffic arrives from an exit relay address, which is publicly listed.
• Outbound from your network, a Tor client connects first to a guard relay or to a bridge, and the traffic is encrypted and looks like TLS.
• Metadata still leaks. The Tor Project notes that encryption hides content but not headers, so traffic analysis can still reveal source, destination, size and timing on each link.

Onion services

An onion service is reachable only inside Tor. Its address is its public identity key, it publishes a signed descriptor listing introduction points, and client and service meet at a rendezvous relay, so the connection passes through six relays, three chosen by each side. The Tor Project lists the benefits as location hiding, end-to-end authentication (the address is the key), end-to-end encryption and no need for open inbound firewall ports. The last point matters to defenders in both directions: an onion service run by your organisation needs no inbound rule, and an onion service run covertly on a compromised host inside your network also needs none, so it will not show up in a review of inbound firewall rules. Look for it instead as an outbound Tor client process on a host that has no business running one.

I2P

I2P is a packet-switched anonymous overlay network. It uses unidirectional tunnels (one outbound, one inbound per destination) with layered encryption and "garlic" messages that bundle several encrypted messages together. Peers find each other through a distributed network database rather than directory servers. I2P is mainly designed for services inside the network (.i2p names); reaching the public internet depends on volunteer outproxies, which are not provided by default.

For the consumer-facing comparison, see the Choosing a VPN Safely Guide.

How attackers use anonymity networks

CISA and the FBI, in advisory AA20-183A (first published 1 July 2020, revised in 2021), report that threat actors from advanced persistent threats to low-skilled attackers use Tor for reconnaissance, exploiting systems, exfiltrating and manipulating data, denial of service and ransomware delivery, and to relay command and control so that server location and ownership are hidden. The defensive view in MITRE ATT&CK terms:

Credential abuse is a large share of this. Stolen API keys, tokens and passwords are often tested and used from Tor exit addresses to avoid attribution, so authentication logs for machine identities are a key place to look. See the Dark Web Monitoring Guide for how leaked credentials surface on hidden services.

Choosing a policy stance

AA20-183A sets out three approaches. The right one depends on your services and users, and can differ per system:

• Inbound to administrative and identity endpoints: block or step up. There is rarely a reason for an SSO admin console, a VPN portal or a cloud management API to accept sessions from exit relays.
• Inbound to public content: usually allow and monitor; the advisory's own example is overseas military voters using Tor to reach election sites.
• Inbound to account login and sign-up: treat exit addresses as a risk signal in adaptive authentication rather than a hard block, so users with privacy needs are not excluded and abuse is still slowed.
• Outbound from corporate endpoints and servers: block by default. Servers should not run Tor clients; on endpoints, approve exceptions explicitly.
• Small organisations can use the Tor category built into many firewalls and WAFs; large organisations should own the feed, version it and apply it consistently across edge, cloud and identity providers.

Detection: data sources and indicators

The advisory lists these indicators, which remain the core of detection:

• Exit addresses: traffic involving addresses from the Tor Project's Exit List Service, which is updated hourly and offers bulk download and real-time queries.
• Ports: TCP and UDP 9001, 9030, 9040, 9050, 9051 and 9150, plus TCP 443 and 8443 (expect many false positives on 443).
• DNS: highly structured queries for names ending in torproject.org, and queries for .onion names, which can indicate a misconfigured Tor client.
• Flows: unexpected connections from exit relays to services that should never receive them, and large data flows to or from relay addresses.
• Existing controls: many firewalls, WAFs and intrusion detection systems already include Tor detection categories.

Add endpoint and identity telemetry, which catches what network lists miss:

• Endpoint: Tor Browser or tor, and I2P router processes on corporate devices; local SOCKS listeners on 9050 or 9150 on servers; software inventory for anonymity tools. See the CIS Control 2 Inventory and Control of Software Assets Guide.
• Identity provider and API gateway: successful or failed sign-ins and token use from exit addresses, especially for service accounts and API keys that normally come from fixed cloud ranges.
• Network: flow records to guard relays listed in the consensus, captured by tools such as Zeek. See the Zeek Network Monitoring Guide.

Metrics

• Percentage of internet-facing services with a documented Tor stance (block, monitor or allow).
• Age of the exit relay feed in enforcement points (target under two hours, given hourly updates).
• Number of corporate endpoints or servers running anonymity network clients without an approved exception.
• Count of machine identity authentications from exit relays per month, and time to revoke the credential.
• Rate of blocked versus allowed exit relay sessions on identity endpoints.

Where identity fits

The most useful place to apply a Tor policy is often the identity layer rather than the network edge, because identity systems see every authentication regardless of the path it took. Three controls give most of the value:

• Conditional access for workforce users: treat exit relay addresses as a named location or risk signal, and require phishing-resistant MFA or deny access to privileged roles from them.
• Network restrictions on machine identities: API keys, service principals and CI tokens should be bound to the address ranges or workloads that use them. A service account that authenticates from a Tor exit is almost always compromised. See the API Key Management Guide.
• Customer-facing login: use exit addresses as one input to bot and fraud scoring rather than a hard rule, so privacy-conscious customers can still sign in while credential stuffing from Tor is slowed.

Investigating Tor-sourced activity

1. Confirm the address was a relay at the time. The Tor Project's ExoneraTor service (on Tor Metrics) checks whether an IP address was a Tor relay on a given date; Relay Search shows a relay's details and flags.
2. Record it as an anonymised source, not as the attacker's address. Relay operators are volunteers; contacting them rarely helps and complaints to them do not identify users.
3. Pivot on what the actor controlled: the credential, token or session used, user agent, request patterns, timing, and payloads. These link Tor-sourced activity to other activity far more reliably than addresses.
4. Contain through identity: revoke and rotate any credential used from Tor, invalidate sessions and check for persistence the actor created (new keys, OAuth grants, mailbox rules).
5. Preserve evidence including full request logs and the relay status lookup, and involve legal counsel and law enforcement where appropriate. See the Incident Response Guide.
6. Feed lessons back into the policy stance for the affected service.

Legitimate organisational uses

• Onion services for your own site or tip line: news organisations, NGOs and companies running whistleblowing channels can publish an onion service so users in monitored networks reach them with end-to-end authentication. Treat the onion service private key as a critical secret: whoever holds it is the service. See the Cryptographic Key Management Guide.
• Staff privacy and safety: staff travelling to or working in hostile jurisdictions may need anonymity tools under a documented exception and on dedicated devices.
• Threat intelligence research: analysts monitoring leak sites and criminal forums should use isolated, non-attributable infrastructure approved by policy and legal, never corporate endpoints. See the Ransomware Leak Sites and Victim Shaming Guide.
• Privacy obligations: treating Tor users as presumptively malicious can conflict with an organisation's privacy commitments; the CyBOK Privacy and Online Rights Knowledge Area frames anonymity as a privacy technology with legitimate social value. See the CyBOK Body of Knowledge Guide.

Framework mapping

Common failure patterns

• Stale exit lists. Lists imported once and never refreshed miss new exits and block addresses that have since been reassigned.
• Treating exit addresses as attribution. Reports that name a relay address as "the attacker" mislead responders and partners.
• Blocking the edge but not identity. Web traffic is filtered, but the identity provider and API gateway accept tokens from exit relays, which is exactly where stolen machine credentials are used.
• Assuming blocking stops C2. Bridges and pluggable transports are designed to evade lists; egress allow-listing and endpoint detection are needed for servers.
• Hard-blocking public services by default, which excludes legitimate users with privacy needs without materially reducing determined attacks.
• Unmanaged research access, with analysts browsing hidden services from corporate laptops.

Practitioner checklist

• Decide and document a Tor stance per service class: admin, identity, public content, login and egress.
• Automate ingestion of the Tor exit list at least hourly into firewalls, WAFs and identity risk policies.
• Block outbound Tor and I2P from servers and detect anonymity clients on endpoints.
• Alert on machine identity authentication from exit relays and revoke the credential.
• Monitor the ports, DNS patterns and flow volumes listed in AA20-183A.
• Use ExoneraTor to confirm relay status in investigations and pivot on credentials and behaviour.
• Provide a governed route for staff privacy needs and threat intelligence research.
• If you run an onion service, protect its private key as a critical secret.

Standards and references

• CISA: AA20-183A Defending Against Malicious Cyber Activity Originating from Tor
• Tor Project: How Tor Works Overview
• Tor Project: How Do Onion Services Work
• Tor Project: Using Bridges
• Tor Project: Tor Metrics, Relay Search and ExoneraTor
• I2P: Introduction to I2P
• MITRE ATT&CK: Multi-hop Proxy
• CyBOK: Privacy and Online Rights Knowledge Area

Related NHI Mgmt Group resources: Privacy-Enhancing Technologies Guide · Dark Web Monitoring Guide · Choosing a VPN Safely Guide · Network Security Guide