一、问题背景

公司核心业务域（域控为 Windows Server 2019）近期做了一次例行补丁更新与域控密码重置。更新后几天，安全团队在 SOC 平台收到多起「本地管理员组被异常添加账户」的告警。进一步排查发现，办公网中多台 Windows 10 / Server 2016 机器均出现同一陌生域账户（svc_backup）被加入本地 Administrators 组，且该账户来自域内而非本地 SAM。攻击者已获得对多台服务器的持久化本地提权能力，但常规的「钓鱼邮件、弱口令 RDP、横向移动工具」痕迹全部缺失。

二、故障现象

现场呈现经典的「域内横向提权后遗症」：

• 多台服务器本地 Administrators 组被统一加入 svc_backup 域账户，登录日志显示该账户成功 RDP/WinRM 访问但无密码喷射记录。
• 域控事件日志（Security.evtx）里「Kerberos 预认证失败」「NTLM 认证成功」类 4624/4768/4769 事件数量异常稀少，且时间分布集中在凌晨 03:17~03:29。
• 域控 C:\Windows\System32\config 下的 SYSTEM / SECURITY hive 文件存在 3 分钟的「被打开后立即关闭」操作痕迹，但无对应进程名写入日志。
• 域内任意一台已沦陷机器执行 whoami /priv 均显示 SeDebugPrivilege 已启用，klist 命令可列出一个 krbtgt 的 TGT 票据，EndTime 为 10 年后。
• 攻击者并未修改域控 krbtgt 账户密码（常规黄金票据检测中会重点关注），只是把票据缓存到了多台跳板机的内存中，形成「一次伪造、永久横向」的效果。

三、排查过程

第一步：确认攻击入口不是弱口令/钓鱼。通过 Exchange 日志、终端 EDR 邮件附件扫描、防火墙出网记录，均未发现可疑邮件或 C2 外联。排除常规社会工程学入口，问题必然出在域协议层面。

第二步：检查黄金票据特征。黄金票据（Golden Ticket）是攻击者用域控 krbtgt 哈希伪造任意用户的 TGT（Ticket Granting Ticket），从而获得域内任意资源的访问权。特征有三：

1. TGT 的 EndTime 通常被攻击者设置为极远未来（默认 10 年）。
2. TGT 的 RenewTill 字段也会被拉长。
3. 票据的 Domain SID 与真实域 SID 一致，但 krbtgt 版本号（Ticket 里的 EncTicketPart）与域控当前 krbtgt 密码版本号不匹配。

在多台受感染机器上执行 klist 确实看到：

1
2
3
4
5
6
7

#0>     Client: svc_backup @ CORP.LOCAL
        Server: krbtgt/CORP.LOCAL @ CORP.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Start Time: 7/20/2026 3:17:12 (local)
        End Time:   7/20/2036 3:17:12 (local)   <--- 10 年
        Renew Till: 7/20/2036 3:17:12 (local)
        Flags: forwardable, renewable, initial, pre_authent, name_canonicalize

这几乎是黄金票据的「招牌」。

第三步：内存取证定位 krbtgt 哈希泄露点。黄金票据的前提是攻击者已拿到 krbtgt 账户的 NTLM/AES 哈希。最常见途径是域控内存转储（Mimikatz lsadump::lsa /patch 或 sekurlsa::tickets）。通过 EDR 历史进程快照，发现 7 月 18 日凌晨 02:11 域控曾被一个 powershell.exe -nop -w hidden 进程执行过 Invoke-Mimikatz，且该进程父进程为 services.exe（计划任务触发）。攻击者通过计划任务在域控上执行内存取证，拿到 krbtgt 哈希后立即清除了任务与日志，仅在内存中留下了 TGT。

第四步：横向移动路径还原。攻击者拿到哈希后，在自己的跳板机上用 mimikatz 的 kerberos::golden 模块生成了 svc_backup 的 TGT，并把该 TGT 注入多台服务器的内存。随后用 PsExec / WinRM 横向，执行 net localgroup administrators /add CORP\svc_backup 完成持久化本地提权。整个过程不产生「密码错误」「Kerberos 预认证失败」类事件，因此常规「暴力破解检测」完全失效。

四、解决方案

立即止血（切断攻击者现有 TGT）：

1. 在所有受感染机器上执行 klist purge，清除内存中可疑 TGT。
2. 强制让 svc_backup 账户密码过期，并从本地 Administrators 组移除：

   1	net localgroup administrators CORP\svc_backup /delete

3. 在域控上将 krbtgt 账户密码连续重置两次（第一次重置后等待 krbtgt 密码复制完成，再重置第二次）。这是微软官方推荐的「杀死所有基于旧 krbtgt 哈希的黄金票据」的标准操作：

   1 2 3 4 5

   # 第一次重置 Reset-KrbtgtPassword -Force Start-Sleep -Seconds 600 # 等待复制 # 第二次重置 Reset-KrbtgtPassword -Force

   重置后，所有基于旧哈希生成的 TGT 立即失效。

根除攻击面：

• 域控上部署 LSA 保护（RunAsPPL=1），禁止 Mimikatz 等工具从 LSASS 读取凭据。
• 启用 Windows Defender Credential Guard，防止内存中 Kerberos 票据被窃取。
• 限制域控登录权限：仅允许特定跳板机 RDP/WinRM 到域控，普通管理员工作站禁止直接访问域控 3389/5985 端口。
• 部署 EDR 规则：检测 powershell.exe 调用 mimikatz / sekurlsa 字符串、检测 klist 输出中 EndTime 超过 365 天的 TGT。

长期加固：

• 建立「域控密码定期轮换 + 双次重置」制度，每 180 天执行一次 krbtgt 密码双重置。
• 对 Protected Users 组内的特权账户启用 Authentication Policy & Silo，限制其只能从特定设备登录、只能使用特定认证协议。
• 在 SIEM 中增加黄金票据检测规则：klist 输出中 EndTime - StartTime > 365 days 且 Server = krbtgt/* 的告警。

五、根因分析

黄金票据的本质是「Kerberos 协议信任链的单点故障」：域内所有服务的信任锚点都是 krbtgt 账户的哈希。只要攻击者拿到该哈希，即可伪造任意用户的 TGT，获得域内上帝权限。传统「改密码就能挡住攻击者」的思路在这里完全失效——因为 TGT 可以在攻击者自己的机器上长期缓存，且不依赖域控上的账户状态。事件中攻击者仅在域控内存中「拿一次」，就实现了「横向到全域」的效果。

六、预防措施

• 内存保护：域控必须启用 LSA 保护 + Credential Guard，禁止普通管理员在域控上运行 Mimikatz 类工具。
• 登录收敛：域控仅允许极少数堡垒机登录，普通终端禁止直接 RDP/WinRM 到域控。
• 票据生命周期监控：SIEM 规则检测 TGT EndTime 异常远期、检测 klist 输出中 krbtgt 票据的 RenewTill 字段。
• krbtgt 定期双重置：每 180 天执行两次连续密码重置，杀死所有旧票据。
• 异常提权检测：对「本地 Administrators 组被域账户异常添加」事件进行实时告警，并关联「是否来自计划任务/PowerShell 隐藏窗口」上下文。

七、总结

黄金票据是 AD 域内最隐蔽也最致命的持久化手法之一——它不产生密码错误、不留下登录日志、不需要反复横向，只需要一次内存取证就能「一劳永逸」。防御的关键在于「不让攻击者拿到 krbtgt 哈希」（LSA 保护 + 登录收敛），以及「即使拿到哈希也能快速杀死所有旧票据」（krbtgt 双重置 + 票据生命周期监控）。把这三件事做到位，黄金票据就失去了生存土壤。