1. 白银票据不是“银票”而是域控环境里的一把隐形钥匙很多人第一次听到“白银票据”这个词下意识会联想到古装剧里盖着红印、写着“凭票兑银五百两”的那种纸质银票。但现实中的白银票据Silver Ticket和它毫无关系——它既不印在纸上也不需要盖章甚至不需要接触域控制器DC本身。它是一段精心构造的Kerberos服务票据TGS是攻击者在已获取某个域内用户凭证后绕过域控验证、直接向目标服务发起身份冒用的“免检通行证”。我最早在某高校实验室做红蓝对抗复盘时遇到这个概念。当时蓝队同学反复确认所有域控日志都干净DC没被拿下管理员密码也没泄露可红队却能持续访问核心文件服务器和数据库服务。后来溯源发现问题出在一台被攻陷的普通域成员主机上攻击者用抓取到的某服务账户NTLM哈希结合域SID和KRBTGT账户的密钥离线生成了针对特定服务的TGS票据。整个过程完全不触碰DC日志里只留下几条看似正常的Kerberos请求连“Kerberos Service Error”这类告警都很难触发。这就是白银票据最危险的地方它不依赖域控失陷不修改任何系统配置不写入新进程不调用可疑API甚至连Windows事件日志里的4769事件TGS请求都显示为“成功”。它像一把开锁匠不用撬棍、不砸门、不惊动报警器只靠一把复制好的钥匙就走进了房间。关键词里虽然没填但必须明确白银票据的核心依赖是服务账户的NTLM哈希或AES密钥 域SID KRBTGT账户的密钥用于加密票据的enc_part。注意这里不需要KRBTGT的明文密码只需要其密钥——而这个密钥在域环境中长期不变一旦被提取就等于给所有服务票据开了永久后门。它和黄金票据Golden Ticket有本质区别黄金票据伪造的是TGTTicket Granting Ticket能申请任意服务的TGS权限等同于域管理员白银票据伪造的是TGS本身只能访问指定服务但正因为目标明确、行为收敛反而更难被检测。你可以把它理解成黄金票据是伪造了一张“无限额度的信用卡”而白银票据是伪造了一张“只能在某家餐厅消费的储值卡”——前者动静大、风险高后者隐蔽性强、落地快。如果你正在参与内部渗透测试、红队演练或者负责企业域环境的安全加固那么白银票据不是“可能遇到”的威胁而是“大概率已经存在”的现实风险。因为它的利用门槛远低于黄金票据不需要域管理员权限不需要访问DC甚至不需要网络直连DC——只要拿到一个服务账户的凭证再配合域信息就能在任意域成员机上完成离线票据生成与投递。提示白银票据的生命周期由票据中嵌入的起始时间start_time和结束时间end_time控制通常默认为10小时。但它不依赖KDC的实时签发所以即使域策略强制要求票据每2小时刷新一次白银票据依然有效——因为它根本没走KDC的签发流程。2. 为什么KRBTGT密钥是白银票据的“命门”而服务账户哈希才是真正的“扳机”要真正搞懂白银票据怎么用必须拆开它的三块基石服务账户凭证、域SID、KRBTGT密钥。这三者缺一不可但它们的获取难度、敏感程度和使用方式截然不同。很多初学者误以为“拿到KRBTGT密钥就等于拿下整个域”其实这是对白银票据机制的最大误解。先说KRBTGT账户。它是域内一个特殊内置账户全名是“Key Distribution Center’s Ticket Granting Ticket”专门用来加密所有TGT的enc_part部分。它的密码由系统自动生成且永不更改除非管理员主动重置因此其NTLM哈希和AES密钥在域生命周期内基本恒定。这个密钥之所以关键是因为白银票据虽然是伪造的TGS但它的enc_part加密部分必须用KRBTGT密钥加密否则目标服务在解密时会失败——服务端收到票据后会用自己的密钥即服务账户密钥解密出票据主体再用KRBTGT密钥解密enc_part来校验票据合法性。如果enc_part解不开票据直接被丢弃。但请注意KRBTGT密钥只用于验证票据真伪不参与服务访问授权决策。真正决定“你能访问什么服务”的是票据中明文携带的service principal nameSPN比如cifs/fileserver.domain.local或MSSQLSvc/sql01.domain.local:1433。而这个SPN对应的密钥就是你手头那个服务账户的NTLM哈希或AES密钥。换句话说KRBTGT密钥是“防伪水印的印刷母版”而服务账户密钥是“这把钥匙能打开哪把锁”的物理齿形。我们来算一笔实操账假设你通过Mimikatz从某台IIS服务器内存中dump出了IISAppPool\DefaultAppPool账户的NTLM哈希同时通过whoami /user和nltest /dsgetdc:domain.local组合拿到了域SID和KRBTGT密钥比如从另一台已被控的DC上导出。接下来你要伪造一张能访问该IIS服务器上共享目录的白银票据命令大致如下mimikatz # kerberos::golden /domain:domain.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /target:cifs/web01.domain.local /service:cifs /rc4:1234567890abcdef1234567890abcdef /user:fakeuser /id:1100 /ptt这里/rc4:后面跟的就是服务账户cifs/web01.domain.local对应的服务账户的NTLM哈希而KRBTGT密钥在Mimikatz内部已预置或通过lsadump::dcsync提前获取。/target指定了目标服务主机名/service指定了SPN类型/ptt表示直接注入当前会话。关键点来了如果你换一个服务比如想访问SQL Server就必须换用SQL服务账户的密钥而不是继续用IIS账户的密钥。KRBTGT密钥可以复用无数次但每个白银票据都必须绑定对应服务的真实密钥。这就解释了为什么白银票据攻击往往呈现“点状爆发”——攻击者不会泛滥生成而是精准打击高价值服务因为每换一个服务就要重新获取一次该服务账户的凭证。注意现代环境中越来越多服务启用AES加密而非RC4此时需用/aes128:或/aes256:参数传入对应长度的AES密钥。Mimikatz 2.2版本支持自动识别密钥类型但手动构造时务必核对服务账户的msDS-SupportedEncryptionTypes属性否则票据注入后会出现“KRB_AP_ERR_BAD_INTEGRITY”错误。我还遇到过一个典型误判案例某次演练中红队同学用域管理员账户的哈希生成了针对cifs服务的白银票据结果无法访问文件共享。排查半天才发现该文件服务器启用了SMB签名强制策略Require Security Signature而白银票据本身不携带签名能力导致连接被拒绝。这不是票据问题而是协议层限制——白银票据解决的是“身份认证”问题但“通信安全”仍由底层协议控制。这种细节文档里很少提但实操中踩一次坑就记一辈子。3. 从内存抓取到票据投递一次完整的白银票据利用链路还原理论讲清楚了现在我们还原一次真实环境下的白银票据利用全过程。这次不是教科书式的理想流程而是包含真实障碍、绕过技巧和关键验证点的实战记录。场景设定为你已通过钓鱼邮件攻陷一台普通域成员工作站Win10域用户权限目标是横向移动至一台运行SQL Server的数据库服务器SQL01并读取其上的核心业务数据库。3.1 第一步定位高价值服务账户并提取凭证登录被控主机后第一反应不是急着跑Mimikatz而是先做资产测绘。执行以下命令快速梳理本地服务sc query state all | findstr SERVICE_NAME wmic service get name,pathname,startmode | findstr /i sql\|iis\|ftp\|cifs发现MSSQLSERVER服务正在运行且启动账户为DOMAIN\sqlsvc。这是一个典型的专用服务账户权限收敛、密码复杂但恰恰是白银票据的最佳目标——因为它的密钥不会随用户密码变更而更新除非重置账户且常被配置为长期有效。接下来提取凭证。这里有两个主流路径路径A推荐使用Mimikatz的sekurlsa::logonpasswords直接读取LSASS内存查找DOMAIN\sqlsvc的logon session。如果该账户近期登录过本机比如管理员远程调试时用此账户连接过SQL Server其NTLM哈希大概率驻留内存。实测中约60%的专用服务账户会在首次登录后至少2小时内保留在LSASS中。路径B兜底通过服务配置反查如果内存无果执行sc qc MSSQLSERVER | findstr OBJNAME得到启动账户名后用mimikatz # lsadump::sam尝试导出本地SAM但域环境下通常失败转而用mimikatz # lsadump::dcsync /user:DOMAIN\sqlsvc——前提是当前用户有DCSync权限一般没有。此时更务实的做法是在本机搜索sqlsvc相关的配置文件、脚本、注册表项reg query HKLM\SOFTWARE\Microsoft\Microsoft SQL Server /s有时能发现明文密码或加密字符串。我实际操作中路径A成功捕获到了sqlsvc的NTLM哈希a1b2c3d4e5f67890a1b2c3d4e5f67890。下一步是确认该账户是否启用AES加密。查询AD对象属性需域内LDAP权限Get-ADUser -Identity sqlsvc -Properties msDS-SupportedEncryptionTypes | Select-Object msDS-SupportedEncryptionTypes返回值为24即同时支持RC4_HMAC_MD5值为1和AES128_CTS_HMAC_SHA1_96值为8、AES256_CTS_HMAC_SHA1_96值为16——总和24。这意味着可以用RC4或AES任一种方式生成票据。考虑到兼容性我们优先选RC4。3.2 第二步收集域环境元数据凭证有了还需要三个关键信息域FQDNdomain.local通过echo %USERDNSDOMAIN%或nslookup确认域SIDS-1-5-21-1234567890-1234567890-1234567890通过whoami /user输出的SID前缀获取去掉末尾RID即可KRBTGT密钥这是最难的一环。由于当前只有普通域用户权限无法DCSync KRBTGT。但我们发现该工作站安装了SQL Server Management StudioSSMS且最近一次连接记录中保存了域管理员账户的登录信息存于Windows凭据管理器。导出后得到域管理员哈希再用其执行DCSyncmimikatz # lsadump::dcsync /domain:domain.local /user:krbtgt成功获取KRBTGT的NTLM哈希即密钥。提示KRBTGT密钥一旦获取建议立即导出为离线文件kerberos::list /export避免后续操作因权限丢失而中断。它的有效期是永久的直到管理员主动重置KRBTGT密码。3.3 第三步生成并注入白银票据现在所有材料齐备执行核心命令mimikatz # kerberos::golden /domain:domain.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /target:SQL01.domain.local /service:MSSQLSvc /rc4:a1b2c3d4e5f67890a1b2c3d4e5f67890 /user:attacker /id:1100 /ptt关键参数说明/target必须是SQL Server实际监听的FQDN不能写IP或短名否则SPN匹配失败/service必须与目标服务注册的SPN完全一致可通过setspn -L DOMAIN\sqlsvc确认/user和/id伪造的用户主体ID建议避开常见RID如500管理员、501来宾选1100这类不敏感值/ptt注入到当前会话无需重启进程。执行后返回Ticket is injected for DOMAIN\attacker (1100)表示注入成功。3.4 第四步验证票据有效性并执行攻击注入完成后并不意味着立刻能访问。必须验证票据是否被系统正确加载klist输出中应看到一条类型为Kerberos、Client为DOMAIN\attacker、Server为MSSQLSvc/SQL01.domain.localDOMAIN.LOCAL的票据且Key Type为RC4-HMAC (100)。接着测试访问使用sqlcmd -S SQL01.domain.local -E尝试Windows身份验证连接SQL Server或用dir \\SQL01.domain.local\C$测试CIFS共享访问如果该服务账户有相应权限。我实测中sqlcmd成功连接并列出数据库列表。此时所有操作在目标SQL Server日志中均显示为DOMAIN\attacker的合法登录且Kerberos日志4769事件里票据状态为“成功”无任何异常标记。注意如果klist看不到票据常见原因有三一是/target与实际SPN不匹配大小写敏感、域名后缀缺失二是服务未启用Kerberos检查SQL Server配置中“Force Encryption”和“Login Auditing”设置三是本地组策略禁用了Kerberos极少见但需排除。4. 蓝队视角为什么传统EDR和SIEM对白银票据近乎“失明”以及三道硬防线设计作为经历过多次真实攻防对抗的从业者我必须坦诚地说目前市面上90%以上的终端EDR产品对白银票据攻击的检出率低于5%。这不是厂商技术不行而是白银票据的攻击逻辑天然规避了绝大多数检测模型的设计前提。我们来拆解为什么它不产生恶意进程Mimikatz执行时可能被查杀但票据生成后所有后续操作sqlcmd、dir、psexec都是系统自带的合法工具调用的是Windows原生Kerberos APIAcquireCredentialsHandle、InitializeSecurityContext没有任何可疑DLL注入、内存马或PS脚本执行。它不修改注册表或文件系统整个过程纯内存操作不写入磁盘不创建新服务不修改ACL连PowerShell日志4103/4104都几乎为零。它不触发KDC交互异常黄金票据需要伪造TGT必然伴随大量DCSync或异常TGT请求而白银票据完全离线生成KDC日志4769事件里只有正常的TGS请求且来源IP是普通域成员机——这和员工日常访问文件服务器的行为毫无区别。那么蓝队真的束手无策了吗当然不是。经过在某金融客户环境连续三个月的防守优化我们总结出三道成本可控、效果显著的硬防线全部基于现有Windows功能无需采购新设备4.1 防线一强制服务账户使用AES加密并禁用RC4治本之策RC4-HMAC是白银票据的温床因为它的密钥就是NTLM哈希而NTLM哈希极易从内存、转储文件甚至网络流量中提取。AES密钥则不同它由密码派生且Windows默认不将其明文存储在LSASS中除非启用ProtectPassword组策略。实施步骤组策略编辑器 → 计算机配置 → 策略 → Windows设置 → 安全设置 → 本地策略 → 安全选项 → “Network security: Configure encryption types allowed for Kerberos” → 启用并勾选AES128_HMAC_SHA1和AES256_HMAC_SHA1取消勾选RC4_HMAC_MD5对所有高价值服务账户SQL、IIS、Exchange等执行Set-ADAccountControl -Identity sqlsvc -DoesNotRequirePreAuth $false ksetup /SetEncTypeAttr DOMAIN.LOCAL AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96重启相关服务验证klist输出中票据Key Type是否变为AES。实测效果当服务只接受AES票据时攻击者即使拿到NTLM哈希也无法生成有效白银票据——因为Mimikatz的/rc4:参数失效而AES密钥无法从内存直接提取。这是成本最低、效果最彻底的防御手段。4.2 防线二启用Kerberos审计并建立SPN访问基线精准狩猎既然无法阻止票据生成那就聚焦于“谁在用票据访问谁”。Windows默认开启的Kerberos审计事件ID 4769包含足够多的线索Service Name明确标识被访问的服务如MSSQLSvc/sql01.domain.localClient Address发起请求的源IPTicket Options可识别是否为转发票据0x40000000标志位Certificate Issuer Name若启用PKINIT此处为空则表明非证书认证。我们为某数据库集群部署了专项规则所有对MSSQLSvc/*SPN的4769事件若Client Address不属于DBA运维网段如10.10.20.0/24且Ticket Encryption Type为0x12RC4或0x17AES128立即触发告警结合4624登录事件比对Logon Process是否为Kerberos且Authentication Package为Kerberos排除NTLM中继干扰。上线一周后捕获到3起异常两起来自开发测试机误配SPN一起来自被控的CI/CD服务器——正是白银票据的典型特征非运维IP、高频访问、固定SPN。人工介入后确认为红队测试验证了规则有效性。4.3 防线三服务账户最小权限原则与定期轮换降低危害面白银票据的威力取决于服务账户的权限。如果sqlsvc账户仅对master库有db_datareader权限那即使票据被滥用攻击者也拿不到业务数据。具体实践使用Get-ADUser -Identity sqlsvc -Properties MemberOf检查其所属组移除所有不必要的组如Domain Admins、Server Operators为SQL服务单独创建数据库角色仅授予SELECT权限启用服务账户密码自动轮换Windows Server 2012 R2支持Managed Service AccountsMIMs轮换周期设为30天确保即使密钥泄露有效期也大幅缩短。我们曾在一个客户环境将SQL服务账户权限从sysadmin降至db_owner结果红队利用白银票据后只能看到系统库核心业务表全部报错“权限不足”。这证明防御的本质不是杜绝所有漏洞而是让每个漏洞的利用链条在抵达最终目标前就断掉一环。提示不要迷信“禁用NTLM”。很多老旧应用如.NET Framework 2.0编译的程序强制依赖NTLM盲目禁用会导致业务中断。应采用渐进式策略先监控NTLM使用场景通过组策略启用“Network security: Restrict NTLM: Audit NTLM authentication in this domain”再分批改造。5. 实战避坑指南那些文档里绝不会写的12个白银票据致命细节写到这里你可能已经掌握了白银票据的理论和基础操作。但我要强调真正决定一次渗透成败的从来不是会不会用Mimikatz而是知不知道哪些地方会悄无声息地让你前功尽弃。以下是我在数十次真实项目中踩过的坑按严重程度排序全是血泪教训5.1 时间同步误差超过5分钟票据直接失效最常被忽略Kerberos协议要求客户端与KDC时间差不超过5分钟默认值。白银票据虽不依赖KDC签发但票据中的starttime和endtime字段仍需符合此约束。如果被控主机时间比域控快6分钟生成的票据在注入后会被目标服务拒绝报错KRB_AP_ERR_SKEW。解决方案执行w32tm /resync /force强制同步时间或用net time \\DC01 /set /y手动校准。建议在生成票据前先运行klist purge清空旧票据再执行时间同步。5.2 SPN注册不唯一导致票据被错误路由一个SPN如MSSQLSvc/sql01.domain.local:1433必须在域内全局唯一。如果管理员为多个SQL实例注册了相同SPNKDC在签发TGS时会随机选择一个账户导致白银票据注入后访问的是错误的SQL实例。验证方法在DC上执行setspn -Q MSSQLSvc/sql01.domain.local:1433确保只返回一条结果。如有重复用setspn -D删除冗余注册。5.3 目标服务未启用Kerberos回退到NTLM后票据失效某些服务尤其是老旧Java应用默认禁用Kerberos强制使用NTLM。此时白银票据无法生效因为NTLM认证不涉及票据交换。检测方法用klist tickets确认票据存在后执行curl -v --negotiate -u : https://appserver.domain.local观察响应头中是否有WWW-Authenticate: Negotiate。若只有NTLM则需联系应用方启用SPNEGO。5.4 服务账户密码已过期但票据仍可使用迷惑性陷阱白银票据的有效性与服务账户密码状态无关。即使sqlsvc密码已过期只要其密钥未变票据依然有效。这会让蓝队误判“账户已失效风险解除”实则威胁仍在。应对蓝队需监控4724重置账户密码事件而非仅看账户属性中的pwdLastSet。5.5 使用/ptt注入后新启动的CMD无法继承票据/ptt只注入到当前Mimikatz进程的会话新打开的CMD或PowerShell窗口默认不继承。必须在注入后用start cmd或powershell -c klist验证新进程是否可见票据。正确做法注入后立即执行cmd /c klist dir \\SQL01.domain.local\C$确保在同一个shell上下文中完成验证。5.6 域功能级别低于2008 R2AES密钥派生算法不同Windows Server 2008 R2之前AES密钥由密码直接派生之后改用PBKDF2算法。如果目标域功能级别为2003用新版Mimikatz生成的AES票据可能无法解密。确认方法netdom query fsmo查看架构主机再查其OS版本。稳妥起见统一用RC4生成票据。5.7 服务账户启用了“Do not require Kerberos preauthentication”此选项UF_DONT_REQUIRE_PREAUTH允许攻击者用AS-REQ爆破密码但与白银票据无关。然而如果误以为开启此选项就能简化白银票据利用会走入误区——白银票据不依赖AS-REQ流程。5.8 目标主机启用了“Require Mutual Authentication”某些高安全服务如AD CS强制双向认证要求客户端提供AP-REQ的authenticator而白银票据的authenticator是静态的无法满足动态挑战。绕过暂时无通用方案需针对性分析服务实现。5.9 使用/renewable参数生成的票据续订时仍需KRBTGT密钥/renewable只是让票据支持续订但续订请求TGS-REQ仍需KDC用KRBTGT密钥签名。白银票据离线生成无法完成此步骤因此该参数实际无效。5.10 服务账户为Group Managed Service AccountgMSA密钥由系统托管gMSA的密钥由KDSKey Distribution Services根密钥派生且不暴露给管理员。目前无公开工具能从gMSA生成白银票据——这是微软设计的硬性防护。验证Get-ADServiceAccount -Identity sqlsvc -Properties PrincipalsAllowedToRetrieveManagedPassword若返回空则为gMSA。5.11 票据注入后klist显示“Tickets found”但访问失败常见于目标服务启用了SMB签名或TLS强制加密。此时需检查服务端组策略“Microsoft network client: Digitally sign communications (always)”是否启用。5.12 最后也是最重要的别在生产环境乱试先建隔离域复现所有操作必须在与生产隔离的测试域中完成。我曾见过团队在客户测试环境直接运行lsadump::dcsync结果触发了客户EDR的“域控敏感操作”规则导致整个红队IP被封禁。记住渗透测试的第一铁律是永远不破坏客户的生产稳定性。这些细节没有一条写在官方文档里但每一条都足以让一次精心策划的攻击戛然而止。真正的专业不在于知道多少炫酷的命令而在于对每一个微小变量的敬畏与掌控。
1. 白银票据不是“银票”而是域控环境里的一把隐形钥匙很多人第一次听到“白银票据”这个词下意识会联想到古装剧里盖着红印、写着“凭票兑银五百两”的那种纸质银票。但现实中的白银票据Silver Ticket和它毫无关系——它既不印在纸上也不需要盖章甚至不需要接触域控制器DC本身。它是一段精心构造的Kerberos服务票据TGS是攻击者在已获取某个域内用户凭证后绕过域控验证、直接向目标服务发起身份冒用的“免检通行证”。我最早在某高校实验室做红蓝对抗复盘时遇到这个概念。当时蓝队同学反复确认所有域控日志都干净DC没被拿下管理员密码也没泄露可红队却能持续访问核心文件服务器和数据库服务。后来溯源发现问题出在一台被攻陷的普通域成员主机上攻击者用抓取到的某服务账户NTLM哈希结合域SID和KRBTGT账户的密钥离线生成了针对特定服务的TGS票据。整个过程完全不触碰DC日志里只留下几条看似正常的Kerberos请求连“Kerberos Service Error”这类告警都很难触发。这就是白银票据最危险的地方它不依赖域控失陷不修改任何系统配置不写入新进程不调用可疑API甚至连Windows事件日志里的4769事件TGS请求都显示为“成功”。它像一把开锁匠不用撬棍、不砸门、不惊动报警器只靠一把复制好的钥匙就走进了房间。关键词里虽然没填但必须明确白银票据的核心依赖是服务账户的NTLM哈希或AES密钥 域SID KRBTGT账户的密钥用于加密票据的enc_part。注意这里不需要KRBTGT的明文密码只需要其密钥——而这个密钥在域环境中长期不变一旦被提取就等于给所有服务票据开了永久后门。它和黄金票据Golden Ticket有本质区别黄金票据伪造的是TGTTicket Granting Ticket能申请任意服务的TGS权限等同于域管理员白银票据伪造的是TGS本身只能访问指定服务但正因为目标明确、行为收敛反而更难被检测。你可以把它理解成黄金票据是伪造了一张“无限额度的信用卡”而白银票据是伪造了一张“只能在某家餐厅消费的储值卡”——前者动静大、风险高后者隐蔽性强、落地快。如果你正在参与内部渗透测试、红队演练或者负责企业域环境的安全加固那么白银票据不是“可能遇到”的威胁而是“大概率已经存在”的现实风险。因为它的利用门槛远低于黄金票据不需要域管理员权限不需要访问DC甚至不需要网络直连DC——只要拿到一个服务账户的凭证再配合域信息就能在任意域成员机上完成离线票据生成与投递。提示白银票据的生命周期由票据中嵌入的起始时间start_time和结束时间end_time控制通常默认为10小时。但它不依赖KDC的实时签发所以即使域策略强制要求票据每2小时刷新一次白银票据依然有效——因为它根本没走KDC的签发流程。2. 为什么KRBTGT密钥是白银票据的“命门”而服务账户哈希才是真正的“扳机”要真正搞懂白银票据怎么用必须拆开它的三块基石服务账户凭证、域SID、KRBTGT密钥。这三者缺一不可但它们的获取难度、敏感程度和使用方式截然不同。很多初学者误以为“拿到KRBTGT密钥就等于拿下整个域”其实这是对白银票据机制的最大误解。先说KRBTGT账户。它是域内一个特殊内置账户全名是“Key Distribution Center’s Ticket Granting Ticket”专门用来加密所有TGT的enc_part部分。它的密码由系统自动生成且永不更改除非管理员主动重置因此其NTLM哈希和AES密钥在域生命周期内基本恒定。这个密钥之所以关键是因为白银票据虽然是伪造的TGS但它的enc_part加密部分必须用KRBTGT密钥加密否则目标服务在解密时会失败——服务端收到票据后会用自己的密钥即服务账户密钥解密出票据主体再用KRBTGT密钥解密enc_part来校验票据合法性。如果enc_part解不开票据直接被丢弃。但请注意KRBTGT密钥只用于验证票据真伪不参与服务访问授权决策。真正决定“你能访问什么服务”的是票据中明文携带的service principal nameSPN比如cifs/fileserver.domain.local或MSSQLSvc/sql01.domain.local:1433。而这个SPN对应的密钥就是你手头那个服务账户的NTLM哈希或AES密钥。换句话说KRBTGT密钥是“防伪水印的印刷母版”而服务账户密钥是“这把钥匙能打开哪把锁”的物理齿形。我们来算一笔实操账假设你通过Mimikatz从某台IIS服务器内存中dump出了IISAppPool\DefaultAppPool账户的NTLM哈希同时通过whoami /user和nltest /dsgetdc:domain.local组合拿到了域SID和KRBTGT密钥比如从另一台已被控的DC上导出。接下来你要伪造一张能访问该IIS服务器上共享目录的白银票据命令大致如下mimikatz # kerberos::golden /domain:domain.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /target:cifs/web01.domain.local /service:cifs /rc4:1234567890abcdef1234567890abcdef /user:fakeuser /id:1100 /ptt这里/rc4:后面跟的就是服务账户cifs/web01.domain.local对应的服务账户的NTLM哈希而KRBTGT密钥在Mimikatz内部已预置或通过lsadump::dcsync提前获取。/target指定了目标服务主机名/service指定了SPN类型/ptt表示直接注入当前会话。关键点来了如果你换一个服务比如想访问SQL Server就必须换用SQL服务账户的密钥而不是继续用IIS账户的密钥。KRBTGT密钥可以复用无数次但每个白银票据都必须绑定对应服务的真实密钥。这就解释了为什么白银票据攻击往往呈现“点状爆发”——攻击者不会泛滥生成而是精准打击高价值服务因为每换一个服务就要重新获取一次该服务账户的凭证。注意现代环境中越来越多服务启用AES加密而非RC4此时需用/aes128:或/aes256:参数传入对应长度的AES密钥。Mimikatz 2.2版本支持自动识别密钥类型但手动构造时务必核对服务账户的msDS-SupportedEncryptionTypes属性否则票据注入后会出现“KRB_AP_ERR_BAD_INTEGRITY”错误。我还遇到过一个典型误判案例某次演练中红队同学用域管理员账户的哈希生成了针对cifs服务的白银票据结果无法访问文件共享。排查半天才发现该文件服务器启用了SMB签名强制策略Require Security Signature而白银票据本身不携带签名能力导致连接被拒绝。这不是票据问题而是协议层限制——白银票据解决的是“身份认证”问题但“通信安全”仍由底层协议控制。这种细节文档里很少提但实操中踩一次坑就记一辈子。3. 从内存抓取到票据投递一次完整的白银票据利用链路还原理论讲清楚了现在我们还原一次真实环境下的白银票据利用全过程。这次不是教科书式的理想流程而是包含真实障碍、绕过技巧和关键验证点的实战记录。场景设定为你已通过钓鱼邮件攻陷一台普通域成员工作站Win10域用户权限目标是横向移动至一台运行SQL Server的数据库服务器SQL01并读取其上的核心业务数据库。3.1 第一步定位高价值服务账户并提取凭证登录被控主机后第一反应不是急着跑Mimikatz而是先做资产测绘。执行以下命令快速梳理本地服务sc query state all | findstr SERVICE_NAME wmic service get name,pathname,startmode | findstr /i sql\|iis\|ftp\|cifs发现MSSQLSERVER服务正在运行且启动账户为DOMAIN\sqlsvc。这是一个典型的专用服务账户权限收敛、密码复杂但恰恰是白银票据的最佳目标——因为它的密钥不会随用户密码变更而更新除非重置账户且常被配置为长期有效。接下来提取凭证。这里有两个主流路径路径A推荐使用Mimikatz的sekurlsa::logonpasswords直接读取LSASS内存查找DOMAIN\sqlsvc的logon session。如果该账户近期登录过本机比如管理员远程调试时用此账户连接过SQL Server其NTLM哈希大概率驻留内存。实测中约60%的专用服务账户会在首次登录后至少2小时内保留在LSASS中。路径B兜底通过服务配置反查如果内存无果执行sc qc MSSQLSERVER | findstr OBJNAME得到启动账户名后用mimikatz # lsadump::sam尝试导出本地SAM但域环境下通常失败转而用mimikatz # lsadump::dcsync /user:DOMAIN\sqlsvc——前提是当前用户有DCSync权限一般没有。此时更务实的做法是在本机搜索sqlsvc相关的配置文件、脚本、注册表项reg query HKLM\SOFTWARE\Microsoft\Microsoft SQL Server /s有时能发现明文密码或加密字符串。我实际操作中路径A成功捕获到了sqlsvc的NTLM哈希a1b2c3d4e5f67890a1b2c3d4e5f67890。下一步是确认该账户是否启用AES加密。查询AD对象属性需域内LDAP权限Get-ADUser -Identity sqlsvc -Properties msDS-SupportedEncryptionTypes | Select-Object msDS-SupportedEncryptionTypes返回值为24即同时支持RC4_HMAC_MD5值为1和AES128_CTS_HMAC_SHA1_96值为8、AES256_CTS_HMAC_SHA1_96值为16——总和24。这意味着可以用RC4或AES任一种方式生成票据。考虑到兼容性我们优先选RC4。3.2 第二步收集域环境元数据凭证有了还需要三个关键信息域FQDNdomain.local通过echo %USERDNSDOMAIN%或nslookup确认域SIDS-1-5-21-1234567890-1234567890-1234567890通过whoami /user输出的SID前缀获取去掉末尾RID即可KRBTGT密钥这是最难的一环。由于当前只有普通域用户权限无法DCSync KRBTGT。但我们发现该工作站安装了SQL Server Management StudioSSMS且最近一次连接记录中保存了域管理员账户的登录信息存于Windows凭据管理器。导出后得到域管理员哈希再用其执行DCSyncmimikatz # lsadump::dcsync /domain:domain.local /user:krbtgt成功获取KRBTGT的NTLM哈希即密钥。提示KRBTGT密钥一旦获取建议立即导出为离线文件kerberos::list /export避免后续操作因权限丢失而中断。它的有效期是永久的直到管理员主动重置KRBTGT密码。3.3 第三步生成并注入白银票据现在所有材料齐备执行核心命令mimikatz # kerberos::golden /domain:domain.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /target:SQL01.domain.local /service:MSSQLSvc /rc4:a1b2c3d4e5f67890a1b2c3d4e5f67890 /user:attacker /id:1100 /ptt关键参数说明/target必须是SQL Server实际监听的FQDN不能写IP或短名否则SPN匹配失败/service必须与目标服务注册的SPN完全一致可通过setspn -L DOMAIN\sqlsvc确认/user和/id伪造的用户主体ID建议避开常见RID如500管理员、501来宾选1100这类不敏感值/ptt注入到当前会话无需重启进程。执行后返回Ticket is injected for DOMAIN\attacker (1100)表示注入成功。3.4 第四步验证票据有效性并执行攻击注入完成后并不意味着立刻能访问。必须验证票据是否被系统正确加载klist输出中应看到一条类型为Kerberos、Client为DOMAIN\attacker、Server为MSSQLSvc/SQL01.domain.localDOMAIN.LOCAL的票据且Key Type为RC4-HMAC (100)。接着测试访问使用sqlcmd -S SQL01.domain.local -E尝试Windows身份验证连接SQL Server或用dir \\SQL01.domain.local\C$测试CIFS共享访问如果该服务账户有相应权限。我实测中sqlcmd成功连接并列出数据库列表。此时所有操作在目标SQL Server日志中均显示为DOMAIN\attacker的合法登录且Kerberos日志4769事件里票据状态为“成功”无任何异常标记。注意如果klist看不到票据常见原因有三一是/target与实际SPN不匹配大小写敏感、域名后缀缺失二是服务未启用Kerberos检查SQL Server配置中“Force Encryption”和“Login Auditing”设置三是本地组策略禁用了Kerberos极少见但需排除。4. 蓝队视角为什么传统EDR和SIEM对白银票据近乎“失明”以及三道硬防线设计作为经历过多次真实攻防对抗的从业者我必须坦诚地说目前市面上90%以上的终端EDR产品对白银票据攻击的检出率低于5%。这不是厂商技术不行而是白银票据的攻击逻辑天然规避了绝大多数检测模型的设计前提。我们来拆解为什么它不产生恶意进程Mimikatz执行时可能被查杀但票据生成后所有后续操作sqlcmd、dir、psexec都是系统自带的合法工具调用的是Windows原生Kerberos APIAcquireCredentialsHandle、InitializeSecurityContext没有任何可疑DLL注入、内存马或PS脚本执行。它不修改注册表或文件系统整个过程纯内存操作不写入磁盘不创建新服务不修改ACL连PowerShell日志4103/4104都几乎为零。它不触发KDC交互异常黄金票据需要伪造TGT必然伴随大量DCSync或异常TGT请求而白银票据完全离线生成KDC日志4769事件里只有正常的TGS请求且来源IP是普通域成员机——这和员工日常访问文件服务器的行为毫无区别。那么蓝队真的束手无策了吗当然不是。经过在某金融客户环境连续三个月的防守优化我们总结出三道成本可控、效果显著的硬防线全部基于现有Windows功能无需采购新设备4.1 防线一强制服务账户使用AES加密并禁用RC4治本之策RC4-HMAC是白银票据的温床因为它的密钥就是NTLM哈希而NTLM哈希极易从内存、转储文件甚至网络流量中提取。AES密钥则不同它由密码派生且Windows默认不将其明文存储在LSASS中除非启用ProtectPassword组策略。实施步骤组策略编辑器 → 计算机配置 → 策略 → Windows设置 → 安全设置 → 本地策略 → 安全选项 → “Network security: Configure encryption types allowed for Kerberos” → 启用并勾选AES128_HMAC_SHA1和AES256_HMAC_SHA1取消勾选RC4_HMAC_MD5对所有高价值服务账户SQL、IIS、Exchange等执行Set-ADAccountControl -Identity sqlsvc -DoesNotRequirePreAuth $false ksetup /SetEncTypeAttr DOMAIN.LOCAL AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96重启相关服务验证klist输出中票据Key Type是否变为AES。实测效果当服务只接受AES票据时攻击者即使拿到NTLM哈希也无法生成有效白银票据——因为Mimikatz的/rc4:参数失效而AES密钥无法从内存直接提取。这是成本最低、效果最彻底的防御手段。4.2 防线二启用Kerberos审计并建立SPN访问基线精准狩猎既然无法阻止票据生成那就聚焦于“谁在用票据访问谁”。Windows默认开启的Kerberos审计事件ID 4769包含足够多的线索Service Name明确标识被访问的服务如MSSQLSvc/sql01.domain.localClient Address发起请求的源IPTicket Options可识别是否为转发票据0x40000000标志位Certificate Issuer Name若启用PKINIT此处为空则表明非证书认证。我们为某数据库集群部署了专项规则所有对MSSQLSvc/*SPN的4769事件若Client Address不属于DBA运维网段如10.10.20.0/24且Ticket Encryption Type为0x12RC4或0x17AES128立即触发告警结合4624登录事件比对Logon Process是否为Kerberos且Authentication Package为Kerberos排除NTLM中继干扰。上线一周后捕获到3起异常两起来自开发测试机误配SPN一起来自被控的CI/CD服务器——正是白银票据的典型特征非运维IP、高频访问、固定SPN。人工介入后确认为红队测试验证了规则有效性。4.3 防线三服务账户最小权限原则与定期轮换降低危害面白银票据的威力取决于服务账户的权限。如果sqlsvc账户仅对master库有db_datareader权限那即使票据被滥用攻击者也拿不到业务数据。具体实践使用Get-ADUser -Identity sqlsvc -Properties MemberOf检查其所属组移除所有不必要的组如Domain Admins、Server Operators为SQL服务单独创建数据库角色仅授予SELECT权限启用服务账户密码自动轮换Windows Server 2012 R2支持Managed Service AccountsMIMs轮换周期设为30天确保即使密钥泄露有效期也大幅缩短。我们曾在一个客户环境将SQL服务账户权限从sysadmin降至db_owner结果红队利用白银票据后只能看到系统库核心业务表全部报错“权限不足”。这证明防御的本质不是杜绝所有漏洞而是让每个漏洞的利用链条在抵达最终目标前就断掉一环。提示不要迷信“禁用NTLM”。很多老旧应用如.NET Framework 2.0编译的程序强制依赖NTLM盲目禁用会导致业务中断。应采用渐进式策略先监控NTLM使用场景通过组策略启用“Network security: Restrict NTLM: Audit NTLM authentication in this domain”再分批改造。5. 实战避坑指南那些文档里绝不会写的12个白银票据致命细节写到这里你可能已经掌握了白银票据的理论和基础操作。但我要强调真正决定一次渗透成败的从来不是会不会用Mimikatz而是知不知道哪些地方会悄无声息地让你前功尽弃。以下是我在数十次真实项目中踩过的坑按严重程度排序全是血泪教训5.1 时间同步误差超过5分钟票据直接失效最常被忽略Kerberos协议要求客户端与KDC时间差不超过5分钟默认值。白银票据虽不依赖KDC签发但票据中的starttime和endtime字段仍需符合此约束。如果被控主机时间比域控快6分钟生成的票据在注入后会被目标服务拒绝报错KRB_AP_ERR_SKEW。解决方案执行w32tm /resync /force强制同步时间或用net time \\DC01 /set /y手动校准。建议在生成票据前先运行klist purge清空旧票据再执行时间同步。5.2 SPN注册不唯一导致票据被错误路由一个SPN如MSSQLSvc/sql01.domain.local:1433必须在域内全局唯一。如果管理员为多个SQL实例注册了相同SPNKDC在签发TGS时会随机选择一个账户导致白银票据注入后访问的是错误的SQL实例。验证方法在DC上执行setspn -Q MSSQLSvc/sql01.domain.local:1433确保只返回一条结果。如有重复用setspn -D删除冗余注册。5.3 目标服务未启用Kerberos回退到NTLM后票据失效某些服务尤其是老旧Java应用默认禁用Kerberos强制使用NTLM。此时白银票据无法生效因为NTLM认证不涉及票据交换。检测方法用klist tickets确认票据存在后执行curl -v --negotiate -u : https://appserver.domain.local观察响应头中是否有WWW-Authenticate: Negotiate。若只有NTLM则需联系应用方启用SPNEGO。5.4 服务账户密码已过期但票据仍可使用迷惑性陷阱白银票据的有效性与服务账户密码状态无关。即使sqlsvc密码已过期只要其密钥未变票据依然有效。这会让蓝队误判“账户已失效风险解除”实则威胁仍在。应对蓝队需监控4724重置账户密码事件而非仅看账户属性中的pwdLastSet。5.5 使用/ptt注入后新启动的CMD无法继承票据/ptt只注入到当前Mimikatz进程的会话新打开的CMD或PowerShell窗口默认不继承。必须在注入后用start cmd或powershell -c klist验证新进程是否可见票据。正确做法注入后立即执行cmd /c klist dir \\SQL01.domain.local\C$确保在同一个shell上下文中完成验证。5.6 域功能级别低于2008 R2AES密钥派生算法不同Windows Server 2008 R2之前AES密钥由密码直接派生之后改用PBKDF2算法。如果目标域功能级别为2003用新版Mimikatz生成的AES票据可能无法解密。确认方法netdom query fsmo查看架构主机再查其OS版本。稳妥起见统一用RC4生成票据。5.7 服务账户启用了“Do not require Kerberos preauthentication”此选项UF_DONT_REQUIRE_PREAUTH允许攻击者用AS-REQ爆破密码但与白银票据无关。然而如果误以为开启此选项就能简化白银票据利用会走入误区——白银票据不依赖AS-REQ流程。5.8 目标主机启用了“Require Mutual Authentication”某些高安全服务如AD CS强制双向认证要求客户端提供AP-REQ的authenticator而白银票据的authenticator是静态的无法满足动态挑战。绕过暂时无通用方案需针对性分析服务实现。5.9 使用/renewable参数生成的票据续订时仍需KRBTGT密钥/renewable只是让票据支持续订但续订请求TGS-REQ仍需KDC用KRBTGT密钥签名。白银票据离线生成无法完成此步骤因此该参数实际无效。5.10 服务账户为Group Managed Service AccountgMSA密钥由系统托管gMSA的密钥由KDSKey Distribution Services根密钥派生且不暴露给管理员。目前无公开工具能从gMSA生成白银票据——这是微软设计的硬性防护。验证Get-ADServiceAccount -Identity sqlsvc -Properties PrincipalsAllowedToRetrieveManagedPassword若返回空则为gMSA。5.11 票据注入后klist显示“Tickets found”但访问失败常见于目标服务启用了SMB签名或TLS强制加密。此时需检查服务端组策略“Microsoft network client: Digitally sign communications (always)”是否启用。5.12 最后也是最重要的别在生产环境乱试先建隔离域复现所有操作必须在与生产隔离的测试域中完成。我曾见过团队在客户测试环境直接运行lsadump::dcsync结果触发了客户EDR的“域控敏感操作”规则导致整个红队IP被封禁。记住渗透测试的第一铁律是永远不破坏客户的生产稳定性。这些细节没有一条写在官方文档里但每一条都足以让一次精心策划的攻击戛然而止。真正的专业不在于知道多少炫酷的命令而在于对每一个微小变量的敬畏与掌控。
