AD 域应急- Pass-the-Hash攻击狩猎

AD 域应急- Pass-the-Hash攻击狩猎

作者 在应急响应

在 Active Directory 环境中，Pass-the-Hash（PtH）是横向移动阶段最常见、也最难根除的技术之一。它不需要破解密码，不需要知道明文，只需要一段 NTLM 哈希，攻击者就能以目标账号的身份登录远程主机。正因为它直接复用了 Windows 认证协议的底层机制，检测和防御的难度远高于普通的账号密码攻击。

Pass-the-Hash 攻击原理

要理解 PtH，首先需要理解 Windows NTLM 认证的工作方式。

在 NTLM 协议中，客户端向服务端证明身份的方式并不是”发送明文密码”，而是：

  1. 服务端发送一个随机的 Challenge（挑战值）
  2. 客户端用自己的 NTLM 哈希对 Challenge 进行加密运算，生成 Response（响应值）
  3. 服务端（或域控）用相同的哈希验证 Response 是否正确

问题就在这里：整个认证过程中，真正起作用的是 NTLM 哈希，而不是明文密码。 明文密码在登录时被 Windows 即时转换成了哈希，之后便不再使用。

这意味着，攻击者只要能获取目标账号的 NTLM 哈希，就完全具备了向任意支持 NTLM 认证的服务发起身份验证的能力——哈希本身就是钥匙。

NTLM 哈希的来源通常是已被攻击者控制的主机内存。Windows 系统的 LSASS 进程负责管理当前登录会话，所有已登录用户的凭据（包括 NTLM 哈希）都会缓存在其中。攻击者通过 mimikatz 的 sekurlsa::logonpasswords 模块或其他工具读取 LSASS 内存，就能批量获取目标主机上所有已登录账号的哈希，随后将这些哈希直接注入到新的认证请求中，完成横向移动。

攻击前置条件

Pass-the-Hash 在攻击链中通常处于中段——攻击者已经控制了一台域内主机，但还不满足于此，需要进一步扩大战果。发动 PtH 需要以下基础：

获取哈希的阶段： 攻击者需要先在已控主机上拿到本地管理员或更高权限，才能读取 LSASS 进程内存。如果目标主机上有高权限账号（尤其是域管理员）登录过，对应的哈希就会留在内存中，成为 PtH 的燃料。

执行横向移动的阶段： 目标主机必须接受 NTLM 认证，且攻击者手中的哈希对应的账号在目标主机上具备足够权限。在域环境中，如果组织内多台主机共用相同的本地管理员账号和密码（这是一个极为普遍的配置问题），一台机器的沦陷往往意味着批量沦陷。

典型的攻击链如下：

初始访问 → 本地提权 → LSASS 内存读取 → PtH 横向移动 → 控制高权限主机 → DCSync / 持久化

Pass-the-Hash 的位置恰好处于”从单点突破到域内横向”的关键节点，也是攻击者扩大战果最高效的手段之一。

攻击执行过程

使用 mimikatz 执行 PtH

mimikatz 的 sekurlsa::pth 模块是最经典的 PtH 实现方式，它通过将哈希注入一个新的进程来建立经过认证的会话：

sekurlsa::pth /user:Administrator /domain:corp.local /ntlm:aad3b435b51404eeaad3b435b51404ee /run:cmd.exe

执行后会弹出一个以目标身份运行的 cmd.exe，攻击者可以在其中直接访问远程共享、执行 WMI 命令或使用 PsExec 在目标主机上运行代码。

使用 Impacket 远程执行

Impacket 工具包中多个工具均支持直接传入哈希进行认证，无需明文密码：

# 使用哈希通过 SMB 在目标上执行命令
python3 psexec.py corp.local/Administrator@192.168.1.20 -hashes :aad3b435b51404eeaad3b435b51404ee

# 使用哈希进行 WMI 执行
python3 wmiexec.py corp.local/Administrator@192.168.1.20 -hashes :aad3b435b51404eeaad3b435b51404ee

与 mimikatz 不同，这种方式完全在攻击者的机器上发起，目标主机上不会产生攻击工具的进程痕迹，检测难度更大。

CrackMapExec 批量横向

在真实攻击场景中，攻击者往往不满足于单台目标，而是使用 CrackMapExec（CME）对整个网段进行批量 PtH 尝试：

crackmapexec smb 192.168.1.0/24 -u Administrator -H aad3b435b51404eeaad3b435b51404ee

这条命令会遍历指定网段，将哈希对所有存活主机逐一尝试，一旦命中则标记为 (Pwned!)。这个过程会在短时间内对大量主机产生登录认证行为，是 PtH 攻击中日志噪声最明显的阶段，也是检测的重要窗口。

从日志中如何发现 Pass-the-Hash 攻击

PtH 的检测难点在于：它使用的是合法的 NTLM 认证流程，从协议层看与正常登录完全一致。检测的核心是识别 NTLM 认证中的异常特征，而不是找到”非法”的协议行为。

关键事件：Event ID 4624（登录成功）

PtH 在目标主机上产生的最核心日志是 Event ID 4624（账号登录成功），其中需要重点关注以下字段组合：

Logon Type = 3（网络登录） PtH 通常以网络登录方式发生，即攻击者从远程访问目标主机的 SMB、WMI 等服务。本地交互登录（Logon Type 2）一般不涉及 PtH。

Authentication Package = NTLM 这是关键特征。在域环境中，域账号之间的正常认证通常使用 Kerberos。如果一个域账号登录时使用的是 NTLM 而不是 Kerberos，本身就值得关注，结合其他异常信号时可信度大幅提升。

Logon Process = NtLmSsp 与 Authentication Package 字段配合，进一步确认此次认证走的是 NTLM 路径。

Impersonation Level = Impersonation PtH 产生的登录事件中，该字段通常为 %%1833（Impersonation），可作为辅助特征。

实际排查时，最有价值的筛选条件是：域账号 + Logon Type 3 + NTLM 认证 + 来源 IP 为非域控的普通主机。这个组合在域内正常业务中极为少见，一旦出现应立即核查。

关键事件：Event ID 4625（登录失败）

当攻击者使用 CrackMapExec 等工具进行批量扫描时，大量失败尝试会产生 Event ID 4625。需要关注的失败特征：

  • Sub Status Code = 0xC000006A：密码错误（此处指哈希不匹配）
  • Sub Status Code = 0xC0000064：用户名不存在
  • 短时间内来自同一源 IP 对多台不同主机的失败登录，是横向扫描的典型特征

单独的 4625 并不能说明问题，但与 4624 配合——先有大量失败，随后某台主机出现成功登录——就构成了完整的攻击轨迹。

关键事件：Event ID 4648（显式凭据登录）

当攻击者使用 mimikatz 的 sekurlsa::pth 注入哈希后执行访问操作时，在源主机上往往会产生 Event ID 4648（使用显式凭据的登录尝试）。该事件记录了本机进程使用另一个账号凭据访问远程资源的行为，是 PtH 在发起端留下的重要痕迹，在攻击者主机上的检测价值高于目标主机。

关键事件：Event ID 4776（NTLM 哈希验证）

在域控制器上，NTLM 认证的最终验证会产生 Event ID 4776。如果域控上频繁出现某个账号的 4776 事件，且对应的请求来自多台不同主机，说明该账号的哈希可能正在被批量复用，需要重点排查。

Pass-the-Hash 攻击排查思路总结

第一步：定位异常的 NTLM 认证行为

在 SIEM 或日志管理平台中，针对目标网段内所有 Windows 主机的 4624 日志，按以下条件进行筛选：

EventID = 4624
AND LogonType = 3
AND AuthenticationPackageName = NTLM
AND TargetDomainName != "本地计算机名"（排除本地账号登录）

筛选出的结果按源 IP 聚合，重点关注单个源 IP 在短时间内向多个不同目标发起 NTLM 认证的情况。

第二步：关联失败事件确认攻击规模

对筛选出的可疑源 IP，回查其同时段内产生的 4625 失败记录，还原”扫描 → 命中”的完整路径，评估攻击者尝试的范围和成功率。

第三步：溯源源主机的初始失陷

确认发起 PtH 的源主机后，重点排查该主机上的 LSASS 内存访问行为。在 Sysmon 日志（Event ID 10，进程访问）中检索对 lsass.exe 的异常访问，确认哈希是何时、被哪个进程获取的：

EventID = 10（Sysmon Process Access）
TargetImage = C:\Windows\System32\lsass.exe
GrantedAccess = 0x1010 或 0x1410（常见的 mimikatz 读取权限掩码）

如果没有 Sysmon，也可以检索 4656（对象句柄请求）或 4663（对象访问），过滤目标为 LSASS 进程的记录。

第四步：检查被横向进入的主机上的后续行为

PtH 成功登录通常不是目的本身，而是为了在目标主机上执行命令或进一步渗透。在被攻击主机上排查 PtH 登录事件（4624）发生后的短时间窗口内：

  • 是否有新的进程创建（Sysmon Event ID 1）
  • 是否有远程服务安装（Event ID 7045，PsExec 的典型痕迹）
  • 是否有计划任务创建（Event ID 4698）

第五步：评估哈希来源账号的权限等级

根据 4624 日志中的账号名，判断攻击者复用的是什么级别的哈希。如果是域管理员账号的哈希被用于 PtH，需要立即按最高优先级处置；如果是普通账号，需要评估该账号在目标主机上的权限，判断后续可能的影响范围。

一个容易被忽视的检测盲区

许多 PtH 防护策略聚焦于”禁止 NTLM”，但这在复杂的企业环境中往往难以完全落地——总有一些遗留系统、打印机、应用服务依赖 NTLM 认证，贸然禁用会导致业务中断。

更容易被忽视的问题是本地管理员账号复用。如果企业内几十台甚至几百台主机使用了相同的本地 Administrator 密码，一台主机被攻破后，攻击者只需用 CrackMapExec 做一次横扫，就能批量控制大量主机。这时候检测 PtH 本身已经来不及了，因为攻击速度远超响应速度。

另一个盲区是Kerberos 降级。在某些场景下，攻击者可以主动触发目标降级到 NTLM 认证（例如通过直接指定 IP 地址而非主机名访问，因为 Kerberos 不支持 IP 认证），使得原本会走 Kerberos 的流量被迫使用 NTLM，从而为 PtH 创造条件。

缓解与防护建议

技术控制层面：

  • 部署并强制执行 LAPS（Local Administrator Password Solution），为每台主机生成唯一的本地管理员密码，从根本上消除本地账号哈希横向复用的可能
  • 在域控组策略中逐步限制 NTLM 使用范围，通过 Network Security: Restrict NTLM 系列策略记录并最终阻断不必要的 NTLM 认证
  • 启用 Protected Users 安全组，将高权限账号加入其中，该组成员的凭据不会被缓存在 LSASS 中，从源头杜绝哈希被提取的可能
  • 开启 Credential Guard，通过虚拟化保护 LSASS 进程，防止 mimikatz 等工具直接读取内存中的哈希

监控层面：

  • 在 SIEM 中建立”域账号 + Logon Type 3 + NTLM + 非 DC 来源”的组合告警规则
  • 对 LSASS 进程的访问行为（Sysmon Event ID 10）设立基线并监控异常
  • 关注批量登录失败（4625）的突发事件，设定阈值告警

事件响应层面：

  • 确认 PtH 攻击发生后，立即隔离确认的源主机，阻断横向扩散
  • 强制重置所有被复用哈希所对应账号的密码
  • 排查攻击者在成功横向进入的主机上留下的持久化机制（新账号、计划任务、服务、注册表启动项）
  • 如果涉及域管哈希，按全域失陷标准处置，参考 DCSync 响应流程

总结

Pass-the-Hash 是 AD 域攻防中一个”老而不死”的技术。它在二十年前就被公开记录，直到今天仍然是渗透测试报告和真实 APT 事件中的常客。原因很简单：NTLM 协议的设计决定了哈希即密码这一根本性问题，而企业环境中大量存在的本地账号复用和 NTLM 依赖让这个问题持续可被利用。

Post Views: 5
赞赏

微信赞赏支付宝赞赏
Zgao

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

发表评论