DanKinsiona/Threat-Hunting-with-Splunk
GitHub: DanKinsiona/Threat-Hunting-with-Splunk
记录了在 Splunk 中对 APT29 模拟攻击进行威胁狩猎的完整调查过程，展示了基于行为分析的日志溯源方法。
Stars: 0 | Forks: 0
# 使用 Splunk 进行威胁狩猎：APT29 初始入侵
一项在 Splunk 中执行的对模拟网络攻击的调查。
Splunk 是一款用于收集网络中各台计算机日志文件并支持检索的工具。威胁狩猎意味着主动在这些日志中寻找攻击者的踪迹，而不是被动等待警报触发。
## 场景
该攻击以 APT29（也称为 Cozy Bear）为原型。这是一个被认为效力于俄罗斯情报机构的真实黑客组织，自 2008 年以来，其被指控对多国政府、大学及研究机构发动了网络攻击。
以下是模拟攻击的流程：
1. 用户收到一个看似 Word 文档的文件。它实际上是一个伪装的程序。
2. 用户将其打开。该程序随即运行，并向攻击者控制的服务器发起通信。
3. 攻击者利用该连接在用户的计算机上打开命令提示符，并开始输入指令。
4. 文件被窃取，同时一个更隐蔽的第二个程序被植入，以便攻击者日后再次潜入。
我的任务是从日志中找出上述所有行径的蛛丝马迹。
## 工作方法
起初我并不知道恶意文件的名称，因此无法直接按名称进行搜索。相反，我转而寻找其必然会暴露出的行为。一个伪装成文档的文件绝不应当主动向互联网发起网络连接，因此任何有此类举动的程序都值得深究。
同样的方法也适用于攻击的每个阶段：
1. 分析攻击者的必为之举，以及由此会留下何种痕迹。
2. 梳理哪些日志会包含该痕迹。
3. 将数以千计的事件汇总成一份简明的摘要表，进而排查出格格不入的那条记录。
4. 在推进下一步前，通过第二个来源对结论进行交叉验证。
大部分证据来自名为 Sysmon 的 Windows 工具，它记录了我所依赖的两类信息：**网络连接**（哪个程序向哪个地址的哪个端口发起了通信）以及**进程创建**（哪个程序启动了另一个程序）。
## 阶段
以下检索指令使用 Splunk 的专有检索语言 SPL 编写。
### 1. 查找导致违规的文件
*目标：找到用户打开的文件。*
```
index=* sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
| stats count by Image, DestinationIp, DestinationPort
| sort - count
```
此操作按发起连接的程序、目标地址以及所用端口对网络连接进行分组。这原本能将数以万计的原始事件转化为一张简明易读的表格。
其中一行数据尤为可疑：一个位于用户桌面上的文件，带有文档风格的扩展名，却主动向外网发起了网络连接。正常的文档绝不会这么做。
该文件名暗藏玄机。它使用了一个隐形的控制字符，能够反转其后的文本内容，使得一个程序文件在屏幕上显示时看起来宛如一份 Word 文档。用户眼中看到的是文档，而计算机实际执行的却是程序。
### 2. 查找攻击者的服务器
*目标：找出该文件试图通信的地址。*
```
index=* sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
| stats count, dc(Image) as distinct_processes, dc(DestinationPort) as distinct_ports,
values(Image) as processes, values(DestinationPort) as ports by DestinationIp
| sort - distinct_processes
```
这是同一份数据，只是按目标地址而非程序进行分组。这回答了另一个问题：哪个地址是最繁忙的交通枢纽？
一个地址被数个毫不相干的程序在不同端口上频繁访问。正常的软件绝不会如此行事。合法的程序通常只与自身专属的服务通信，不做他想。毫无关联的程序共享同一目标地址，意味着该地址必然属于攻击者。
### 3. 查找用于连接的端口
*目标：找出该连接使用的异常端口。*
```
index=* sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3 Image="**"
| stats count, dc(DestinationPort) as distinct_ports, values(DestinationPort) as ports by Image, DestinationIp
```
端口就如同计算机上一扇扇带编号的门。Web 流量几乎总是通过 80 和 443 端口出入，因此出现非常规端口号的流量就值得怀疑。
该恶意文件每次都使用同一个异常端口，毫无例外。这表明该地址是攻击者在构建程序时直接硬编码在其中的，而非在运行时动态选取。
### 4. 查找被入侵的计算机
*目标：查明该事件发生在哪台机器上，以及是否波及其他设备。*
```
index=* sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational" Image="**"
| stats count, dc(host) as affected_hosts, values(host) as hosts
```
这一步的意义比表面看来更为重大。如果仅有一台机器受影响，直接拔掉网线即可。但若有十台机器中招，问题就严重得多了。因此，真正的关键不仅在于哪台计算机受影响，还在于有多少台受影响。
所有事件均来自同一台工作站。我还排查了是否有其他机器与攻击者的服务器有过通信，以防第二次感染使用了不同的文件名。
有一点值得直言不讳：这仅仅证明了没有其他*受监控的*计算机受到影响。一台根本不向 Splunk 上传日志的机器无论如何都不会出现在排查结果中。在断言攻击已得到遏制之前，你必须清楚自己实际监控的范围究竟有多大。
### 5. 查找攻击者开启的命令提示符
*目标：找到在网络连接建立后被打开的命令提示符对应的会话 ID (Session ID)。*
```
index=* sourcetype="WinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1 ParentImage="**"
| table _time, host, ParentImage, Image, CommandLine, LogonId, User
| sort _time
```
Windows 会记录哪个程序启动了另一个程序。命令提示符本身极为常见，每天会被打开成百上千次。但一个伪造的 Word 文档去启动命令提示符则绝不正常。
这证实了攻击者已经从单纯的运行程序升级为在机器上主动输入指令。
这一阶段的要点在于获取会话 ID。Windows 会为每个登录会话分配唯一的 ID，在该会话期间打开的每个程序都会携带此 ID。一旦掌握了它，你就能按时间顺序将攻击者在该会话中的所有操作提取出来，汇成一份完整的清单。这就是你从一个可疑线索入手，最终重现整个入侵过程的方法。
## 使用工具
Splunk Enterprise、Windows Sysmon、Windows Security 日志，以及 MITRE ATT&CK（一个公开的攻击者技术目录）。
*该攻击链基于 MITRE 公开发布的 [APT29 adversary emulation plan](https://github.com/center-for-threat-informed-defense/adversary_emulation_library)，并在 2019 年 ATT&CK Evaluations 中被投入使用。*
*本次调查使用了 Immersive Labs 提供的“Threat Hunting with Splunk: Initial Compromise”实验环境。文中的目标陈述均为本人原创概括，同时隐去了具体的文件名、地址和端口。本文旨在记录狩猎方法本身，而非提供特定答案。*
标签：APT29, HTTP工具, IP 地址批量处理, Sysmon, 知识库安全