🔐 Silver Ticket：为什么伪造一个服务票据，能直接绕过很多 Windows 横向移动防线

很多人先记住 Kerberos 里最危险的是 Golden Ticket，但现实攻防里，Silver Ticket 往往更安静，也更贴近“已经拿下一台机器后怎么继续扩大权限”这个场景。它的核心不是伪造整套登录身份，而是伪造“某个具体服务愿意接受的票据”。如果攻击者已经拿到了某个服务账户的密钥，比如机器账户、IIS 应用池账户，或者跑 SQL Server 的域账户，他就能自己离线构造一张 TGS（Ticket Granting Service ticket），然后直接去访问这个服务。关键点在于，这张票据不一定要再去找域控签发，所以很多只盯着 DC 日志的检测思路会漏掉它。

为什么会发生？因为 Kerberos 的服务票据本质上是“拿服务自己的密钥加密，证明这个客户端被允许访问你”。服务端收到票据后，只要能用自己的密钥解开，并且里面的字段看起来成立，就可能放行。也就是说，验证动作发生在服务端，而不是每次都回头问域控“这票是真的吗”。这就是 Silver Ticket 的土壤：一旦服务密钥泄露，攻击者就能伪造“发给这个服务看的证明”。它不像 Golden Ticket 那样掌控整个域，但对文件共享、远程管理、MSSQL、HTTP/SPN 绑定服务这些目标已经足够致命。

现实里它常被用在“低噪声横向移动”。比如攻击者先拿下一台服务器的本地管理员，再导出这台机器账户的哈希。接着他可以伪造访问 cifs/host 的票据去碰 SMB，共享、计划任务、远程服务控制都可能被串起来。如果拿到的是 http/ 或 mssqlsvc/ 这类 SPN 对应账户的密钥，攻击面就会变成 Web 管理后台、数据库服务甚至应用层数据。它可怕的地方不在“理论上能做”，而在于很多环境里服务账户权限本来就配得过大，结果一个服务密钥泄露，后面不只是这个服务出事，而是一串依赖它的资源一起沦陷。

防它不能靠空话。第一，别让服务账户长期复用静态高权限口令，优先用 gMSA 这类自动轮换的托管账户。第二，机器账户和服务账户权限要收紧，别让一个跑业务的账户顺手拥有本地管理员、远程登录或数据库超权。第三，检测上不要只看 TGS-REQ/TGT 申请链路，因为 Silver Ticket 可能根本不经过正常申请；你要盯的是“服务端看到一个 Kerberos 登录，但域控侧没有对应票据签发痕迹”的不一致，还有异常 SPN 访问、伪造票据常见的生命周期和 PAC 特征。第四，一旦怀疑泄露，处理不是“删个会话”就完了，而是必须轮换对应服务账户或机器账户密钥，不然伪造能力还在。

🧪 你在一台 IIS 服务器上发现攻击者导出了运行站点的域服务账户 NTLM/AES 密钥。第二天，域控上几乎没有新的异常票据申请日志，但这台 IIS 后面的 SQL Server 和文件共享却出现了来自该用户身份的 Kerberos 访问。更可能发生了什么？为什么只盯域控日志会漏报？


💡 核心记忆：Silver Ticket 的本质不是“偷到一次登录”，而是“拿到服务密钥后，自己伪造这个服务愿意相信的票据”。

#Security