黄金票据攻击与防御:从Kerberos原理到域安全加固 1. 黄金票据是什么先搞懂Kerberos这笔“信任账”如果你在域渗透这块摸爬滚打过一阵大概率听过这句话拿下域管不算本事能一直保持权限才算本事。而黄金票据恰恰就是那个能让攻击者在域里“长期隐身”的高阶手法。我第一次接触这个概念时也被它的名字唬住了但真正把Kerberos认证流程捋清楚之后你会发现它本质上就干了一件事伪造了一张“由域控签发的万能通行证”。先打个比方。一个Windows域就像一栋有前台、有门禁、有各个独立办公室的大楼。你早上来上班得先到前台刷工卡验证身份前台确认你是本公司员工后给你发一张当天的临时门禁卡这就是TGT票据授予票据。之后你拿着这张临时门禁卡去刷各个办公室的门办公室门卫看到门禁卡上有前台的盖章就不再问你是谁直接让你刷特定房间的门禁这张能开某个房间门的卡就是ST服务票据。整个流程里前台就是域控上的KDC密钥分发中心而前台盖章用的那枚“公章”就是krbtgt账户的密码哈希。Kerberos实际认证过程可以拆成五步我在排查问题时经常对着这五步找断点第一步客户端向KDC的AS认证服务发AS-REQ说“我是张三我要申请一张门禁卡”。第二步KDC用krbtgt的哈希给TGT加密连同一把“临时门禁卡专用密钥”一起返回这就是AS-REP。第三步客户端拿着TGT去KDC的TGS票据授予服务申请访问某台服务器的ST发的是TGS-REQ。第四步TGS验证TGT没问题就签发ST回来即TGS-REP。第五步客户端拿着ST去访问目标服务服务端验证ST无误后允许访问。这里的关键在第二步谁拥有krbtgt的哈希谁就能模拟KDC签发任意TGT。黄金票据就是攻击者拿到krbtgt的哈希后离线自行构造一张TGT伪造一个不存在的用户、指定任意权限甚至把票据的有效期设成十年。因为这张TGT本身是用krbtgt哈希正确加密的域内所有KDC在验证时都会认为这是自己签发的合法票据于是攻击者就能凭这张假票据访问域内任意资源包括域控上的文件、指定服务器的计划任务以及任何配置了Kerberos认证的服务。为什么叫“黄金”我的理解是它和“白银票据”相对黄金票据伪造的是TGT这种顶层凭证相当于伪造了前台的公章而白银票据伪造的是ST只针对某个具体服务。公章能盖无数张介绍信所以黄金票据的权限边界是整个域的信任边界威力完全不是一个量级。不少刚入门的朋友会误解觉得黄金票据是“入侵”工具。其实更准确地说它是“维持权限”和“横向移动”的工具攻击者在已经取得域控权限、拿到krbtgt哈希之后才会使用它。它解决的核心痛点是域管密码可以改、会话可以被踢、后门可能被杀软查但krbtgt哈希一旦被拿到除非域控主动重置否则攻击者相当于永远握着前台的公章。理解了这笔“信任账”再看后面所有利用和检测思路都顺理成章了。2. 攻击者要什么黄金票据的前置条件与攻击面2.1 攻击者是如何拿到krbtgt哈希的任何技术分析都要先回答一个问题攻击者到底需要什么黄金票据的门槛不在“伪造”本身而在于“拿到krbtgt哈希”。这一步没做到后面都是空谈。常见的获取路径有几种。第一是域控本地提权后抓取内存在域控的LSASS进程里读取krbtgt的哈希第二是提取NTDS.dit数据库文件配合注册表里的SYSTEM键值解密出所有域用户和机器的哈希第三是用DCSync攻击即通过 replication API 模拟域控从目标域控请求账户哈希数据只要攻击者拥有复制目录权限的相关ACL比如域管组、企业管理员组或者被单独授予了权限的账户就能远程拉取哈希第四是比较少见但确实存在的备份服务器失陷导致ntds.dit备份文件泄露。在实际攻防演练和应急响应中我见过最多的还是前两种域控被突破后抓内存或者到了AD数据库备份然后离线分析。这里必须多说一句以上所有能力都必须建立在你已经合法拿到目标系统测试授权、且对方明确同意你进行渗透测试的基础上。域渗透技术是把双刃剑未经授权对任何网络系统做测试都是违法行为这一点在我所在的行业里是没有任何讨论余地的红线。2.2 黄金票据为什么能“绕过”常规检测了解前置条件后另一个关键问题是为什么黄金票据在攻击者的武器库里地位这么高因为它有三大特征让它在绕过检测方面非常有优势。第一离线生成。攻击者不需要和域控产生任何交互就凭手里的哈希在自己电脑上把票据算好。这意味着常规基于流量检测的机制很难直接发现“有人正在生成票据”——当攻击者把做好的票据注入内存时域控毫无感知。第二长期有效。攻击者可以自定义票据的有效期我在授权测试中见过把票据有效期设为10年的样例。只要krbtgt哈希不变这张票据在到期之前一直有效攻击者不需要反复和KDC通信也就不容易触发账户锁定、异常登录等检测规则。第三权限极大。使用默认域管理员账户甚至伪造一个SID为500或512的内置账户生成的票据天然拥有域管理员权限。攻击者拿着它可以直接访问文件服务器、数据库、邮件系统甚至还能再通过DCSync把哈希拉走形成权限的再扩大。但“绕过常规检测”不等于“无法检测”。黄金票据有个非常明显的逻辑破绽票据的发起者身份是伪造的。你在域里明明没有998这个用户可一条TGS请求却声称自己来自一个SID为998的用户这在大量正常请求中相当扎眼。后面我专门用一节来讲防守方怎么抓住这个破绽。2.3 黄金票据与白银票据的差异对照很多新手会把黄金票据和白银票据搞混这两个概念放一起对比才能真正理解各自的适用场景。我整理了一张表基本可以覆盖日常讨论中的高频点对比维度黄金票据白银票据伪造对象TGT域控签发ST服务签发需要哈希krbtgt哈希目标服务账户的哈希权限范围域内所有服务仅针对指定服务是否经过KDC校验需要TGS验证但TGT伪造成功即通过客户端直接访问服务端服务端校验ST隐蔽程度较高但涉及KDC交互更高几乎无KDC日志适用场景域内持久化、模拟域控失陷持久访问某个特定服务如文件服务器失效条件krbtgt哈希变更目标服务账户密码变更从这张表能看出一个实战选型逻辑如果攻击者只为了稳定访问某台文件服务器白银票据动静更小如果目标是长期控制整个域那黄金票据几乎是唯一选择。防守方两条线的检测重点也不一样抓白银票据重点看服务端日志和异常SPN请求抓黄金票据重点看KDC日志和TGT生命周期。3. 从蓝队视角还原攻击链路攻击者拿到哈希之后会发生什么3.1 攻击链路的四个关键阶段作为防守方我习惯把一次黄金票据攻击拆成四段来看而不是把它当做一个黑盒“啪一下就打进去了”。拆解开才能对应上日志和告警。阶段一是拿哈希。攻击者可能是通过前面说的DCSync、域控内存抓取或NTDS.dit提取拿到了krbtgt哈希。这个阶段会在域控上留下痕迹比如LSASS进程异常读取行为、复制目录的复制请求、事件日志里的特殊登录类型。阶段二是离线伪造。攻击者用工具在自己机器上指定krbtgt哈希、伪造用户名、指定SID和票据有效期生成kirbi格式的票据文件。这个阶段和你的内网没有任何网络交互几乎无法通过网络侧设备发现。阶段三是注入内存。攻击者把生成的票据文件注入到当前会话的内存中这个过程不需要管理员权限普通域用户就能完成但攻击者通常会以高权限用户身份登录后再注入以便直接访问目标资源。阶段四是访问资源。攻击者拿着伪造TGT去申请目标服务的ST然后像合法用户一样访问文件共享、计划任务、数据库等。从检测角度看阶段一和阶段四是防守方最有机会发现异常的两个点阶段二和阶段三基本属于“黑盒”。这也解释了为什么纯依靠边界防护设备很难防住黄金票据必须把检测重心放到域控日志和认证行为分析上。3.2 攻击过程中产生的关键痕迹很多蓝队同行问我黄金票据利用过程中到底会留下什么日志我的经验是与其找“黄金票据专用日志”不如盯住三类行为特征。第一类是异常TGS请求。正常的TGT生命周期由域策略控制Windows默认情况下用户票据的生命周期一般是10小时可续期到7天。如果你在日志里看到某个TGT对应的后续TGS请求持续了几天、甚至几个月这几乎可以断定有问题。第二类是票据里的用户身份奇怪。伪造票据可以任意指定用户名和SID但如果攻击者没仔细对齐域内真实数据就可能出现票据里的用户名查无此人、或者SID和用户名不匹配的异常。第三类是访问行为跳跃。一个平时只访问文件服务器的账户突然开始访问域控上的SYSVOL共享、尝试查询域对象这种跨资源跳转在高权限账户上尤其可疑。在授权测试中我甚至会故意让攻击者“做得糙一点”用不存在的用户名生成黄金票据再让蓝队去翻日志锻炼他们从大量正常请求里识别异常的能力。实测下来最有价值的是异常生命周期检测这几乎是所有蓝队都能快速上手、并且不会漏报的方向。3.3 授权测试中的验证要点如果你所在团队正在做红蓝对抗或安全评估想在测试环境里验证黄金票据风险我建议按下面的思路来设计用例而不是直接套用某个攻击命令一步到位。先准备一个隔离测试域里面至少有一台域控、一台成员服务器、一台客户端。测试前确认krbtgt哈希可以导出并记录当前域内一个普通用户的SID和用户名。接着生成一张伪造票据让票据使用一个域内不存在的用户名但指定一个高权限SID比如域管理员组的SID然后注入内存并尝试访问成员服务器。最后观察蓝队设备是否产生告警、域控事件日志里是否能追溯到对应的TGS请求以及通过流量抓包能否看到异常认证交互。这样设计的好处是能分层验证如果连不存在的用户名都能访问成功说明认证层面存在严重问题如果访问成功但没有任何日志记录说明你的日志审计策略要优化如果日志记录了但没人看那就是运营流程问题。我在多次内部演练中得出的结论是黄金票据问题的根源往往不在技术而在流程——日志有了但不告警告警有了但没人跟进。4. 防守方硬仗检测黄金票据利用的实战思路4.1 从Windows事件日志入手排查我自己做应急响应时第一站永远是域控的事件日志。不是说日志就一定能看到全貌而是它是成本最低、覆盖最全的起点。针对黄金票据我会重点关注这几个事件事件4769是“Kerberos服务票据请求”当攻击者拿着伪造TGT来申请ST时这里会留下记录。一个黄金票据利用过程中经常出现的特征是同一个TGT在短时间内为完全不同的服务申请ST而且这些服务分布在不同服务器上。事件4768是“Kerberos TGT请求”正常来说攻击者已经持有伪造TGT不会触发新的TGT请求但如果蓝队发现有“TGT请求来源不是通常的客户端”的异常也值得追查。事件4624是登录类型尤其要关注类型3网络登录和类型9显式凭据登录它们的来源IP有时能暴露攻击者的跳板。不过单独看日志会漏因为事件日志里记录的用户名可能是伪造的SID才是真正该对的东西。我在一个项目里遇到过一种情况攻击者伪造了一个“Administrator”用户名的黄金票据但SID指向的却不是真实域管理员账户日志里单看用户名完全正常一查SID才发现对不上。从那以后我把“用户名SID匹配性校验”写进了排查手册这比单纯看名字有效得多。4.2 重置krbtgt哈希的正确方法与误区检测到黄金票据利用痕迹之后最核心的修复动作就是重置krbtgt密码哈希原则是连续重置两次两次间隔至少12小时。很多人第一次听到这个方案都觉得奇怪重置一次不就行了为什么要两次原因是这样的域内所有域控之间通过多主复制同步数据krbtgt密码修改后会复制到所有域控。但如果你只改一次在复制完成之前那些还没来得及同步密码的域控仍然用旧哈希在签发和验证票据。攻击者如果在你改密码之前已经用旧哈希生成了一张超长有效期的黄金票据那么在这张票据到期之前依然有效。连续重置两次并等待足够长的复制时间是为了确保域内所有域控都完成了新旧哈希的同步并且第一次重置后的新哈希在复制窗口内也不会被攻击者二次利用。重置的时候有几个常见的坑我得提前说。第一不要在业务高峰做这个操作重置krbtgt会导致域内所有已签发的TGT和ST全部失效所有域用户都要重新认证影响范围极大。第二重置前要确认所有域控在线且复制正常只要有离线域控就必须等它上线并完成复制否则会出现新旧密码不一致的混乱。第三重置后要观察Kerberos相关服务是否正常运行尤其是有自定义服务账户的环境一些老系统对票据变化非常敏感可能会集中报错。微软官方文档里有一套相关的脚本逻辑核心就是用PowerShell把krbtgt密码更新两次。业界还有一种说法是“96小时稳一点”意思是两次重置之间可以拉开到4天进一步降低复制窗口被利用的概率。我在实际项目里按12小时一次来做已经足够但如果你是在重大攻防演练前做加固可以留出更充足的间隔给自己的环境留冗余。4.3 系统性的域信任安全加固清单重置krbtgt只是治标要真正降低黄金票据风险还得从整体加固上做文章。我把平时给客户做安全评估时推的一套清单整理出来你可以按顺序对照自己环境检查第一给DCSync权限上锁。DCSync攻击之所以能成功核心是攻击者拿到了“复制目录更改”和“复制目录所有更改”这两个权限默认域管理员组和企业管理员组都拥有这个权限。建议在AD中检查所有特权组的成员列表把不活跃的成员清出去同时可以在域控的安全设置里限制能够从网络访问该计算机的用户列表减少可以被滥用DCSync的账户面。第二启用LDAP签名和通道绑定。很多AD环境默认不启用LDAP签名导致攻击者可以降级认证方式配合中继手段拿到高权限。这里建议把域控上的“域控制器: LDAP服务器签名要求”策略设为“要求签名”并将客户端上的“域成员: 对LDAP服务器签名要求”也设为“要求签名”。第三把域管理员和其他高权限账户设置为“敏感账户不能委派”并开启“受保护的用户组”策略这个策略会强制使用Kerberos加密、禁止明文凭据缓存能显著提高攻击者拿到凭据的难度。第四管理本地管理员密码。在域内所有服务器和工作站上使用统一的本地管理员密码管理方案避免一台机器被攻破后攻击者用同样的密码横向打穿所有机器。第五关闭无用服务端口尤其是域名控上不对外暴露的135、139、445端口配合防火墙和网络分段减小攻击者的横向移动面。这套清单做完不敢说黄金票据绝对打不进来但攻击者要走到“拿到krbtgt哈希”那一步的难度会大很多。5. 关于黄金票据的高频疑问与实操经验5.1 为什么改了域管密码黄金票据还能用这个问题我反复被问到而且问的人往往是已经有几年经验的工程师。答案其实一句话就能说清楚域管密码和krbtgt哈希是两个东西黄金票据用的是后者你改前者当然没用。域管理员只是一个高权限账户KDC签发TGT时用的密钥是krbtgt账户的哈希域管密码变化不会影响krbtgt哈希本身。所以攻击者只要没暴露就可以一直用旧krbtgt哈希签发有效票据。这也是为什么所有标准修复方案都会强调“重置krbtgt”而不是“重置域管密码”。5.2 黄金票据和白金票据哪个更危险这个问题有点“关公战秦弓”的味道。黄金票据伪造TGT白金票据本质上是利用证书服务里的某些配置缺陷伪造允许用户登录的证书从而获得长期有效的认证凭据。两者都能实现持久化但攻击路径完全不同。现实情况里一个攻击者可能两种都用先利用证书服务的问题拿到合法证书再配合其他手段提取krbtgt哈希做双重保险。防守方别纠结于“哪个更危险”而是要把证书服务审计和Kerberos滥用检测都纳入日常监控。因为证书服务一旦被滥用检测难度比黄金票据高不少。5.3 如何判断域内是否已经出现过黄金票据这个问题没有一个“一键扫描就能确诊”的工具。我在应急响应中一般按三步走第一步从域控上拉取最近几个月的事件日志重点关注4769、4768、4624事件中SID异常、生命周期异常、来源IP跳变明显的记录第二步在网络层和设备层查找有没有非工作时间的异常认证流量特别是来自非域控机器却频繁请求TGS的IP第三步结合EDR数据检查域控和其他核心服务器上的进程注入、内存抓取痕迹。第一步和第二步可以交给自动化平台跑第三步通常需要人肉研判。只要三步里有两步都指向同一台可疑主机我就会建议客户进入排查流程。实践证明能发现黄金票据利用的往往不是某个单一产品而是一套能把日志、流量、主机数据关联起来看问题的分析流程。单纯依赖一个安全设备就想包打天下在域渗透这个层面是行不通的。5.4 我踩过的几次坑说了这么多方法论最后分享几个我实际踩过的坑算给后来人提个醒。第一次处理黄金票据时我上来就想重置krbtgt结果没注意到有一台离线的子域控密码复制没完成导致部分用户认证失败被业务部门投诉了整整半天。从那以后凡是涉及krbtgt重置我一定先检查所有域控的健康状态和复制状态哪怕多用一天时间也值得。还有一次在测试环境里验证黄金票据我忘记检查测试域是否接入了共享的信任关系。黄金票据在同一个域内有效但如果测试域和其他域存在双向信任伪造的票据有可能被其他信任域接受导致影响范围超出预期。在授权测试中这种失控是绝对不能接受的所以我现在动手前一定会先梳理信任关系。另外很多人会忽视“运营闭环”这件事。有一次某客户部署了很强的事件审计平台理论上黄金票据的异常TGT生命周期一定会被捕获但实际发生了攻击后告警确实产生了却被淹没在每天上千条低优先级告警里直到我进场翻日志才发现。技术设备都有了人没跟上安全能力依然是零。黄金票据这个技术说到底拼的不是工具多高级而是对信任模型的理解有多深。域渗透走到最后你会发现所有安全问题的根源都是信任被滥用Kerberos信任krbtgt的哈希于是哈希泄露就满盘皆输Web应用信任用户输入于是注入就大行其道。理解这一点比背一百条攻击命令都有用。希望这篇分享能帮你在域安全的路上少踩几个坑不只是知道“黄金票据是什么”更清楚“它为什么有效”以及“该怎么防”。