LantianXie3/threat-hunting-scenario
GitHub: LantianXie3/threat-hunting-scenario
这是一个威胁狩猎实战案例，展示如何通过Microsoft Defender for Endpoint的KQL查询检测企业终端上未经授权的Tor浏览器使用并重建完整攻击时间线。
Stars: 0 | Forks: 0
# 威胁狩猎报告：发现未经授权的 Tor 浏览器使用
## 📸 项目预览
*快速展示狩猎效果的视觉图 — 最终查询输出、仪表板视图或最能代表该项目的屏幕截图。*
## 概述
这是我在实验室环境中进行的一次威胁狩猎的完整过程，追踪了单个用户如何在企业 Windows 10 终端上安装和运行 Tor 浏览器，然后使用它访问暗网上的隐藏服务。整个调查完全基于 Microsoft Defender for Endpoint 中的遥测数据，使用 Kusto 查询语言进行深入分析。目标是将"管理层"的一个模糊线索转化为清晰、可辩护的时间线，展示设备上实际发生的情况。
您可以在这里找到产生此遥测数据的实验室设置：
- [场景创建](https://github.com/LantianXie3/threat-hunting-scenario/blob/main/threat-hunting-scenario-tor-event-creation.md)
## 工具与环境
- **终端：** 托管在 Microsoft Azure 中的 Windows 10 虚拟机
- **EDR：** Microsoft Defender for Endpoint
- **查询语言：** Kusto Query Language (KQL)
- **攻击工具：** Tor Browser，版本 14.5.5
## 场景描述
最近的防火墙日志出现了一些奇怪的模式：加密流量与企业基线不匹配，传出连接落在公共 Tor 入口中继列表中出现的 IP 上。此外，还收到了一些匿名举报，称员工在工作时间交流如何绕过网页过滤器的"心得"。
任务很明确：确认或排除整个终端群中的 Tor 活动，记录发现的任何情况，如果确实存在则上报管理层
## 我的方法
在处理数据之前，我先梳理了最可能留下线索的位置：
- `DeviceFileEvents` — 任何包含"tor"文件名的写入、复制或提取操作
- `DeviceProcessEvents` — 安装程序启动、浏览器启动、子进程生成
- `DeviceNetworkEvents` — 通过 Tor 已知端口（9001、9030、9050、9051、9150）的传出连接
三个表，三个角度。如果这台机器上有 Tor，至少其中一个会有所显示
## 实施步骤
### 1. 在 `DeviceFileEvents` 中查找文件活动
第一次扫描是查找文件名中包含"tor"的任何内容。结果基本上直接给了我整个故事：用户 `labuser` 下载了 Tor 浏览器安装程序，运行它，并让解压缩程序将数十个 Tor 相关文件解压到桌面上。还有一个小发现 — 一个名为 `tor-shopping-list.txt` 的文件创建于 `2025-08-05T20:27:19.7259964Z`，这正是让狩猎者提高警惕的那种情况。
整个序列始于 `2025-08-05T20:15:27.0000000Z`。
```
DeviceFileEvents
| where DeviceName == "lan-vt"
| where InitiatingProcessAccountName == "labuser"
| where FileName contains "tor"
| where Timestamp >= datetime(2025-08-06T01:15:27.1828804Z)
| order by Timestamp desc
| project Timestamp, DeviceName, ActionType, FileName, FolderPath, SHA256, Account = InitiatingProcessAccountName
```
*带静默标志的安装程序启动 — 屏幕上很安静，日志里很热闹。*
### 3. 他们真的打开浏览器了吗？
仅安装并不能说明全部问题。很多安装程序运行后就不再被触碰。为了排除这种情况，我在同一设备上搜索 `firefox.exe` 和 `tor.exe` 活动。在 `2025-08-05T20:17:19.0000000Z`，浏览器打开了，随后立即开始生成一系列 `firefox.exe` 和 `tor.exe` 子进程 — 这正是 Tor 运行后预期的进程树。
```
DeviceProcessEvents
| where DeviceName == "lan-vt"
| where FileName has_any ("tor.exe", "firefox.exe", "tor-browser.exe")
| order by Timestamp desc
| project Timestamp, DeviceName, AccountName, ActionType, FileName, FolderPath, SHA256, ProcessCommandLine
```
*进程树确认浏览器确实被启动了，而不仅仅是安装了。*
### 4. 观察网络活动
最后一部分：机器是否真的联系了 Tor 网络？我查询 `DeviceNetworkEvents`，查找从 `tor.exe` 或 `firefox.exe` 发出的、目的地为 Tor 已知端口的任何连接。在 `2025-08-05T20:17:50.0000000Z`，`tor.exe`（运行于 `c:\users\labuser\desktop\tor browser\browser\torbrowser\tor\tor.exe`）向 `37.120.171.230` 的端口 `9001` 打开了连接 — 这是一个典型的 Tor 中继握手。之后有很多后续连接通过端口 `443` 发出。
```
DeviceNetworkEvents
| where DeviceName == "lan-vt"
| where InitiatingProcessAccountName !~ "system"
| where InitiatingProcessFileName in ("tor.exe", "firefox.exe")
| where RemotePort in (9001, 9030, 9040, 9051, 9150, 80, 443)
| project Timestamp, DeviceName, InitiatingProcessAccountName, RemoteIP, RemotePort, RemoteUrl, InitiatingProcessFileName, InitiatingProcessFolderPath
| order by Timestamp desc
```
*向 Tor 入口节点的传出连接 — 电路启动的时刻。*
## 重建的时间线
将四个查询结果整合在一起，让我看到了整个事件的清晰、分阶段视图，从初始下载到主动浏览。
### 阶段 1 — 下载与安装（下午 3:15 – 3:17）
- **下午 3:15:27** — Tor 浏览器安装程序到达 `C:\Users\labuser\Downloads\`
- 文件名：`tor-browser-windows-x86_64-portable-14.5.5.exe`
- SHA256：`6d38a13c6a5865b373ef1e1ffcd31b3f359abe896571d27fa666ce71c486a40d`
- **下午 3:16:47** — 使用静默标志（`/S`）执行安装程序
- **下午 3:17:08 – 3:17:09** — 许可证文件（`tor.txt`、`Torbutton.txt`、`Tor-Launcher.txt`）和 `tor.exe` 解压到 `C:\Users\labuser\Desktop\Tor Browser\`
- **下午 3:17:27** — `Tor Browser.lnk` 快捷方式放置到桌面
### 阶段 2 — 首次启动（下午 3:17 – 3:18）
- **下午 3:17:18 – 3:17:19** — `firefox.exe`（Tor 构建版）启动
- SHA256：`6872f0df504c7a4a308caa86a73c62a51bb6e573107681ab60edbd72126df766`
- **下午 3:17:26** — GPU 辅助进程生成
- **下午 3:17:27 – 3:17:35** — 创建六个内容和实用程序子进程用于标签处理
- **下午 3:17:29** — `tor.exe` 启动；控制端口在 `127.0.0.1:9151` 上运行，SOCKS 代理在 `127.0.0.1:9150`；网络初始由 `DisableNetwork 1` 限制
### 阶段 3 — Tor 电路建立（下午 3:17 – 3:18）
- **下午 3:17:43 – 3:17:50** — 出口到入口和中继节点：
- `95.143.193.125:443`
- `87.118.116.90:443`
- `194.126.174.190:443`
- `37.120.171.230:9001`
- **下午 3:17:50** — 访问隐藏服务，涵盖 `wujjupiz5ut5n.com`、`vynfq5kmdoueyba.com`、`xzejyxz7fr.com` 和 `445dd5l5cr.com`
- **下午 3:17:58** — Firefox 连接到本地 SOCKS 代理 `127.0.0.1:9150` — 电路完全运行
### 阶段 4 — 主动会话（下午 3:18 – 3:55）
大约 40 分钟的持续浏览，随着新标签页和窗口的打开，新的内容进程（子进程 #7 到 #22）被创建。构建 ID 在整个会话中保持一致为 `20250722101758`，排除了浏览器二进制文件被篡改的可能性
## 调查结果
`lan-vt` 上的 `labuser` 于 2025 年 8 月 5 日下午 3:15 开始下载、静默安装并立即启动了 Tor Browser 14.5.5。在浏览器打开后大约两分钟内，Tor 电路就建立起来了，用户开始访问 `.onion` 隐藏服务。该会话持续了大约40 分钟的主动浏览。
从技术层面看，执行得很干净 — 正确的签名、预期的子进程、没有明显的篡改。引人注目的是*行为模式*：静默安装、立即访问暗网，以及在会话期间创建的 `tor-shopping-list.txt` 文件。这个顺序怎么看都不像是无心的好奇
## 响应措施
- 确认了 `lan-vt` 上的 Tor 活动。
- 通过 Defender for Endpoint 隔离了该终端。
- 通知了用户的直接经理，并提供了完整的时间线和支持证据
## 我学到了什么
这是我第一次围绕真实的 EDR 数据集构建狩猎，而不是静态的实验室转储，有几点让我印象深刻：
- **跨表关联至关重要。** 这三个表中的任何一个都只能给出故事的一部分。文件事件告诉我二进制文件存在。进程事件告诉我它运行了。网络事件告诉我它实际上做了什么事。把三者结合起来才能把"这看起来可疑"转化为"这里有一个带有时间戳和 SHA256 哈希值的可辩护时间线。"
- **静默安装比他们想象的更明显。** `/S` 标志本意是向用户隐藏安装，但在 EDR 遥测中它实际上很突出，因为合法的用户驱动安装通常会触发 UAC，而且不会以无头模式运行。这最终成为整个狩猎中最有用的行为线索之一。
- **了解工具有助于狩猎工具。** 了解 Tor 内部使用 9001/9030/9050/9051/9150，以及 `tor.exe` 通常位于安装目录下的 `Browser\TorBrowser\Tor\` 中，让我能够写出比仅仅到处搜索"tor"更精确的查询。
- **写报告是工作的一半。** 把 KQL 写对很令人满足，但把原始行转化为分阶段的叙述才能让工作对除我之外的任何人真正有用
## 后续改进方向
我想回头探索的几个方向：
- **将其转化为检测规则。** 不要手动运行这些查询，而是将模式（便携式浏览器的静默安装 → 几分钟内通过 Tor 端口发出流量）编入 Defender 中的自定义检测，这样下次相同场景就会自动触发。
- **加入基线过滤。** 在真实组织中，一些用户确实会运行看起来可疑的开发工具或隐私工具。批准进程和路径的允许列表应用到整个终端群时会大幅减少噪音。
- **将 DNS 遥测纳入狩猎。** 这次我依赖了 `DeviceNetworkEvents`，但对 Tor 目录机构的 DNS 查询，或尝试解析 `.onion` 域名（在正常 DNS 中会失败）可能是另一个强有力的早期指标。
- **将所有内容映射到 MITRE ATT&CK。** 将活动标记到特定技术 — `T1090.003`（多跳代理：Tor）是最明显的 — 会让报告对冷启动的 SOC 分析师更有用。
- **在 macOS 和 Linux 上运行相同的狩猎。** 战术、技术和程序（TTP）在不同平台间会有所不同，我想看看当终端不是 Windows 时这会是什么样子 — 不同的路径、不同的进程、不同的 EDR 信号。
*带静默标志的安装程序启动 — 屏幕上很安静，日志里很热闹。*
### 3. 他们真的打开浏览器了吗？
仅安装并不能说明全部问题。很多安装程序运行后就不再被触碰。为了排除这种情况，我在同一设备上搜索 `firefox.exe` 和 `tor.exe` 活动。在 `2025-08-05T20:17:19.0000000Z`，浏览器打开了，随后立即开始生成一系列 `firefox.exe` 和 `tor.exe` 子进程 — 这正是 Tor 运行后预期的进程树。
```
DeviceProcessEvents
| where DeviceName == "lan-vt"
| where FileName has_any ("tor.exe", "firefox.exe", "tor-browser.exe")
| order by Timestamp desc
| project Timestamp, DeviceName, AccountName, ActionType, FileName, FolderPath, SHA256, ProcessCommandLine
```
*进程树确认浏览器确实被启动了，而不仅仅是安装了。*
### 4. 观察网络活动
最后一部分：机器是否真的联系了 Tor 网络？我查询 `DeviceNetworkEvents`，查找从 `tor.exe` 或 `firefox.exe` 发出的、目的地为 Tor 已知端口的任何连接。在 `2025-08-05T20:17:50.0000000Z`，`tor.exe`（运行于 `c:\users\labuser\desktop\tor browser\browser\torbrowser\tor\tor.exe`）向 `37.120.171.230` 的端口 `9001` 打开了连接 — 这是一个典型的 Tor 中继握手。之后有很多后续连接通过端口 `443` 发出。
```
DeviceNetworkEvents
| where DeviceName == "lan-vt"
| where InitiatingProcessAccountName !~ "system"
| where InitiatingProcessFileName in ("tor.exe", "firefox.exe")
| where RemotePort in (9001, 9030, 9040, 9051, 9150, 80, 443)
| project Timestamp, DeviceName, InitiatingProcessAccountName, RemoteIP, RemotePort, RemoteUrl, InitiatingProcessFileName, InitiatingProcessFolderPath
| order by Timestamp desc
```
*向 Tor 入口节点的传出连接 — 电路启动的时刻。*
## 重建的时间线
将四个查询结果整合在一起，让我看到了整个事件的清晰、分阶段视图，从初始下载到主动浏览。
### 阶段 1 — 下载与安装（下午 3:15 – 3:17）
- **下午 3:15:27** — Tor 浏览器安装程序到达 `C:\Users\labuser\Downloads\`
- 文件名：`tor-browser-windows-x86_64-portable-14.5.5.exe`
- SHA256：`6d38a13c6a5865b373ef1e1ffcd31b3f359abe896571d27fa666ce71c486a40d`
- **下午 3:16:47** — 使用静默标志（`/S`）执行安装程序
- **下午 3:17:08 – 3:17:09** — 许可证文件（`tor.txt`、`Torbutton.txt`、`Tor-Launcher.txt`）和 `tor.exe` 解压到 `C:\Users\labuser\Desktop\Tor Browser\`
- **下午 3:17:27** — `Tor Browser.lnk` 快捷方式放置到桌面
### 阶段 2 — 首次启动（下午 3:17 – 3:18）
- **下午 3:17:18 – 3:17:19** — `firefox.exe`（Tor 构建版）启动
- SHA256：`6872f0df504c7a4a308caa86a73c62a51bb6e573107681ab60edbd72126df766`
- **下午 3:17:26** — GPU 辅助进程生成
- **下午 3:17:27 – 3:17:35** — 创建六个内容和实用程序子进程用于标签处理
- **下午 3:17:29** — `tor.exe` 启动；控制端口在 `127.0.0.1:9151` 上运行，SOCKS 代理在 `127.0.0.1:9150`；网络初始由 `DisableNetwork 1` 限制
### 阶段 3 — Tor 电路建立（下午 3:17 – 3:18）
- **下午 3:17:43 – 3:17:50** — 出口到入口和中继节点：
- `95.143.193.125:443`
- `87.118.116.90:443`
- `194.126.174.190:443`
- `37.120.171.230:9001`
- **下午 3:17:50** — 访问隐藏服务，涵盖 `wujjupiz5ut5n.com`、`vynfq5kmdoueyba.com`、`xzejyxz7fr.com` 和 `445dd5l5cr.com`
- **下午 3:17:58** — Firefox 连接到本地 SOCKS 代理 `127.0.0.1:9150` — 电路完全运行
### 阶段 4 — 主动会话（下午 3:18 – 3:55）
大约 40 分钟的持续浏览，随着新标签页和窗口的打开，新的内容进程（子进程 #7 到 #22）被创建。构建 ID 在整个会话中保持一致为 `20250722101758`，排除了浏览器二进制文件被篡改的可能性
## 调查结果
`lan-vt` 上的 `labuser` 于 2025 年 8 月 5 日下午 3:15 开始下载、静默安装并立即启动了 Tor Browser 14.5.5。在浏览器打开后大约两分钟内，Tor 电路就建立起来了，用户开始访问 `.onion` 隐藏服务。该会话持续了大约40 分钟的主动浏览。
从技术层面看，执行得很干净 — 正确的签名、预期的子进程、没有明显的篡改。引人注目的是*行为模式*：静默安装、立即访问暗网，以及在会话期间创建的 `tor-shopping-list.txt` 文件。这个顺序怎么看都不像是无心的好奇
## 响应措施
- 确认了 `lan-vt` 上的 Tor 活动。
- 通过 Defender for Endpoint 隔离了该终端。
- 通知了用户的直接经理，并提供了完整的时间线和支持证据
## 我学到了什么
这是我第一次围绕真实的 EDR 数据集构建狩猎，而不是静态的实验室转储，有几点让我印象深刻：
- **跨表关联至关重要。** 这三个表中的任何一个都只能给出故事的一部分。文件事件告诉我二进制文件存在。进程事件告诉我它运行了。网络事件告诉我它实际上做了什么事。把三者结合起来才能把"这看起来可疑"转化为"这里有一个带有时间戳和 SHA256 哈希值的可辩护时间线。"
- **静默安装比他们想象的更明显。** `/S` 标志本意是向用户隐藏安装，但在 EDR 遥测中它实际上很突出，因为合法的用户驱动安装通常会触发 UAC，而且不会以无头模式运行。这最终成为整个狩猎中最有用的行为线索之一。
- **了解工具有助于狩猎工具。** 了解 Tor 内部使用 9001/9030/9050/9051/9150，以及 `tor.exe` 通常位于安装目录下的 `Browser\TorBrowser\Tor\` 中，让我能够写出比仅仅到处搜索"tor"更精确的查询。
- **写报告是工作的一半。** 把 KQL 写对很令人满足，但把原始行转化为分阶段的叙述才能让工作对除我之外的任何人真正有用
## 后续改进方向
我想回头探索的几个方向：
- **将其转化为检测规则。** 不要手动运行这些查询，而是将模式（便携式浏览器的静默安装 → 几分钟内通过 Tor 端口发出流量）编入 Defender 中的自定义检测，这样下次相同场景就会自动触发。
- **加入基线过滤。** 在真实组织中，一些用户确实会运行看起来可疑的开发工具或隐私工具。批准进程和路径的允许列表应用到整个终端群时会大幅减少噪音。
- **将 DNS 遥测纳入狩猎。** 这次我依赖了 `DeviceNetworkEvents`，但对 Tor 目录机构的 DNS 查询，或尝试解析 `.onion` 域名（在正常 DNS 中会失败）可能是另一个强有力的早期指标。
- **将所有内容映射到 MITRE ATT&CK。** 将活动标记到特定技术 — `T1090.003`（多跳代理：Tor）是最明显的 — 会让报告对冷启动的 SOC 分析师更有用。
- **在 macOS 和 Linux 上运行相同的狩猎。** 战术、技术和程序（TTP）在不同平台间会有所不同，我想看看当终端不是 Windows 时这会是什么样子 — 不同的路径、不同的进程、不同的 EDR 信号。标签：AI合规, APT检测, Conpot, EDR, IP 地址批量处理, KQL, Kusto Query Language, Microsoft Defender for Endpoint, Tor浏览器检测, Windows安全, 匿名网络检测, 威胁情报, 安全运营, 开发者工具, 扫描框架, 暗网检测, 深网, 端点检测与响应, 网络安全, 脆弱性评估, 脱壳工具, 防火墙日志分析, 隐私保护, 隐私保护工具滥用