Work / Case study
Hunting unauthorized Tor Browser use
Management suspected employees were using Tor to get around network controls. I hunted through endpoint telemetry, confirmed it on one machine, and isolated the device.
- Endpoint
- Windows 11 VM in Azure
- EDR
- Microsoft Defender for Endpoint
- Query language
- KQL
- Outcome
- Device isolated, manager notified
The scenario
Network logs showed unusual encrypted traffic and connections to known Tor entry nodes, and there were anonymous reports of employees discussing ways around the content filters. The task was to find any Tor usage and report it to management.
The plan
Tor leaves evidence in three places, so the hunt checked three tables in order:
- DeviceFileEvents for the installer and any Tor files
- DeviceProcessEvents for installation and execution
- DeviceNetworkEvents for connections on known Tor ports
1. Find the files
A first search for anything containing "tor" was too loose, because it also matched file names like "editor" and "storage". Narrowing it to "tor-browser" left one result: the user employee downloading the Tor Browser 15.0.20 installer on a Windows 11 machine.
KQL: file events
DeviceFileEvents
| where DeviceName == "threat-hunt-lab"
| where InitiatingProcessAccountName == "employee"
| where FileName contains "tor-browser"
| order by Timestamp desc
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, SHA256,
Account = InitiatingProcessAccountName2. Confirm the install and launch
Process events showed the installer running from the Downloads folder with the /S flag, which is a silent install. A second query showed tor.exe and firefox.exe starting later that day, so the browser was opened as well as installed.
KQL: process events
DeviceProcessEvents
| where DeviceName == "threat-hunt-lab"
| where FileName has_any ("tor.exe", "firefox.exe", "tor-browser.exe")
| project Timestamp, DeviceName, AccountName, ActionType, FileName,
FolderPath, SHA256, ProcessCommandLine
| order by Timestamp desc3. Prove it connected
Installing Tor is a policy problem. Using it is the finding. Network events showed tor.exe connecting to a remote address on port 9001, a known Tor relay port, plus the local proxy on 9150.
KQL: network events
DeviceNetworkEvents
| where DeviceName == "threat-hunt-lab"
| where InitiatingProcessAccountName != "system"
| where InitiatingProcessFileName in ("tor.exe", "firefox.exe")
| where RemotePort in ("9001", "9030", "9040", "9050", "9051", "9150", "80", "443")
| project Timestamp, DeviceName, InitiatingProcessAccountName, ActionType,
RemoteIP, RemotePort, RemoteUrl, InitiatingProcessFileName
| order by Timestamp descTimeline
| Time (UTC) | Event |
|---|---|
| 21:06:55 | Tor installer downloaded to the Downloads folder |
| 21:13:43 | Installer run silently |
| 23:05:08 | tor.exe and firefox.exe start |
| 23:05:21 | tor.exe connects to a relay on port 9001 |
| 23:09:08 | tor-shopping-list.txt created on the desktop |
Response
The telemetry showed the user installed, launched, and used Tor Browser. I isolated the device in Defender for Endpoint and notified the user's direct manager, as the scenario required.
The repo also includes the steps used to create the scenario, so the hunt can be repeated as a tabletop exercise.