AD域应急-LDAP枚举行为狩猎

在 Active Directory 域环境中，LDAP 是一个再正常不过的存在。无论是用户登录、计算机加入域，还是服务账户访问资源，底层几乎都绕不开 LDAP 查询。从运维视角看，这是“基础设施的必要操作”；但从攻击者视角看，LDAP 则是快速摸清整个域环境结构的捷径。

在多起真实的域渗透事件中，LDAP 枚举几乎都是攻击链的早期阶段。攻击者在拿到一个普通域用户权限后，第一件事往往不是横向，而是尽可能全面地理解域结构：

• 有哪些用户？
• 有哪些计算机？
• 哪些账号具备高权限？
• 权限之间的依赖关系是什么？

而这正是 BloodHound 存在的意义。

BloodHound是什么？

BloodHound 是一个专门用于分析 Active Directory 权限关系的攻击路径分析工具。

它的核心价值不在于“入侵”，而在于把域内复杂、隐蔽的权限关系用图的方式彻底摊开，让攻击者或防守方一眼看清：

从一个普通域用户，究竟能不能、以及如何一步步走到域管理员。

在真实的 AD 环境里，权限并不是简单的“是不是域管”。真正危险的，往往是下面这些隐性关系：

• 某个普通用户对某台服务器有 本地管理员权限
• 某台服务器上跑着 域管理员登录过的会话
• 某个账号对关键用户/组对象有 ACL 写权限
• 某个服务账号配置了 不安全的委派（Delegation）

这些关系单独看都不致命，但一旦串起来，就可能形成一条完整的提权路径。BloodHound 的作用，就是把这些“可以被串起来的关系”全部找出来，并自动帮你算路径。

为什么攻击者需要 LDAP 枚举

BloodHound 本身并不“入侵”系统，它的价值在于情报整合。通过其采集器 SharpHound，攻击者可以在极短时间内对域内进行大规模 LDAP 查询，收集包括用户、计算机、组、ACL、委派关系等大量信息。

这些数据随后会被导入到 Neo4j 数据库中，生成一张逻辑关系图。攻击者不再需要凭经验去猜“谁可能是域管”，而是可以直接看到从当前账号到高权限目标的最短路径。

从应急响应的角度来看，这一步往往意味着：
攻击者已经不再试探，而是在系统性规划下一步行动。

SharpHound 在域内的实际行为

在我的演示环境中，SharpHound 是在一个普通域用户 user001 的上下文中运行的。执行完成后，可以看到枚举过程非常迅速，几乎在几分钟内完成了大量查询。

这里我是在kali上部署bloodhound，和AD域在同一个环境，就直接通过bloodhound-python快速进行信息收集，代替使用 SharpHound.exe 和 SharpHound.ps1 在Windows域内主机上运行。

运行完成后再当前目前下会生成对应的压缩包，在bloodhound界面右侧点击上传数据，选择对应的压缩包上传，然后点击analysis就能看到分析结果。

也可以手动在目标机器上执行SharpHound.exe，。这类行为在终端上看起来既没有 Exploit，也没有权限提升，甚至没有明显的异常进程行为。但在域控侧，却已经留下了足够多的痕迹。

为什么 LDAP 枚举这么难检测？

我在刚接触 AD 安全时就思考过一个问题：
既然攻击者在疯狂查询 LDAP，为什么不能直接把所有 LDAP 查询都记录下来？

答案很现实：性能撑不住。

LDAP 是 AD 的核心功能。如果对每一个对象访问都开启审计，一个普通用户登录都可能产生五六条事件。在一个成百上千用户的企业环境中，这样的日志量会直接拖垮域控。

正因为如此，对象访问审计在 AD 中默认是关闭的，而攻击者正是利用了这一点，在“合法流量”中完成枚举。

在默认情况下，执行SharpHound.exe进行大量ldap查询，在域控上筛选4662也只能看到非常少的日志，无法判断是否异常。

防守视角下的关键突破口：Canary 对象

既然不能全量审计，那就只能“有选择地监听”。

在实际防御中，一个非常有效的思路是使用 Canary 对象：

• 创建一些看起来完全正常，但实际上不会被任何业务使用的用户、计算机或组
• 让它们自然地“混”在 AD 环境中
• 只对这些对象开启对象访问审计

正常情况下，没有任何理由去频繁查询这些对象。一旦攻击者运行 BloodHound 这类自动化工具，这些 Canary 对象几乎一定会被一起枚举到，从而触发日志。

这种方式的优势在于：

• 不影响域整体性能
• 审计目标非常明确
• 误报率极低

在大型环境中，Canary 对象的数量往往是“越多越好”，这样可以显著提升检测命中率。

批量创建 Canary 对象

我写了一个 Deploy-CanaryObjects.ps1 的脚本用于批量创建。

https://zgao.top/download/Deploy-CanaryObjects.ps1

  # 部署 Canary 对象（创建 + 配置审计）
  .\Deploy-CanaryObjects.ps1

  # 自定义密码
  .\Deploy-CanaryObjects.ps1 -Password "YourP@ssw0rd!"

  # 只创建对象，跳过 SACL 配置
  .\Deploy-CanaryObjects.ps1 -SkipSACL

  # 删除所有 Canary 对象
  .\Deploy-CanaryObjects.ps1 -RemoveAll

脚本功能如下：

功能	说明
创建用户	10个伪装成服务账户/管理员的用户
创建计算机	8个伪装成工作站/服务器的计算机
创建组	8个伪装成高权限组的安全组
SACL配置	自动为所有对象配置 ReadProperty 审计
审计策略检查	自动检测 DS Access 审计是否启用
一键清理	-RemoveAll 参数快速清理所有对象

关键日志：Event ID 4662

配置完成后再次运行SharpHound.exe。

在 Windows 安全日志中，与 LDAP 对象访问直接相关的事件是 4662。

在本文的演示环境中，可以清晰地看到：

• 发起查询的用户是 User001
• 被查询的对象是事先布置好的 Canary 用户（例如 “VPN_FullAccess”）
• 同一个对象在极短时间内被执行了多种访问操作

随后，还能看到同一用户在几乎相同的时间点，枚举了多个 Canary 计算机对象 。

从时间维度来看，这些事件之间几乎没有间隔。这一点在应急响应中非常关键，因为人工操作几乎不可能在如此短时间内完成如此多的查询。

如何在真实AD环境中判断攻击行为？

在分析 LDAP 相关日志时，可以重点关注以下几个维度：

如果这三个条件同时成立，基本可以判定为一次自动化 LDAP 枚举行为。在真实企业环境中，如果部署了足够数量的 Canary 对象，这种行为会非常“显眼”。

LDAP 枚举防御思路

从应急响应的角度来看，LDAP 枚举并不意味着“已经失陷”，但它几乎总是高危攻击链的前奏。

一旦确认存在此类行为，建议立刻：

• 评估该账号是否存在权限滥用风险
• 排查是否有后续横向、提权或凭据窃取行为
• 结合终端日志、网络流量进一步还原攻击路径

在防御层面，核心思路并不是“阻止 LDAP”，而是：

• 限制低权限账号的枚举能力
• 通过 Canary 对象提升可见性
• 在攻击者真正动手前感知威胁

赞赏

微信赞赏支付宝赞赏