AD域应急-Golden Ticket攻击狩猎

在企业级 Windows 域环境中，Kerberos 是最核心的身份认证机制之一。而一旦 Kerberos 的根基被攻破，攻击者就可能获得对整个域的“无限通行证”——这正是 Golden Ticket（黄金票据）攻击 的本质。

什么是 Golden Ticket 攻击

Golden Ticket 攻击是一种针对 Kerberos 票据机制 的高级攻击手法。攻击者通过获取 Kerberos 中至关重要的 krbtgt 服务账户 的密钥（通常是 NTLM Hash），伪造一个合法的 TGT（Ticket Granting Ticket，票据授权票据）。

一旦攻击者成功伪造 TGT，就可以：

• 为任意用户（包括域管理员）申请服务票据
• 在不需要真实密码的情况下访问域内资源
• 长时间潜伏在环境中，甚至持续数年

之所以被称为“Golden Ticket”，正是因为它几乎赋予了攻击者对域内所有资源的完全访问权限。

攻击前提与影响范围

从应急响应的角度来看，这类攻击有一个非常重要的前提条件：

攻击者必须已经获得了域管理员级别的权限。

原因很简单——只有具备高权限，才能从域控内存（如 lsass.exe）中提取 krbtgt 的 NTLM Hash。一旦攻击成功，后果往往是灾难性的：

• 任意访问域内主机、文件和共享资源
• 直接登录或横向移动到域控制器
• 在日志层面伪装成“合法认证行为”，极难被察觉

Golden Ticket 的攻击过程

提取 krbtgt 的关键信息

lsadump::lsa /inject /name:krbtgt

攻击者通常会使用诸如 mimikatz 这样的工具，从域控内存中提取 krbtgt 账户的关键信息，包括：

• 域 SID
• krbtgt 的 RID（用户 ID）
• krbtgt 的 NTLM Hash

这些信息是后续伪造 Golden Ticket 的核心材料。

构造并注入伪造票据

在掌握上述信息后，攻击者可以直接构造 Golden Ticket，并将其注入当前会话内存。此时，即使原本只是一个普通域用户，也能瞬间“变身”为域管理员。

kerberos::golden /domain:polaris.local /sid:S-1-5-21-2216522546-3480378344-1528462524 /krbtgt:d77ec4ea89b9d7ef8b229eb6dd74c24d /user:Administrator /ptt

这里我们拿到了krbtgt 账户的关键信息，在另一台域内的机器上去执行。

在实战中，攻击者往往不会立即大规模行动，而是选择潜伏，等待合适的时机再进行横向移动或权限滥用。

利用伪造票据访问关键资源

klist
net use \\POLARIS\C$
dir \\Polaris\c$

完成票据注入后，攻击者可以：

• 访问域控制器的管理共享（如 C$）
• 执行远程命令
• 获取系统级 Shell

从应急响应角度看，这一步往往意味着 域已被完全失陷。

Golden Ticket 攻击排查点

Golden Ticket 攻击最危险的地方在于：

它使用的是“合法”的 Kerberos 认证流程。

在日志中，很多行为看起来与正常管理员操作几乎没有区别，这也是应急时面临的最大挑战。在实际分析中，检测 Golden Ticket 往往依赖 多事件关联，而不是单一指标。

Event ID 4769（请求服务票据）

• 请求 krbtgt 服务票据的客户端来源
• 请求来源并非域控制器，而是一台普通工作站

虽然管理员登录工作站也可能触发类似行为，但在真实AD环境中，这种情况并不常见，值得重点关注。

Event ID 4624（成功登录）

这是 Windows 中最常见的登录事件，但在 Golden Ticket 场景下，往往会出现一些“异常组合”：

• Security ID 与 Account Name 不匹配
  • 账户名显示为 Administrator
  • SID 却属于 krbtgt
• Account Domain 显示为 FQDN
  • 正常情况下应为简短域名（如 CORP）
• Logon Type 为 3（Network Logon）
  • Golden Ticket 攻击中非常常见
• 源 IP 地址为普通工作站
  • 而非域控制器

单独看任何一条，都可能是误报；但如果这些特征同时出现，几乎可以确认是 Golden Ticket 攻击。

重点检测票据生命周期

在默认配置下：

• Kerberos 票据有效期通常为 10 小时

而攻击者伪造的 Golden Ticket：

• 有效期可能被设置为 10 年甚至更久

通过在可疑主机上执行 klist，检查当前票据的生命周期，是应急响应中非常实用的一步。

应急响应总结

在实战中，判断 Golden Ticket 攻击，通常需要同时满足以下多个条件：

1. 从非域控主机请求 krbtgt 服务票据（4769）
2. 登录事件中 SID 与账户名不一致（4624）
3. 登录类型为网络登录（Type 3）
4. 账户域名为 FQDN 形式
5. 源网络地址指向普通工作站

这些信号必须 综合分析、相互验证，才能最大限度降低误报。

缓解与防护建议

从防御和应急响应角度，以下措施至关重要：

1. 最小化域管理员权限，严格限制高权限账号的使用场景
2. 定期更换 krbtgt 密码，这是官方推荐、也是最有效的缓解手段之一
3. 强化日志与可视化能力，结合事件日志、Sysmon 日志进行关联分析
4. 关注攻击工具痕迹，在进程与命令行参数中重点排查：mimikatz，lsadump，kerberos::golden 等关键词

赞赏

微信赞赏支付宝赞赏