Dmokom1/Detection-Engineering-EQL-MITRE-Validation

# 检测工程：EQL 序列规则与 MITRE ATT&CK 验证 本项目是在一个为检测工程实践而搭建的独立 Active Directory 实验室中完成的。 ## 项目概述 本项目侧重于从零开始构建和验证一个小型的 Elastic EQL 检测工作流。 其目标是实践在检测工程过程中，端点遥测技术、Windows 审核策略、Sysmon、Elastic 以及 MITRE ATT&CK 映射如何协同工作。我在一台 Windows Server 2022 域控制器上配置了遥测技术，验证了进程命令行数据是否成功传输至 Elastic，模拟了一个受控的多阶段攻击序列，并构建了一个 EQL 序列规则——当同一主机上执行了 `whoami.exe` 并随后发生文件创建行为时，该规则会生成警报。 最终的检测规则被有意限定为一个两阶段的模式： 1. `whoami.exe` 执行 2. 创建文件 `C:\Users\Public\payload.exe` 本项目还包含了一些辅助活动，例如 PowerShell 下载尝试、注册表 Run 键持久化以及 MITRE ATT&CK 覆盖范围审查。这些后续操作有助于提供上下文背景，但它们并未全部包含在最终的 EQL 序列规则中。 ## 为什么构建这个项目 只有当检测规则背后的遥测数据正常工作时，检测规则才是有用的。 我构建这个实验室是为了实践检测工程的流程： 1. 配置端点遥测。 2. 验证日志和字段是否已填充。 3. 模拟类似攻击者的行为。 4. 构建 EQL 序列规则。 5. 触发并审查警报。 6. 记录该规则能检测到什么以及不能检测到什么。 这个项目帮助我理解到，检测工程不仅仅是编写一条规则。更困难的部分是确保数据存在、字段被正确索引，并且规则逻辑与被测试的行为相匹配。 ## 实验室环境与架构 ## 架构 ``` graph LR subgraph "Data Sources" A[Windows Event Logs] B[Elastic Agent] C[Sysmon] end subgraph "SIEM Platform" D[Security Onion] E[Elastic Stack] end subgraph "Detection" F[EQL Rules] G[Sigma Rules] H[Alert Generation] end A --> D B --> E C --> D D --> F E --> F F --> G G --> H ``` *注意：此图代表了实验室环境和调查工作流。* | 组件 | 详细信息 | |---|---| | Hypervisor | VMware Workstation Player 17 | | 目标主机 | Windows Server 2022 Domain Controller | | Domain | `cs.local` | | DC IP 地址 | `192.168.9.142` | | Kali Linux VMNet IP | `192.168.9.136` | | Kali eth1 静态 IP | `10.0.0.5` | | SIEM | Elastic Security / Kibana | | 端点遥测 | 使用 SwiftOnSecurity `sysmonconfig-export.xml` 的 Sysmon | | Windows 日志记录 | 高级审核策略、进程创建审核、命令行日志记录 | | 检测语言 | Elastic EQL | ## 使用的工具与技术 | 工具 | 用途 | |---|---| | Sysmon | 收集端点遥测数据，例如进程创建、文件创建和注册表活动 | | SwiftOnSecurity Sysmon Config | 提供了具有降噪功能的实用 Sysmon 配置 | | Windows Advanced Audit Policy | 启用了进程创建审核和命令行可见性 | | Elastic / Kibana | 审查遥测数据并创建 EQL 检测规则 | | Kali Linux | 提供攻击者/测试系统和静态测试接口 | | MITRE ATT&CK Coverage View | 审查了映射的检测覆盖范围和盲区 | ## 项目流程 本项目遵循以下顺序： 1. 准备 Sysmon 和 SwiftOnSecurity 配置。 2. 在 Domain Controller 上安装 Sysmon。 3. 启用进程可见性所需的 Windows 审核策略设置。 4. 启用进程创建事件的命令行日志记录。 5. 配置 Kali 网络以获得稳定的实验室 IP。 6. 在 Elastic 中验证进程命令行遥测数据。 7. 使用 `whoami` 模拟第一阶段攻击。 8. 在 `C:\Users\Public\payload.exe` 创建暂存文件。 9. 尝试执行 PowerShell 远程脚本。 10. 添加注册表 Run 键以模拟持久化。 11. 在 Elastic 中审查攻击遥测数据。 12. 构建并启用 EQL 序列规则。 13. 重新运行活动以验证警报生成。 14. 审查 MITRE ATT&CK 覆盖范围，了解已映射的可见性和盲区。 ## 阶段 0：遥测设置 在构建检测规则之前，我配置了 Elastic 观察这些活动所需的端点遥测。 这个阶段至关重要，因为如果缺少必要的日志或字段，EQL 规则将无法工作。 ## Sysmon 二进制文件与配置 在 Windows Server 系统上准备了 Sysmon 和 SwiftOnSecurity 配置。  ## 这证明了什么 这确认了在安装之前 Sysmon 二进制文件和配置文件已准备就绪。 SwiftOnSecurity 配置有助于减少嘈杂的遥测数据，同时仍能收集有用的端点事件，例如进程创建、文件创建和注册表活动。 ## Sysmon 安装 使用配置文件安装了 Sysmon。  ## 这证明了什么 这确认了 Sysmon 已成功安装并开始收集端点遥测数据。 这是第一个遥测关卡。如果没有运行 Sysmon，EQL 规则所需的文件和进程事件将无法使用。 ## 审核策略子类别强制执行 启用了 Windows 审核策略子类别强制执行。  ## 这证明了什么 这确认了已启用细粒度的审核策略设置，并且它们将优先于更广泛的审核策略类别。 这有助于确保特定的进程创建设置得到正确应用。 ## 进程创建的命令行日志记录 为进程创建事件启用了命令行日志记录。  ## 这证明了什么 这确认了进程命令行参数将包含在进程创建遥测数据中。 这很重要，因为命令行可见性通常是区分仅仅看到 `powershell.exe` 运行了和了解它实际尝试做了什么的关键。 ## 高级审核进程创建 配置了高级审核策略以捕获进程创建事件。  ## 这证明了什么 这确认了已针对成功和失败事件启用了进程创建审核。 Sysmon 和 Windows 审核策略共同为实验室提供了足够的可见性，以测试进程执行和命令行遥测。 ## 阶段 1：Kali 网络设置 Kali Linux 有多个网络接口。在分配静态地址之前，我检查了接口列表。  随后为 `eth1` 分配了一个静态 IP 地址。  ## 这证明了什么 这确认了 Kali 拥有一个用于测试的稳定实验室地址。 `eth1` 接口显示为： `10.0.0.5/24` Kali VMNet 地址也显示为： `192.168.9.136` 这有助于在审查源或目标活动时保持测试环境的可预测性。 ## 阶段 2：Elastic 中的遥测验证 在运行攻击模拟之前，我验证了 Elastic 正在接收进程命令行数据。  ## 这证明了什么 此截图确认了 Elastic 中已填充 `process.command_line`。 这一点很重要，因为缺少命令行数据会削弱后续的调查和规则开发能力。 这是该项目最重要的经验之一：在编写规则之前先验证遥测数据。 ## 阶段 3：攻击模拟 攻击模拟旨在生成用于检测测试的端点遥测数据。 活动包括： 1. 使用 `whoami` 进行用户/上下文发现 2. 在 `C:\Users\Public\payload.exe` 创建文件 3. 尝试执行 PowerShell 远程脚本 4. 模拟注册表 Run 键持久化 这是一个受控的实验室序列。应将其视为检测练习，而不是真实的入侵事件。 ## 阶段 1：`whoami` 执行 第一个活动是在 Domain Controller 上运行 `whoami`。  ## 这证明了什么 这确认了在 `cs\administrator` 上下文下的执行。 从检测的角度来看，`whoami.exe` 可作为早期的发现信号，但它本身非常嘈杂。管理员和脚本可能会出于正当理由运行 `whoami`。 这就是为什么最终的检测并没有仅针对 `whoami.exe` 发出警报。它使用的是在同一主机上执行 `whoami.exe` 随后发生文件创建这一组合行为。 ## 阶段 2：文件创建与早期攻击遥测 通过将 `calc.exe` 复制到 `C:\Users\Public\payload.exe` 来暂存文件。 模拟还包括对可疑域的 DNS 查询尝试。  ## 这证明了什么 此截图支持两个重要的活动： - 在 `C:\Users\Public\payload.exe` 的文件创建 - 对 `malicious-c2-domain.bit` 的 DNS 查询尝试 DNS 查询失败是因为该域不存在。这作为遥测数据仍然有用，但不应将其描述为成功的命令与控制 (C2) 活动。 文件创建事件成为了最终 EQL 序列规则的第二阶段。 ## 阶段 3：PowerShell 下载尝试 使用 `DownloadString` 尝试通过 PowerShell 进行远程脚本检索。  ## 这证明了什么 此截图显示了一个 PowerShell 下载尝试，使用了： `IEX (New-Object Net.WebClient).DownloadString(...)` 由于远程服务器无法访问，该尝试失败。 这一点很重要：该截图支持了尝试进行 PowerShell 下载的模式，但并不能证明成功检索或执行了有效载荷。 从检测的角度来看，该命令行仍然有用，因为即使连接失败，`IEX`、`DownloadString` 和远程脚本检索模式也是可疑的。 ## 阶段 4：注册表持久化模拟 添加了一个注册表 Run 键以模拟持久化。  ## 这证明了什么 这确认了在以下位置添加了一个 Run 键值： `HKCU\Software\Microsoft\Windows\CurrentVersion\Run` 该值指向： `C:\Users\Public\payload.exe` 这支持了实验室的持久化部分。然而，这个注册表步骤并未包含在最终的 EQL 序列规则中，因为活动中的规则被限定为进程执行后跟文件创建。 ## 阶段 4：Elastic 遥测审查 在攻击模拟之后，使用 Elastic 审查了活动是否出现在遥测数据中。  ## 这证明了什么 此截图确认了 Elastic 包含了来自该活动的进程相关遥测数据，包括与 PowerShell 相关的事件。 重点不在于每一个动作都被自动检测到了。重点在于遥测数据存在，并且可以被搜索、审查和用于检测工程。 ## 阶段 5：EQL 检测规则 最终的 EQL 规则被构建为一个两阶段的序列。 它查找的是： 1. `whoami.exe` 的执行 2. 创建文件 `C:\Users\Public\payload.exe` 这两个事件必须在配置的时间窗口内在同一主机上发生。  ## EQL 规则 ``` sequence by host.name with maxspan=1h [process where process.name : "whoami.exe"] [file where file.path : "C:\\Users\\Public\\payload.exe"] ``` ## 为什么这样构建此规则 该规则被有意设计得简单且专注。 仅靠 `whoami.exe` 不足以构成强有力的检测，因为它可能是合法的。仅靠文件创建也可能很常见。但是，当 `whoami.exe` 执行之后在同一主机上又创建了一个暂存的有效载荷文件时，在实验室检测背景下，这个序列就变得更有意义了。 `host.name` 关联很重要，因为它可以防止来自不同机器的不相关事件满足同一个序列。 ## 此规则无法检测什么 此规则无法检测整个攻击链。 它不直接包含： - PowerShell DownloadString 活动 - DNS 查询尝试 - 注册表 Run 键持久化 - 整体上的 MITRE ATT&CK 覆盖范围 这些活动作为辅助遥测数据进行了审查，但最终的 EQL 警报是基于这个两阶段序列的。 ## 阶段 6：规则重新执行与警报验证 启用规则后，重新运行了攻击序列以验证 Elastic 是否会生成警报。  ## 这证明了什么 这显示了在启用 EQL 规则之后重新执行的测试活动。 该序列包括用户发现、文件暂存、PowerShell 下载尝试和注册表持久化模拟。 需要再次指出的是，由于远程服务器无法访问，PowerShell 下载尝试失败了。检测验证仍然有效，因为 EQL 规则是基于 `ami.exe` 及随后的文件创建。 ## 警报生成 Elastic 为 EQL 序列规则生成了警报。  ## 这证明了什么 这确认了 EQL 序列规则成功触发。 显示的警报是： `Multi-Stage Adversary Execution Chain` 该警报为高严重级别，并关联到主机： `win-hs48gjmnogp` 这在实验室环境中验证了规则逻辑。 ## 阶段 7：MITRE ATT&CK 覆盖范围审查 使用 Security Onion 的覆盖范围视图审查了 MITRE ATT&CK 的覆盖情况。  ## 这证明了什么 此截图显示了 ATT&CK 技术的映射规则覆盖范围。 应将其视为一个覆盖范围概览，而不是证明这一个自定义的 EQL 规则涵盖了每一个高亮的技术。 此步骤的价值在于了解检测覆盖范围存在于何处以及可能存在哪些盲区。 ## 检测逻辑解析 检测规则使用了三个核心理念： ### 1. 序列逻辑 该规则寻找有序的行为： 1. 进程执行 2. 文件创建 这与单事件警报不同，因为该规则关心的是事件之间的关系。 ### 2. 主机关联 该序列使用了 `host.name`，因此两个事件必须发生在同一台机器上。 如果没有该关联，一台主机上的 `whoami.exe` 事件和另一台主机上的文件创建事件可能会意外地满足规则条件。 ### 3. 时间窗口 该序列使用了一小时的时间窗口。 这为暂存行为的发生提供了足够的时间，同时仍保持事件之间的关联性足够紧密。 ## 关键发现与分析 ### 1. 遥测验证先于规则编写 该项目最重要的部分是证明了在构建 EQL 规则之前日志和字段就已经存在。 ### 2. 命令行可见性很重要 命令行日志截图确认了 Elastic 拥有有用的进程命令行数据。这有助于调查和验证。 ### 3. PowerShell 命令失败了，但仍然创建了有用的遥测数据 失败的下载尝试仍然显示了可疑的命令行行为。这对于分析很有用，但不应将其描述为一次成功的有效载荷下载。 ### 4. 最终的 EQL 规则被有意限定了范围 该规则检测到了 `whoami.exe` 以及随后 `C:\Users\Public\payload.exe` 的文件创建。 它并未检测到模拟的每一个阶段。 ### 5. 注册表持久化是辅助遥测数据 Run 键修改是模拟的一部分，但它并非最终 EQL 序列规则的一部分。 ### 6. MITRE 覆盖范围需要谨慎解读 ATT&CK 视图显示了映射的检测覆盖范围，但不应夸大其词地认为它证明了本项目完全涵盖了所有高亮的技术。 ## 局限性 这是一个受控的家庭实验室，而不是一个生产环境的检测管道。 重要局限性： - 该 EQL 规则是针对特定的实验室模式构建的。 - `whoami.exe` 在真实环境中可能会非常嘈杂。 - 在 `C:\Users\Public\payload.exe` 的文件创建是受控的。 - PowerShell 下载尝试失败了，因此不应将其描述为成功的有效载荷检索。 - 注册表持久化动作并非最终 EQL 序列规则的一部分。 - MITRE 截图显示的是覆盖范围映射，而不是完整的检测验证。 - 生产环境的调优需要针对正常的管理员行为和更广泛的端点遥测数据进行测试。 ## 未来版本的改进计划 如果我扩展这个项目，我会通过以下方式进行改进： - 在确认可靠的注册表字段映射后，将注册表持久化添加到单独的检测规则中。 - 为可疑的 PowerShell 命令行模式构建单独的规则。 - 针对良性管理员活动进行测试以减少误报。 - 在 README 中为每个主要事件类型添加 Sysmon Event ID 参考。 - 捕获更清晰的 EQL 警报事件详细信息的截图。 - 跨多台主机测试相同的规则。 - 构建一个简短的检测时间表，将每个模拟动作映射到 Elastic 证据。 ## 截图证据 | 截图 | 展示了什么 | |---|---| | `screenshots/01_Sysmon_Binary_And_Config_Ready.png` | Sysmon 二进制文件和配置文件已就绪 | | `screenshots/02_Sysmon_Installation_Complete.png` | Sysmon 成功安装 | | `screenshots/03_Force_Audit_Policy_Subcategory_Enabled.png` | 审核策略子类别强制执行已启用 | | `screenshots/04_Include_Command_Line_In_Process_Creation_Enabled.png` | 进程创建的命令行日志记录已启用 | | `screenshots/05_Advanced_Audit_Process_Creation_Enabled.png` | 高级审核进程创建已启用 | | `screenshots/06_Kali_Network_Interfaces_List.png` | 分配静态 IP 前的 Kali 网络接口 | | `screenshots/07_Kali_Static_IP_Assigned.png` | Kali `eth1` 配置为 `10.0.0.5/24` | | `screenshots/08_Elastic_Command_Line_Verification_Success.png` | Elastic 显示已填充的 `process.command_line` | | `screenshots/09_Phase1_Whoami_Execution.png` | 作为 `cs\administrator` 执行的 `whoami` | | `screenshots/10_Phase1_Attack_Chain_Telemetry.png` | 文件暂存和可疑的 DNS 查询尝试 | | `screenshots/11_Phase1_PowerShell_Execution.png` | 连接失败的 PowerShell `DownloadString` 尝试 | | `screenshots/12_Phase1_Persistence_Establishment.png` | 注册表 Run 键持久化模拟 | | `screenshots/13_Elastic_Attack_Telemetry_Verification.png` | 对与攻击相关的进程遥测数据的 Elastic 审查 | | `screenshots/14_Multi_Stage_Rule_Activation.png` | 在 Elastic 中启用的 EQL 序列规则 | | `screenshots/15_Full_Attack_Chain_Reexecution.png` | 为进行验证而重新执行的攻击序列 | | `screenshots/16_EQL_Sequence_Alert_Generation.png` | EQL 警报成功生成 | | `screenshots/17_MITRE_ATT&CK_Detection_Coverage.png` | MITRE ATT&CK 覆盖范围概览 | ## 仓库信息 **项目**：Detection-Engineering-EQL-MITRE-Validation **作者**：Dmokom1 **目的**：用于技能培养的网络安全动手实验室 **环境**：配备 Windows Server 2022 DC 的独立家庭实验室 **工具**：参见上文的“使用的工具与技术”部分 ### 使用说明： - 本仓库记录的是一次学习练习，而非生产代码 - 所有截图均来自受控的实验室环境 - 所展示的技术仅用于教育目的 - 请始终遵循组织政策和法律准则 ### 贡献： 虽然这主要是一个个人的学习作品集，但也欢迎大家提出建议和反馈。请开启一个 Issue 来讨论改进方案。

标签：Active Directory, AMSI绕过, Cloudflare, DNS 解析, EQL, IPv6, MITRE ATT&CK, MIT许可证, OpenCanary, Plaso, PowerShell, Sysmon, Terraform 安全, Windows Server 2022, 事件查询语言, 嗅探欺骗, 域控制器, 威胁检测, 安全实验室, 安全运营, 扫描框架, 攻击模拟, 攻击生命周期, 数据展示, 权限维持, 注册表, 私有化部署, 端点遥测, 红队, 网络信息收集, 网络安全, 越狱测试, 防御规避, 隐私保护, 驱动签名利用