defender-for-identity

Microsoft Defender for Identity

Microsoft Defender for Identity（MDI）是一种基于云的身份威胁检测与响应 （ITDR）解决方案。部署在域控制器和其他身份基础结构上的轻量级传感器会解析网络流量、ETW 事件和 AD 对象读取记录，以检测侦察、凭据窃取、横向移动和域控制。相关信号会关联为 Defender XDR 事件。

适用场景

检测针对本地 Active Directory、AD CS、AD FS 和 Entra Connect 的身份攻击，并发现可能导致这些攻击的身份安全态势问题（旧版协议、不安全的帐户、高风险委派）。

请勿将此技能用于仅限云的 Entra ID 风险检测——这属于 Entra ID Protection （entra-id-protection）。MDI 可监视本地和混合身份基础结构。

将攻击映射到检测来源

选择与攻击者行为相符的行，以确认 MDI 是否是合适的防护措施，以及哪个传感器界面会生成相关信号。

如果攻击者正在……	MDI 检测系列	传感器界面
枚举用户、组、SPN	侦察	DC 传感器（LDAP、SAMR）
离线破解服务帐户的 TGS 票据	Kerberoasting	DC 传感器（Kerberos）
复制目录机密（DCSync）	域控制	DC 传感器（DRSUAPI RPC）
伪造 Kerberos 票据	Golden / Silver Ticket	DC 传感器（Kerberos 异常）
滥用 AD CS 错误配置（ESC1–ESC8）	基于证书的权限提升	AD CS 传感器
劫持 AD FS 登录流程	令牌 / SAML 伪造	AD FS 传感器
窃取 Entra Connect 同步帐户凭据	混合身份泄露	Entra Connect 传感器
探测高风险配置（旧版 SMB、弱 SPN）	身份安全态势管理（ISPM）	所有传感器 + 云评估

**经验法则：**只要攻击者在任何步骤中接触本地身份服务，MDI 就应该能检测到。任何传感器存在缺口（某个未部署监测的 DC、AD CS 或 AD FS），都会让整个攻击链出现盲点。

方法

1. 梳理身份基础设施 — 清点每个域控制器（包括 RODC）、每个 AD CS 企业 CA、每台 AD FS 服务器，以及每台 Entra Connect / Cloud Sync 主机。 此清单即为传感器目标清单——其中的缺口日后会成为攻击路径。 验证：Get-ADDomainController -Filter * 的数量应与 MDI 门户中“设置” → “传感器”下已部署的传感器数量一致。

2. 部署前确认先决条件 — 每台传感器主机都需要能够通过出站 HTTPS 连接到 MDI 云服务、MDI 传感器 MSI、目录服务帐户（DSA），以及（在 DC 上）MDI 要求的高级审核策略设置和对象访问 SACL。 验证：运行 MDI 规模评估工具，确认 CPU/RAM 有余量；传感器在 DC 上造成的持续 CPU 占用应低于 10%。

3. 目录服务帐户使用 gMSA — 组托管服务帐户会自动轮换密码，从而消除最严重的一类凭据暴露风险。切勿使用明文密码的服务帐户。 验证：Get-ADServiceAccount mdi-gmsa$ -Properties PrincipalsAllowedToRetrieveManagedPassword 返回的应是传感器主机组，不应包含范围更广的主体。

4. 分批部署传感器 — 先部署 DC 传感器（信号最强），再部署 AD CS、AD FS、Entra Connect 传感器。每批部署间隔 24 小时，以便建立流量基线，并避免初次出现的活动警报淹没 SOC。

5. 调整警报，然后处理安全状况 — 确认首周的良性警报（管理工具产生的噪声），然后处理 身份安全状况评估（安全分数面板）。安全状况问题（例如 不安全的帐户属性、旧版协议、休眠帐户）是攻击者在警报触发前会利用的薄弱环节。 验证：在第 1 周记录安全状况分数基线；按月而非按日跟踪变化。

6. 部署蜜罐令牌 — 植入 1-2 个虚假的高权限帐户（例如 svc-legacy-backup），确保没有人会实际使用它们。任何身份验证尝试都极有可能是恶意行为。

7. 在 Defender XDR 中关联分析 — MDI 警报会自动与 MDE 和 Entra ID Protection 关联，形成单个 XDR 事件。应从事件而非独立警报开始调查。

防护要点

• 每个 DC 都必须安装传感器。 未安装传感器的 DC 就是攻击者会找到的横向移动落脚点。RODC 也包括在内。
• 2026 年，AD CS 上的传感器不可或缺。 在当前事件响应案例中，滥用 AD CS（ESC1-ESC8）是最常见的权限提升路径；没有 AD CS 传感器，你只能看到结果（域管理员），却看不到原因。
• DSA 应使用 gMSA。 切勿使用密码固定的普通服务帐户——它会成为下一个 Kerberoasting 攻击目标。
• 调整警报，不要抑制警报。 禁用某类警报来消除噪声，也会移除相应的检测。应按来源进行抑制，并每月审查。
• 使用蜜罐令牌时务必谨慎。 将其放在侦察工具能够发现的位置（组成员身份、描述），同时做好记录，以免 SOC 浪费精力调查由合法测试触发的警报。

常见反模式

• “我们先覆盖最重要的 DC” — 攻击者会挑选未安装传感器的 DC。要么覆盖所有 DC，要么一个都不覆盖。
• “为了简单起见，我们用域管理员帐户作为 DSA” — 如果传感器主机遭到入侵，就等于把域管理员权限拱手交给攻击者。务必使用遵循最小权限原则的 gMSA。
• “安全状况警报不是真正的警报，所以我们忽略它们” — 安全状况问题是攻击前信号。解决这些问题，比应对它们引发的事件成本更低。
• “我们没有部署 AD CS 传感器，因为颁发的证书不多” — 证书颁发量无关紧要。标准 AD CS 安装中就存在 ESC1/ESC8 配置错误，需要监控。
• “MDI 警报会直接发送到旧版 SIEM，我们不使用 Defender XDR” — 这会丢失跨工作负载关联分析能力。即使 SIEM 是主要平台，也应保留 XDR 来查看攻击图。

示例提示词

• Plan Defender for Identity sensor coverage across DCs, AD CS, AD FS, and Entra Connect.
• Which Defender for Identity detections cover the Kerberoasting kill chain?
• How do I configure a gMSA Directory Service Account for MDI?
• Which Identity Security Posture assessments should I fix first?
• Show me how to deploy a honeytoken account in MDI.
• Why am I seeing high CPU on a DC after installing the MDI sensor - how do I size it?

Microsoft Learn

• 概述：https://learn.microsoft.com/defender-for-identity/what-is
• 规划容量（大小调整工具）：https://learn.microsoft.com/defender-for-identity/deploy/capacity-planning
• 在 AD CS 上部署传感器：https://learn.microsoft.com/defender-for-identity/deploy/active-directory-federation-services
• 目录服务帐户（gMSA）：https://learn.microsoft.com/defender-for-identity/deploy/directory-service-accounts
• 身份安全态势评估：https://learn.microsoft.com/defender-for-identity/security-assessment
• Honeytoken 帐户（实体标记）：https://learn.microsoft.com/defender-for-identity/entity-tags
• 警报参考（Kerberoasting、DCSync、Golden Ticket）：https://learn.microsoft.com/defender-for-identity/alerts-overview