企业官网建设流程全解析

1. 从一张“通行证”说起：Windows认证体系里的白银票据到底是什么

在Windows域环境里摸爬滚打过的朋友，大概率都听过“黄金票据”和“白银票据”这两个词。名字听起来挺唬人，其实它们描述的是同一类事情：攻击者伪造了一张身份凭证，让目标机器误以为自己是合法用户。区别在于伪造的对象不同——黄金票据伪造的是域控级别的凭证，而白银票据伪造的是针对某台具体服务的服务票据。

这篇文章我想把白银票据这件事讲透。它涉及的核心技术点包括：Kerberos认证流程、服务票据（Service Ticket）的构造方式、机器账户密钥的获取途径、以及为什么白银票据能绕过域控直接访问目标服务。适合谁看？如果你在做内网安全评估、域环境渗透测试，或者单纯想搞明白Windows认证体系里这块“灰色地带”的运作逻辑，那这篇内容应该能给你不少参考。

先给一个最直白的类比。Kerberos认证就像去一家大型游乐场：你先进大门（域控认证），拿到一张通票（TGT），然后想去哪个项目玩，就用通票换那个项目的单次票（服务票据）。黄金票据相当于你伪造了大门发的通票，而白银票据则是你直接伪造了某个游乐项目的单次票，连大门都不用经过。这就是白银票据最核心的特点：它不需要和域控交互，直接拿伪造的服务票据去访问目标服务。

这个特性决定了白银票据的适用场景和局限性。它不能用来访问所有服务，只能访问那些使用特定机器账户密钥加密服务票据的服务。常见的比如文件共享（CIFS）、SQL Server、HTTP服务等。而且伪造白银票据需要拿到目标机器账户的NTLM哈希——这通常意味着你已经在某台机器上拿到了本地管理员权限，或者通过其他方式提取到了机器账户的凭证。

注意：本文所有内容仅用于授权的安全评估场景。未经授权对他人系统进行测试属于违法行为，请务必在合法合规的前提下使用相关技术。

2. 白银票据背后的认证逻辑：为什么它能绕过域控

2.1 Kerberos认证流程的简化拆解

要理解白银票据，得先把Kerberos的基本流程捋清楚。整个流程可以拆成三个阶段：

第一阶段是AS交换（Authentication Service Exchange）。客户端向域控的KDC（Key Distribution Center）发送自己的身份信息，KDC验证通过后返回一张TGT（Ticket Granting Ticket）。这张TGT是用域控的krbtgt账户哈希加密的，客户端无法解密，只能原样保存。

第二阶段是TGS交换（Ticket Granting Service Exchange）。客户端需要访问某个服务时，拿着TGT向KDC请求该服务的服务票据。KDC验证TGT有效后，用目标服务所属机器账户的哈希加密一张服务票据返回给客户端。

第三阶段是AP交换（Application Exchange）。客户端拿着服务票据去访问目标服务，目标服务用自己的机器账户哈希解密票据，验证其中的用户身份和权限信息，然后决定是否提供服务。

白银票据的攻击点就在第二阶段和第三阶段之间。攻击者如果拿到了目标机器账户的哈希，就可以直接跳到第三阶段——自己伪造一张服务票据，用机器账户哈希加密，然后直接发给目标服务。目标服务解密后发现票据“合法”，就提供了服务。整个过程完全不需要域控参与。

2.2 为什么机器账户哈希是关键

这里有个核心问题：为什么伪造白银票据需要机器账户哈希，而不是用户哈希？

原因在于Kerberos的设计逻辑。服务票据是用目标服务所在机器的账户密钥加密的，这样只有目标机器能解密并验证票据。域控在签发服务票据时，用的就是目标机器账户的哈希。所以攻击者要伪造服务票据，也必须用同样的哈希来加密，否则目标机器解密会失败。

机器账户哈希的获取途径通常有几种：一是直接在目标机器上提取本地SAM数据库中的机器账户凭证；二是通过域内信息收集找到机器账户的哈希；三是在某些配置不当的环境中，普通用户就能读取机器账户的密码信息。拿到哈希之后，攻击者就可以离线构造服务票据，完全不接触域控。

2.3 白银票据与黄金票据的核心差异

很多人容易把白银票据和黄金票据搞混，这里用一张表把关键差异列清楚：

从表中可以看出，白银票据的权限范围更窄，但获取门槛也相对更低。在实际评估中，白银票据往往是在已经拿下某台机器后，用来横向移动到特定服务的手段。

3. 实操环境搭建与核心工具选型

3.1 实验环境的合理搭建

要复现白银票据的完整流程，需要一个最小化的域环境。我建议的配置是：

• 一台域控服务器（Windows Server 2016或2019），充当KDC角色
• 一台成员服务器（Windows Server 2016或2019），加入域，提供文件共享或SQL Server服务
• 一台攻击机（Kali Linux或Windows），用于执行票据伪造和访问测试

域功能级别建议设置为Windows Server 2016，这样既支持现代Kerberos特性，又不会引入过于复杂的约束。成员服务器上需要启用文件共享服务，并配置一个测试共享目录，方便验证白银票据的访问效果。

网络配置上，三台机器需要在同一网段，DNS指向域控。成员服务器的机器账户密码会自动轮换，默认周期是30天，这个在后续测试中需要注意。

3.2 核心工具的选择与理由

在Windows域安全评估中，常用的工具组合是Mimikatz加PsExec。Mimikatz负责提取哈希和构造票据，PsExec负责远程执行和验证访问。

Mimikatz的选择理由很直接：它内置了kerberos::golden命令，可以通过/silver参数直接生成白银票据，支持指定域、用户、目标服务、机器账户哈希等参数。而且它能在内存中注入票据，不需要落地文件，隐蔽性较好。

PsExec的选择理由也很实际：它可以通过SMB协议连接到目标机器，正好用来验证CIFS服务的白银票据是否生效。如果票据构造正确，PsExec应该能直接建立连接并执行命令，而不需要输入任何密码。

实操心得：Mimikatz的版本选择很重要。建议使用较新的2.2.0以上版本，旧版本在Windows Server 2016+环境中可能存在兼容性问题。另外，Mimikatz的kerberos::golden命令虽然名字叫golden，但通过/silver参数就能生成白银票据，这个命名容易让人困惑，但用起来没问题。

3.3 前置信息收集清单

在构造白银票据之前，需要收集以下信息：

• 目标服务的SPN（Service Principal Name），比如cifs/目标机器名.域名
• 目标机器账户的NTLM哈希
• 域名和域控的FQDN
• 一个存在的域用户名（用于票据中的身份字段）
• 目标机器的SID（可选，但某些场景下需要）

这些信息中，机器账户哈希是最关键的。获取方式通常是在已经拿到目标机器本地管理员权限后，通过Mimikatz的sekurlsa::logonpasswords或lsadump::sam命令提取。如果目标机器是域控，还可以通过lsadump::dcsync获取。

4. 白银票据的完整构造与访问流程

4.1 提取目标机器账户哈希

假设我们已经通过某种方式拿到了目标成员服务器的本地管理员权限。在目标机器上以管理员身份运行Mimikatz，执行以下命令：

privilege::debug sekurlsa::logonpasswords

在输出中查找机器账户对应的条目。机器账户的格式通常是机器名$，比如FILESERVER$。找到后记录其NTLM哈希。

如果sekurlsa::logonpasswords没有显示机器账户哈希，可以尝试：

lsadump::sam

这个命令会导出本地SAM数据库中的账户哈希，包括机器账户。注意，机器账户的哈希在SAM中是以加密形式存储的，Mimikatz会自动解密。

注意事项：在某些Windows版本中，机器账户哈希可能不会直接显示在sekurlsa::logonpasswords的输出中。这时候可以尝试sekurlsa::msv命令，专门提取MSV认证相关的凭证。如果还是不行，可能需要检查是否启用了Credential Guard等保护机制。

4.2 构造白银票据的核心参数

拿到机器账户哈希后，就可以在攻击机上构造白银票据了。Mimikatz的命令格式如下：

kerberos::golden /user:Administrator /domain:example.com /sid:S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx /target:fileserver.example.com /service:cifs /rc4:机器账户NTLM哈希 /ptt

逐个参数解释：

• /user：指定票据中伪造的用户名。可以是任意存在的域用户，甚至是不存在的用户，但建议使用一个真实存在的域管理员账户，这样权限更高。
• /domain：目标域名，必须是FQDN格式。
• /sid：域的SID。这个可以通过whoami /user在域内机器上获取，或者通过lsadump::lsa /patch在域控上提取。
• /target：目标服务的FQDN，比如fileserver.example.com。
• /service：服务类型，CIFS对应文件共享，MSSQL对应SQL Server，HTTP对应Web服务。
• /rc4：目标机器账户的NTLM哈希。
• /ptt：表示直接将票据注入当前会话，不需要额外导入。

执行成功后，Mimikatz会输出票据的详细信息，包括票据的有效期、加密类型等。默认情况下，白银票据的有效期是10年，这个可以通过/endin参数调整。

4.3 验证票据是否生效

票据注入后，可以通过以下方式验证：

klist

这个命令会列出当前会话中的所有Kerberos票据。如果看到新注入的服务票据，说明注入成功。

然后尝试访问目标服务：

dir \\fileserver.example.com\c$

如果白银票据构造正确，应该能直接列出目标机器的C盘内容，而不需要输入任何凭证。这是因为目标服务解密票据后，认为我们是合法的域管理员。

如果dir命令失败，可以尝试用PsExec：

PsExec.exe \\fileserver.example.com cmd.exe

如果成功，会直接获得一个远程shell。

实操心得：白银票据生效的前提是目标服务的SPN与票据中的/service参数匹配。比如访问文件共享必须用cifs，访问SQL Server必须用MSSQLSvc。如果服务类型写错，目标服务会拒绝解密票据。另外，某些服务可能配置了额外的验证机制，比如SMB签名，这时候白银票据可能无法直接生效，需要额外处理。

4.4 票据的有效期与续期问题

白银票据默认有效期是10年，但这并不意味着它可以一直使用。实际影响票据有效性的因素有两个：

一是机器账户密码轮换。域内机器账户密码默认每30天自动更换一次。一旦密码更换，之前用旧哈希构造的白银票据就会失效，因为目标服务解密票据时用的是新密码派生的密钥。

二是票据缓存清理。注入的票据存在于当前会话的内存中，如果会话结束或系统重启，票据就会丢失，需要重新注入。

所以白银票据更适合作为短期横向移动手段，而不是长期持久化后门。如果需要长期访问，可以考虑在目标机器上建立其他形式的持久化机制。

5. 常见问题排查与避坑指南

5.1 票据注入失败的可能原因

问题一：klist看不到注入的票据。

这种情况通常是权限不足导致的。Mimikatz注入票据需要管理员权限，如果当前会话不是管理员，注入会静默失败。解决方法是先提升到管理员权限，再执行/ptt。

问题二：票据注入成功但访问被拒绝。

可能的原因有几个：一是服务类型写错，比如把cifs写成了smb；二是目标机器的SPN与票据中的/target不匹配；三是目标服务启用了SMB签名或扩展保护，导致伪造的票据被拒绝。

排查方法是先用setspn -L 机器名确认目标机器的SPN，然后检查票据参数是否一致。如果目标服务启用了SMB签名，可以尝试用其他协议访问，比如winrm或rpc。

问题三：Mimikatz报错“ERROR kuhl_m_kerberos_golden ; LsaCallAuthenticationPackage failed”。

这个错误通常是因为当前会话中已经存在同类型的票据，导致冲突。解决方法是先用klist purge清理所有票据，然后重新注入。

5.2 机器账户哈希获取失败的场景

在某些环境中，sekurlsa::logonpasswords可能无法提取机器账户哈希。常见原因包括：

• 目标机器启用了Credential Guard，阻止了LSASS内存读取
• 目标机器是只读域控（RODC），机器账户哈希不在本地
• 当前会话不是高完整性级别，无法访问LSASS

针对这些情况，可以尝试的替代方案包括：使用lsadump::sam直接从SAM数据库提取；通过DCSync从域控同步机器账户哈希；或者在目标机器上使用其他凭证提取工具。

避坑技巧：如果目标机器是Windows Server 2019或更高版本，Credential Guard可能默认启用。这时候可以检查注册表HKLM\SYSTEM\CurrentControlSet\Control\Lsa下的LsaCfgFlags值，如果为1或2，说明Credential Guard已启用。这种情况下，内存提取会失败，需要考虑其他途径。

5.3 白银票据的检测与防御视角

从防御角度看，白银票据的检测有几个切入点：

一是异常的服务票据请求。正常流程中，服务票据是由域控签发的，会记录在域控的4769事件中。如果某台机器直接收到了服务票据但没有对应的TGS请求记录，就可能是伪造的。

二是票据加密类型异常。白银票据通常使用RC4加密，而现代域环境可能默认使用AES。如果发现大量RC4加密的服务票据，值得警惕。

三是机器账户密码轮换后的访问失败。如果某台机器在密码轮换后仍然收到用旧哈希加密的票据，说明存在伪造行为。

防御措施方面，可以启用SMB签名、强制使用AES加密、缩短机器账户密码轮换周期、监控异常的Kerberos事件等。

5.4 常见问题速查表

6. 白银票据在实际评估中的定位与延伸思考

6.1 适用场景与局限性

白银票据在实际安全评估中的定位很明确：它是横向移动阶段的一把利器，但不是万能钥匙。适用场景包括：

• 已经拿到某台机器的本地管理员权限，需要横向移动到文件服务器
• 需要访问特定SQL Server实例，但不想触发域控的认证日志
• 在域控不可达或认证受限的环境中，需要直接访问目标服务

局限性也很明显：只能访问特定服务，不能获取域管理员权限，受机器账户密码轮换影响，对启用了强验证机制的服务无效。

6.2 与其他横向移动手段的对比

在域环境横向移动中，白银票据只是众多手段之一。与Pass-the-Hash、Pass-the-Ticket、Overpass-the-Hash等技术相比，白银票据的优势在于不需要与域控交互，隐蔽性较好。但劣势是需要提前获取机器账户哈希，且权限范围有限。

实际评估中，通常会根据目标环境和已有权限选择最合适的手段。如果已经拿到了域管理员权限，黄金票据可能更直接；如果只是拿到了某台机器的本地管理员，白银票据则是更现实的选择。

6.3 机器账户密码轮换的影响与应对

机器账户密码轮换是白银票据最大的“天敌”。默认30天的轮换周期意味着伪造的票据最多只能用30天。在某些环境中，管理员可能缩短了轮换周期，进一步压缩了票据的有效窗口。

应对方式有两种：一是在轮换前完成横向移动，二是想办法获取新的机器账户哈希。后者通常需要重新在目标机器上提取凭证，或者通过域控同步获取最新哈希。

从防御角度，缩短机器账户密码轮换周期、启用Credential Guard、强制SMB签名，都能有效增加白银票据的攻击难度。

6.4 个人实操体会

我在实际测试中踩过几次坑，这里分享两个印象比较深的：

第一次是服务类型写错。当时目标机器提供的是SQL Server服务，我习惯性地用了cifs，结果票据注入成功但访问一直被拒。后来用setspn -L查了一下，发现SPN是MSSQLSvc/sqlserver.example.com:1433，改成MSSQLSvc后才成功。

第二次是忽略了SMB签名。目标文件服务器启用了SMB签名，白银票据注入后dir命令一直报错。后来改用winrs通过WinRM访问，才绕过了签名限制。这个经历让我意识到，白银票据的成败不仅取决于票据本身，还取决于目标服务的配置。

还有一个细节：Mimikatz的/ptt参数在某些Windows版本中可能不生效，这时候可以先用/out参数把票据导出为.kirbi文件，然后用kerberos::ptt 文件路径手动注入。这个方式更可控，也方便排查问题。

最后再分享一个小技巧：如果目标环境中有多台机器使用相同的本地管理员密码（比如通过组策略统一部署），那么在一台机器上提取的机器账户哈希可能在其他机器上也能用。这种情况下，白银票据的适用范围会大大扩展。当然，这也提醒防御方，为每台机器设置独立的本地管理员密码是很有必要的。