AD域应急-NTDS.dit 转储狩猎

AD域应急-NTDS.dit 转储狩猎

在 Active Directory 环境中,NTDS.dit 是最核心、也是最危险的一份数据。一旦这份文件落入攻击者手中,基本可以视为整个域已经失守。在应急响应过程中,如果我们忽略了对 NTDS 数据库转储行为的监控,往往意味着攻击者离拿下域控不远了。

NTDS.dit 是什么

NTDS.dit(NT Directory Services Database)是 Active Directory 的核心数据库文件,里面存储着域中最重要的资产,包括:

  • 域用户与计算机账户
  • 用户密码哈希
  • 组成员关系
  • 安全策略与目录对象信息

在每一台域控制器上,NTDS.dit 默认存放在:

%SystemRoot%\NTDS\Ntds.dit

只要攻击者能够成功导出这份数据库,并配合 SYSTEM 注册表 hive,就可以离线解析出域内所有账号的凭据,进一步横向移动、持久化控制,甚至完全接管整个域环境。

从应急响应角度来说,NTDS.dit 被成功转储,往往已经是一次“严重入侵事件”的后期阶段

如何转储 NTDS.dit

实战中,攻击者并不一定会直接使用恶意利用的工具。相反他们更偏向于滥用系统自带能力,以降低被检测的概率。

其中一个最常见的方式,就是使用 Windows 自带的工具 —— ntdsutil

ntdsutil 本来就是域控制器上用于备份和维护 Active Directory 数据库的合法工具,在正常运维场景下经常被使用,这也让它成为攻击者“完美的伪装”。

一个典型的转储命令如下:

ntdsutil "ac i ntds" "ifm" "create full C:\Users\Administrator\Desktop\NTDS_BACKUP" q q

这条命令做了几件关键的事情:

  • 激活本地正在运行的 NTDS 实例
  • 进入 NTDS 实例管理(IFM)子菜单
  • 创建一份 完整的 NTDS 数据库副本,并输出到指定目录
  • 正常退出工具,几乎不留下异常操作痕迹

执行完成后,攻击者会在目标路径中得到:

  • ntds.dit 数据库文件
  • SYSTEM 注册表 hive
  • SECURITY 注册表 hive

这三者组合在一起,基本等同于AD域的核心。

从日志中如何发现 NTDS 数据库被转储

在应急响应中,发现 NTDS 转储的关键不在进程本身,而在数据库行为

即使攻击者使用的是系统自带工具,Active Directory 的数据库引擎依然会留下痕迹

所有关键信息,都记录在 Application(应用程序)日志 中,日志源为:

ESENT

ESENT 是 Windows 使用的数据库引擎,NTDS.dit 正是基于它运行。需要重点关注的三个 Event ID

Event ID 325 — 新数据库被创建

当 NTDS.dit 被导出为一份新的数据库文件时,系统会生成 Event ID 325

这是最关键、也是最具指示意义的事件之一。在绝大多数场景下,只要看到 325 + 非默认路径,就必须高度警惕。重点关注字段是数据库的 文件路径

Event ID 327 — 数据库被卸载

在转储完成后,数据库引擎会将这份临时数据库卸载,此时会生成 Event ID 327

这个事件通常会紧跟在 325 之后出现,两者结合起来,可以更明确地判断这是一次数据库转储行为,而不是偶发的系统操作。

Event ID 216 — NTDS 被写入非默认位置

Event ID 216 的价值在于时间关联

当 NTDS 数据被写入到 非默认路径(不是 %SystemRoot%\NTDS\ntds.dit)时,会触发该事件。

虽然这个事件本身不直接展示目标路径,但如果它与 325、327 在极短时间内连续出现(毫秒级),基本可以确认这是一次 NTDS 数据库转储行为。

NTDS转储排查思路总结

在真实环境中,可以按照以下思路快速确认事件性质:

  1. 在 Application 日志中筛选事件源 ESENT
  2. 重点查看 Event ID:325、327、216
  3. 检查 325 和 327 中的数据库路径,是否偏离 C:\Windows\NTDS\
  4. 对比三者的时间戳,是否在极短时间内连续发生
  5. 如事件量较大,可直接在 Event Viewer 中搜索关键词 ntds,快速缩小范围

如果以上条件同时满足,基本可以认定:
域控制器上的 NTDS 数据库已被导出,属于高危入侵事件。

应急加固建议

需要搞清楚的一点是:
NTDS 数据库转储本身并不是一个“漏洞”,而是一次被滥用的正常系统行为。

因此,并不存在一个“打补丁就能解决”的方案。

在应急响应与长期防御层面,更现实的做法包括:

  • 严格控制域控制器上的管理员权限
  • 定期审计所有对 DC 的登录与高权限操作
  • 对 ESENT 相关事件建立持续监控与告警
  • 将 NTDS 转储行为纳入高优先级告警规则
  • 对异常备份路径(如 Desktop、Temp、Backup 等)保持高度敏感

从防守角度来说,是无法阻止 ntdsutil 的存在,但可以确保它一旦被滥用,能够第一时间知道。

赞赏

微信赞赏支付宝赞赏

Zgao

愿有一日,安全圈的师傅们都能用上Zgao写的工具。

发表评论