黄金票据和白银票据是kerberos信任模型被滥用的结果；防御关键在于阻断krbtgt或服务账户哈希的获取路径，而非拦截票据本身。
黄金票据和白银票据不是“漏洞”，而是kerberos协议设计中信任模型被滥用的结果；防御的关键不在拦截票据，而在切断攻击者获取签名密钥的路径。
黄金票据为什么能绕过域控验证？
黄金票据伪造的是 TGT，它由域控制器（KDC）用 krbtgt 账户的密码哈希加密签名。只要攻击者拿到这个哈希（比如通过 mimikatz::lsadump::dcsync /user:krbtgt），就能离线生成任意用户的 TGT，且该票据在默认配置下有效期长达10年。
常见错误现象：Security 日志里看不到异常登录，Kerberos Service Ticket Operations 事件（ID 4769）大量出现但来源 IP 正常——因为票据是合法签发的，只是签发者不是 KDC。
- 攻击前提必须是已控制域控或拥有
Domain Admin权限（否则无法执行dcsync） -
krbtgt哈希一旦泄露，所有历史 TGT 都可能被重放，不依赖网络连通性 - Windows 默认不记录 TGT 签发行为（ID 4768 仅记录初始 AS_REQ，不包含票据内容）
白银票据为何更难被检测？
白银票据直接伪造 ST（服务票据），签名密钥来自目标服务账户（如 CIFS/dc.corp.com 对应的计算机账户哈希），不经过 KDC，因此不会触发任何域控侧日志（ID 4769 不会出现）。
使用场景：横向移动到文件服务器、SQL Server 或 Exchange 时，无需先拿下域控，只要拿到某台成员机的本地管理员权限 + 该机器的服务哈希即可。
- 典型参数组合：
kerberos::silver /service:CIFS /domain:corp.com /sid:S-1-5-21-xxx /target:fileserver.corp.com /rc4:aaabbbccc - 票据默认有效期仅 10 小时，但可手动设为长期，且每次使用都像“正常用户访问”
- 目标服务自身不做二次身份校验（如 SMB 不验证用户是否在域组中），只认票据签名
真正有效的防御动作有哪些？
监控日志不如阻断密钥获取路径。防御重心必须落在三个不可绕过的环节上：
- 强制轮换
krbtgt密码：必须连续轮换两次（第一次使旧哈希失效，第二次确保新哈希生效），间隔至少 4 小时；PowerShell 检查命令：Get-ADUser krbtgt -Properties PasswordLastSet - 禁用 NTLM 认证：白银票据依赖服务账户的
RC4_HMAC_MD5哈希，而该哈希只在启用 NTLM 时才会被缓存；组策略路径：Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Network security: LAN Manager authentication level - 限制 DCSync 权限：默认只有
Domain Admins、Enterprise Admins和Administrators组有此权限，检查是否有非必要账户被加入——用dsacls "dc=corp,dc=com"查看 ACL
为什么很多检测规则会漏掉白银票据？
因为白银票据根本不会向 KDC 发起请求。所有检测逻辑如果只盯 KDC 日志（ID 4768/4769）、或依赖票据中的用户名与源 IP 关联分析，都会失效。
容易被忽略的点：SPN 扫描本身不触发告警，但它是白银票据攻击前必做的一步；攻击者常用 setspn -T corp.com -Q */* 枚举，而该命令在默认策略下无审计事件。必须手动开启 Directory Service Access 审计并配置 SACL 才能捕获。
