alemuscyber/MitreAttack-Lab

# MITRE ATT&CK 技术模拟与检测工程 本实验室在一个隔离的 Azure VM 上使用 Atomic Red Team 模拟了真实的攻击者行为，随后在 Microsoft Sentinel 中为每种技术构建了有效的检测——从原始的 KQL 查询一直到能够生成真实事件的实时、自动化*分析规则* (Analytics Rules)。 涵盖的 Mitre Att&ck 技术如下： | 技术 | 战术 | 检测逻辑 | |:---------:|:-------------------------:|:---------------------------------------------------------------------:| | T1110.001 | 暴力破解密码猜测 | 5 分钟内来自单个账户的 5 次以上失败登录 | | T1018 | 远程系统发现 | 5 分钟内来自单个账户的 2 个以上不同的侦察命令 (net/ping/arp) | | T1059.001 | Powershell 命令执行 | PowerShell 脚本块执行事件 | **架构：** image - Windows 10 VM（隔离的、单一用途的实验室环境 - Log Analytics Workspace + Microsoft Sentinel - 两个 Data Collection Rules： - **Windows Security Events via AMA** connector（内置的 Sentinel content hub 解决方案）-> 输入结构化的 'SecurityEvent' 表，配置为 "**All Security Events**" 层级 - 带有 XPath 'Microsoft-Windows-Powershell/Operational*' 的 **Custom DCR** -> 输入 'Event' 表 **实验操作指南：** 设置好 VM 后，我使用 RDP 访问它，并以提升的权限进入 PowerShell 以启用 auditpol，然后下载 Atomic Red Team，这是一个开源库，用于模拟映射到 MITRE ATT&CK 框架的真实世界攻击技术。 auditpol image installer image 在安装 Atomic Red Team 之后，我浏览了该库以搜索可用的攻击技术。我选择了 T1110.001、T1018 和 T1059.001。让我们逐一了解它们。 **T1110.001 - 暴力破解密码猜测（凭据访问）** 通过 VM 的 powershell 执行了测试： t1110 run image 在此之后，我前往 VM 的内部安全日志以确认此攻击模拟确实生成了日志。结果呈阳性，因此我回到 Azure Log Analytics Workspace 设置 KQL 检测查询，使用的参数包括 EventID 4625、FailedAttempts 的计数函数，并设置了阈值。此 KQL 检测查询成功，证明日志已被正确流式传输到 Azure 且没有任何误报，因为给定的阈值是基于异常的（5 分钟内 FailedAttempts >= 5）。 **T1018 - 远程系统发现** 通过 VM 的 powershell 执行了测试： t1018 run image Atomic Red Team 的测试工作流程正确运行了该测试。然而，由于 VM 本身的性质，侦察并未成功。该 VM 隔离在其自己的虚拟网络中，没有其他机器可以发现。因此，为了本实验的顺利进行，我决定通过环回地址（127.0.0.1 localhost）自行进行侦察。 self recon image 这成功生成了安全日志，因此我回到 Azure 设置 KQL 检测查询，使用的参数包括 EventID 4688、进程搜索（net.exe、ping.exe、arp.exe）并设置了阈值。此 KQL 检测查询成功，确保了日志被正确流式传输到 Azure。 **T1059.001 - Powershell 命令执行** 通过 VM 的 powershell 执行了测试： t1059 run image 好吧，那句 "Hello, from PowerShell!" 让我露出了微笑，但我确信，对于在受控实验室环境之外经历这种攻击的人来说，这绝对是非常可怕的。该技术的 Atomic Red Team 测试在第一次运行后就成功了，我通过审查内部日志确认了这一点。然后前往 Azure 设置我的 KQL 检测查询，使用的参数包括 EventID 4104，并确保源与最初设置的 XPath（Microsoft-Windows-Powershell）匹配。 **Microsoft Sentinel 设置** 如果我们不能将这些检测集中到一个统一的视图（single pane of glass）中，从而允许提供可追踪的证据和符合 Mitre Att&ck 框架的可操作工作流程，那还有什么意义呢？Microsoft Sentinel 为此提供了广泛的功能菜单。我前往 sentinel 设置 Analytics Rules，以成功生成和分类事件。 Brute force rule image Remote system rule image PowerShell Execution Detection image **最终成果：** image final **经验教训** - *检测逻辑需要与技术**实际**生成的内容相匹配——我设置了发现查询，要求以 2 个以上不同的命令作为阈值来避免误报，但 atomic 测试本身只产生了一个； 必须手动扩展模拟行为才能正确测试检测。* - *并非所有已记录的 ATT&CK 技术都有适合平台的可用工具—— 在确定使用某种技术之前验证工具/操作系统兼容性，能节省大量的返工。* - *告警分组设置在运营中很重要：如果没有启用 "**group all alerts from this rule into a single incident**"，单次真实的暴力破解测试在几小时内就生成了超过 300 个重复的 事件——这是一个关于真实 SOC 环境中如何发生告警疲劳的很好提醒。*

标签：AI合规, Atomic Red Team, KQL, Microsoft Sentinel, OpenCanary, 安全实验室, 数据泄露检测