a-tan-cyber/breach_trace
GitHub: a-tan-cyber/breach_trace
基于 MITRE ATT&CK 框架构建的 SOC 实验室项目，通过 Elastic Security 和 Snort 实现六种模拟攻击 TTP 的端到端检测与告警验证。
Stars: 0 | Forks: 0
**设计与验证对齐 MITRE ATT&CK 的 SOC 告警规则以实现端到端 TTP 检测**
学生姓名：Tan Amos
学生学号：s22
班级代码：CCK3_250714
所属学院：网络安全中心
指导教师：Samson
## 1. 引言
Project Breach Trace 是入侵模拟系列的第二部分，属于安全运营中心 (SOC) 轨道。本报告记录了在受控实验室中完成的从攻击到防御的完整工作流程，其中执行了模拟攻击者的 TTP，并通过 SOC 风格的监控和告警进行了检测。
在 VMware Workstation 虚拟局域网中，攻击从 Kali Linux 虚拟机发起，目标针对 Windows Server 2019 域控和 Linux Web 服务器，其中 pfSense（启用 Snort）提供网络可见性，Elastic Security/Kibana 作为用于分析的集中式 SIEM。
本工作的重点是通过创建和验证与每种场景对齐的告警规则，将可观察的对手行为转化为可操作的检测，包括 SSH 暴力破解、SMB 暴力破解、SMB 枚举、基于 SMB 的数据窃取、哈希转储以及 Pass-the-Hash 以获取 DC shell，还有 ICMP 洪水 DoS。结果完全符合端到端的预期：创建了 6 条自定义规则 → 执行了 6 次攻击 → 触发了 6 种类型的告警。
## 2. 实验环境与拓扑
### 2.1 拓扑
所有攻击均源自 VMware Workstation 虚拟局域网实验室中的 Kali Linux 攻击者虚拟机（**172.16.50.52**）。安全遥测数据被接入到 ELK 服务器（**172.16.50.2**），并使用 Elastic Security/Kibana 进行调查，同时 pfSense/Snort 为 DoS 场景提供了网络 IDS 事件。
### 2.2 系统与 IP 地址
* **pfSense (Netgate) 防火墙/路由器 + Snort IDS：** 172.16.50.1
* **ELK Linux 服务器 (Elastic Stack / Kibana)：** 172.16.50.2
* **域控制器 (Windows Server 2019)：** 172.16.50.254
* **Linux Web 服务器：** 172.16.100.20
* **Kali Linux（攻击者）：** 172.16.50.52
### 2.3 数据源、索引及数据视图
* **主要安全事件索引模式：** `logs-*`（用于攻击 **#1–#5**）
* **防火墙/IDS (pfSense/Snort) 索引模式：** `logs-pfelk-*`（用于 DoS 攻击 **#6**）
* **注意：** 活动的 Elastic Security *数据视图* 决定了哪些索引会显示在 Elastic Security 页面上，以及检测规则可以查询哪些索引。
## **3. 日志前提条件与接入设置**
本节总结了我启用的最低日志记录和接入前提条件，以便 Elastic Security 能够接收到**正确的细节级别**（事件代码、字段和上下文），从而支持为每种攻击场景构建的告警规则。
### 3.1 Windows 域控制器日志前提条件 (DC: 172.16.50.254)
### A) 高级审核策略配置（通过组策略）
为了确保身份验证、SMB 和对象访问活动能够为检测生成一致的安全事件日志，我通过组策略在域控制器上启用了“高级审核策略”子类别。
**操作步骤：**
* 在 DC 上打开**组策略管理**。
* 创建或编辑链接到包含该 DC 的域/OU 的 GPO。
* 导航至：
`计算机配置 → 策略 → Windows 设置 → 安全设置 → 高级审核策略配置 → 系统审核策略`
* 启用所需的审核子类别（根据需要选择成功/失败）。
* 运行 `gpupdate /force` 并确认事件出现在**事件查看器 → Windows 日志 → 安全**中。
**已启用的审核子类别：**
* **登录/注销**
* 审核登录（成功/失败）
* 审核帐户锁定（失败）
* 审核特殊登录（成功）
* **帐户登录**
* 审核凭据验证（成功/失败）
* **对象访问**（用于 SMB/共享活动）
* 审核文件共享（成功/失败）
* 审核详细文件共享（成功/失败）
* **详细跟踪**
* 审核进程创建（成功）
**原理说明：**
* 暴力破解和 Pass-the-Hash 模式依赖于身份验证事件。
* SMB 枚举/数据窃取依赖于共享/文件共享访问审核。
* 进程创建改善了调查上下文（执行了什么、何时执行以及由谁执行）。
### B) 安装并配置 Sysmon
安装 Sysmon 是为了在默认 Windows 日志之外，添加更高保真度的端点遥测（进程、网络及相关活动）。
**操作步骤：**
* 在域控制器上从 Microsoft Sysinternals 下载 **Sysmon** 并将其解压（例如文件夹：`C:\Tools\Sysmon`）。
* 将你的 Sysmon 配置 XML 放在同一文件夹中（例如：`C:\Tools\Sysmon\sysmonconfig.xml`）。
* 以管理员身份打开 **PowerShell**。
* 将目录切换到 Sysmon 文件夹：
* `cd C:\Tools\Sysmon`
* 安装 Sysmon 并加载配置（接受 EULA）：
* `Sysmon64.exe -accepteula -i C:\Tools\Sysmon\sysmonconfig.xml`
* 确认 Sysmon 已安装并正在运行：
* 打开**服务** (`services.msc`) → 验证 **Sysmon64** 是否**正在运行**
* 或者运行：`sc query Sysmon64`
* 如果以后需要更新配置，直接应用无需重新安装：
* `Sysmon64.exe -c C:\Tools\Sysmon\sysmonconfig.xml`
* 确认事件正在被写入：
* 打开**事件查看器**并导航至 Sysmon Operational 日志（`应用程序和服务日志 → Microsoft → Windows → Sysmon → Operational`）。
* 验证最近的 Sysmon 事件是否正在出现（在正常活动后不久你应该能看到新条目）。
### 3.2 将 Windows 日志发送至 ELK (logs-*)
来自 DC 的 Windows 事件被转发到 ELK 服务器 (172.16.50.2)，以便 Elastic Security 可以在 `logs-*` 中查询它们以进行攻击 #1 - #5。
**已发送的数据：**
* **Windows 安全事件日志**（身份验证 + SMB/共享审核）
* **Sysmon Operational 日志**（增强的端点遥测）
**接入方法：**
* 在 DC 上安装 Winlogbeat（常见路径：`C:\Program Files\Winlogbeat\`）。
* 以管理员身份打开 `winlogbeat.yml` 并配置这些 Windows 事件通道：
* `Security`
* `Microsoft-Windows-Sysmon/Operational`
* 配置输出，以便将日志发送到 **172.16.50.2** 上的 ELK pipeline（直接发送到 Elasticsearch 或通过 Logstash，具体取决于你的实验室配置）。
* 启用 Sysmon 解析/标准化，以便将 Sysmon 事件映射到 Elastic 中有用的结构化字段（具体取决于你的配置的 module/pipeline）。
* 从提升的 PowerShell 运行验证测试：
* `winlogbeat test config`
* `winlogbeat test output`
* 将 Winlogbeat 安装为服务（如果尚未安装）并启动它：
* 典型流程：`winlogbeat.exe install-service`
* 然后：`Start-Service winlogbeat`
* 确认 Winlogbeat 正在运行并发送事件：
* 在**服务**中检查 **winlogbeat** = 正在运行
* 在 Kibana **Discover** 中，过滤 `host.ip: 172.16.50.254` 并确认安全事件 + Sysmon 事件正在 `logs-*` 下到达。
### 3.3 Linux Web 服务器日志前提条件 (172.16.100.20)
为了支持 SSH 暴力破解检测和调查，收集了 Linux 身份验证日志并发送至 ELK。
**操作步骤：**
* 确认 SSH 身份验证正在 Linux Web 服务器本地进行日志记录：
* Debian/Ubuntu：`/var/log/auth.log`
* RHEL/CentOS：`/var/log/secure`
* 在 Linux Web 服务器上安装你的日志转发器（Elastic Agent 或 Filebeat）。
* 启用身份验证/系统日志的收集：
* 如果使用 Filebeat：启用 **system** module (auth)。
* 确保转发器正在为你的发行版读取正确的 auth 日志路径（auth.log 还是 secure）。
* 配置输出，使用你实验室的 pipeline（Elasticsearch/Logstash）将事件转发到 ELK（**172.16.50.2**）。
* 启动转发器并确认其持续运行：
* 检查服务状态和日志以确保没有连接/解析错误。
* 生成一个清晰的测试事件：
* 执行 1-2 次失败的 SSH 登录，以便你可以轻松验证接入和字段解析。
### 3.4 pfSense + Snort（通过 logs-pfelk-* 提供的 DoS 遥测源）
ICMP 洪水 DoS 场景是使用 pfSense (172.16.50.1) 上的 Snort 检测到的。这些 IDS 告警被转发到 ELK 并存储在 `logs-pfelk-*` 下，该索引仅用于 DoS 检测规则。
**操作步骤：**
* 在 pfSense 上安装 Snort：
* pfSense UI → **System → Package Manager → Available Packages**
* 搜索 **Snort** → **Install**
* 在正确的接口上启用 Snort：
* **Services → Snort → Interfaces**
* 添加/选择承载你实验室流量（LAN/内部）的接口
* 在该接口上启用 Snort
* 配置基准 Snort 设置以便生成并记录告警：
* 确保为该接口启用了告警记录
* 适当设置受保护网络（HOME\_NET 应覆盖你的实验室子网，例如 `172.16.50.0/24` 和 `172.16.100.0/24`）
* 启用与 ICMP 洪水相关的规则/签名：
* 在 Snort 规则管理/类别中，启用生成 ICMP 洪水告警的规则
* 验证 Snort 是否正在生成告警：
* 首先触发一个短暂的 ICMP 突发（安全测试）
* 确认在 Snort 告警视图中出现告警
* 将 pfSense/Snort 日志转发到 ELK (pfELK pipeline)：
* pfSense → **Status → System Logs → Settings**
* 配置 **Remote Logging Options** 以将日志发送到 **172.16.50.2**
* 确保在被转发的日志中包含 Snort 告警日志（基于你的 pfSense/Snort 日志记录设置）
* 确认日志在 Kibana 的 `logs-pfelk-*` 下显示：
* Kibana **Discover** → 选择包含 `logs-pfelk-*` 的数据视图
* 过滤 pfSense/Snort 事件，并确认出现了与你的测试时间戳匹配的 ICMP 告警
## 4. 检测内容概述
### 4.1 已创建规则
我为**每种攻击场景创建了一条检测规则**，从而产生了 **6 条自定义规则**：**5 条阈值规则**（SSH 暴力破解、SMB 暴力破解、SMB 枚举、SMB 数据窃取、通过 Snort 事件的 ICMP 洪水/DoS）和 **1 条使用 EQL 的事件关联规则**（导致在域控制器上成功获取 shell 的 Pass-the-Hash）。
对于攻击者行为在短时间窗口内产生*突发*或*高数量*类似事件（例如，反复的身份验证失败或反复的 IDS 告警）的情况，使用阈值规则非常合适，这使得它们非常适合暴力破解和洪水式的模式。
Pass-the-Hash 场景作为 EQL 事件关联规则实施，因为最好将其验证为在定义时间范围内发生的**一系列相关事件**，而不是单次计数的阈值。
### 4.2 使用的仪表板
为了跟踪安全活动并确认规则按预期运行，我使用了 Elastic Security 的内置仪表板：
* **概览仪表板** — 提供测试窗口期间当前告警和事件的高级快照。
* **检测规则监控仪表板** — 提供对检测规则执行情况的可见性，包括规则是否成功运行及其整体健康状况/性能。
### 4.3 在 Kibana 中创建检测规则
本项目中的所有告警规则均使用以下导航从 Elastic Security 界面创建：
* **左侧菜单 → Security → Rules → Detection rules (SIEM) → Create new rule**
在“Create new rule”工作流程中，我选择了适当的规则类型（针对突发/基于计数的攻击选择 **Threshold**，针对 Pass-the-Hash 序列选择 **Event Correlation (EQL)**），设置了数据源（例如 `logs-*` 或 `logs-pfelk-*`），并配置了查询、阈值/关联逻辑、计划和告警元数据，然后启用规则。
## **5. 逐次攻击验证**
本节通过展示 (1) 攻击者活动、(2) 为该活动创建的检测规则，以及 (3) 在 Elastic Security 中生成的告警，来验证每种攻击场景。
*注意：* 所有攻击均通过运行带有为 Breach Trace 实现的附加功能的 **Project Breach Point (Part 1)** 脚本来执行；本报告侧重于检测结果，因此有关完整的命令和执行细节，请参阅随附的 **.sh** 文件。
为了保持一致性，每个小节都遵循相同的证据流程：**终端输出 → 规则配置 + 逻辑 → 触发的告警（Alerts 页面）**。
### **5.1 攻击 1 — 针对 Linux Web 服务器的 SSH 暴力破解**
**MITRE ATT&CK：** 暴力破解：密码猜测 (**T1110.001**)
从 Kali（**172.16.50.52**）出发，我使用 **Hydra** 对 Linux Web 服务器（**172.16.100.20**）执行了 SSH 暴力破解尝试，以便在短时间窗口内产生重复的身份验证失败。
**构建的规则（阈值；索引：** **`logs-*`****）：**
**KQL：** `host.os.type: linux AND event.category: authentication AND event.action: ssh_login AND event.outcome: failure`
**分组依据：** `source.ip`, `host.name`
**检测逻辑：**
当**单个源 IP** 在约 **2 分钟的滚动窗口**内（例如：**每 1 分钟运行一次**，**额外回溯 1 分钟**）针对**同一主机**生成 **≥ 10 次失败的 SSH 登录**时触发告警。
**原理说明：**
* **Linux + 身份验证 + ssh_login** 将规则缩小到仅限*SSH 登录尝试*（不包括其他日志类型），使用了 ECS 分类和更具体的 `event.action` 字段。
* **`event.outcome: failure`** 隔离了暴力破解信号（重复的失败）。
* **分组依据** **`source.ip`** **+** **`host.name`** 保持告警的可操作性（谁攻击了什么），并与 Elastic 对 SSH 暴力破解的建模方式（同一源 → 同一目标）相匹配。
* **计划 + 回溯：** Elastic 建议使用 **≥ 1 分钟**的额外回溯，以避免在执行发生漂移时遗漏告警。
**调优：** Elastic 预置的 SSH 暴力破解规则在嘈杂的环境中使用较高的突发阈值（例如，**15 秒内失败 25 次**或 **30 秒内失败 60 次**）；在内部实验室中，**约 2 分钟内失败 10 次**是一个实用的基线，它仍然可以捕获 Hydra 的行为，同时减少“一次性输入错误”的噪音。
**验证：**
告警在攻击窗口期间触发；**source.ip = 172.16.50.52** 且 **destination.ip/host = 172.16.100.20**。
### **5.2 攻击 2 — 针对域控制器的 SMB 暴力破解**
**MITRE ATT&CK：** 暴力破解：密码猜测 (**T1110.001**)
从 Kali（**172.16.50.52**）出发，我使用 **Hydra** 对域控制器（**172.16.50.254**）执行了重复的 SMB/NTLM 登录尝试，以产生大量失败的网络身份验证事件。
**构建的规则（阈值；索引：** **`logs-*`****）：**
**KQL：** `host.os.type: windows AND event.code: 4625 AND winlog.event_data.LogonType: 3`
**分组依据：** `source.ip`, `user.name`, `host.name`
**检测逻辑：**
当**单个源 IP** 在约 **2 分钟的滚动窗口**内（例如：**每 1 分钟运行一次**，**额外回溯 1 分钟**），针对**同一用户 + 主机**生成 **≥ 10 次失败的网络登录**（**LogonType 3**）时触发告警。Elastic 建议使用 **≥ 1 分钟**的额外回溯，以减少在规则执行发生漂移时遗漏告警的情况。
**原理说明：**
* **`event.code: 4625`** 针对的是 Windows “帐户登录失败”事件，这是暴力破解活动期间重复登录失败的主要信号。
* **`winlog.event_data.LogonType: 3`** 缩小到了**网络**登录（类型 3），这是通过网络到达的 SMB 式身份验证尝试的预期登录类型。
* **`host.os.type: windows`** 保持检测专注于 Windows 身份验证遥测（减少不相关的非 Windows 噪音）。
* **分组依据** **`source.ip`** **+** **`user.name`** **+** **`host.name`** 通过将激增情况与**谁**成为目标、在**哪里**以及**从哪个攻击者 IP**（例如，Kali → DC）联系起来，使告警变得精确且可操作。
**调优：** Elastic 预置的 Windows“多次登录失败”内容寻找的是失败**网络**登录的**大容量突发**，并在其参考规则查询中使用了极高的阈值（例如：**每 60 秒 ≥ 100 次失败**）——适用于嘈杂的环境。对于希望进行早期检测（且背景噪音较小）的内部实验室/DC，**约 2 分钟内失败 10 次**是一个合理的基线，它仍然可以可靠地捕获 Hydra 的行为，而不会因一次性的错误操作而触发告警。
**验证：**
告警在攻击窗口期间触发；**source.ip = 172.16.50.52** 且 **destination host = 172.16.50.254** (DC)。
### **5.3 攻击 3 — 针对域控制器的 SMB 枚举**
**MITRE ATT&CK：** 网络共享发现 (**T1135**)
从 Kali（**172.16.50.52**）出发，我使用 `smbclient` 枚举了域控制器（**172.16.50.254**）上的 SMB 共享，以识别可访问的共享，并验证共享发现行为是否对 Elastic Security 可见。
**构建的规则（阈值；索引：** **`logs-*`****）：**
**KQL：** `host.os.type: windows AND event.code: 5140 AND winlog.event_data.ShareName: \\*\\IPC$`
**分组依据：** `source.ip`, `user.name`, `host.name`
**检测逻辑：**
当**单个源 IP** 在约 **5 分钟的滚动窗口**内（例如：**每 1 分钟运行一次**，**额外回溯 4 分钟**），针对**同一用户 + 主机**生成 **≥ 3 次 IPC$ 共享访问事件 (5140)** 时触发告警。
**原理说明：**
* **`host.os.type: windows`** 将规则的范围限定为仅 Windows 共享访问遥测，从而减少了不相关的匹配。
* **`event.code: 5140`** 专门捕获“访问了网络共享对象”，这是在 DC 上跟踪 SMB 共享访问的核心事件。
* **`ShareName: \\*\\IPC$`** 专注于 **IPC$ 管理共享**，该共享的存在是为了支持**命名管道通信**；共享发现通常会在远程共享枚举工作流程中涉及 IPC$。
* **分组依据** **`source.ip`** **+** **`user.name`** **+** **`host.name`** 通过将突发情况与**谁**执行了枚举、**从哪里**执行以及目标**是哪台主机**联系起来，从而保持告警的可操作性。
**调优：** Microsoft 指出，当第一次尝试访问共享时，事件 **5140 在每个会话中生成一次**。因为枚举工具可能会创建**多个短暂的连接/会话**，在**更长的窗口**内使用**更低的阈值**（例如，**5 分钟内 3 次**）是发现重复 IPC$ 访问而不对单次正常连接进行标记的实用基线。
Splunk 还强调，事件 ID **5140/5145** 可用于狩猎网络共享发现，并且重复的 IPC$ 访问模式可能是共享枚举活动的标志。
**验证：**
告警在攻击窗口期间触发；**source.ip = 172.16.50.52** 且 **destination host = 172.16.50.254** (DC)。
### **5.4 攻击 4 — 针对域控制器的 SMB 数据窃取**
**MITRE ATT&CK：** 通过替代协议进行数据窃取 (**T1048**)
从 Kali（**172.16.50.52**）出发，我使用 `smbclient` 从 DC 的 SMB 共享（**172.16.50.254**）中复制文件，以模拟通过 SMB 进行数据窃取的过程。
**构建的规则（阈值；索引：** **`logs-*`****）：**
**KQL：** `host.os.type: windows AND event.code: 5145 AND winlog.event_data.ShareName: \\*\\SMB_share`
**分组依据：** `host.name`, `user.name`, `source.ip`
**检测逻辑：**
当**单个源 IP** 在约 **5 分钟的滚动窗口**内（例如：**每 1 分钟运行一次**，**额外回溯 4 分钟**），针对**同一用户 + 主机**的 **SMB_share** 生成 **≥ 30 条事件 ID 5145** 记录时触发告警。
**原理说明：**
* **`event.code: 5145`** 由**审核详细文件共享**生成，并在**文件/文件夹访问级别**记录活动（即，它记录了*每次*通过共享访问文件或文件夹的情况），使其非常适合发现复制/数据窃取中典型的快速/批量访问。
* **`ShareName: \\*\\SMB_share`** 将检测范围缩小到实验室数据窃取场景中使用的特定共享，从而减少了由于正常访问其他共享而引起的噪音。
* **分组依据** **`source.ip`** **+** **`user.name`** **+** **`host.name`** 通过将活动与**发起主机 (Kali)**、**所使用的帐户**以及**目标系统 (DC)** 联系起来，从而保持告警的可操作性。
* **设置阈值**非常重要，因为事件 5145 可能会**非常嘈杂**：对于一次单一的“用户操作”（目录列表、文件打开、读取、元数据检查），可能会生成多条 5145 条目。基于计数的规则有助于区分批量活动与一次性访问。
**调优：** 事件 5145 通常被 SIEM 内容用于检测网络共享上的**高频文件复制**。例如，Splunk 针对“网络共享中的高频文件复制”的检测逻辑就是基于 5145 构建的，并在 **5 分钟的存储桶**内评估活动，其阈值只有在计数明显高于基线时触发（包括平均值超过 ~20 的情况）。这支持将**“约 5 分钟内几十次”**的范围作为起点，然后根据正常的共享使用情况进行调整。
**验证：**
告警在攻击窗口期间触发；**source.ip = 172.16.50.52** 且 **destination host = 172.16.50.254** (DC)。
### **5.5 攻击 5 — 哈希转储 + Pass-the-Hash 获取 DC shell**
### **5.5.1 哈希转储（从 DC 转储凭据）**
**MITRE ATT&CK：** OS 凭据转储：NTDS (**T1003.003**)
从 Kali（**172.16.50.52**）出发，我使用 Impacket 工具从域控制器（**172.16.50.254**）中转储了与 NTDS 相关的凭据材料，作为 Pass-the-Hash 测试的先决条件。
### **5.5.2 Pass-the-Hash（EQL 事件关联规则 → 获取 shell）**
**MITRE ATT&CK：** 使用备用身份验证材料：Pass the Hash (**T1550.002**)
使用转储的哈希材料，我在没有明文密码的情况下对域控制器（**172.16.50.254**）进行了身份验证，并从 Kali（**172.16.50.52**）获取了交互式 shell。
**构建的规则（事件关联 / EQL；索引：** **`logs-*`****)：**
**EQL 查询：**
`sample by host.name [ any where event.code: "4776" and winlog.event_data.Status: "0x0" ] [ any where event.code: "4624" and winlog.event_data.LogonType: "3"
and winlog.event_data.AuthenticationPackageName: "NTLM"
and event.outcome : "success"
] [ any where event.code: "4688" and process.parent.name: "WmiPrvSE.exe" and process.name: "cmd.exe"
] [ any where event.code: "5145" and winlog.event_data.ShareName : "\\\\*\\ADMIN$" and winlog.event_data.RelativeTargetName : "__*"
]`
**检测逻辑：**
当 DC 显示出与用于远程执行的 Pass-the-Hash 相符的**相关事件集合**时触发告警：成功的 NTLM 凭据验证 → 成功的 NTLM 网络登录 → 由 WMI 生成的 `cmd.exe` → 访问了以 `__` 开头的 `ADMIN$` 文件（Impacket WMIExec 风格命令输出重定向的典型特征）。
**原理说明（简明）：**
* **带有 Status** **`0x0`** **的 4776** 表示在 DC 上**进行了成功的 NTLM 凭据验证**，使其成为用于关联的强有力“身份验证成功”锚点。
* **4624 LogonType 3 + NTLM + 成功**确认了**使用 NTLM 进行的成功网络登录**，这与通过网络执行 PtH 的常见方式相一致（并且与专注于异常 NTLM LogonType 3 活动的 ATT&CK 检测指南相匹配）。
* **4688，其中** **`WmiPrvSE.exe`** **生成了** **`cmd.exe`**，这是**基于 WMI 的远程执行**的高信号指标，这是 Impacket WMIExec 类行为的常见模式。
* **5145 访问了** **`\\*\\ADMIN$`** **且** **`RelativeTargetName: "__*"`**，它捕获了 SMB 工件，其中**命令输出被重定向到** **`ADMIN$`** **上以** **`__`** **开头的临时文件**，多个防御者将其记录为 Impacket WMIExec 活动的标志。
* **为何使用 EQL** **`sample by host.name`****：** EQL 的 `sample` 通过 join key（这里指目标主机）关联事件，即使时间/顺序在不同的日志源中并不完全一致——这对于多日志源的 PtH 追踪非常有用。
**验证：**
关联告警在攻击窗口期间在 DC（**172.16.50.254**）上触发，与从 Kali（**172.16.50.52**）发起的 PtH shell 活动相匹配。
### **5.6 攻击 6 — 针对部分 Linux Web 服务器的 DoS**
**MITRE ATT&CK：** 网络拒绝服务：直接网络洪水 (**T1498.001**)
从 Kali（**172.16.50.52**）出发，我对 Linux Web 服务器（**172.16.100.20**）执行了 **ICMP 洪水**。该场景是使用转发到 Elastic 中 **`logs-pfelk-*`** 下的 pfSense/Snort 遥测数据检测到的。
**构建的规则（阈值；索引：** **`logs-pfelk-*`****)：**
**KQL：**
`network.transport: ICMP AND
(destination.ip: 10.0.0.0 to 10.255.255.255 OR
destination.ip: 172.16.0.0 to 172.31.255.255 OR
destination.ip: 192.168.0.0 to 192.168.255.255)`
*(这些目标范围代表 RFC1918 私有网络。)*
**分组依据：** `source.ip`, `destination.ip`
**检测逻辑：**
当来自**同一 source.ip** 到**同一 destination.ip** 的 **ICMP 事件**在 1 分钟内超过 **≥ 5 个事件**时触发告警（例如：**每 1 分钟运行一次**，**额外回溯 1 分钟**）。Elastic 建议使用 **≥ 1 分钟**的额外回溯，以减少在规则执行发生漂移时遗漏告警的情况。
**原理说明：**
* **`network.transport: ICMP`** 专门过滤 ICMP 流量，这在直接网络洪水（Ping 洪水）中很常见。
* **目标限制为 RFC1918 范围**，使检测专注于**内部/私有实验室目标**，避免了不相关的公共 IP 流量。
* **按** **`source.ip`** **和** **`destination.ip`** **进行分组**使得告警具有可操作性（谁正在向哪个目标发起洪水），并防止将不相关的 ICMP 流量聚合在一起。
**调优：** 由于这些是**源自 pfSense/Snort 的事件**（而非原始的数据包捕获），**较低的阈值**（例如，**1 分钟内 5 次告警/事件**）通常足以确认**持续的洪水攻击**，同时避免因偶尔的 Ping/诊断活动而产生误报。如果你的数据集记录了*每一个 ICMP 数据包*（而不是 IDS 告警），请大幅提高阈值，并根据你的基线进行调优。
**验证：**
告警在攻击窗口期间触发；**source.ip = 172.16.50.52** 且 **destination.ip/host = 172.16.100.20**。
## 6. 讨论与改进
总体而言，检测按预期工作，因为每种规则类型都匹配了攻击者行为潜在的“形状”。
**阈值规则**对于暴力破解、SMB 活动和 ICMP 洪水非常有效，因为这些操作会在短时间内产生**大容量的类似事件突发**（例如，重复的身份验证失败、重复的共享访问记录或重复的 IDS/网络事件）。
相比之下，**Pass-the-Hash** 最好表现为一个**多步骤链条**（成功的 NTLM 验证 → 网络登录 → 后续执行和访问），因此 **EQL 事件关联**规则通过将相关事件关联到单个检测中，而不是仅仅依赖计数，从而提供了更强的保真度。
将 `source.ip`、`user.name` 和 `host.name` 等字段进行分组，通过清楚地识别**谁攻击了什么**，使告警保持具体且具有可操作性。
对于真实的组织而言，主要的调优目标将是在保持早期检测的同时减少误报。我将按子网和主机角色建立“正常”身份验证和共享访问行为的基线，然后针对面向互联网的系统和内部服务器，以及特权帐户和标准用户，应用**不同的阈值**。
我还将为已知的运维跳板机、漏洞扫描程序或会合理产生 SMB 或身份验证噪音的定时管理工具添加**规则例外/允许列表**。
最后，我将标准化计划以平衡及时性与可靠性，并保持一致的**额外回溯**，以减少在规则执行发生漂移期间的漏报，同时利用严重性/风险评分来确定高置信度告警的优先级（例如，基于关联的 PtH 检测）。
**我接下来要添加的内容：**
* 添加更丰富的遥测数据（例如，扩展的 Sysmon 覆盖范围和/或网络流/数据包可见性），以改善上下文并减少歧义。
* 为某些规则（例如暴力破解）创建具有不同严重性和阈值的“高置信度”和“低置信度”版本。
* 扩展横向移动的关联（例如，将 NTLM 登录 + 远程执行 + SMB 管理共享工件结合到一个调查视图中）。
* 通过针对攻击者 IP、目标主机和最常用用户名的下钻来改进仪表板，并为每个场景添加一个快速的“攻击时间线”面板。
* 定义与每个告警相关联的响应剧本（分类步骤、验证查询、遏制措施），以加快分析师的工作流程。
## 7. 结论
本项目在受控实验室环境中验证了跨越**六次**模拟攻击的 SOC 风格检测，每种场景都在 Elastic Security 中产生了预期的告警。
**阈值规则**对于突发的大容量模式证明是最有效的，例如 SSH/SMB 暴力破解、SMB 共享活动和 ICMP 洪水行为，其中短时间窗口内的重复事件是核心信号。对于使用**Pass-the-Hash** 进行的横向移动，**EQL 事件关联**规则通过将多个相关的 Windows 事件链接到一个单一的高保真检测中，从而提供了最高的价值。
总体而言，结果表明使用基于主机和网络/IDS 的遥测数据，实现了从攻击者执行到 SIEM 告警的可靠端到端可见性。
## 8. 参考
### MITRE ATT&CK
MITRE ATT&CK. (n.d.). Brute Force: Password Guessing (T1110.001).
Elastic. (n.d.). About detection rules (rule types overview).
Elastic. (n.d.). Manage detection alerts (Alerts page workflow).
Elastic. (n.d.). Overview dashboard (alerts/events snapshot).
Elastic. (n.d.). Detection rule monitoring dashboard (rule execution health/performance).
Elastic. (n.d.). Data views and Elastic Security (active data view controls what appears in Security pages).
Elastic. (n.d.). Data views (Kibana data view fundamentals).
### Windows 日志记录前提条件（审核策略 + Sysmon）
Microsoft. (2025). Advanced Audit Policy Configuration settings (Windows Server).
Microsoft Sysinternals. (2024). Sysmon (System Monitor).
标签：AMSI绕过, Elastic Security, Modbus, XXE攻击, 威胁检测, 安全实验室, 越狱测试