This is the second post in a series on SecOps Alert Enrichment. You can find the first post here:

SecOps Alert Enrichment: Part 1 - Recent Related Alerts
The idea behind this enrichment is that you take various IOCs from the alert and then make an API call to your alert platform to return the last 5 alerts where those IOCs were mentioned.
SecEng Newsletter by Andrew KatzAndrew Katz

The premise of this series is that, although many SecOps teams have implemented basic alert enrichment, I submit that there are a lot of other niche, high-value enrichment use cases that teams out there may have not considered yet.

I am not saying any of these ideas are novel, but if you look at any blog post or canned SOAR playbooks related to alert enrichment, there is a very good chance it is just another re-hashed example of looking up an IP or a hash from an alert in VirusTotal.

Tor Exit Nodes

The concept behind this enrichment is to correlate IP addresses in alerts with an up-to-date list of Tor exit node IP addresses.

Threat actors use Tor for anonymity. Tor is not only useful for a specific activity like performing reconnaissance – it can be used throughout the entire lifecycle of an attack. Okta recently reported unprecedented amounts of credential stuffing attacks on its customers. In all attacks that Okta observed, the requests came through Tor and various residential proxies (e.g. NSOCKS, Luminati, and DataImpulse).

Since a Tor exit node is where traffic exits the Tor network and interacts with services on the open internet, exit node IPs are the ones you're actually going to see in your logs.

Here is a reliable list of Tor exit nodes you can use: https://www.dan.me.uk/torlist/?exit.

💡
If memory serves correctly, the dan.me.uk list is rate-limited to one call per 24 hours.

In the example below, alerts are being enriched post-creation by an alert enrichment pipeline (e.g., within a SOAR):

Bonus: update the alert priority if a Tor Exit node is matched

Scenario

Let's say that we received an Okta New API Token Created alert. Without enrichment in place, the associated source IP address for the alert may seem non-descript. Even if you have some geoip information, if the source IP is located where your headquarters are, you may incorrectly assume that it is your IT team legitimately creating a token and de-prioritize this alert in place of another one.

If you were enriching IP addresses in alerts against Tor exit nodes, it would raise this alert to the top of the stack and instantly get the response it needs. 🏆

As I mentioned in the caption above, you might consider dynamically updating alert prioritizes from your pipeline based on enrichment outcomes.

Summary

Correlating IP addresses against Tor exit nodes is a useful enrichment to add to your alerts because it is such a high fidelity indicator. It is especially high fidelity if your company enforces a list of approved browsers and you don't have people using Brave's built-in Tor browser, for example.