defender-xdr

Microsoft Defender XDR

Microsoft Defender XDR 是一套统一的入侵前和入侵后防御套件。它可原生关联来自终端（MDE）、身份（MDI + Entra ID Protection）、邮件/协作（MDO）和云应用（MDA）的信号，从而生成一个优先级明确的事件，并呈现完整的攻击过程——关系图、时间线、证据和建议操作。

适用场景

需要从一个门户（security.microsoft.com）对整个 Microsoft 365 环境开展协同检测和响应，而不是分别调查各个工作负载时。也适用于需要使用攻击中断功能的场景——该功能需要 XDR 关联。

以下场景不应使用此技能：摄取第三方日志或针对非 Microsoft 数据源编写自定义 KQL 检测（sentinel）、将 Sentinel + Defender 合并到一个门户（unified-secops-platform），或调整仅适用于终端的策略（defender-for-endpoint）。

将信号映射到源工作负载

XDR 的效果取决于向其提供信号的工作负载。使用此表确认已接入的工作负载，以及缺失的警报。

如果信号是……	源工作负载	所需许可证
设备上的进程树、网络连接、文件哈希	Defender for Endpoint (MDE) P2	M365 E5 / MDE P2
Kerberos 异常、DCSync、AD CS 滥用、本地横向移动	Defender for Identity (MDI)	M365 E5 / EMS E5
有风险的登录、泄露的凭据、异常的令牌使用	Entra ID Protection	Entra ID P2
点击钓鱼 URL、恶意附件引爆、BEC	Defender for Office 365 P2	M365 E5 / MDO P2
有风险的 OAuth 应用、异常的 SaaS 上传、MCAS 风格的警报	Defender for Cloud Apps (MDA)	MDA 独立许可证或 E5
Azure 资源警报、AKS Pod 遭到入侵	Defender for Cloud	基于计划的 DfC

**经验法则：**如果事件显示“1 个警报、1 个实体”，则说明有工作负载缺失。真实攻击总会涉及上述至少两种工作负载。

方法

1. 先接入核心工作负载——顺序如下：MDE（端点信号最丰富）、MDI（横向移动）、Entra ID Protection、MDO。若 SaaS 应用在范围内，再添加 MDA。每个工作负载即使接入各自的门户，也仍会显示在统一的 Defender 门户中。 验证：24 小时后，Incidents 视图显示至少 3 种不同 ServiceSource 值的警报。

2. 大范围启用前配置统一 RBAC——从各工作负载独立的角色迁移到 Microsoft Defender XDR Unified RBAC（security.microsoft.com → Permissions）。按数据源和权限级别构建自定义角色。先以活动目录模式试点 30 天，再强制执行。 验证：Tier-1 分析师可以分类处置并遏制威胁，但无法修改策略；Tier-3 分析师可以调整检测，但无法更改 RBAC。

3. 按事件调查，而不是按警报调查——事件会将相关警报、资产和证据与攻击图关联起来。始终从 Incidents 队列开始。攻击图会在一个视图中展示跨工作负载的攻击链。 验证：打开一个包含多个警报的事件；图中会显示跨工作负载关联的实体（用户、设备、邮箱、IP）。

4. 启用自动攻击中断——Defender XDR 可利用跨信号置信度 ≥ 99% 来遏制高置信度的活动攻击（禁用用户、隔离设备、遏制邮箱）。先以仅报告模式推出 14 天，检查操作，然后再强制执行。 验证：查看过去 14 天的 Action center；攻击中断操作中没有误报。

5. 高级搜寻——使用 KQL 查询共享架构（DeviceEvents、IdentityLogonEvents、EmailEvents、CloudAppEvents）。将有用的搜寻提升为自定义检测规则，并配置事件分组和受影响实体映射。 验证：每条自定义规则都有实体映射；否则警报不会合并到事件中。

6. 自动调查与修正（AIR）——按设备组配置修正级别（No remediation → Semi → Full）。大多数环境会在工作站上使用 Full，在服务器上使用 Semi。

7. 每月审查覆盖范围——使用 MITRE ATT&CK coverage 视图查找盲点。将平均确认时间和遏制时间作为衡量 XDR 投资回报率仅有的两项 SOC 指标。

防护措施

• 缺少任一工作负载，就不算 XDR。 仅部署 MDE 的“Defender XDR”只是配了精美门户的 EDR。关联分析至少需要 MDE + MDI + Entra ID Protection。
• 先配置统一 RBAC，再大范围启用。 否则，分析师会通过各工作负载的角色组获得整个租户的权限。授予访问权限前，先收紧 RBAC。
• 先以仅报告模式运行攻击中断。 它会隔离设备并禁用用户。先试点这些操作 14 天，查看 Action Center，然后再强制执行。
• 自定义检测规则需要实体映射。 没有实体映射，警报就无法关联到事件中，攻击图也会中断。
• 不要在队列级别抑制事件。 应在警报来源（MDE/MDI/MDO）处抑制，以便继续调整底层检测。队列抑制只会隐藏症状，而非根因。
• Defender 门户是 SOC 工作区。 不要让分析师在 MDE、MDI、MDO 门户之间来回切换——这正是 XDR 要解决的问题。

常见反模式

• “我们只接入了 MDE，却称其为 XDR” —— 攻击链有一半不可见。声称覆盖 XDR 前，先接入 MDI 和 Entra ID Protection。
• “每个 Defender 工作负载都有自己的分析师团队” —— 这会破坏统一调查模式。一个事件，一位分析师，覆盖所有工作负载。
• “第一天就为整个租户启用了攻击中断” —— 这会中断合法活动 （例如，看起来像勒索软件攻击的渗透测试）。先使用仅报告模式运行 14 天。
• “创建了没有实体映射的自定义规则” —— 警报不会汇总到事件中。始终至少映射一个实体（用户／设备／IP）。
• “部分工作负载使用统一 RBAC，其他工作负载使用旧版 RBAC” —— 权限重叠会导致权限过高。要么迁移所有工作负载，要么都不迁移。
• “所有地方都将 AIR 设为不修复，因为我们不信任自动化” —— 分析师的时间浪费在重复性任务上。先在工作站上使用半自动模式并进行审核。

示例提示词

• What are the first Defender XDR controls I should enable for a new Microsoft 365 tenant?
• Walk me through how to investigate a multi-stage incident in Defender XDR using the attack graph.
• Write an advanced hunting KQL query to find suspicious PowerShell execution across devices.
• How does automatic attack disruption work and what should I configure first?
• How do I correlate an identity alert with a device alert in the same incident?
• Design the unified RBAC roles for a 3-tier SOC.
• Convert this hunting query into a custom detection rule with entity mappings.

Microsoft Learn

• 概述：https://learn.microsoft.com/defender-xdr/microsoft-365-defender
• 高级搜寻：https://learn.microsoft.com/defender-xdr/advanced-hunting-overview
• 攻击中断：https://learn.microsoft.com/defender-xdr/automatic-attack-disruption
• 自定义检测规则：https://learn.microsoft.com/defender-xdr/custom-detection-rules
• 统一 RBAC：https://learn.microsoft.com/defender-xdr/manage-rbac
• 事件调查：https://learn.microsoft.com/defender-xdr/investigate-incidents
• AIR 概述：https://learn.microsoft.com/defender-xdr/m365d-autoir