序言从窃听到伪造信任体系的崩塌在上一篇文章《Active Directory 攻防一Kerberoasting 实战》中我们聊了如何利用 Kerberos 协议中 TGS-REP 阶段的“正常机制”将服务票据带回家离线破解。那是一种“合法索取非法利用”的优雅战术。如果说 Kerberoasting 是在皇宫的宴会上趁人不备偷走了一块带有牙印的糕点带回家慢慢分析是谁咬的那么今天我们要讲的两种技术则是直接对 Kerberos 协议的信任根基下手。AS-REP Roasting针对的是那些防守松懈的入口。当系统为了“方便”而关闭了预认证攻击者甚至不需要知道你的密码就能拿到加密的凭证这就像是保安还没看你的身份证就把通行证递给了你而你接过后直接拿回家破解上面的防伪水印。而黄金票据则是整个 AD 域安全体系中最为致命的终极武器。它不再是利用某个配置失误而是直接利用了 Kerberos 协议的设计本质KDC 只认票不认人。当你掌握了“造币厂”的底版你就可以凭空创造出域控都无法拒绝的伪造票据自立为王。今天我们继续深入这座黑暗森林剖析这两种足以让任何企业内网沦陷的核武器。第一章无声的窃取——AS-REP Roasting很多人把 AS-REP Roasting 和 Kerberoasting 混为一谈因为它们都是“拿回家烤”。但从协议层面看它们处于完全不同的阶段攻击前提也截然不同。1.1 预认证KDC 的第一道门禁在 Kerberos 协议的第一阶段AS-REQ AS-REP客户端向 KDC 索要 TGT票据授予票据。KDC 凭什么把这张长期通行证发给你它必须确认你是谁。默认情况下Windows 域要求预认证。当你发送 AS-REQ 时你必须附带一个用你自己的密码哈希加密的时间戳。KDC 收到请求后会去 NTDS.dit 数据库里查你的密码哈希尝试解密那个时间戳。如果解得开且时间没被篡改防重放KDC 确信这货确实是张三。然后KDC 才会把用张三哈希加密的 Session Key 和用 KRBTGT 哈希加密的 TGT 发给他。这是合理的安全设计。但在庞大的企业网络中总有例外。1.2 漏洞触发当门禁失效有些老旧的第三方应用比如某些基于 Java 的老系统、或者某些 Linux 机器加入域的配置在进行 Kerberos 认证时会出问题。为了兼容这些“奇葩”系统运维人员往往会在 AD 用户属性里勾选一个致命的选项“不要求 Kerberos 预身份验证”。一旦关闭了预认证逻辑就变成了这样客户端发 AS-REQ“我是张三给我 TGT。”不带任何加密证明KDC是个死脑筋“哦你是张三啊我不查你身份了直接把 TGT 给你。为了你以后能用这个 TGT我顺便把用你密码哈希加密的 Session Key 也一起给你吧。”攻击者视角任何在域内有有效账号的攻击者哪怕是个最底层的普通域用户都可以遍历域内用户向 KDC 发送针对“关闭了预认证”的用户如张三的 AS-REQ。KDC 会毫无保留地把 AS-REP 发给你。而在 AS-REP 中包含着一段用张三密码哈希加密的数据。你拿回家用字典去碰撞一旦解密成功你就拿到了张三的明文密码或哈希。区别Kerberoasting需要域用户权限针对注册了 SPN 的服务账户。AS-REP Roasting不需要域用户权限只要能连上域控网络针对关闭了预认证的普通用户。1.3 实战狩猎寻找不需要暗号的账户在实战中第一步是找出域内哪些账户关闭了预认证。这其实是一个 LDAP 查询。工具箱Empire 的 PowerView老牌的 PowerView 提供了一个现成的模块# 查询域内关闭了预认证的账户Get-DomainUser-PreauthNotRequired它的底层原理是向域控发送 LDAP 查询过滤条件为(userAccountControl:1.2.840.113556.1.4.803:4194304)。这个掩码就代表“不需要预认证”。工具箱Rubeus作为红队神兵Rubeus 自然也集成了这个功能。它的优势在于查到目标后可以直接发请求并格式化输出哈希。Rubeus.exe asreproast /outfile:C:\Temp\asrep_hashes.txt工具箱Impacket (GetNPUsers.py)如果你在 Linux 环境下或者只有一组通过弱口令爆破出来的域凭据Impacket 是最好的选择。它甚至不需要你事先知道哪些账户关闭了预认证只要你提供一个域用户账号它会自动通过 LDAP 查询然后发起 AS-REQ。# 使用已知域用户自动查询并请求 AS-REPpython3 GetNPUsers.py corp.local/zhangsan:Password123-request-formathashcat-outputfileasrep_hashes.txt1.4 离线烘烤与破解策略拿到的哈希文件内容长这样$krb5asrep$23$zhangsanCORP.LOCAL:9e8b8c...[省略]...注意这里的$23它同样代表 RC4-HMAC 加密。与 Kerberoasting 类似如果目标是现代的 AES 加密破解难度会呈指数级上升。但幸运的是对攻击者来说关闭预认证的账户往往是历史遗留的老系统支持 RC4 的概率极高。Hashcat 破解AS-REP Roasting 对应的 Hashcat Mode 是18200。hashcat-m18200asrep_hashes.txt rockyou.txt-rbest64.rule破解逻辑和 Kerberoasting 完全一致本质上都是算力的碰撞。一旦破解出明文密码如果这个账户是个运维管理员那么恭喜你你以零成本获得了一个高权限跳板。1.5 蓝队雷达与修复检测AS-REP Roasting 的检测相对容易一些因为它的行为特征很明显在没有预认证的情况下发出了 AS-REQ 并成功收到了 AS-REP。在域控的安全日志中关注Event ID 4768Kerberos 身份验证票据请求。如果Pre-Authentication Type字段为0意味着没有进行预认证。如果这个事件频繁出现或者针对同一个账户在短时间内出现多次基本可以断定有人在扫盲。根治绝对不要关闭预认证。对于老旧系统宁愿麻烦一点去修改应用配置也不要为了兼容性牺牲整个域的安全底线。定期审计域内账户使用Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}找出并修复这些定时炸弹。第二章权力的本质——黄金票据的诞生如果说前文的攻击都是利用漏洞那么黄金票据则是对 Kerberos 协议设计哲学的降维打击。在讲实操之前我们必须先理解它的底层逻辑。2.1 深入理解 TGT上帝的授权书在 Kerberos 体系中客户端要访问服务必须先拿着 TGT 向 KDC 换取 ST服务票据。那么 TGT 里面到底装了什么TGT 本质上是一个数据包用KRBTGT 账户的密码哈希加密。里面包含了用户信息谁在请求如用户名、SID、所属组。Session Key客户端与 KDC 后续通信的密钥。授权数据这是最核心的。包含了用户的 PACPrivilege Attribute Certificate特权属性证书。PAC 里详细记录了用户在哪些组里比如 Domain Admins。KDC 的致命盲点当客户端拿着 TGT 去换 ST 时KDC 会用 KRBTGT 的哈希解开 TGT。KDC完全信任 TGT 里的内容。如果 TGT 里的 PAC 说这个用户是 Domain Admins 组的KDC 就会信以为真并在随后发出的 ST 里写入“此人是域管”。简单来说KDC 只认 KRBTGT 哈希加密的票票里写什么KDC 就认什么。2.2 攻击逻辑我自己造一张上帝的授权书如果攻击者拿到了 KRBTGT 账户的哈希他就可以在自己的电脑上离线伪造一个 TGT。他可以在伪造的 TGT 里写入用户名随便写甚至写一个域里不存在的用户名。用户 SID写一个高权限的 SID。组信息写上 Domain Admins、Enterprise Admins 等最高权限组。只要这个伪造的 TGT 是用正确的 KRBTGT 哈希加密的当攻击者拿着它去 KDC 换 ST 时KDC 解密成功看到里面的 PAC 写着“你是域管”KDC 就会乖乖地给你发放访问任何服务的 ST。这就是黄金票据。它绕过了 AS-REQ 阶段不需要密码直接伪造了第二阶段的通行证。它的有效期可以长达 10 年Kerberos 默认策略。2.3 为什么需要 DCSync要伪造黄金票据前提是拿到 KRBTGT 的哈希。怎么拿常规思路是拿下域控在上面跑 Mimikatz从 LSASS 内存里抠出来。但如果你无法直接登录域控呢或者域控开了凭据保护Credential Guard你抠不出来呢2015 年Benjamin DelpyMimikatz 的作者和 Vincent Le Toux 发现了一个震惊业界的协议滥用技术DCSync。AD 域的多个 DC 之间需要同步数据使用的协议是DRSUAPIDirectory Replication Remote Protocol。域控之间通过这个协议互相复制 NTDS.dit 数据库。DCSync 的精髓在于域内任何拥有“复制目录更改”权限的账户都可以伪装成域控向真正的域控发送复制请求要求它把数据库里的内容包括 KRBTGT、域管的哈希发过来。谁默认有这个权限Domain AdminsEnterprise Admins以及一个经常被忽视的组DC域控制器组。这意味着如果你拿下一了一台域控的本地 System 权限哪怕它不是 PDC你也能直接 DCSync。实战流程通过各种手段如零日漏洞、配置失误拿到了一台域控的 System 权限。不需要抓取 LSASS 内存规避 EDR。直接在域控上或通过代理使用 Mimikatz 向主域控发起 DCSync 请求。拿到 KRBTGT 哈希撤离。第三章伪造皇权黄金票据的实战锻造手握 KRBTGT 哈希我们就可以开始“铸币”了。3.1 铸币所需的原材料在本地伪造一张完整的黄金票据你需要以下四个核心要素域名如CORP.LOCAL。域 SID域的安全标识符。注意是域 SID不是用户 SID。域 SID 是去掉最后一段数字的如S-1-5-21-123456789-...-1000去掉1000。KRBTGT 账户的 NTLM Hash这是加密伪造票据的密钥。要伪造的用户名随便写如hacker但通常为了方便会写一个域里已存在的域管名字避免某些奇怪的后端校验。3.2 Mimikatz 铸币厂实操第一步使用 DCSync 获取原材料如果你已经拿到了 System 权限的 shellmimikatz.exe lsadump::dcsync /domain:corp.local /user:krbtgt exit在输出中你会看到Object Security ID域 SID。Hash NTLMKRBTGT 的哈希。第二步开始锻造。伪造的命令通常这样写mimikatz.exe kerberos::golden /domain:corp.local /sid:S-1-5-21-123456789-... /krbtgt:9c4a8e... /user:Administrator /ptt exit参数解析kerberos::golden开启黄金票据锻造模块。/domain域名。/sid域 SID。/krbtgt哈希值。/user你想伪造的身份。/pttPass The Ticket。伪造完成后直接将票据注入到当前进程的内存中。执行完毕后当前 CMD 窗口就拥有了上帝的权限。3.3 神格降临验证与利用不要关闭这个 CMD 窗口在这个窗口里执行dir \\DC01.corp.local\c$如果直接列出了域控 C 盘的目录恭喜你你的黄金票据生效了。你可以通过 PsExec、WMI 或直接建立 IPC$ 连接在域控上执行任何命令。3.4 隐匿与 OPSEC做聪明的神在实战中直接用 Mimikatz 落地有极大风险。现在的 EDR 对 Mimikatz 的特征码查杀极严。作为一名合格的成年人我们需要更优雅的方式。方案一RubeusRubeus 同样支持黄金票据的生成与注入且用 C# 编写更容易做免杀处理。Rubeus.exe golden /domain:corp.local /sid:S-1-5-... /krbtgt:9c4a8e... /user:Administrator /ptt方案二离线锻造跨平台注入如果目标环境严苛你甚至可以在你自己的 Linux 笔记本上使用ticketer.py(Impacket套件) 离线生成一个.ccache格式的票据文件。python3 ticketer.py-domaincorp.local -domain-sid S-1-5-...-nthash9c4a8e... Administrator然后通过设置环境变量KRB5CCNAME使用 Impacket 的其他工具如wmiexec.py、secretsdump.py带着这个票据直接发起攻击。整个过程不碰目标机器的磁盘流量侧走的是标准 Kerberos 协议极具伪装性。关于加密类型的选择在锻造时最好指定/rc4或/aes256。如果域环境已经禁用了 RC4你却伪造了一个 RC4 的 TGT去请求 ST 时会被拒绝。实战中通常先 DCSync 出 AES 哈希来伪造兼容性更好。第四章白银与黄金——票据的对比学说到黄金票据就不得不提它的孪生兄弟——白银票据。理解它们的区别能加深对整个攻防体系的认知。4.1 服务票据的伪造白银票据伪造的是ST服务票据而不是 TGT。它的原理是如果你拿到了某个服务账户的哈希比如通过 Kerberoasting 破解了 MSSQL 服务账户的明文你可以直接伪造一张访问该 MSSQL 服务的 ST。4.2 优势与劣势分析维度黄金票据白银票据伪造对象TGTST所需哈希KRBTGT 哈希服务账户哈希权限范围整个域全能神仅限该特定服务是否经过 KDC是需用 TGT 换 ST但 KDC 认不出假 TGT否直接拿着假 ST 去找服务服务认不出隐蔽性较低。会产生大量 4769 日志因为没有 4768 日志却突然出现 4769。极高。完全不与 KDC 交互域控日志里没有任何痕迹。防御难度较难。只要 KRBTGT 不重置票据一直有效。相对容易。修改服务账户密码即可使票据失效。在实战中红队往往根据目标灵活选择需要全网穿透时用黄金需要在特定高价值服务器上潜伏且不留域控日志时用白银。第五章蓝队的终极反击——抗击上帝当攻击者手里握着黄金票据时防守方往往会感到一种无力感。因为你面对的不是一个在运行的木马而是一个在协议深处合法游走的幽灵。但蓝队并非无计可施。5.1 幽灵日志抓取看不见的请求正如前文所说黄金票据是凭空出现的它没有经过 AS-REQ 阶段。因此在域控的安全日志中你会发现一个极其诡异的现象异常特征没有对应的Event ID 4768TGT 请求成功。但却突然出现了大量的Event ID 4769服务票据请求成功。4769 日志中的请求者可能是一个根本不存在于 AD 中的用户名。如果你在 SIEM 中设置了“有 4769 无 4768”的关联告警恭喜你你抓住了黄金票据的尾巴。5.2 KRBTGT 重置两道铁门的更替发现黄金票据后最紧迫的任务是让现有的假票据失效。很多新手运维的第一反应是改 KRBTGT 账户的密码这是一个致命的错误。Windows 域控制器为了保证数据复制的容错性KRBTGT 账户保留了当前密码和上一次历史密码两个哈希。如果你只改了一次密码攻击者伪造的旧票据依然可以用上一次的哈希解开。微软官方的修复指南重点必须重置 KRBTGT 密码两次。第一次重置后当前密码失效但上一次的历史密码变成了你刚改的那个新密码。攻击者伪造的票据用最老的哈希依然有效。等待一段复制时间确保所有 DC 同步完毕。第二次重置后最老的哈希被挤出历史列表。此时所有伪造的黄金票据彻底作废。注意重置 KRBTGT 是一个高风险操作会导致当前正在进行的 TGT 认证失效可能引发短暂的业务中断。在实际操作中应分步骤、分站点进行。5.3 架构级防御让 DCSync 无处遁形黄金票据的前置是拿到 KRBTGT而拿到 KRBTGT 大多通过 DCSync。切断 DCSync 的路径就等于切断了黄金票据的生产线。收紧 DCSync 权限审计DC组和Domain Admins组成员。任何非域控的机器账户绝不能拥有“复制目录更改”权限。在 AD 的“用户和计算机”管理单元中查看域根目录的属性 - 安全 - 高级。将“完全控制”和“复制目录更改”的权限限制在最小范围内。管理员账户隔离严禁域管账户登录日常办公机或 Web 服务器。域管凭据只能出现在域控上。这是阻断 DCSync 攻击链最有效的手段。监控 DRSUAPI 调用在域控上监控网络层面的 DRSUAPI 调用。如果有非域控 IP 向域控发起 IDL_DRSBind 请求这极大概率是 DCSync 攻击。5.4 从微弱信号中寻找痕迹PAC 验证高级的蓝队还可以通过 PAC 验证来发现异常。如前所述PAC 里包含了用户的组信息。虽然攻击者可以伪造任何组信息但企业内部的网络架构往往是有规律的。比如一个一直处于“普通业务服务器”网段的机器突然以“Enterprise Admins”的身份发起大量 CIFS文件共享请求这种行为模式的异常可以通过 UEBA用户实体行为分析系统捕捉到。第六章结语信任的崩塌与重建Active Directory 的攻防本质上是对信任边界的争夺。AS-REP Roasting 利用了配置的松懈让未经身份验证的信任随意流通而 Golden Ticket 则更彻底它直接获取了信任的根基——那个用于盖章的印章。当印章落入敌手所有基于印章的信任体系都会瞬间崩塌。在这些攻击面前传统的边界防御显得如此脆弱。你以为关了门但攻击者拿着你自己造的通行证从你的正门大摇大摆地走进去。作为防守方我们需要清醒地认识到不存在绝对安全的系统Kerberos 的设计在当年是伟大的但随着算力的提升和攻防视角的转换它的“信任逻辑”成为了软肋。安全不能依赖于单点。哪怕 KRBTGT 被攻破如果你有完善的日志关联分析无 4768 有 4769你依然有时间止损。最关键的是控制权限的蔓延。不要让普通机器能轻易拿到高权限DCSync 的泛滥正是因为管理员毫无顾忌地滥用 Domain Admins。