Why Monitoring for TOR Exit Node Activity Matters
In today’s complex cybersecurity landscape, one of the most overlooked but critical elements in proactive threat detection is monitoring for TOR (The Onion Router) exit node activity. TOR enables anonymous communication, and while it serves legitimate privacy interests, it also provides cover for cybercriminals, malware campaigns, and data exfiltration.
What Are TOR Exit Nodes?
TOR exit nodes are the final relay points in the TOR network where encrypted traffic exits to the open internet. If a user browses the web anonymously via TOR, the website or service they access will see the IP address of the exit node, not the user's actual IP address.
In other words, any network traffic originating from a TOR exit node is untraceable to its source without cooperation from the TOR network, which is unlikely by design.
Why Should You Care?
While not all TOR activity is malicious, a substantial amount of malicious traffic uses TOR to mask its origin. Here’s why it matters:
-
Anonymized Reconnaissance: Attackers often perform scans and probes from TOR exit nodes. If someone is mapping your infrastructure using TOR, they may be preparing for a breach attempt while remaining anonymous.
-
Command and Control (C2) Channels: Many malware families use TOR for C2 communications, making it hard to trace the infected endpoint back to its controller.
-
Data Exfiltration: TOR is a common channel for exfiltrating sensitive data out of an organization. If sensitive files are being uploaded to external endpoints via TOR, you may already be compromised.
-
Compliance Risks: Some industries (e.g., healthcare, finance) require strict data handling and access controls. Allowing or ignoring TOR-originated traffic could violate these policies or industry regulations.
You should look for any interactions between TOR exit nodes and:
- host.ip
- server.ip
- destination.ip
- source.ip
- client.ip
This can occur in logs from firewalls, DNS, proxies, endpoint agents, cloud access logs, and more.
How to Monitor for TOR Exit Nodes
In order to collect, monitor, alert, and report on TOR Exit Node activity, we must first create a few components, namely, we will create an index template and an ingest pipeline. We will then hit the TOR API endpoint every 1 hour to request the most recent detailed information.
If you would like to learn more about options for monitoring TOR, you may read about them here. If you would like to know more about the TOR Project in general, you may read about it here.
Ingest Pipeline
First, let’s create an Ingest Pipeline that will accomplish the last bit of parsing our data before it is written to an index. In DevTools, simply apply the following: there are descriptions for each processor; should you want to know more about what each does and its associated condition, if present.
Here is what your screen may look like:
You may find the ingest pipeline on GitHub.
Index Template
Next, we need to create our index template to ensure our fields are correctly mapped.
Still in DevTools, submit the following request just as you completed with the ingest pipeline. You may find the index template via this link on GitHub.
Notice the priority of the index template; we set this to a much higher number so that this template will take precedence over the default logs-*-* template. While you will notice in the following steps that we set the ingest pipeline in our configuration for data collection, we may also apply it here as a safeguard to ensure data is written through this pipeline.
Elastic-Agent Policy
With these two items loaded, we may now navigate to Fleet and select the “agent policy” we want to install our integration to.
On the policy you wish to install the TOR collection to, simply click “Add integration”.
Select “Custom” from the left-hand category list, then click “Custom API”.
Click the blue “Add Custom API” button on your top right.
You may title your Integration anything you like; however, I will be using “TOR Node Activity” in this example.
Fill in the following fields:
Dataset name:
ti_tor.node_activity
Ingest Pipeline:
logs-ti_tor.node_activity
Request URL:
https://onionoo.torproject.org/details?fields=exit_addresses,nickname,fingerprint,running,as_name,verified_host_names,unverified_host_names,or_addresses,last_seen,last_changed_address_or_port,first_seen,hibernating,last_restarted,bandwidth_rate,bandwidth_burst,observed_bandwidth,flags,version,version_status,advertised_bandwidth,platform,recommended_version,contact
Request Interval:
60m
Request HTTP Method:
GET
Response Split:
target: body.relays
You will then need to click to expand the “> Advanced options” and scroll down a bit more.
You may find the necessary processor snippet to copy at GitHub here.
You may now click the “Save and continue” button and in a few minutes you will have TOR node activity available in your logs-* index!
Filebeat Installation Option
If you are not using Elastic-Agent and wish to ingest via Filebeat, that’s cool too! Instead of using the steps above, simply leverage the following “filebeat.inputs:” which will use the exact same ingest pipeline and index template as above! Simply copy and paste the input section into your filebeat.yml file, you will still need to add an output section.
Reviewing your data
Now that you've completed the configuration of the ingest pipeline and the agent integration, you can see the TOR nodes in the Discover view. From here, you can create rules, visualizations, dashboards, etc., to help keep tabs on how TOR is being used on your network.
What can you do next?
The beautiful thing about the naming convention for this index, is that it will automatically function with your Threat Intel IP Address Indicator Match rule available in the Elastic SIEM.
However, you may want to make your own rule using some of the wealth of information that is provided with this integration; particularly depending on the type of node observed environment. Since there was a considerable amount of geo-based data enriched with this index, now would be an excellent time to check out some of the map features within Kibana.