黄金票据攻击与防御：从KRBTGT哈希到域控安全加固

黄金票据攻击这个说法做内网安全和域渗透的人应该都不陌生。简单说它是我见过的域环境里最“一锤定音”的攻击方式之一拿到域控的KRBTGT哈希伪造一张谁都不会怀疑的TGT票据授予票据整个域就成了你自己的游乐场。攻击者有了这张票据想给自己签发什么身份都行横向移动、提权、持久化在这些能力面前基本都不值得一提。本文从防御者视角拆解黄金票据攻击的完整链路从Kerberos的认证底子讲起讲清楚它为什么这么强、实际攻击时哪些条件缺一不可、域控日志里会留下什么以及我们能做些什么把它堵住。适合刚接触域安全的运维、红队新人以及给客户做审计的乙方同学参考我不会给你堆一堆抽象概念尽量用大白话把这块讲透。1. 黄金票据攻击的基本概念与核心定位1.1 什么是黄金票据攻击“黄金票据”其实是一个很形象的比喻。在Kerberos认证体系里TGT是用户访问域内资源的第一道通行证而签发TGT的根密钥掌握在域控的KRBTGT账号手里。黄金票据攻击就是攻击者拿到KRBTGT的密码哈希之后离线伪造了一张生命周期极长的TGT再用这张TGT去换取任意服务的访问票据。很多朋友容易把黄金票据和白银票据搞混这里先做个最简单的区分黄金票据伪造的是TGT也就是所有服务访问的“总钥匙”白银票据伪造的是服务票据也就是某一把具体的“门钥匙”。就影响范围而言黄金票据覆盖整个域白银票据只影响单个服务。从攻击定位来说黄金票据攻击一般出现在攻击链的后期。攻击者通常已经拿下了域管权限或域控的某台机器但这并不意味着攻击就结束了。因为域管理员密码可以更改、会话可以被清理而KRBTGT哈希一旦改动会引发整个域所有票据失效所以很多防御者根本不敢随便重置它。攻击者正是抓住了这个痛点拿到哈希之后就立刻伪造长期有效的票据把权限固化下来哪怕后续管理员改了域管密码他手里的TGT照样能用。这里有个很反常识的点票据里写的用户名即使已经被禁用服务端在验证时也未必会立刻拒绝因为Kerberos协议里PAC的校验链路对票据内嵌信息的信任度很高。这也是为什么黄金票据能成为很多红队项目里最稳定的权限维持方案。1.2 黄金票据在整体攻击链中的位置在实际的事件响应里黄金票据攻击很少单独出现它前面通常跟着至少两三次前置突破。最常见的前置链路是某台员工电脑中了钓鱼邮件拿到一个普通账号在内网里用漏洞或弱密码提到本地管理员然后通过横向移动摸到域控或某台备份服务器再从LSASS进程里抓出KRBTGT的哈希。整个过程可能持续几周甚至几个月黄金票据只是最终“压轴”的那一下。理解了这一点做防御时就不能只盯着“伪造票据”这一个动作更要看它在整个攻击链中的前置信号。日志审计里如果频繁出现大量服务票据请求、异常的技术账号、不寻常的登录时段就要怀疑是不是已经有人在为最后的票据伪造做准备了。我给客户做应急响应时最头疼的不是发现黄金票据本身而是发现它之后往前回溯。因为攻击者在拿到哈希之前可能已经在域内活动了很久清理日志、删掉上传的工具、关掉计划任务最后留下一张票据。你如果只盯着4768这种TGT请求事件去查大概率什么都找不到。所以从项目管理的角度来说黄金票据攻击考验的不是某个点上的检测规则而是整个域环境的日志留痕能力和账号行为基线这块后面我会专门讲。2. Kerberos认证机制理解黄金票据的物理基础2.1 认证流程里的三部曲要理解黄金票据为什么难防必须先明白Kerberos是怎么工作的。我用大白话描述这个过程第一步客户端拿用户名和密码向域控的认证服务AS发请求域控验证通过后返回一个TGT里面包含用户的SID、PAC特权属性证书等信息整个TGT用KRBTGT的哈希派生出来的密钥加密签名。第二步客户端拿这个TGT向票据授予服务TGS申请访问某个服务的票据TGS验证TGT合法后返回一张服务票据ST。第三步客户端拿着ST去访问具体的服务比如文件共享、HTTP应用服务端校验ST无误就放行。这里最关键的是第一步的签名密钥。TGT不是明文存储的它是用KRBTGT的密码哈希派生的密钥来加密签名的。域内所有域控共享同一个KRBTGT对象所以任何一个域控上的KRBTGT哈希都能签发全网有效的TGT。攻击者不需要知道明文密码只要拿到这个哈希就能离线生成任意用户的TGT而且TGT里的PAC可以按需伪造因为PAC本身也需要通过KRBTGT密钥来验证你拿着根密钥自然想写什么就写什么。2.2 KRBTGT账号的特殊地位KRBTGT是Kerberos服务账号它在创建域时自动生成拥有一个随机长密码且这个密码默认不随其他域管密码策略一起自动轮换。很多单位从搭建域到现在很可能从来没改过KRBTGT的密码。这个账号无法直接登录、默认被禁用登录权限但它掌握着签发TGT的根密钥所以在整个域的安全体系里属于“核弹级”资产。如果给域内账号按敏感度打个分KRBTGT的敏感度比域管理员账号还要高一档因为域管账号还能靠改密码来止血KRBTGT哈希泄露意味着整个域的认证根基都暴露了。攻击者一旦通过DCSync利用域控复制协议远程抽取密码哈希或者拿到域控上LSASS内存这个哈希就成了一切票据伪造的根。这里要注意一个隐蔽点DCSync不一定要在域控上执行只要域用户拥有复制目录变更的权限就可能被滥用这也是黄金票据前置步骤里最不容易被发现的一环。所以在权限设计上对域对象“复制目录更改”权限的授予必须极其谨慎我见过不少单位把这项权限给了备份账号等于是把认证根密钥的备份通道主动交了出去。2.3 时间戳和票据生命周期的影响Kerberos协议对时间异常敏感TGT和ST都有时效。正常TGT默认有效期一般是10小时最长可续签7天。攻击者伪造的黄金票据最明显的特点是生命周期被改得非常长常见的有10年甚至“永远有效”。这种情况下域内的安全日志就会出现异常的生命周期字段。另外Kerberos还要求客户端和服务端时间偏差不能太大默认通常是5分钟如果域内时间没有严格同步那么伪造票据的时间戳和后续服务票据请求会在日志里露出马脚。这也是为什么在检测黄金票据时时间戳和lifetime是最优先排查的字段后面我会具体展开。这里额外提一句有些攻击者会故意把票据的有效期改成和正常票据差不多的10小时目的是躲避只查“超长生命周期”的检测规则。但那样做的话他就必须每隔一段时间重新伪造一次而且每次伪造的票据仍然需要对应KRBTGT哈希这就在日志里引入了一定的周期性。真正高水平的检测不会只看单个票据而是看一个用户在一段时间内的认证行为是否呈现出“无来源、无规律、高权限”的组合特征。3. 攻击原理与前置条件拆解3.1 伪造黄金票据的三个关键参数从技术上来说生成一张能用的黄金票据需要三样东西KRBTGT的哈希NTLM或AES256、目标域的SID、要伪装的用户名一般是域管理员或企业管理员。如果是在跨域信任的场景还需要知道对方的域名。满足这些条件后攻击者就可以用工具离线生成TGT完全不依赖当前在线状态、不用在域控上执行任何操作。这也是黄金票据和很多其他内网攻击不一样的地方生成过程是离线的只要参数正确票据在几天甚至几个月后依然有效。这里补充一个细节很多文章只说“需要KRBTGT哈希”但实际操作中如果域环境启用了AES加密通常还需要AES256哈希。如果攻击者只拿得到NTLM哈希生成的票据在某些服务上可能无法使用。所以攻击者会倾向于在拿到哈希后同时确认域控的加密类型配置避免出现票据被拒的尴尬。从防御角度讲优先启用AES256、逐步禁用RC4也是一条非常重要的加固路径因为RC4密钥可作为降级攻击的入口。3.2 攻击者如何拿到KRBTGT哈希这里我用防御视角描述常见的哈希泄露途径希望各位运维朋友能对着自查域控上的ntds.dit文件被读取离线解析出全部哈希。这个文件默认位于C:\Windows\NTDS\ntds.dit很多备份软件会把它复制到共享目录甚至运维跳板机上一旦那块区域失守哈希就等于是送上门。通过DCSync攻击利用复制协议从域控远程拉取KRBTGT的哈希。这一类在域控日志里会留下目录服务访问事件但很多单位没有对“复制目录更改”权限做审计导致漏报。攻击者在域控上拿到SYSTEM权限后从LSASS进程内存里挖出Kerberos密钥。这类行为可以发生在任何一台域控上所以对域控的登录防护要格外严格。备份文件和快照泄露。有些虚拟化平台会给域控做快照快照文件如果放到普通存储或者运维网段被突破攻击者直接把快照下载下来离线提取哈希全程不需要碰在线域控。防御者应该把注意力放在这些泄露点上而不是只盯最后的伪造动作。安全设备常用入侵检测规则会盯“dcsync”和“lsass读取”这些行为但事件响应时你往往会在会话清理之后才发现异常。这里最重要的原则是在域环境里任何非域控机器上的SYSTEM权限操作都要谨慎放行任何备份域控数据的行为都必须走审批和加密通道。3.3 黄金票据的影响范围黄金票据的杀伤力在于“全域信任”。有了TGT之后攻击者可以伪装成任何域用户包括但不限于域管理员组的成员、禁用或已删除的账号甚至可以伪造一个不存在的SID然后把自己加入高权限组。票据机制决定了服务端校验ST时会信任PAC里的信息而PAC又由TGT传递。只要KRBTGT哈希没改攻击者伪造的票据就一直有效即使原始账号的密码已经重置、即使账号被删除。这就是为什么说它是“一道很难撤销的权限”。影响范围还体现在跨域和森林信任上。如果两个域之间存在信任关系而攻击者拿的是根域的KRBTGT哈希那他甚至可以尝试去访问子域或其他信任域的资源这会进一步放大攻击半径。所以在做域信任设计时需要严格控制信任的方向和访问边界不要让一个域的认证根被突破后直接波及其他域。4. 实操视角攻击在测试环境中的全过程与现场痕迹4.1 一个典型的模拟实验设置这里说下我在授权测试环境里怎么验证黄金票据。一般会准备两到三台Windows Server 2022域控和两台成员服务器客户端加入域配置好DNS、时间和Kerberos策略。模拟攻击时拿到KRBTGT哈希后可以生成一张用户名为“fakeadmin”的票据然后把票据导入当前会话再去访问某台文件服务器上的加密共享。整个过程里我不会碰业务域只观察域控上的安全日志变化。整个验证的核心不是“能不能通”能通是必然的重点是要搞清楚“通了之后日志里到底长什么样”这样才能回头去写检测规则。这里面有个容易被忽略的细节测试域的日志级别要和真实生产环境保持一致。很多人在测试环境把审核策略全开了结果生产环境什么都没有最后拿测试环境的检测经验去上线等于纸上谈兵。我一般会把测试域先按生产域的审计策略配置好再逐步打开更细的审核项这样才能模拟出“在真实配置下黄金票据到底有没有痕迹”的效果。4.2 攻击成功后域控日志里的关键异常分享几个我在测试环境中观察到的技术指标这些都是可以在生产环境预演的事件ID 4768Kerberos TGT已请求请求者的IP与用户常规登录来源不一致或者TGT生命周期和默认值差异过大。如果组织把默认生命周期设成10小时突然出现一个几百天生命周期的4768必须重点盯。事件ID 4769Kerberos服务票据已请求同一用户短时间内向大量服务请求ST且服务端IP不在该用户业务范围可能是在拿黄金票据“刷服务”。这里要尤其关注SPN异常比如请求了多个非业务相关的服务。事件ID 4624登录成功登录类型3网络登录和类型10远程交互登录同时出现或者一个被禁用的域管账号突然在域控上登录都是信号。日志里出现加密套件异常正常环境多数用AES256突然出现RC4加密的TGT请求。如果组织已经禁用了RC4这个直接可以定为高可疑。需要注意的一点是上述异常不一定在攻击成功当天就出现。黄金票据的加密特性决定了它可以用“后来再登录”的方式使用攻击者完全可能在拿到哈希之后隔一个月再伪造并登录。因此检测黄金票据不能只看单点事件要把时间窗口拉长到几天甚至几周。4.3 为什么很多防护设备明明部署了还是漏了做SIEM的人经常会遇到一个尴尬告警出来了但因为没有上下文只能按低危忽略。黄金票据的一个特点是认证包本身完全合法他拿着真钥匙走正门刷卡、过闸机上全都有记录但每一条记录单看都合理。所以规则层面很难直接封死更多要靠“账户行为基线”来判断。比如某个账号三个月没登录过突然在凌晨三点请求了一堆服务票据这种偏离基线的行为人工研判的价值远大于一条固定规则。我见过不少单位上了很贵的态势感知规则库里确实有“黄金票据检测”但检出效果很差。原因很简单规则默认了攻击者会把票据生命周期改成十年而真实攻击者早就知道了这条规则会改成正常时长。所以我在做检测项时从来不以“生命周期超长”作为唯一的金标准而是结合登录来源、服务请求数量、时间区间、加密类型四维一起来打点。这也是为什么我要在这里反复强调别把黄金票据检测当成一个“签名匹配”问题它本质上是“行为偏离”问题。5. 防御与加固从根上降低黄金票据的杀伤力5.1 先保住KRBTGT哈希防御黄金票据的第一原则就是别让KRBTGT哈希落到攻击者手里。具体做法包括域控安全加固关闭不必要的服务、及时打补丁、限定管理口的来源IP。域控不能像普通应用服务器一样随便对外开放管理网段要收敛到独立且受控的堡垒网络。保护好域管账号不在普通机器上使用域管凭证使用受保护的管理主机有条件可以采用Privileged Access Workstation方案。对DCSync行为做监控域对象上的“复制目录更改”权限要收紧不要随意授予普通账号。更稳妥的做法是定期审查域内所有账号对该权限的持有情况。备份与快照要单独加密ntds.dit的备份副本是泄露哈希最常见的路径之一。对备份系统做双因子认证、限定备份恢复的人员和机器比给备份系统打补丁还重要。提示这个原则要从整体权限设计入手。我见过不少单位给“备份管理员”配了域对象复制权限一旦该账号被拿走DCSync直接可用黄金票据只是时间问题。5.2 定期重置KRBTGT密码的正确姿势前面说过KRBTGT密码默认不轮换但真正重置它是有讲究的。因为域内所有域控共享同一个KRBTGT对象重置必须在短时间内传播到每台域控。最稳妥的操作是分两步走第一次重置KRBTGT密码等待复制完成后把之前可能存在的所有TGT全部作废。至少等待12到24小时确保所有域控复制状态健康、没有落伍的域控。再重置一次把以前可能已经泄露的、以旧哈希签发的票据彻底失效同时避免AD密码历史里留下可追溯的旧值。具体命令可以用PowerShell里的Set-ADAccountPassword但执行前必须在测试域完整演练一遍。执行时要避开业务高峰因为重置之后所有已签发的TGT会全部失效域内客户端的首次认证会遇到短暂的重新认证过程。这个短期影响通常可以接受但如果环境里有大量缓存的计划任务或服务账户就需要提前准备。重置KRBTGT密码不能做成“一年一次”的机械动作。如果你的域很大、分支很多先做一次清点统计DC的复制状态把健康检查做了再动手。真正要养成习惯的是每次重置后观察24小时内的认证失败和复制错误确认没有异常再结束操作。5.3 利用安全事件线和日志基线做主动发现除了被动等待告警建议搭建一个简单的Kerberos异常分析管道。不一定要多贵用现成的SIEM甚至ELK就能做。核心思路是这样收集域控的4768、4769、4624日志归一化到同一个平台保留至少六个月。对每个用户建立TGT生命周期基线生命周期超过三倍基线的直接高可疑。这里的基线不是固定值要按用户类型分组。对服务票据的“请求服务数量”做阈值比如一个账号十分钟内请求超过五十个不同服务触发通知。对“TGT请求来源IP”和“用户常规登录来源”做资产关联出现非法来源要重点看。这一步不需要很高级的模型一张聚合表加几个SQL查询就能做出很好的效果。我个人的经验是不要只看单条日志要看用户维度的时间切片。黄金票据最大的弱点是“生命周期长”只要在检测模型里把生命周期和登录频率同时考虑漏报的几率会大幅下降。当然恶意攻击者也可能伪造短生存期票据但这种情况下他得持续依赖KRBTGT哈希次数多了一定会在来源和频率上留下线索。6. 常见问题与排查技巧实录6.1 黄金票据和白银票据怎么区分很多人在应急响应时分不清这两个概念我直接用表格总结几个关键差异维度黄金票据白银票据伪造对象TGT服务票据ST所需哈希KRBTGT哈希目标服务账号哈希影响范围整个域单个服务依赖在线不需要不需要日志痕迹AS请求阶段4768异常TGS请求阶段4769异常检测难度较高中等实际排查时先看是哪一类日志异常再决定优先关注哪些资产。比如在4771或4768里发现大量异常优先排查KRBTGT是否泄露如果只在4769里发现某个服务的异常优先排查那个服务账号的哈希是否泄露。这两条线的处置思路完全不同用错方向会耽误很多时间。6.2 发现可疑TGT之后怎么处理最快如果怀疑环境中存在黄金票据最紧急的处置不是去删除某个会话而是考虑让旧票据快速失效。直接的思路是先确认KRBTGT是否已泄露查看域控进程里有没有异常的内存读取行为同时检查最近一周是否有DCSync相关的目录服务访问审计。临时启用域管账号的登录限制阻断用票据换取服务票证的后续访问。这里可以配合对High Value账号进行双因子保护。重置KRBTGT密码这是唯一能让旧票据彻底失效的办法。按前面说的两步重置来做不要图快一次搞定。在日志平台里针对伪造账号和异常生命周期做一次全量回溯找出攻击者的首次出现时间判断是否还有后门。这个处置过程中最忌讳的是在没有确认哈希泄露范围的时候就重置密码。我有一个项目里客户先重置了一次KRBTGT结果攻击者已经通过其他后门控制了另一台域控新哈希也被拿走了重置等于白做。所以处置之前必须先把攻击链上所有可能的域控权限都排查干净否则治标不治本。6.3 我做域安全评估时踩过的一些坑最后说点个人经验。早期做域安全评估时我总想把所有攻击行为都拦在门外于是加了一堆严格的规则结果业务账号因为票据续签经常报错运维团队差点把我拉黑。后来才明白对黄金票据这类认证层攻击真正的防御底座是权限收敛和密钥管理日志和规则只是发现工具。你不能指望靠一条规则就挡住所有攻击但良好的密钥管理习惯能让攻击者即使进来了也拿不到最有价值的东西。还有一个很真实的案例某个客户在应急响应时发现事件日志里根本没有4768排查后才知道他们域控日志被清理过之前的所有证据都没了。这件事提醒我域控的日志必须实时外传只存本地根本不安全。建议把域控安全日志接到独立的日志平台设置保留期至少六个月同时监控“清除安全日志”这个行为本身一旦出现4639事件立刻按事故处理。黄金票据攻击真正的可怕之处在于它的密钥根源很少被轮换、日志痕迹又容易被清洗所以我们要做的不是等它发生时去补救而是提前把密钥管好、日志留好、权限收好。只要这三件事做到位它就不再是无解的攻击了。