如果你管过一套 Windows 域环境或者参与过红蓝对抗那你一定听过“黄金票据攻击”这个名头。它是 Kerberos 认证体系里最经典、破坏力也最大的一种横向攻击方式。简单说攻击者只要拿到了域控里 KRBTGT 账户的哈希就相当于掌握了整个域的“信任根”能给自己签一张“万能通行证”想冒充谁就冒充谁想访问哪个服务就访问哪个服务而且这张票证除非自然过期否则几乎没有办法被单独撤销。这篇内容我想从攻击原理、影响范围、实操还原和防守视角四个方面把这套东西讲透。不管你是刚接触 AD 安全的新人还是已经在做应急响应和检测规则的老手应该都能从中拿到一些可以直接落地的思路。先说清楚一个前提我这里讲攻击流程最终目的是为了防御。黄金票据的底层逻辑如果理解不透蓝队根本没法写检测规则也没法判断自己是否已经中招。所以我会尽量用“从业者之间说话”的方式把原理、操作和排查经验串在一起。1. 黄金票据攻击原理拆解先从 Kerberos 认证说起1.1 Kerberos 的三要素票据、KDC 与 KRBTGT 账户要理解黄金票据为什么“金”得先把 Kerberos 认证流程拆开。Kerberos 是 Windows 域环境默认的认证协议核心目标就一句话让客户端向服务端证明“我是我”且不需要在网络上传输明文密码。这里的三个关键角色分别是客户端、服务端和 KDCKey Distribution Center密钥分发中心。KDC 部署在域控上可拆成两个逻辑组件ASAuthentication Service认证服务和 TGSTicket Granting Service票据授予服务。用户登录时客户端会向 KDC 的 AS 服务发起 AS-REQ 请求里面带着自己的用户名和加时间戳的认证信息。AS 验证身份后返回两个东西一个是用户要访问目标服务时用的票据授权票据 TGTTicket Granting Ticket另一个是用于解开 TGT 的会话密钥。TGT 本身不是拿用户的密码哈希加密的而是用 KRBTGT 账户的哈希加密。KRBTGT 是域里一个内置的、基本上永远不登录、不交互的特殊账户它的密码哈希就是整个域“签发信任凭证”的根密钥。当用户后续想访问某个服务比如文件服务器、Web 应用客户端会带着 TGT 去找 TGS 服务申请服务票据 STService TicketTGS 先验证 TGT 是不是由合法 KRBTGT 签发验证通过后才会发放针对具体服务的 ST。这个过程可以类比成一个大型公司的门禁系统。员工进门需要刷工牌生成一张临时通行卡TGT这张临时通行卡要想到不同楼层办事还需要到总服务台盖章换取对应楼层的门禁卡ST。总服务台认的不是员工本人而是“公司统一使用的钢印”KRBTGT 哈希。只要钢印是真的总服务台就会认为临时通行卡可信。黄金票据攻击的思路就是攻击者偷到了这颗钢印本身然后自己拿张白纸印了一张总裁级别的临时通行卡放到门禁系统里。1.2 “黄金”体现在哪里伪造信任根而非绕过验证很多人一开始会搞混这个概念以为黄金票据是绕过 Kerberos 验证。其实恰恰相反它是顺着 Kerberos 验证规则把它最顶层的那把“根钥匙”拿到手然后合法合规地伪造身份。攻击者不需要知道域管理员密码不需要碰目标用户的密码甚至不需要和域控产生明显的认证交互。一张合法 TGT 的内容包括用户名、用户域 SID、用户 RID、票据有效期、签发时间、holding 信息等。这些内容最终由 KRBTGT 哈希签名并加密。攻击者一旦拿到了 KRBTGT 哈希和域的 SID就可以通过 Mimikatz 这类工具手工构造一个指定用户名例如 Administrator、指定 RID例如 500即域管理员默认 RID、自定义有效期的 TGT。然后通过ptt命令把这张伪造票据注入当前系统会话或者用tgt::ask等方式把它导入到内存里。后续访问域内任意主机、任意服务时系统会拿着这张伪造 TGT 去申请 ST域控的 TGS 只认 KRBTGT 哈希是否能正确解密根本不检查这张 TGT 是否真的由 AS 签发。这也是黄金票据和白银票据最大的区别。白银票据是针对某个具体服务的伪造 ST它需要拿到目标服务账户的哈希只能访问那一个服务。黄金票据则是伪造顶层信任拿到后可以访问域内几乎所有服务而且如果后续再申请某个服务的 ST都是合法流程。用一句话总结就是白银票据是伪造了一把房间钥匙黄金票据是伪造了整栋大楼的备胎门禁卡可以刷开绝大多数房间。更麻烦的是黄金票据的有效期可以自定义攻击者甚至可以给它设置成 10 年只要域内不主动重置 KRBTGT 密码这张票就在那能持续流通。2. 攻击前置条件与影响范围分析2.1 拿到 KRBTGT 哈希的常见通道黄金票据威力大但门槛也不低。最基本的前置条件是拿到KRBTGT账户的哈希。这个哈希不会在网络正常认证的交互环节中出现因为它只被 KDC 用来加密和解密 TGT普通主机根本不会感知到它。攻击者要拿它常见路径无非这几种。第一种也是最经典的一种直接拿域控主机权限。攻击者先通过漏洞打穿域控或者通过内网渗透拿到域控本地 SYSTEM 权限然后用 Mimikatz 的lsadump::dcsync /domain:xxx /user:krbtgt命令模拟域控来请求 KRBTGT 密码哈希并提取出来。这本质上是 DCSync 攻击不需要获取域控本地文件直接在网络上发起复制请求即可。第二种是拿到域控的 NTDS.dit 文件也就是域数据库文件离线解析出所有账户哈希。该文件默认就在C:\Windows\NTDS\目录下一旦域控所在的物理机或虚拟磁盘被攻陷就能被拖走慢慢跑。第三种是备份文件泄露比如某些企业把域控备份到备份服务器或云存储谁都没想到备份里包含 NTDS.dit一旦备份系统被攻破KRBTGT 哈希也就裸露了。还有一种是域管滥用域管理员本身就是整个域的“上帝”他如果直接使用特权账户在普通工作站登录操作凭证被窃取后攻击者可凭域管令牌在域内穿梭并最终触达 KDC 相关入口。这里想强调一点KRBTGT 哈希一旦泄露和普通用户密码泄露完全不是一个量级。普通用户密码泄露了管理员可以禁掉该用户、让用户改密码KRBTGT 密码即便被重置也会影响所有已发放 TGT 的可用性导致全域用户重新认证。所以企业往往不敢轻易重置它这就给了攻击者很长的利用窗口。2.2 攻击成功后的影响范围与时间维度黄金票据攻击的影响范围可以拆成两个维度来看横向维度是“所有域内服务和主机”纵向维度是“所有特权身份”。横向来说攻击者拿到伪造 TGT 后能访问的目标取决于域内已存在的服务主体和信任关系。同一个域内几乎所有使用 Kerberos 认证的文件服务器、数据库、应用系统都会受影响只要它们注册了 SPNService Principal Name服务主体名称攻击者便可以用伪造 TGT 申请对应的 ST。对于域控本身攻击者还可以进一步申请 DC 的 ST从而传递到C$之类管理共享彻底拿捏整个域。纵向来说攻击者可以伪造任意用户名。典型操作是把用户名指定为Administrator把 RID 指定为 500这样在任何一台域内主机的管理员组判断逻辑里当前身份就是真正的域管理员。很多应用不检查 RID只检查用户名是否等于 Administrator这种时伪造身份更是直接穿透。攻击者还可以伪造成krbtgt账号本身这种身份在日志里极其罕见反而更隐蔽。从时间维度讲一张 TGT 的生命周期由域策略控制默认是 10 小时但如果攻击者在制作黄金票据时自定义了生命周期那么域控不会主动拒绝它。它跟会话中的续订也有关系只要攻击者在这期间持续使用就可以不断续期。更狠的是攻击者如果拿到的 KRBTGT 哈希一直没有变化即便那张 TGT 过期了他也能再制作一张新的。换句话说票据会过期但攻击能力不会过期。这也是许多应急响应团队最头疼的地方你找到了一台失陷主机清掉了木马改了所有用户密码但只要没意识到 KRBTGT 已泄露攻击者很快又能回来。2.3 期间值得关注的时间戳细节热词里有个“时间戳攻击”放到黄金票据上其实也在讲同一个问题。Kerberos 协议依赖时间戳来防止重放攻击。正常情况下客户端请求认证时会在加密数据里带一个时间戳KDC 会校验客户端时钟与域控时钟偏差是否在 5 分钟宽限窗口内。黄金票据虽然是手工伪造的 TGT但 TGT 里面的起始时间、到期时间都是可以手工设置的攻击者会努力让伪造 TGT 的签发时间落在当前时间范围内否则就会出现“票据暂时不可用”的情况。从蓝队检测角度看时间戳是一个很微弱的异常信号但也不是完全没价值。如果域控日志中同时出现大量来自同一主机、针对不同服务的 TGS-REQ 请求且这些请求使用的 TGT 创建时间点和实际认证时间距离过大那就值得排查。只是现实中多数组织不会单独记录这些字段所以这个信号更多是辅助判断。3. 实操演练与关键步骤还原3.1 制作一张黄金票据需要准备哪些材料为了把概念落到地上我们应该完整走一遍制作流程。这里只做研究和防御演练用途请务必在没有授权的外部目标或隔离实验环境中执行。整个过程需要准备四样核心材料KRBTGT 账户哈希、域 SID、目标用户 RID、目标域名。KRBTGT 哈希可以通过你所在环境的域控权限提取。用 Mimikatz 的标准 DCSync 命令即可lsadump::dcsync /domain:目标域 /user:krbtgt。输出结果里会有一长串Hash NTLM字段那就是所需的 NTLM 哈希。域 SID 可以在whoami /user里看到结果类似S-1-5-21-123456789-1234567890-123456789。目标用户 RID 一般是 500域管理员也可以选择 502krbtgt这类特殊 RID。制作命令在 Mimikatz 里是kerberos::golden完整示例kerberos::golden /user:admin /domain:corp.local /sid:S-1-5-21-123456789-1234567890-123456789 /krbtgt:abcdefghijklmnopqrstuvwxyz123456 /ptt命令解析如下/user指定要伪装的用户名/domain指定目标域名/sid是指域的 SID/krbtgt后面跟上面提取到的 NTLM 哈希/ptt表示制作完成后直接注入当前会话内存。如果不加/ptt默认生成一个.kirbi文件后续可以用kerberos::ptt 文件路径再注入。注入成功后你可以在当前会话执行klist查看票据列表里面会出现一张用户名和域管理员高度相似的 TGT。这里要专门提一个容易踩的坑域 SID 必须写域名所在的 SID而不是用户 SID。很多人直接在whoami /user里看到一整串 SID 就抄进去结果里面包含了最后两位数 -500这是用户 RID不是域 SID。错误写法会对后续票据的 SID 组成产生致命影响导致票据虽然在本地能看到但访问域内服务时被 KDC 拒绝。3.2 从蓝队视角看“时间戳攻击”细节在制作黄金票据时还可以附加/startoffset、/endoffset、/renewmax、/sids等参数。/endoffset:180表示票据有效期为 180 小时/startoffset:-10表示让票据起始时间回溯 10 小时这样做是为了规避某些时间轴分析。域控只验证客户端时间是否在上下 5 分钟偏差内它是比较“当前时间和票据携带时间”而不是“票据携带时间是否和 AS 签发记录一致”因为 TGT 是自包含的没有对应 AS 签发记录可查这就给了攻击者操控时间字段的空间。蓝队如果怀疑遭遇了黄金票据可以直接用klist查看当前系统的 TGT 详情关注Server Full Name是不是写成krbtgt/目标域名Start Time和End Time是否异常比如一张新建会话里的票据起始时间比当前时间早了几小时这通常是手工构造的痕迹。不过这个检查方法只在本地有嫌疑时管用真正的检测还是得上日志和集中分析。3.3 攻击行为在实际环境中的“表象”黄金票据攻击在目标主机上不一定会有明显的进程异常或网络连接异常因为攻击者注入票据后后续访问方式都走正常 Windows API比如直接访问\\dc01\C$、winrm、psexec等。如果攻击者只注入票据然后通过dir \\dc01\c$查看文件那几乎所有蓝队设备都看不到恶意流量日志上也只看到正常的访问事件。这也是为什么很多组织明明已经被拿下了主域却迟迟无法定位到根因。更隐蔽的玩法是结合非 Windows 主机使用。攻击者先在 Windows 上制作黄金票据然后导出成.kirbi再放到 Linux 攻击端通过 impacket 套件里的ticketConverter.py把.kirbi转换成.ccache格式接着就能在 Linux 上用组合命令访问相关服务。这种跨平台操作让检测难度进一步上升因为很多 Windows 侧的 EDR 看不到 Linux 上发生的动作。4. 检测与防御实战经验4.1 日志侧重点抓住黄金票据的“狐狸尾巴”既然黄金票据攻击最终要使用票据去访问服务那网络和日志侧就不可能完全隐形只是需要知道看哪里。Windows 安全日志中与 Kerberos 认证相关的事件 ID 最主要是 4768请求 Kerberos 服务票据、4769请求授权票据和 4624登录成功。正常情况下每个用户登录时AS 会先签发一张 TGT随后才有各种 TGS-REQ 请求。黄金票据攻击的特点是攻击者手里已经有一张 TGT所以直接就有权限发起 TGS-REQ而域控的日志中只会有 4769却没有前置的 4768。当然了很多环境里默认只开部分日志策略4768 和 4769 不一定都记录了。有条件的可以启用 Kerberos 服务票据操作的详细审计把成功审计也开起来再通过日志分析平台做后续聚合。我见过比较有效的检测思路是在域控上开启 4769 审计后额外记录服务名称和客户端 IP然后建立一个基线模型。黄金票据访问CIFS/dc01这类服务时如果之前某个用户名从未在该 IP 上出现过或者同一个用户名在短时间内访问大量不同服务就需要重点排查。一个特定信号是当攻击者伪装成域管理员RID 500时域控日志 4768 或 4769 中会出现权限ID为 500 的账户记录而实际登录来源主机却不该出现在对应的资源访问场景中。比如明明是运维人员张三的电脑突然出现一个来自它 IP 的域管 TGT 访问请求这基本就是有问题了。另一个信号是黄金票据制作时如果没有绑定到具体主机票据请求会带有不特定的主机信息通常与当前认证主机本体历史记录关联不上。4.2 防御加固与配置清单最重要的防护思路必须摆在前面KRBTGT 哈希的泄露窗口决定了黄金票据的利用价值所以防止 KRBTGT 被提取是第一道防线。具体可从三个层面入手。第一限制域控主机的本地管理员权限坚持“域控上不允许运行无关软件、不允许普通管理员交互式登录”的原则。域控主机一旦被横向攻击者拿下本地 SYSTEMDCSync 就等于自助取款。可部署额外的特权访问工作站PAW来隔离高风险操作。第二启用 Microsoft LAPS 管理本地管理员密码并对域管账户开启“受保护的用户组”或 Credential Guard降低凭证抓取概率。第三对备份系统和虚拟化平台加强保护避免 NTDS.dit 因为备份泄露而被离线解析。如果怀疑 KRBTGT 已经泄露并且无法确认泄露范围最终手段是重置 KRBTGT 密码。这是一个影响全域的操作需要走专门脚本分两步重置krbtgt密码每次间隔至少 12 到 24 小时目的是让每个域控的 KDC 同步到新密钥之后再清理域内所有旧 TGT 票据。普通情况下别随便操作否则可能造成大批用户认证失败、复制问题不断。配置清单方面建议在域策略里将 Kerberos 票据最长生命周期设为较短时间比如 10 小时甚至 4 小时这样即便伪造票据也会很快过期。同时开启强制使用 Kerberos 的 AES 加密类型、禁用 RC4减少旧协议带来的哈希暴露面。还要把域上所有主机、特别是服务器资产的系统时间同步到统一的 NTP 源时间偏差太大时Kerberos 会拒绝请求影响正常业务但攻击者也会因此暴露痕迹。4.3 常见问题速查表这里整理几个我在排查和培训时被问得最多的问题并用表格直接呈现对比答案方便后期查阅。问题快速结论黄金票据与白银票据的核心区别是什么黄金票据使用 KRBTGT 哈希伪造 TGT影响整个域内所有服务白银票据使用服务账户哈希伪造 ST只影响该服务黄金票据能绕过账户锁定策略吗能。黄金票据走的是 Kerberos 票据验证不会触发传统密码错误次数也不会锁定账户修改域管密码能阻止黄金票据吗不能。域管理员密码与 KRBTGT 哈希无关只有重置 KRBTGT 密码才有效黄金票据为什么在日志中难检测它不触发 AS-REQ 错误也不使用明文密码只走正常的 TGS-REQ 流程且可从非 Windows 端发起黄金票据攻击适合哪些企业重点关注所有使用 AD 域的中大型企业、政府单位、金融机构尤其是已经发生过域管失陷或备份泄露的事件响应场景有没有办法提前验证环境遭受黄金票据影响可在域控上开启 Kerberos 详细审计拉取 4769/4768 日志做异常分析定期检查特权账户的异常 TGT 申请行为4.4 从应急响应往回看攻击面收敛参与过几次涉及域控的应急响应后我最大的体会是黄金票据攻击从来不是“单一漏洞”导致的结果它是一条完整攻击链的最后一步。前面可能经历了钓鱼打点、内网穿透、提权、DCSync攻击者才能把这些关键材料凑齐。所以如果企业只盯着“黄金票据怎么防”其实是把问题想窄了。真正有效的方式是提前收敛攻击面对域管资产进行严格的访问控制把域管会话限制在跳板机或特权工作站里并通过时间限制、来源 IP 限制做双重校验。对域管账户和敏感账户启用蜜罐账号捕获非法触碰行为。定期做攻击面审计用 BloodHound 之类工具看域内是否存在过多的域管组嵌套、危险的 ACL 权限、不必要的委派关系。对 DCSync 行为建立专门监测因为黄金票据的前置动作往往就是一次 DCSync日志中会出现“目录服务复制”相关的特殊访问事件。我自己在实操中习惯用一份“可疑 TGT 检查流程”来指导新人第一看域控中 4769 缺失前置 4768 的账号第二看特权账号是否出现在非预期来源主机第三看klist中 TGT 时长与系统策略是否匹配第四看目标主机上是否存在.kirbi或.ccache文件残留。这四个点不一定能百分之百命中但至少能在攻击者继续横向移动时给我们争取到定位窗口。还有一个值得分享的细节是很多运营人员因为嫌日志量太大只保留了失败审计没有开成功审计。这导致黄金票据这类绕过登录行为的攻击在事后追查时几乎没有完整链路可看。如果你所在企业还没有把域控的成功审计日志集中收集起来我强烈建议尽快启用。磁盘成本再高也比被“金票”打进家里之后才发现强。
如果你管过一套 Windows 域环境或者参与过红蓝对抗那你一定听过“黄金票据攻击”这个名头。它是 Kerberos 认证体系里最经典、破坏力也最大的一种横向攻击方式。简单说攻击者只要拿到了域控里 KRBTGT 账户的哈希就相当于掌握了整个域的“信任根”能给自己签一张“万能通行证”想冒充谁就冒充谁想访问哪个服务就访问哪个服务而且这张票证除非自然过期否则几乎没有办法被单独撤销。这篇内容我想从攻击原理、影响范围、实操还原和防守视角四个方面把这套东西讲透。不管你是刚接触 AD 安全的新人还是已经在做应急响应和检测规则的老手应该都能从中拿到一些可以直接落地的思路。先说清楚一个前提我这里讲攻击流程最终目的是为了防御。黄金票据的底层逻辑如果理解不透蓝队根本没法写检测规则也没法判断自己是否已经中招。所以我会尽量用“从业者之间说话”的方式把原理、操作和排查经验串在一起。1. 黄金票据攻击原理拆解先从 Kerberos 认证说起1.1 Kerberos 的三要素票据、KDC 与 KRBTGT 账户要理解黄金票据为什么“金”得先把 Kerberos 认证流程拆开。Kerberos 是 Windows 域环境默认的认证协议核心目标就一句话让客户端向服务端证明“我是我”且不需要在网络上传输明文密码。这里的三个关键角色分别是客户端、服务端和 KDCKey Distribution Center密钥分发中心。KDC 部署在域控上可拆成两个逻辑组件ASAuthentication Service认证服务和 TGSTicket Granting Service票据授予服务。用户登录时客户端会向 KDC 的 AS 服务发起 AS-REQ 请求里面带着自己的用户名和加时间戳的认证信息。AS 验证身份后返回两个东西一个是用户要访问目标服务时用的票据授权票据 TGTTicket Granting Ticket另一个是用于解开 TGT 的会话密钥。TGT 本身不是拿用户的密码哈希加密的而是用 KRBTGT 账户的哈希加密。KRBTGT 是域里一个内置的、基本上永远不登录、不交互的特殊账户它的密码哈希就是整个域“签发信任凭证”的根密钥。当用户后续想访问某个服务比如文件服务器、Web 应用客户端会带着 TGT 去找 TGS 服务申请服务票据 STService TicketTGS 先验证 TGT 是不是由合法 KRBTGT 签发验证通过后才会发放针对具体服务的 ST。这个过程可以类比成一个大型公司的门禁系统。员工进门需要刷工牌生成一张临时通行卡TGT这张临时通行卡要想到不同楼层办事还需要到总服务台盖章换取对应楼层的门禁卡ST。总服务台认的不是员工本人而是“公司统一使用的钢印”KRBTGT 哈希。只要钢印是真的总服务台就会认为临时通行卡可信。黄金票据攻击的思路就是攻击者偷到了这颗钢印本身然后自己拿张白纸印了一张总裁级别的临时通行卡放到门禁系统里。1.2 “黄金”体现在哪里伪造信任根而非绕过验证很多人一开始会搞混这个概念以为黄金票据是绕过 Kerberos 验证。其实恰恰相反它是顺着 Kerberos 验证规则把它最顶层的那把“根钥匙”拿到手然后合法合规地伪造身份。攻击者不需要知道域管理员密码不需要碰目标用户的密码甚至不需要和域控产生明显的认证交互。一张合法 TGT 的内容包括用户名、用户域 SID、用户 RID、票据有效期、签发时间、holding 信息等。这些内容最终由 KRBTGT 哈希签名并加密。攻击者一旦拿到了 KRBTGT 哈希和域的 SID就可以通过 Mimikatz 这类工具手工构造一个指定用户名例如 Administrator、指定 RID例如 500即域管理员默认 RID、自定义有效期的 TGT。然后通过ptt命令把这张伪造票据注入当前系统会话或者用tgt::ask等方式把它导入到内存里。后续访问域内任意主机、任意服务时系统会拿着这张伪造 TGT 去申请 ST域控的 TGS 只认 KRBTGT 哈希是否能正确解密根本不检查这张 TGT 是否真的由 AS 签发。这也是黄金票据和白银票据最大的区别。白银票据是针对某个具体服务的伪造 ST它需要拿到目标服务账户的哈希只能访问那一个服务。黄金票据则是伪造顶层信任拿到后可以访问域内几乎所有服务而且如果后续再申请某个服务的 ST都是合法流程。用一句话总结就是白银票据是伪造了一把房间钥匙黄金票据是伪造了整栋大楼的备胎门禁卡可以刷开绝大多数房间。更麻烦的是黄金票据的有效期可以自定义攻击者甚至可以给它设置成 10 年只要域内不主动重置 KRBTGT 密码这张票就在那能持续流通。2. 攻击前置条件与影响范围分析2.1 拿到 KRBTGT 哈希的常见通道黄金票据威力大但门槛也不低。最基本的前置条件是拿到KRBTGT账户的哈希。这个哈希不会在网络正常认证的交互环节中出现因为它只被 KDC 用来加密和解密 TGT普通主机根本不会感知到它。攻击者要拿它常见路径无非这几种。第一种也是最经典的一种直接拿域控主机权限。攻击者先通过漏洞打穿域控或者通过内网渗透拿到域控本地 SYSTEM 权限然后用 Mimikatz 的lsadump::dcsync /domain:xxx /user:krbtgt命令模拟域控来请求 KRBTGT 密码哈希并提取出来。这本质上是 DCSync 攻击不需要获取域控本地文件直接在网络上发起复制请求即可。第二种是拿到域控的 NTDS.dit 文件也就是域数据库文件离线解析出所有账户哈希。该文件默认就在C:\Windows\NTDS\目录下一旦域控所在的物理机或虚拟磁盘被攻陷就能被拖走慢慢跑。第三种是备份文件泄露比如某些企业把域控备份到备份服务器或云存储谁都没想到备份里包含 NTDS.dit一旦备份系统被攻破KRBTGT 哈希也就裸露了。还有一种是域管滥用域管理员本身就是整个域的“上帝”他如果直接使用特权账户在普通工作站登录操作凭证被窃取后攻击者可凭域管令牌在域内穿梭并最终触达 KDC 相关入口。这里想强调一点KRBTGT 哈希一旦泄露和普通用户密码泄露完全不是一个量级。普通用户密码泄露了管理员可以禁掉该用户、让用户改密码KRBTGT 密码即便被重置也会影响所有已发放 TGT 的可用性导致全域用户重新认证。所以企业往往不敢轻易重置它这就给了攻击者很长的利用窗口。2.2 攻击成功后的影响范围与时间维度黄金票据攻击的影响范围可以拆成两个维度来看横向维度是“所有域内服务和主机”纵向维度是“所有特权身份”。横向来说攻击者拿到伪造 TGT 后能访问的目标取决于域内已存在的服务主体和信任关系。同一个域内几乎所有使用 Kerberos 认证的文件服务器、数据库、应用系统都会受影响只要它们注册了 SPNService Principal Name服务主体名称攻击者便可以用伪造 TGT 申请对应的 ST。对于域控本身攻击者还可以进一步申请 DC 的 ST从而传递到C$之类管理共享彻底拿捏整个域。纵向来说攻击者可以伪造任意用户名。典型操作是把用户名指定为Administrator把 RID 指定为 500这样在任何一台域内主机的管理员组判断逻辑里当前身份就是真正的域管理员。很多应用不检查 RID只检查用户名是否等于 Administrator这种时伪造身份更是直接穿透。攻击者还可以伪造成krbtgt账号本身这种身份在日志里极其罕见反而更隐蔽。从时间维度讲一张 TGT 的生命周期由域策略控制默认是 10 小时但如果攻击者在制作黄金票据时自定义了生命周期那么域控不会主动拒绝它。它跟会话中的续订也有关系只要攻击者在这期间持续使用就可以不断续期。更狠的是攻击者如果拿到的 KRBTGT 哈希一直没有变化即便那张 TGT 过期了他也能再制作一张新的。换句话说票据会过期但攻击能力不会过期。这也是许多应急响应团队最头疼的地方你找到了一台失陷主机清掉了木马改了所有用户密码但只要没意识到 KRBTGT 已泄露攻击者很快又能回来。2.3 期间值得关注的时间戳细节热词里有个“时间戳攻击”放到黄金票据上其实也在讲同一个问题。Kerberos 协议依赖时间戳来防止重放攻击。正常情况下客户端请求认证时会在加密数据里带一个时间戳KDC 会校验客户端时钟与域控时钟偏差是否在 5 分钟宽限窗口内。黄金票据虽然是手工伪造的 TGT但 TGT 里面的起始时间、到期时间都是可以手工设置的攻击者会努力让伪造 TGT 的签发时间落在当前时间范围内否则就会出现“票据暂时不可用”的情况。从蓝队检测角度看时间戳是一个很微弱的异常信号但也不是完全没价值。如果域控日志中同时出现大量来自同一主机、针对不同服务的 TGS-REQ 请求且这些请求使用的 TGT 创建时间点和实际认证时间距离过大那就值得排查。只是现实中多数组织不会单独记录这些字段所以这个信号更多是辅助判断。3. 实操演练与关键步骤还原3.1 制作一张黄金票据需要准备哪些材料为了把概念落到地上我们应该完整走一遍制作流程。这里只做研究和防御演练用途请务必在没有授权的外部目标或隔离实验环境中执行。整个过程需要准备四样核心材料KRBTGT 账户哈希、域 SID、目标用户 RID、目标域名。KRBTGT 哈希可以通过你所在环境的域控权限提取。用 Mimikatz 的标准 DCSync 命令即可lsadump::dcsync /domain:目标域 /user:krbtgt。输出结果里会有一长串Hash NTLM字段那就是所需的 NTLM 哈希。域 SID 可以在whoami /user里看到结果类似S-1-5-21-123456789-1234567890-123456789。目标用户 RID 一般是 500域管理员也可以选择 502krbtgt这类特殊 RID。制作命令在 Mimikatz 里是kerberos::golden完整示例kerberos::golden /user:admin /domain:corp.local /sid:S-1-5-21-123456789-1234567890-123456789 /krbtgt:abcdefghijklmnopqrstuvwxyz123456 /ptt命令解析如下/user指定要伪装的用户名/domain指定目标域名/sid是指域的 SID/krbtgt后面跟上面提取到的 NTLM 哈希/ptt表示制作完成后直接注入当前会话内存。如果不加/ptt默认生成一个.kirbi文件后续可以用kerberos::ptt 文件路径再注入。注入成功后你可以在当前会话执行klist查看票据列表里面会出现一张用户名和域管理员高度相似的 TGT。这里要专门提一个容易踩的坑域 SID 必须写域名所在的 SID而不是用户 SID。很多人直接在whoami /user里看到一整串 SID 就抄进去结果里面包含了最后两位数 -500这是用户 RID不是域 SID。错误写法会对后续票据的 SID 组成产生致命影响导致票据虽然在本地能看到但访问域内服务时被 KDC 拒绝。3.2 从蓝队视角看“时间戳攻击”细节在制作黄金票据时还可以附加/startoffset、/endoffset、/renewmax、/sids等参数。/endoffset:180表示票据有效期为 180 小时/startoffset:-10表示让票据起始时间回溯 10 小时这样做是为了规避某些时间轴分析。域控只验证客户端时间是否在上下 5 分钟偏差内它是比较“当前时间和票据携带时间”而不是“票据携带时间是否和 AS 签发记录一致”因为 TGT 是自包含的没有对应 AS 签发记录可查这就给了攻击者操控时间字段的空间。蓝队如果怀疑遭遇了黄金票据可以直接用klist查看当前系统的 TGT 详情关注Server Full Name是不是写成krbtgt/目标域名Start Time和End Time是否异常比如一张新建会话里的票据起始时间比当前时间早了几小时这通常是手工构造的痕迹。不过这个检查方法只在本地有嫌疑时管用真正的检测还是得上日志和集中分析。3.3 攻击行为在实际环境中的“表象”黄金票据攻击在目标主机上不一定会有明显的进程异常或网络连接异常因为攻击者注入票据后后续访问方式都走正常 Windows API比如直接访问\\dc01\C$、winrm、psexec等。如果攻击者只注入票据然后通过dir \\dc01\c$查看文件那几乎所有蓝队设备都看不到恶意流量日志上也只看到正常的访问事件。这也是为什么很多组织明明已经被拿下了主域却迟迟无法定位到根因。更隐蔽的玩法是结合非 Windows 主机使用。攻击者先在 Windows 上制作黄金票据然后导出成.kirbi再放到 Linux 攻击端通过 impacket 套件里的ticketConverter.py把.kirbi转换成.ccache格式接着就能在 Linux 上用组合命令访问相关服务。这种跨平台操作让检测难度进一步上升因为很多 Windows 侧的 EDR 看不到 Linux 上发生的动作。4. 检测与防御实战经验4.1 日志侧重点抓住黄金票据的“狐狸尾巴”既然黄金票据攻击最终要使用票据去访问服务那网络和日志侧就不可能完全隐形只是需要知道看哪里。Windows 安全日志中与 Kerberos 认证相关的事件 ID 最主要是 4768请求 Kerberos 服务票据、4769请求授权票据和 4624登录成功。正常情况下每个用户登录时AS 会先签发一张 TGT随后才有各种 TGS-REQ 请求。黄金票据攻击的特点是攻击者手里已经有一张 TGT所以直接就有权限发起 TGS-REQ而域控的日志中只会有 4769却没有前置的 4768。当然了很多环境里默认只开部分日志策略4768 和 4769 不一定都记录了。有条件的可以启用 Kerberos 服务票据操作的详细审计把成功审计也开起来再通过日志分析平台做后续聚合。我见过比较有效的检测思路是在域控上开启 4769 审计后额外记录服务名称和客户端 IP然后建立一个基线模型。黄金票据访问CIFS/dc01这类服务时如果之前某个用户名从未在该 IP 上出现过或者同一个用户名在短时间内访问大量不同服务就需要重点排查。一个特定信号是当攻击者伪装成域管理员RID 500时域控日志 4768 或 4769 中会出现权限ID为 500 的账户记录而实际登录来源主机却不该出现在对应的资源访问场景中。比如明明是运维人员张三的电脑突然出现一个来自它 IP 的域管 TGT 访问请求这基本就是有问题了。另一个信号是黄金票据制作时如果没有绑定到具体主机票据请求会带有不特定的主机信息通常与当前认证主机本体历史记录关联不上。4.2 防御加固与配置清单最重要的防护思路必须摆在前面KRBTGT 哈希的泄露窗口决定了黄金票据的利用价值所以防止 KRBTGT 被提取是第一道防线。具体可从三个层面入手。第一限制域控主机的本地管理员权限坚持“域控上不允许运行无关软件、不允许普通管理员交互式登录”的原则。域控主机一旦被横向攻击者拿下本地 SYSTEMDCSync 就等于自助取款。可部署额外的特权访问工作站PAW来隔离高风险操作。第二启用 Microsoft LAPS 管理本地管理员密码并对域管账户开启“受保护的用户组”或 Credential Guard降低凭证抓取概率。第三对备份系统和虚拟化平台加强保护避免 NTDS.dit 因为备份泄露而被离线解析。如果怀疑 KRBTGT 已经泄露并且无法确认泄露范围最终手段是重置 KRBTGT 密码。这是一个影响全域的操作需要走专门脚本分两步重置krbtgt密码每次间隔至少 12 到 24 小时目的是让每个域控的 KDC 同步到新密钥之后再清理域内所有旧 TGT 票据。普通情况下别随便操作否则可能造成大批用户认证失败、复制问题不断。配置清单方面建议在域策略里将 Kerberos 票据最长生命周期设为较短时间比如 10 小时甚至 4 小时这样即便伪造票据也会很快过期。同时开启强制使用 Kerberos 的 AES 加密类型、禁用 RC4减少旧协议带来的哈希暴露面。还要把域上所有主机、特别是服务器资产的系统时间同步到统一的 NTP 源时间偏差太大时Kerberos 会拒绝请求影响正常业务但攻击者也会因此暴露痕迹。4.3 常见问题速查表这里整理几个我在排查和培训时被问得最多的问题并用表格直接呈现对比答案方便后期查阅。问题快速结论黄金票据与白银票据的核心区别是什么黄金票据使用 KRBTGT 哈希伪造 TGT影响整个域内所有服务白银票据使用服务账户哈希伪造 ST只影响该服务黄金票据能绕过账户锁定策略吗能。黄金票据走的是 Kerberos 票据验证不会触发传统密码错误次数也不会锁定账户修改域管密码能阻止黄金票据吗不能。域管理员密码与 KRBTGT 哈希无关只有重置 KRBTGT 密码才有效黄金票据为什么在日志中难检测它不触发 AS-REQ 错误也不使用明文密码只走正常的 TGS-REQ 流程且可从非 Windows 端发起黄金票据攻击适合哪些企业重点关注所有使用 AD 域的中大型企业、政府单位、金融机构尤其是已经发生过域管失陷或备份泄露的事件响应场景有没有办法提前验证环境遭受黄金票据影响可在域控上开启 Kerberos 详细审计拉取 4769/4768 日志做异常分析定期检查特权账户的异常 TGT 申请行为4.4 从应急响应往回看攻击面收敛参与过几次涉及域控的应急响应后我最大的体会是黄金票据攻击从来不是“单一漏洞”导致的结果它是一条完整攻击链的最后一步。前面可能经历了钓鱼打点、内网穿透、提权、DCSync攻击者才能把这些关键材料凑齐。所以如果企业只盯着“黄金票据怎么防”其实是把问题想窄了。真正有效的方式是提前收敛攻击面对域管资产进行严格的访问控制把域管会话限制在跳板机或特权工作站里并通过时间限制、来源 IP 限制做双重校验。对域管账户和敏感账户启用蜜罐账号捕获非法触碰行为。定期做攻击面审计用 BloodHound 之类工具看域内是否存在过多的域管组嵌套、危险的 ACL 权限、不必要的委派关系。对 DCSync 行为建立专门监测因为黄金票据的前置动作往往就是一次 DCSync日志中会出现“目录服务复制”相关的特殊访问事件。我自己在实操中习惯用一份“可疑 TGT 检查流程”来指导新人第一看域控中 4769 缺失前置 4768 的账号第二看特权账号是否出现在非预期来源主机第三看klist中 TGT 时长与系统策略是否匹配第四看目标主机上是否存在.kirbi或.ccache文件残留。这四个点不一定能百分之百命中但至少能在攻击者继续横向移动时给我们争取到定位窗口。还有一个值得分享的细节是很多运营人员因为嫌日志量太大只保留了失败审计没有开成功审计。这导致黄金票据这类绕过登录行为的攻击在事后追查时几乎没有完整链路可看。如果你所在企业还没有把域控的成功审计日志集中收集起来我强烈建议尽快启用。磁盘成本再高也比被“金票”打进家里之后才发现强。
