1. 从一次内网排查说起：为什么"白银票据"值得单独拎出来讲
很多人第一次听到"白银票据"这个词，是在做内网安全评估或者域环境排查的时候。它不像"黄金票据"那样一出场就自带光环、动辄控制整个域，但恰恰因为它的门槛更低、更隐蔽，反而成了实战中出现频率极高的一类攻击手法。我在实际项目里遇到过好几次这样的情况：明明没有拿到域控权限，也没有域管哈希，但攻击者就是能访问某台文件服务器、某台数据库服务器，甚至能横向到其他机器上执行命令。追查下来，问题往往就出在服务账户的密钥泄露上，而利用这个密钥伪造出来的，正是所谓的"白银票据"。
先把概念说清楚。在Windows域环境里，Kerberos是默认的认证协议。正常流程下，你输入账号密码登录，域控（KDC）验证通过后给你发一张票据授权票据（TGT），你拿着TGT再去向域控申请针对某个具体服务的服务票据（ST），最后拿ST去访问那个服务。整个过程里，域控是核心，所有票据都得它盖章才有效。而"白银票据"的核心思路是：我不经过域控，直接用某个服务账户的密钥（NTLM Hash或AES Key）自己伪造一张服务票据，因为服务端只认自己账户密钥加密的票据，不关心这张票是不是域控发的。这就绕过了域控的整个认证环节，直接骗过目标服务。
这个手法为什么危险？因为它把攻击面从"必须拿下域控"降到了"拿下任意一台运行服务的机器上的服务账户凭据"。而服务账户的凭据在域环境里到处都是——IIS的应用池账户、SQL Server的服务账户、各种计划任务用的账户，这些账户的密码哈希可能被缓存在本地，也可能通过Kerberoasting被离线破解出来。一旦拿到，攻击者就能伪造票据访问该服务所在的主机，甚至以该服务的权限执行操作。更麻烦的是，这种伪造的票据在服务端日志里看起来"一切正常"，因为票据本身是合法的、用正确密钥加密的，只是签发者不是域控而已。
我写这篇东西的目的，不是教人怎么攻击，而是把这件事的来龙去脉、技术细节、检测思路和防御手段讲透。因为只有真正理解了票据是怎么被伪造出来的，你才知道该在哪里设卡、该监控什么日志、该给服务账户做什么样的加固。下面我会从Kerberos的票据结构讲起，一步步拆到白银票据的构造方式、利用条件、检测点和防御策略，中间穿插我在实际排查中踩过的坑和总结的经验。
2. Kerberos票据的"防伪标识"到底藏在哪
2.1 服务票据的加密结构：为什么服务端只认自己的密钥
要理解白银票据，必须先搞清楚一张服务票据（ST）里面到底装了什么。Kerberos的ST本质上是一个被服务账户密钥加密的数据结构，里面包含了客户端身份、会话密钥、票据有效期、权限信息等。关键点在于：这张票据是用服务账户的长期密钥加密的，而不是域控的密钥。域控在签发ST的时候，会从活动目录里读取目标服务对应的账户密钥，用它来加密票据内容，然后发给客户端。客户端拿着这张加密后的票据去找服务，服务用自己的密钥解密，验证通过后就认为"这是域控认可的用户"，然后根据票据里的信息决定给什么权限。
这里有个容易被忽略的细节：服务端在验证票据时，并不会去联系域控确认这张票是不是真的由域控签发的。它只做一件事——用自己的密钥解密，能解开就认。这个设计本身是为了性能考虑，避免每次服务访问都去骚扰域控。但正是这个"只解密不验证来源"的机制，给了白银票据可乘之机。攻击者只要拿到服务账户的密钥，就能自己构造一张一模一样的票据，服务端照样能解密，照样认。
我在一次排查中遇到过这样的情况：某台文件服务器的安全日志里显示某个普通域用户访问了共享目录，但那个用户当天根本没登录过。后来发现是攻击者用文件服务器机器账户的哈希伪造了ST，把自己伪装成了那个用户。服务端日志里记录的访问者是伪造票据里填的那个用户名，而不是攻击者真实的身份。这就是白银票据最迷惑人的地方——日志里看到的"人"和实际操作的人可能完全对不上。
2.2 服务账户密钥的几种来源：为什么它比想象中好拿
服务账户的密钥在域环境里其实并不难获取，这也是白银票据泛滥的根本原因。常见的来源有这么几类：
第一类是机器账户的哈希。每台加入域的计算机都有一个机器账户，它的密码是自动维护的，默认30天轮换一次。但如果你拿到了某台机器的本地管理员权限，就可以从内存里把机器账户的哈希抓出来。这个哈希可以用来伪造针对该机器上各种服务的白银票据。
第二类是服务账户的密码哈希。很多服务在配置的时候会指定一个域用户作为服务账户，比如IIS的应用池身份、SQL Server的启动账户。这些账户的密码哈希可能被缓存在服务所在机器的LSASS进程里，也可能通过Kerberoasting攻击被离线破解。Kerberoasting的原理是：任何域用户都可以向域控请求任意服务账户的ST，而这张ST是用服务账户密钥加密的，拿回来之后可以离线暴力破解。如果服务账户的密码强度不够，很快就能破出来。
第三类是组托管服务账户（gMSA）的密钥。gMSA是微软后来推出的一种更安全的服务账户方案，密码由域控自动管理且复杂度很高，理论上很难破解。但如果攻击者拿到了域控权限，或者拿到了能读取gMSA密码的权限，照样能提取出密钥。不过相比传统服务账户，gMSA的门槛已经高了很多。
第四类是计划任务和应用程序的硬编码凭据。这个说起来有点尴尬，但确实常见——有些应用程序的配置文件里直接写了服务账户的明文密码，或者脚本里硬编码了凭据。攻击者拿到这些文件，就等于拿到了服务账户的密钥。
我个人的经验是，在做内网评估的时候，Kerberoasting几乎是必做的动作。因为它的门槛极低——只要有一个普通域用户权限就能发起，而且很多老系统的服务账户密码还是几年前设的，强度堪忧。一旦破出来一个服务账户的密码，对应的白银票据就能直接安排上。
2.3 白银票据与黄金票据的本质区别：权限范围决定隐蔽性
很多人会把白银票据和黄金票据搞混，这里必须掰扯清楚。黄金票据伪造的是TGT，用的是域控上krbtgt账户的哈希。有了krbtgt哈希，你可以伪造任意用户的TGT，然后拿这个TGT去申请任意服务的ST，等于拿到了整个域的通行证。但krbtgt哈希只在域控上有，拿到它意味着你已经拿下了域控，这是域渗透的终极目标之一。
白银票据伪造的是ST，用的是某个具体服务账户的哈希。你只能伪造针对那个服务的票据，访问那个服务所在的主机或资源，权限范围局限在服务账户能触及的范围内。但好处是，你不需要域控权限，只需要拿到某个服务账户的密钥就行。门槛低、范围小、隐蔽性强，这是白银票据的特点。
从检测角度看，黄金票据因为伪造的是TGT，而TGT的签发在域控上有严格日志记录，所以相对容易被发现。白银票据伪造的是ST，ST的签发在域控上也有日志，但服务端验证票据时不会去域控核对，所以如果攻击者直接用伪造的ST去访问服务，域控那边根本不会有对应的ST签发记录。这就造成了一个检测盲区：服务端有访问日志，域控端没有签发日志，两边对不上。这个"日志缺口"恰恰是检测白银票据的重要线索。
3. 伪造一张白银票据需要凑齐哪些"零件"
3.1 域SID、服务账户哈希与目标SPN：三样缺一不可
要伪造一张能用的白银票据，你需要凑齐三个核心要素：域的SID、服务账户的密钥（NTLM Hash或AES Key）、目标服务的SPN。这三个东西缺一不可，少一个票据就构造不出来，或者构造出来服务端解不开。
域的SID是标识这个域的唯一字符串，格式类似S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx。它的作用是放在票据的权限信息里，告诉服务端这个用户属于哪个域。获取域SID的方法很多，普通域用户就能通过whoami /user或者查询活动目录拿到，不算什么秘密。
服务账户的密钥是核心。如果是NTLM Hash，就是那个32位的十六进制字符串；如果是AES Key，就是更长的字符串。获取方式前面已经说了，Kerberoasting、内存抓取、配置文件泄露等等。这里要注意一点：用NTLM Hash和用AES Key伪造出来的票据，在服务端看来可能有些细微差别，因为加密算法不同。有些老服务只支持RC4加密，那就只能用NTLM Hash；新一点的服务支持AES，用AES Key更稳妥。
目标SPN是你要访问的服务的标识，格式类似MSSQLSvc/sqlserver.domain.com:1433或者CIFS/fileserver.domain.com。SPN必须填对，因为服务端在解密票据后会检查票据里的SPN是否和自己匹配。填错了，服务端直接拒绝。获取SPN的方法也简单，普通域用户就能查询活动目录里的SPN记录。
我见过有人伪造票据失败，排查半天发现是SPN写错了——把CIFS写成了HOST，或者端口号漏了。这种细节看着小，但直接决定票据能不能用。所以构造之前，一定要先用工具把目标服务的SPN确认清楚。
3.2 票据里的PAC字段：权限信息的"暗箱"
票据里还有一个关键部分叫PAC（Privilege Attribute Certificate），里面装着用户的SID、所属组、权限信息等。服务端在解密票据后，会读取PAC里的信息来决定给用户什么权限。白银票据的伪造者可以自定义PAC里的内容，比如把自己塞进"域管理员"组，这样访问服务时就能拿到最高权限。
但这里有个坑：PAC字段是有签名的。正常情况下，PAC会由域控用krbtgt密钥签名，服务端验证签名确保PAC没被篡改。如果攻击者伪造的票据里PAC签名不对，有些服务会拒绝。不过在实际环境中，很多服务对PAC签名的验证并不严格，尤其是那些只做简单认证的服务。所以白银票据能不能拿到高权限，取决于目标服务的具体配置。
我在测试中遇到过这样的情况：用伪造的票据访问文件共享，能列目录、能读文件，但想写文件就被拒了。后来分析发现，服务端虽然认了票据，但在做写操作时额外检查了PAC里的组信息，而伪造的PAC里没有对应的权限组。这说明白银票据的权限不是无限的，它受限于服务端的授权逻辑。想拿到更高权限，要么伪造更完整的PAC，要么目标服务本身对PAC校验不严。
3.3 时间戳与票据有效期：别让"过期票"坏了事
票据里还有时间戳字段，包括签发时间和过期时间。服务端在验证票据时会检查当前时间是否在有效期内。如果伪造的票据时间设置不对，比如签发时间在未来，或者已经过期，服务端会直接拒绝。所以构造票据时，时间字段要设置得合理——通常签发时间设为当前时间稍早一点，过期时间设为当前时间之后若干小时。
这个细节看似简单，但实际构造时容易忽略。有些工具默认的时间设置可能和目标的时区不一致，导致票据"看起来"过期了。我在一次测试中就因为这个卡了半天，后来把时间字段手动调整了一下才通过。所以如果你自己写脚本构造票据，时间字段一定要仔细处理。
4. 从零构造一张白银票据的完整实操链路
4.1 信息收集：先把域SID、SPN和目标账户摸清楚
构造白银票据的第一步是信息收集。你需要确认三件事：域的SID是什么、目标服务的SPN是什么、服务账户的哈希有没有拿到。前两个用普通域用户权限就能查，第三个取决于你之前的渗透成果。
查域SID，可以在域内任意一台机器上执行whoami /user，输出里的SID去掉最后的RID部分就是域SID。比如输出是S-1-5-21-1234567890-1234567890-1234567890-1105，那域SID就是S-1-5-21-1234567890-1234567890-1234567890。也可以用PowerShell的Get-ADDomain命令，直接拿到DomainSID属性。
查SPN，可以用setspn -T domain.com -Q */*列出所有SPN，或者用PowerShell的Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName。找到目标服务对应的SPN后记下来，格式要完整。
服务账户哈希的获取方式前面说过了，这里不再展开。假设你已经拿到了某个服务账户的NTLM Hash，接下来就可以进入构造环节。
4.2 用Mimikatz构造票据：参数逐个拆解
Mimikatz是构造白银票据最常用的工具之一，它的kerberos::golden命令虽然名字叫golden，但通过指定参数也可以用来构造白银票据。核心参数有这么几个：
/domain：域名，比如domain.com/sid：域SID，就是前面查到的那个/target：目标服务的SPN，比如CIFS/fileserver.domain.com/service：服务类型，比如cifs、mssql、http/rc4：服务账户的NTLM Hash/user：你想伪装成的用户名，可以随便填/ptt：直接注入到当前会话，不生成文件
一个典型的命令长这样：
kerberos::golden /domain:domain.com /sid:S-1-5-21-1234567890-1234567890-1234567890 /target:fileserver.domain.com /service:cifs /rc4:abcdef1234567890abcdef1234567890 /user:fakeuser /ptt执行完之后，当前会话就多了一张伪造的ST。你可以用klist命令查看当前会话里的票据，确认伪造的票据已经注入。然后尝试访问目标服务，比如dir \\fileserver.domain.com\share，如果能列目录，说明票据生效了。
这里有几个实操细节值得注意。第一，/user字段填什么名字不影响票据能不能用，但会影响服务端日志里记录的用户名。如果你想隐蔽一点，可以填一个真实存在的普通用户名，这样日志看起来更"正常"。第二，/ptt参数是直接注入内存，不落盘，相对隐蔽；如果不加这个参数，Mimikatz会生成一个.kirbi文件，你需要用kerberos::ptt命令手动注入。第三，如果目标服务支持AES加密，可以用/aes256参数替代/rc4，票据的兼容性更好。
4.3 不用Mimikatz的替代方案：Rubeus与自写脚本
Mimikatz虽然强大，但在某些环境下会被杀软拦截。这时候可以考虑用Rubeus，它是一个专门针对Kerberos的工具，用C#写的，功能很全。Rubeus构造白银票据的命令是rubeus.exe silver，参数和Mimikatz类似：
rubeus.exe silver /service:cifs/fileserver.domain.com /rc4:abcdef1234567890abcdef1234567890 /user:fakeuser /domain:domain.com /sid:S-1-5-21-1234567890-1234567890-1234567890 /pttRubeus的好处是它可以直接在内存里执行，不依赖外部库，而且对某些杀软的绕过效果更好。不过它也不是万能的，具体能不能用还得看目标环境的防护情况。
如果连Rubeus都用不了，还可以自己写脚本构造票据。Kerberos票据的格式是公开的，用Python的impacket库就能构造。impacket里的ticketer.py脚本就是干这个的：
python ticketer.py -nthash abcdef1234567890abcdef1234567890 -domain-sid S-1-5-21-1234567890-1234567890-1234567890 -domain domain.com -spn cifs/fileserver.domain.com fakeuser执行完会生成一个.ccache文件，然后用export KRB5CCNAME=fakeuser.ccache设置环境变量，就可以用这个票据访问目标服务了。这种方式的优点是跨平台，Linux环境下也能用，适合在渗透测试的后期阶段使用。
4.4 票据注入后的验证：怎么确认"票"真的能用
构造完票据、注入到会话之后，怎么确认它真的生效了？最直接的方法就是尝试访问目标服务。如果是CIFS服务，就试着列共享目录；如果是MSSQL服务，就试着连接数据库；如果是HTTP服务，就试着访问Web页面。能正常访问，说明票据被服务端认可了。
但这里有个容易误判的情况：有时候你访问成功了，但用的其实不是伪造的票据，而是当前会话里本来就有的合法票据。所以验证之前，最好先用klist purge清空当前会话的所有票据，然后再注入伪造的票据，再访问。这样才能确保访问成功是因为伪造的票据生效了。
另一个验证方法是看服务端日志。如果服务端记录了你的访问，但域控端没有对应的ST签发记录，那就基本可以确认是白银票据在起作用。这个"日志缺口"也是后面检测环节要重点关注的。
5. 服务端日志里的"幽灵访问"：白银票据的检测思路
5.1 域控端没有ST签发记录，服务端却有访问日志
白银票据最核心的检测思路就是找"日志缺口"。正常情况下，用户访问某个服务，流程是这样的：用户先拿TGT向域控申请ST，域控签发ST并记录事件日志（事件ID 4769），然后用户拿ST访问服务，服务端记录访问日志。所以域控端有4769事件，服务端有访问日志，两边能对上。
但白银票据绕过了域控，攻击者直接伪造ST访问服务。服务端照样记录访问日志，但域控端没有对应的4769事件。如果你在服务端看到某个用户访问了服务，但在域控端查不到该用户申请该服务ST的记录，这就非常可疑了。
实际操作中，可以把服务端的访问日志和域控端的4769事件做关联分析。具体做法是：从服务端日志里提取访问者的用户名、访问时间、目标服务；然后去域控的Security日志里查同一时间窗口内该用户是否有对应的4769事件。如果没有，基本可以判定是伪造票据。
这个方法的难点在于日志量可能很大，手工比对不现实。通常需要写脚本或者用SIEM平台做自动化关联。我在项目里用PowerShell写过简单的关联脚本，从两台机器的日志里分别导出数据，然后用哈希表做匹配，效率还可以。
5.2 票据里的异常字段：SPN不匹配与PAC签名缺失
除了日志缺口，票据本身的异常字段也是检测点。比如，服务端在解密票据后会检查票据里的SPN是否和自己匹配。如果攻击者构造票据时SPN填错了，服务端会拒绝，并在日志里记录异常。这种异常日志可以作为检测线索。
另一个检测点是PAC签名。正常情况下，PAC会由域控用krbtgt密钥签名。如果服务端配置了严格的PAC验证，伪造的票据因为签名不对会被拒绝。但很多服务默认不验证PAC签名，所以这个检测点不是万能的。不过如果服务端日志里出现了PAC验证失败的记录，那就值得深挖。
还有一个细节：伪造票据里的加密类型可能和正常票据不同。比如正常环境里服务端可能偏好AES加密，但攻击者用NTLM Hash伪造的票据是RC4加密的。如果服务端日志里记录了加密类型，可以对比正常访问和可疑访问的加密类型差异。这个差异不一定能直接定性，但可以作为辅助判断。
5.3 访问行为异常：非工作时间、非常用IP、异常权限
除了技术层面的检测，行为层面的异常也很重要。白银票据伪造出来的身份是攻击者自己填的，可能是一个真实存在的用户，也可能是一个虚构的用户。如果服务端日志里出现了不存在的用户名，或者某个用户在不正常的时间（比如凌晨三点）访问了服务，或者访问来源IP和该用户平时的习惯不符，这些都是可疑信号。
更隐蔽的一种情况是权限异常。攻击者伪造票据时可能把自己塞进了高权限组，导致一个普通用户在服务端表现出了不该有的权限。比如一个普通域用户突然能访问只有管理员才能访问的共享目录，这就是明显的异常。服务端如果配置了权限变更审计，这类异常会被记录下来。
我在一次排查中就是通过权限异常发现的线索：某台文件服务器的日志显示一个普通用户读取了一个敏感目录，但该用户所属的组并没有这个目录的权限。深入分析后发现是伪造票据里塞了额外的组信息。这个案例说明，光看认证日志不够，还得结合授权日志一起分析。
6. 把门关紧：针对白银票据的防御加固清单
6.1 服务账户密码强度与轮换策略：让哈希"破不出来"
白银票据的根基是服务账户密钥泄露，所以最直接的防御就是让密钥难以获取。具体措施包括：给服务账户设置足够复杂的密码，长度至少25位，包含大小写字母、数字和特殊字符；定期轮换服务账户密码，尤其是那些长期未更换的账户；避免多个服务共用同一个账户，降低单点泄露的影响范围。
如果条件允许，尽量使用组托管服务账户（gMSA）。gMSA的密码由域控自动管理，复杂度高且定期轮换，攻击者即使拿到了哈希，能用的时间窗口也很短。而且gMSA的密码不会缓存在本地，内存抓取也拿不到。这是目前防御白银票据最有效的措施之一。
另外，要定期检查域内是否存在密码强度弱的服务账户。可以用工具做Kerberoasting模拟攻击，看看哪些账户的哈希能被快速破解。发现弱密码账户后，立即更换密码并排查是否已经被利用。
6.2 限制服务账户权限：别让一张票"通吃"
服务账户的权限应该遵循最小权限原则。很多环境里，服务账户被随手加进了域管理员组或者本地管理员组，这是非常危险的。一旦这个账户的密钥泄露，攻击者伪造的票据就能拿到管理员权限，后果严重。
正确的做法是：为每个服务账户单独配置所需的权限，只授予它完成工作所必需的最小权限。比如，一个只负责读取数据库的服务账户，就不应该给它写文件的权限；一个只负责运行Web应用的服务账户，就不应该给它域管权限。这样即使票据被伪造，攻击者能做的事情也有限。
还要注意服务账户的委派权限。Kerberos委派允许服务代表用户去访问其他服务，如果配置不当，攻击者可以利用委派链扩大访问范围。对于不需要委派的服务，应该禁用委派；对于需要委派的服务，应该使用约束委派或基于资源的约束委派，限制委派的目标范围。
6.3 开启PAC签名验证与审计策略：让伪造票据"露馅"
前面提到，PAC签名验证是检测伪造票据的一个手段。虽然默认情况下很多服务不验证PAC签名，但可以通过组策略开启。具体来说，可以在域控上配置"安全选项"里的"Kerberos策略"，启用PAC签名验证。开启后，服务端会验证票据里的PAC签名，伪造的票据因为签名不对会被拒绝。
不过这个措施有个副作用：可能会影响一些老系统的兼容性。因为有些老系统不支持PAC签名，开启验证后它们可能无法正常认证。所以开启之前要做好测试，确认所有关键服务都能正常工作。
审计策略方面，要确保域控和服务端都开启了详细的Kerberos审计。域控上要记录4769事件（ST申请），服务端要记录访问日志和认证日志。只有日志齐全，才能做关联分析，发现日志缺口。同时，建议把日志集中收集到SIEM平台，设置告警规则，比如"服务端有访问但域控无对应ST签发"就触发告警。
6.4 监控Kerberoasting行为：从源头掐断密钥泄露
Kerberoasting是获取服务账户哈希的主要手段之一，所以监控Kerberoasting行为能从源头减少白银票据的风险。Kerberoasting的典型特征是：一个普通用户短时间内向域控请求大量不同服务的ST。正常情况下，用户只会请求自己需要访问的少数几个服务，不会到处请求。
检测方法是在域控上监控4769事件，统计每个用户请求ST的频率和目标服务数量。如果某个用户在短时间内请求了大量不同SPN的ST，尤其是那些该用户平时不访问的服务，就可能是Kerberoasting。可以设置阈值告警，比如"5分钟内请求超过10个不同SPN"就触发。
另外，Kerberoasting请求的ST通常是用RC4加密的（因为RC4更容易破解），而正常环境里可能已经升级到AES。如果发现大量RC4加密的ST请求，也是一个可疑信号。可以在域控策略里禁用RC4加密，强制使用AES，这样即使攻击者拿到ST，破解难度也会大很多。
7. 几个我在实操中踩过的坑和总结的经验
第一个坑是时间同步问题。Kerberos对时间非常敏感，域内机器的时间偏差默认不能超过5分钟。伪造票据时如果时间字段设置不当，或者攻击机和目标机的时间不同步，票据可能直接被拒。我有一次在虚拟机里做测试，宿主机休眠后虚拟机时间没跟上，导致伪造的票据怎么都用不了，排查了半天才发现是时间问题。所以做这类操作之前，先确认时间同步是正常的。
第二个坑是SPN格式。前面提过，SPN必须填对，但具体怎么填有时候容易搞混。比如CIFS服务的SPN，有的环境是CIFS/fileserver.domain.com，有的是CIFS/fileserver，还有的带端口号。填错了服务端就不认。我的经验是，先用setspn -Q把目标服务的SPN原样查出来，然后一字不差地填进去，不要自己猜。
第三个坑是票据注入后的会话问题。用Mimikatz的/ptt参数注入票据后，票据是注入到当前进程的会话里的。如果你新开一个命令行窗口，新窗口里是没有这张票据的。所以注入之后要在同一个会话里操作，或者用klist确认票据在当前会话里。这个细节看着小，但新手很容易在这里卡住。
第四个坑是日志关联的复杂度。做检测的时候，域控日志和服务端日志的时间戳可能有时区差异，直接比对会对不上。要先统一时区，再做关联。另外，域控日志量很大，全量导出分析不现实，最好先按时间窗口和目标服务过滤，缩小范围。
最后一个经验是关于权限的。白银票据能拿到什么权限，取决于服务端的授权逻辑和票据里的PAC内容。不要想当然地认为伪造了票据就一定能拿到管理员权限。实际测试中，很多服务只做认证不做细粒度授权，伪造票据能访问服务，但具体能做什么还得看服务本身的配置。所以评估影响范围时，要针对具体服务具体分析，不要一概而论。
把这些东西串起来看，白银票据本质上是一个"信任错位"的问题：服务端信任域控签发的票据，但验证时只看密钥不看签发者；攻击者利用这个错位，用泄露的服务账户密钥自己"签发"票据。防御的核心也就清晰了：要么让密钥拿不到（强密码、gMSA、最小权限），要么让伪造票据露馅（PAC验证、日志关联、行为监控）。两条路都走通，白银票据的空间就会被大幅压缩。
