khaledmedz/Defender-XDR-Detection-Engineering

# Defender-XDR 检测工程 端到端安全实验室，演示 MDE 环境加固、持久化攻击模拟，以及 KQL 自定义检测规则创建。 ## 目标 本项目的目的是从零开始构建、配置并验证一个完整的 Microsoft Defender for Endpoint (MDE) 环境。该实验室涵盖了完整的安全运营生命周期：云基础设施配置、环境加固、攻击模拟、警报分类、使用 KQL 进行自定义检测工程，以及事件响应手册的执行。 ## 工具与技术 - **平台：** Microsoft Defender XDR, Microsoft Azure (虚拟机) - **防御工程：** 攻击面减少 (ASR)、EDR 阻止模式、防篡改保护 - **检测工程：** Kusto 查询语言 (KQL)、近实时 (NRT) 规则 - **框架：** MITRE ATT&CK (T1053, T1106, T1057) ## 阶段 1：环境设置与加固 在模拟威胁之前，部署基础设施、确保传感器正常通信并建立安全基线至关重要。 ### 1. 基础设施配置与上线 我在 Microsoft Azure 中配置了一台 Windows 虚拟机，并通过本地上线脚本将其成功上线到 Defender XDR 门户。  *描述：在 Azure 门户中运行的 Windows 虚拟机 (`azurevm-endpoint`)，代表目标端点。*  *描述：在 Microsoft Defender 门户中进行的验证，显示设备已成功通信并显示“已上线”状态。* ### 2. 启用 Defender 核心功能 为了强化端点以抵御篡改和活跃威胁，我在整个租户范围内全局启用了高级安全功能。  *描述：配置为启用 EDR 阻止模式、防篡改保护和实时响应功能的全局设置。* ### 3. 配置自动调查与修复 (AIR) 我为该端点配置了一个特定的设备组，将修复级别设置为在采取破坏性操作之前需要分析师批准。  *描述：** 将目标设备组 (`endpoints-groupe2`) 配置为完全修复，以允许自主进行威胁遏制。* ### 4. 攻击面减少 (ASR) 为了主动缩小攻击面，我实施了针对常见恶意软件传递机制（例如，恶意 Office 宏）的 ASR 规则。  *描述：主动部署的 ASR 规则，用于阻止 Office 应用程序创建子进程或注入代码。* ### 5. 警报通知 为了确保在事件发生时具有立即可见性，我创建了一项自定义通知规则，用于将高优先级警报路由到 SOC 邮箱。  *描述：针对目标设备组作用域的自定义电子邮件通知规则。* ### 6. 基线遥测验证 在发起攻击之前，我运行了一次基线 KQL 查询，以验证进程事件是否成功从 VM 路由到高级搜寻日志。  *描述：高级搜寻查询 (`DeviceProcessEvents | take 10`) 返回了标准的后台进程，确认日志摄取正常。* ## 阶段 2：攻击模拟（持久化） 为了测试环境的防御能力，我模拟了一种高级持续性威胁 (APT) 通常使用的持久化技术，以便在系统重启后继续存活。 **执行命令：** ``` schtasks /create /sc minute /mo 5 /tn "Updater" /tr "powershell.exe -Command whoami" ```  *描述：在受害 VM 上通过命令行执行恶意计划任务 payload。* ## 阶段 3：事件分类与响应 Defender XDR 立即识别并拦截了计划任务 payload，并为 SOC 生成了一个事件。 ### 1. 警报生成与恶意软件拦截 Defender 标记了该活动，将其归因于 'Ceprolad' 恶意软件家族，并主动阻止了命令行的执行。  *描述：显示被阻止的 'Ceprolad' payload 以及中等暴露级别的事件仪表板。* ### 2. 进程树与 MITRE ATT&CK 映射 调查警报故事揭示了确切的执行链。Defender 成功将文件能力映射到特定的 MITRE ATT&CK 技术。  *描述：显示被阻止的 `powershell.exe` 的事件时间线，以及对 T1106（Native API）和 T1057（进程发现）技术的识别。* ## 阶段 4：自定义检测工程 (KQL) 仅仅依赖供应商提供的签名是一种被动的做法。为了主动检测整个环境中任何未经授权的计划任务创建行为，我设计了一条行为检测规则。 **Kusto 查询语言 (KQL) 逻辑：** ``` DeviceProcessEvents | where ProcessCommandLine contains "schtasks" and ProcessCommandLine has "/create" | where not(InitiatingProcessFileName in ("explorer.exe", "services.exe")) | project Timestamp, DeviceName, ActionType, FileName, ProcessCommandLine, InitiatingProcessFileName ``` *调优上下文：有意排除了合法的父进程 (`explorer.exe`, `services.exe`)，以最大限度地减少误报并防止 SOC 警报疲劳。*  *描述：自定义 KQL 查询在 DeviceProcessEvents 表中成功搜寻特定的 `schtasks` 行为。*  *描述：配置检测规则，以便在将来发生类似情况时自动触发调查。* ## 阶段 5：事件响应手册 在禁用自动调查的场景中，我将执行手动遏制。 **手动 IR 执行步骤：** 1. **遏制：** 通过 Defender 门户执行“隔离设备”，切断网络连接，同时保持 MDE 管理通道。 2. **取证收集：** 启动实时响应会话，以收集内存转储、运行中的进程以及网络连接。 3. **修复：** 通过实时响应远程移除持久化机制： schtasks /delete /tn "Updater" /f 4. **根除：** 终止发起进程（例如 `powershell.exe`）并触发完整的、离线的 Microsoft Defender 防病毒扫描。 5. **事件后活动：** 升级至 Tier 3/威胁搜寻，以调查初始访问向量并确定攻击者是如何获得执行权限的。  *描述：从 Defender 设备清单菜单执行“隔离设备”操作，以实现网络遏制。*

标签：GitHub Advanced Security, KQL, 安全加固, 安全实验室, 微软Defender, 端点检测与响应, 脱壳工具