← Back to Blog
October 05, 2025 security-operations 10 min read

Threat Hunt Walkthrough: Detecting TOR Browser Usage

Applying the 4-step threat hunting methodology to detect unauthorized TOR usage on corporate networks

Threat Hunt Walkthrough: Detecting TOR Browser Usage

Applying the 4-step threat hunting methodology to detect unauthorized TOR usage on corporate networks.

The Scenario

Management raised concerns about potential policy violations. Recent network monitoring revealed unusual encrypted traffic patterns and connections to IP addresses associated with known TOR entry nodes. Additionally, anonymous reports suggested that some employees may be discussing methods to access restricted websites during work hours.

The security concern: TOR browsers can bypass network security controls, potentially allowing:

The mission: Conduct a proactive threat hunt to determine if TOR browsers are being used within the organization, identify affected systems and users, and implement appropriate security controls.

In our previous post on threat hunting methodology, we covered the 4-step framework for structured threat hunts. Today, we’re putting that methodology into action with this real-world scenario.

Hunt Timeline Overview

timeline
    title TOR Usage Detection Timeline
    Oct 4, 20:54 UTC : TOR Browser Downloaded
    Oct 4, 20:54-Oct 5, 21:48 UTC : 28 Process Executions
    Oct 5, 17:44 UTC : Connection to TOR Node
    Oct 5, After Hunt : Detection Rules Implemented

STEP 1: Develop a Hypothesis

Every threat hunt begins with a clear hypothesis — our guide for the investigation.

Our Hypothesis:

“Employees are using TOR browsers to bypass network security controls, as evidenced by unusual encrypted traffic patterns and connections to known TOR entry nodes.”

What would confirm this hypothesis? If TOR usage is occurring, we should find:

What would disprove this hypothesis?

With our hypothesis defined, we moved to identifying where evidence would appear.

STEP 2: Identify Evidence Sources

This step flows directly from the hypothesis. We took the clues from Step 1 and researched what they meant.

Our Environment: We were using Microsoft Defender for Endpoint (MDE), which provided access to multiple log sources:

Evidence Type Log Source Log Fields
TOR process execution DeviceProcessEvents FileName, FolderPath, ProcessCommandLine, AccountName, Timestamp
Network connections DeviceNetworkEvents RemoteIP, RemotePort, InitiatingProcessFileName, Timestamp
DNS queries DeviceNetworkEvents RemoteUrl, SourceIP, Timestamp
File downloads DeviceFileEvents FileName, FileOriginUrl, Timestamp

Search Strategy:

We built targeted queries for each evidence type:

Query 1 — TOR Process Execution:

DeviceProcessEvents
| where DeviceName contains "ELCT_DPMT"
| where FileName has_any ("tor.exe", "tor")
    or FolderPath has_any ("Tor Browser", "\\tor\\", "\\Tor\\")
    or ProcessCommandLine has_any ("tor", "torrc", "-f torrc")
| project Timestamp, DeviceName, AccountName, FileName, FolderPath, ProcessCommandLine, InitiatingProcessFileName
| sort by Timestamp desc

Query 2 — Connections to TOR Nodes:

DeviceNetworkEvents
| where DeviceName == "WORKSTATION-042"
| where Timestamp between (datetime(2025-10-04T20:54:42Z) .. datetime(2025-10-05T21:48:28Z))
| where RemotePort in (9001, 9030)
| where InitiatingProcessFileName has_any ("tor", "firefox")
| project Timestamp, DeviceName, LocalIp, RemoteIp, RemotePort, InitiatingProcessFileName
| sort by Timestamp desc

Query 3 — DNS Queries for TOR:

DeviceNetworkEvents
| where DeviceName == "WORKSTATION-042"
| where Timestamp between (datetime(2025-10-04T20:54:42Z) .. datetime(2025-10-05T21:48:28Z))
| where RemoteUrl contains_any (".onion", "torproject.org")
| project Timestamp, DeviceName, RemoteUrl, InitiatingProcessFileName
| sort by Timestamp desc

STEP 3: Transform & Analyze Data

With our queries prepared, we executed the hunt systematically, correlating findings across log sources and building evidence chains.

Query Execution & Results

Query 1 — TOR Process Execution:

This was significant — not a single execution, but 28 separate executions over 25 hours, indicating repeated or ongoing usage.

Query 2 — Connections to TOR Nodes:

The connection to port 9001 (TOR ORPort) to a known TOR entry node confirmed that TOR wasn’t just installed — it was actively used to establish a TOR circuit.

Query 3 — DNS Queries for TOR:

This doesn’t disprove TOR usage — it simply means the user may have accessed .onion sites through IP addresses or used TOR’s internal DNS resolution.

Building the Evidence Chain

We correlated findings across log sources to build a comprehensive timeline:

**User: jsmith Device: WORKSTATION-042**
Timestamp Event Source Analysis
Oct 4, 20:54 UTC TOR Browser portable executed (28 times over 25 hours) DeviceProcessEvents User launched TOR Browser multiple times from Downloads folder
Oct 5, 17:44 UTC tor.exe connected to 45.88.104.74:9001 DeviceNetworkEvents Active connection to TOR entry node, confirming TOR usage

Confidence Level: HIGH

The evidence chain is clear and compelling:

  1. ✅ TOR Browser was deliberately downloaded to Downloads folder
  2. ✅ TOR Browser was executed 28 times over 25 hours
  3. ✅ TOR process established connection to known TOR entry node
  4. ✅ Connection occurred during the investigation timeframe

This pattern indicates deliberate, repeated TOR usage — not accidental or one-time behavior.

STEP 4: Refine Detections & Take Action

With our hypothesis confirmed, we documented findings and implemented controls to prevent future unauthorized TOR usage.

Hunt Summary

Findings:

Conclusion for Management: Confirmed TOR Browser usage by employee jsmith on device WORKSTATION-042. The user downloaded a portable TOR Browser to their Downloads folder and executed it 28 times over 25 hours, establishing a connection to known TOR entry node 45.88.104.74 on port 9001. This constitutes a clear policy violation and represents a security risk due to potential data exfiltration or unauthorized access to restricted content.

Detection Rules Implemented

Rule 1: Block TOR Process Execution

This rule will prevent future TOR Browser execution while alerting the security team to investigation attempts.

Immediate Recommendations

URGENT — Investigate jsmith on WORKSTATION-042:

Key Takeaways

This threat hunt demonstrated the power of the 4-step methodology:

  1. Hypothesis-driven approach kept us focused on specific indicators rather than aimless searching. We knew exactly what to look for because we defined it upfront.

  2. Threat intelligence provided concrete indicators — TOR ports, process names, network signatures — that made our queries precise and efficient.

  3. Multi-source correlation was critical. The process execution alone might have seemed benign, but combined with the network connection to a known TOR node, it told a complete story.

  4. Documentation ensures repeatable results and provides clear evidence for stakeholders. When management asked “how do we know it was TOR?”, we had a clear timeline to show.

The methodology is repeatable. Whether hunting for TOR usage, credential dumping, lateral movement, or persistence mechanisms — the process remains the same:

Additional Resources

Have you conducted your own TOR hunts or similar investigations? Share your experiences and approach in the comments below. Let’s learn from each other’s methodologies.

Ready to hunt other threats? Check out our upcoming walkthroughs on detecting credential dumping, lateral movement, and persistence mechanisms.

Threat Hunting TOR Detection Network Security SOC Operations Incident Response