1. 为什么Kerberos成了权限维持的兵家必争之地干了这么多年内网安全我越来越觉得一个道理不理解Kerberos就谈不上理解Windows域环境下的攻防对抗。在内网AD域环境里Kerberos不是单纯的一个认证协议它是整个域信任体系的基石也是红蓝双方反复拉扯的核心战场。黄金票据、白银票据、钻石票据、蓝宝石票据这些听起来像是某种宝石收藏的名字本质上全都是围绕Kerberos这个协议做文章的产物。先说清楚Kerberos到底解决了什么问题。在一个AD域环境里用户、计算机、服务有成百上千个如果每个服务都自己维护一份密码表那IT管理员得疯掉。Kerberos的设计思路是引入一个可信第三方——域控Domain Controller里的KDCKey Distribution Center由它来统一颁发通行证。我把这个过程简化成大家熟悉的场景。你想进一栋大楼访问某个服务不能直接进去得先到物业中心KDC办一张门禁卡TGT票据授权票据然后再拿着门禁卡去对应的楼层管理处TGS换取该楼层的临时门禁权限ST服务票据最后拿着ST去刷具体的门目标服务。整个过程里门卫目标服务不需要认识你本人它只认票据是否由它信任的机构签发、签名是否有效。这里有一个容易被新手忽略、但对后续理解票据攻击至关重要的细节票据里的核心信息是PACPrivilege Attribute Certificate特权属性证书。PAC里装着你的SID、所属组、权限策略等信息。换句话说Kerberos系统判断你是谁、你能干什么依据的不是你这个人本身而是KDC在签发TGT时塞进PAC里的那一堆字节。那么问题来了如果攻击者能伪造一张票据或者篡改票据里的PAC域控和目标服务能不能识别出来答案取决于签名和校验机制。而黄金票据这类攻击的根源恰恰在于Kerberos协议对某些环节的信任假设过于淳朴——它信任krbtgt账户的密钥信任服务账户的密钥信任PAC的签名链而这些信任一旦被打破整个认证体系就形同虚设。搞懂了这块基石后面看黄金、白银、钻石、蓝宝石这四种票据的攻击思路和检测思路就能串成一条完整的线。否则你只会背几个命令换个环境照样两眼一抹黑。2. 黄金票据与白银票据从伪造身份到定向访问的思路演变2.1 黄金票据的底层逻辑拿到krbtgt哈希等于拿到整个域的签发权黄金票据是我接触最早、也是理解成本最低的一种票据攻击。它的目标非常直接krbtgt账户。在每一个AD域里都有一个名为krbtgt的账户这个账户的密码默认在域创建时自动生成几乎不被人为修改。它的哈希被KDC用来加密和签名所有TGT。也就是说整个域的门禁卡签发系统的信任根就是krbtgt的密码哈希。攻击者如果通过DCSync、域控提权等方式拿到了krbtgt的哈希就可以在任意一台机器上不需要接触域控自己伪造一张任意用户的TGT。这张TGT可以指定任意用户名甚至可以指定任意SID和组成员身份。举个例子攻击者可以生成一张用户名为Administrator、SID为域管理员的TGT有效期设置成10年。在这10年内这张票据几乎等同于一个合法的域管理员身份可以访问域内几乎所有资源而且不需要跟域控有任何交互。这也是为什么黄金票据常常被视为一种极强、但又足够粗犷的权限维持手段——它的威力极大动静也相对容易暴露。理解黄金票据的检测视角要抓住一个核心矛盾krbtgt账户本身的密码哈希不应该是经常被使用的对象更不应该在非域控机器上出现。正常情况下krbtgt的哈希只存在于域控的内存和注册表里。一旦你在某台业务服务器或工作站上看到了用krbtgt哈希签发的TGT那基本可以认定域控已经失守或者域管权限已经被拿下了。2.2 白银票据服务级别上的精准制导黄金票据是伪造TGT白银票据则是伪造ST。两者的思路完全不同但基础逻辑相似都是利用信任根被泄露来伪造合法性。白银票据针对的是具体的服务账户哈希比如SQL Server服务账户、HTTP服务账户、CIFS文件共享服务账户。拿到某个服务账户的哈希后攻击者可以直接伪造一张访问该服务的ST不需要与KDC发生任何交互也不需要TGT。这就像是你拿到了某栋楼某个楼层的门禁卡模板直接照着复制一张去刷这个楼层的门不需要再去物业中心办卡。白银票据的隐蔽性比黄金票据高不少原因有几个它不产生与域控的任何通信流量域控看不到它。它只影响被伪造的那个服务不需要带着管理员权限的SID到处招摇。服务端验证ST时可能不会每次都校验PAC甚至有些服务压根不校验PAC签名这就给了攻击者可乘之机。但白银票据也有明显的局限作用域非常窄。你想访问文件共享就得伪造CIFS服务的ST想访问HTTP应用就得伪造HTTP服务的ST。每个服务都需要单独伪造一张票据不像黄金票据那样一张走天下。在实战中白银票据更适合在已经拿下一台服务器之后做横向移动到特定服务或是在日志已经很嘈杂的环境里做低成本的权限维持。2.3 两类票据的横向对比该用哪种凭什么维度黄金票据白银票据伪造对象krbtgt账户哈希签发任意TGT目标服务账户哈希签发特定ST影响范围整个域所有服务单一服务或同一哈希下的多个服务隐蔽性相对较低域控可能检测到异常TGT更高不产生域控交互流量前置条件DCSync或域控权限拿到krbtgt哈希拿到目标服务账户的哈希往往需要本地管理员权限持久性可设置极长有效期同样可设置有效期但受制于服务范围检测难度中较高个人经验是红队做权限维持时经常会先用白银票据探路、做特定服务访问再在关键时刻落一张黄金票据保底。蓝队如果只盯着黄金票据的检测特征很容易漏掉白银票据这种小而美的持久化手法。理解这两者的差别不是为了会操作而是为了在日志里能认出来。3. 钻石票据与蓝宝石票据贴着合法边界游走的进阶变种3.1 钻石票据改造而不伪造踩着合法TGT的肩膀往上爬黄金票据最大的破绽之一是它完全是凭空生成的。域控上的认证日志里如果出现了一个没有对应AS-REQ记录的TGT那就是明显的异常信号。蓝队只要把TGT是否都有对应的请求记录作为一个检测点黄金票据的生存空间就被压缩了一大截。于是就有了钻石票据的思路——不再凭空伪造而是拿到一个合法用户的TGT解密它、篡改其中的PAC再用krbtgt哈希重新签名最后把这张改良版合法TGT放回环境中使用。这个过程你可以理解成不重新造一张身份证而是拿一张真的身份证把照片和姓名换了再盖上真章放回去。由于这张TGT确实是从合法请求流程中来的它的相关日志链路更完整比凭空伪造的黄金票据更难被审计系统标记。钻石票据需要在内存中直接修改票据内容对攻击者的操作精细度和对PAC结构的理解要求更高但换取的是明显的隐蔽性提升。从防御角度钻石票据真正让人头疼的地方在于——它不再违反有请求才有票据的日志规律传统的黄金票据检测思路直接失效。检测钻石票据需要更底层的特征比如PAC的签名时间是否合理、票据的续期历史是否连贯、被修改PAC的用户的会话行为是否与之前一致等。这类检测对普通企业来说门槛不低但也并非无解后面我会展开说。3.2 蓝宝石票据当密码轮换也挡不住持久化蓝宝石票据算是这个宝石家族里比较新、也比较反直觉的一个变种。常规认知里当怀疑域环境失守时安全团队的第一反应是重置krbtgt密码。毕竟黄金票据的根子就在krbtgt哈希改了密码旧的TGT理论上全部作废这是公认的标准加固动作。蓝宝石票据的发现恰恰扇了这个认知一耳光。它利用了Kerberos密码轮换机制的一个细节在Windows环境中Kerberos的密钥类型是分版本管理的旧密码对应的密钥不会在修改后瞬间失效而是会保留一段时间用于处理历史票据。攻击者如果拿到了旧版本的krbtgt密钥并且能判断出当前版本的密钥是旧版本密钥的后代因为域内密钥轮换有一套固定的派生关系就可以构造出一种特殊票据——这张票据既能通过旧密钥的验证又能在当前密钥体系中看起来有效。这意味着什么意味着哪怕你重置了krbtgt密码只要攻击者提前拿到了轮换前的密钥材料它依然能生成一张当前环境认可的TGT。权限维持的周期被进一步拉长重置krbtgt密码这个标准应对动作的有效性被打了一个大折扣。从实战角度蓝宝石票据的原理理解门槛比前三个都高但其表达的核心理念值得每个安全运营人员记住应对方案不能永远假设轮换一次密码就等于清理干净了。在真实的应急响应中krbtgt密码重置之后我通常会强调继续监控至少两轮密码生命周期不能重置完就急着下已清除的结论。3.3 从黄金到蓝宝石攻击思路的演进主线把四个票据放在一起看能清晰看到一条演进脉络黄金票据——信任krbtgt哈希的不可泄露性。泄露了就彻底沦陷。白银票据——信任服务账户哈希的不可泄露性。范围缩小但更隐蔽。钻石票据——不再无中生有改为借壳上市规避基于日志完整性的检测。蓝宝石票据——连轮换密钥这个最后的防线都要绕过去。这条脉络本质上回答了一个问题在AD域这个信任体系里攻击者永远在寻找那个只要拿下一个秘密就能持续伪装合法的交汇点。防御者要做的不是寄希望于某一个秘密不出意外而是要围绕这些交汇点建立多层的检测与响应能力。4. 从攻击手法反推检测信号日志、行为与异常特征4.1 域控日志里的关键事件ID怎么读、怎么串做票据攻击检测域控的安全日志永远是第一战场。虽然没有哪一条单一日志能直接告诉你这是假票据但把几个事件拼在一起往往能还原出完整的故事线。我平时最关注这么几个事件ID4768TGT请求每次用户获取TGT时产生。重点关注有没有没有前期AS-REQ过程却凭空出现TGT的对应关系这往往是黄金票据的信号之一。4769ST请求用户请求服务票据时产生。重点关注请求的服务类型是否异常、发起请求的IP是否是预期内的。4672授予特殊权限用户获得管理员特权时产生。如果对应用户的会话行为看起来很陌生就要回头查它之前获取的TGT。4624/4625登录成功/失败重点看登录类型、来源IP、使用的账户是否匹配业务场景。很多团队部署了SIEM之后只知道把4768、4769拉出来存数却从没做过事件之间的关联。我自己的习惯是建一条简单的规则凡是4768/4769中出现的账户名在最近24小时内没有对应的工作站登录行为先标记为可疑。这条规则不算精妙但在实际环境里能筛出不少白银票据和初始攻击痕迹。4.2 时间漂移与服务访问的反常理特征票据攻击的本质是冒充合法身份所以身份侧做检测不如行为侧更灵敏。举个例子一台文件服务器平时只在工作时间9点到18点被访问突然在凌晨3点出现一个域管账户的TGT并用它请求CIFS服务即使这张TGT在技术上完全合法它也值得被标记。再比如时间漂移。Kerberos协议对时间非常敏感TGT和ST里都带时间戳。正常情况下票据的起始时间和当前时间差应该在几分钟以内。如果一个账户的票据有效起始时间戳和它在域内的登录时间完全对不上或者票据时间戳存在明显的回拨/前跳这通常是伪造票据时时间设定不严谨留下的破绽。还有一类行为特征容易被忽略服务账户的异常认证行为。服务账户的密码几乎不会被人为改动其哈希通常只存在于配置文件和系统服务里。如果检测到某个服务账户的哈希在短时间内被大量不同主机用于票据请求那极大概率是白银票据在横向移动。这类规则在Windows事件日志里实施起来不复杂关键是要有服务账户不该满天飞的基线意识。4.3 蓝队最容易踩的三个误判我见过不少蓝队朋友在票据攻击检测上摔跟头总结下来主要有三类误判第一类是把看到krbtgt相关日志直接等同于失守。实际上域控之间复制、特殊管理操作都会触发krbtgt相关记录直接拿这个做告警会让运维团队疲劳轰炸最后反而漏掉真信号。正确的做法是关注krbtgt哈希的非预期使用比如某个普通账号请求了含krbtgt PAC签发的TGT或者TGT的加密类型异常。第二类是过度依赖重置krbtgt密码这个动作。前面蓝宝石票据已经说清楚了轮换密码不等于切断所有后路。每一次密码轮换之后我建议至少做一轮完整的日志回溯——观察有没有轮换时间点之后依然在用旧密钥签发票据的情况确认旧密钥相关的持久化确实被清理干净。第三类是忽视服务账户哈希的泄漏面。很多企业把所有服务都跑在域管账户下一旦某台机器被拿白银票据的利用条件瞬间拉满。我在评估AD域健康度时会花大量时间梳理哪些服务账户拥有过高权限这些账户的哈希暴露在多少台机器上。这个基础工作不做后面的检测规则都是空中楼阁。5. 加固与响应的实操清单让票据攻击打不进来、传不下去5.1 krbtgt密码轮换的正确打开方式关于krbtgt密码重置网上能搜到大量脚本但真正做得规范的不多。这里给出一个我在应急响应中反复使用的流程框架先评估当前域内是否存在活跃的恶意票据手段包括检查是否有异常TGT请求记录、检查域控上是否有非预期进程和计划任务。使用微软提供的工具或脚本分两步修改krbtgt密码改第一次等域控复制完成后再改第二次确保每个域控都拿到新密钥。为什么必须分两步因为Kerberos有密钥版本的概念一次性修改可能导致部分域控仍使用旧版本密钥签发票据反而留下混乱。修改完成后强制所有域成员主机重新加入身份认证流程重启机器或注销重登让每个用户重新获取TGT。修改完成后持续监控至少一个完整票据生命周期重点观察是否出现使用旧密钥版本签发的TGT仍在请求服务票据的记录。常见的一个误区是改完密码就完事后面也不再关注。事实上krbtgt密码轮换后的头几天恰恰是攻击者最容易暴露的时间窗口——他们持有的旧票据无法继续使用了大概率会重新触发认证行为此时日志里的异常请求反而比平时更明显。5.2 服务账户与特权账户的收敛策略白银票据和钻石票据都能从服务账户哈希泄露里获得养分所以收敛服务账户的暴露面是性价比极高的一项加固。第一步盘点域内所有服务账户。别只盯着名字里带svc的账户很多隐藏的服务账户用的是普通用户命名规则要结合被哪些服务使用密码是否设置为永不过期是否加入了本地管理员组几个维度去筛。第二步给每个服务账户分配仅够用的权限。比如某个服务只需要读取文件共享就给它一个仅对该共享有读取权限的账户绝不顺手加到域管组。这条原则说起来人人都知道做起来却经常因为图省事而破功。第三步开启服务账户相关的审计策略对服务账户请求高权限服务票据这类行为做定向告警。一旦某个服务账户开始访问与业务无关的服务告警应该直接拉响。特权账户的收敛思路类似额外要关注的是受保护用户组Protected Users。把这组策略用起来之后域内高价值账户的TGT生命周期会大幅缩短攻击者想用一张长期有效的黄金票据做持久化难度会显著增加。5.3 日志审计的能力建设采集、保留、响应检测票据攻击最大的现实障碍往往不是规则写不出来而是数据根本不全。很多企业的域控安全日志默认只保留几天出了问题再去翻早就被覆盖了。这里有几个具体建议域控的安全日志至少要集中到独立的日志服务器保留周期建议不低于180天。攻击者的持久化周期往往以月计仓促的日志周期等于给攻击者送掩护。重点采集的日志来源包括所有域控的Security日志、DNS服务器日志Kerberos请求里主机名解析会留下DNS记录、DHCP日志辅助定位来源IP对应的物理设备。引入Sysmon之类的工具增强进程级可见性。票据攻击的很多操作如内存中的票据注入不一定会直接反映在Security日志里Sysmon的参数记录往往能补上这一环。我个人在实际项目里还有一个习惯每隔一段时间手动发起一次票据攻击模拟演练用合规的测试手段验证当前告警规则能不能真的抓到可疑票据。只有跑过模拟你才知道SIEM里那些规则是纸面有效还是实战有效。这个动作不需要很频繁季度一次就够但每次都能发现一些被忽略的检测盲区。5.4 检测与响应联动被动防御不如主动狩猎规范化日志采集之后就可以进入更高一级的能力建设主动狩猎。所谓主动狩猎不是坐在SIEM前面等告警而是定期在日志里翻找不该出现但确实出现的现象。我常用的狩猎切入点包括TGT请求里包含异常加密类型域内统一使用AES加密时突然出现RC4加密的TGT请求这个信号往往意味着攻击者正在尝试做降级攻击或用旧哈希生成票据。同一账户在多台机器上同时有活跃TGT正常情况下一个用户不太可能在同一时刻在5台机器上发起票据请求。这类信号在日志关联分析里非常明显。敏感组域管、备份操作员等成员的TGT请求记录出现非工作时间这类账户通常有固定的运维窗口打破窗口本身就值得调查。需要强调的是这些狩猎动作不是靠一个人拍脑袋就能完成的它要求负责日志分析的同事对域内业务架构足够熟悉。比如哪些机器是核心业务、哪些账户是真实在用的、哪些服务本来就需要跨域访问。脱离业务背景的日志分析只会产出大量误报最后不了了之。6. 关于这些宝石票据我最后想说几句票据攻击演进到今天已经从早期的威力至上明显转向了隐蔽至上。黄金票据时代红队拿到krbtgt哈希就大摇大摆到了钻石票据和蓝宝石票据阶段攻击者开始认真思考如何让自己的行为镶嵌在正常的Kerberos流量之中让每一次认证请求都显得合情合理。这对防御方提出的要求是不能再指望某一条银弹规则解决所有问题更不能再迷信重置密码就是最终手段。我在实际做域安全建设时反复跟团队强调一个理念——把域环境当成一套需要持续维护的信任体系而不是一个配置完就再也不动的静态系统。日常巡检、基线核对、日志狩猎、定期演练每一件事看起来都不惊天动地但组合起来才是让票据攻击者真正感到棘手的那张网。如果这篇文章能帮你把Kerberos这套体系的理解从背命令提升到看本质那我觉得花在它上面的时间就值了。最后留一个建议找一台测试域控把认证日志开全自己动手构造一次合规的票据攻击流程再回到日志里逐条对照那几个事件ID。只有亲手走完这条链路你才会真正理解为什么Kerberos既是企业认证的王牌也是内网攻防里最惊心动魄的战场。