1. 项目缘起从“ZQH”这个神秘代号说起最近在整理ADActive Directory域环境的学习笔记时翻到了一个被我标记为“ZQH”的文件夹。这个代号看起来有点无厘头像是随手打的几个字母。但对我而言它代表了一段非常具体且深刻的实战经历——一次关于域内权限持久化与横向移动的深度探索。当时我正试图理解攻击者在获取初始立足点后如何像幽灵一样在域内“扎根”并悄无声息地扩散。ZQH其实就是我为了记录这个探索过程而随手敲下的一个项目代号它背后关联的核心技术是黄金票据Golden Ticket和白银票据Silver Ticket的攻防对抗。很多刚接触域安全的朋友可能对Kerberos协议、票据这些概念感到头疼更别提区分这两种“票据”了。网上资料要么过于学术化满篇的KRB_AS_REQ、PAC让人望而生畏要么就是简单的工具使用命令知其然不知其所以然。我当时就卡在这个地方我能用Mimikatz打出命令看到屏幕上刷出一串票据但完全不明白这串字符到底意味着什么它在域里是怎么流转的防守方又该如何精准地发现它。这次“ZQH”项目就是我用接近两周的时间自己搭建实验环境从协议原理开始抠再到动手复现攻击最后部署检测策略把这条链路彻底跑通的一次完整实践。所以这篇笔记不是一份标准的教材而是一个域安全初学者的“破局”实录。我会带你回到我当时那个“一脸懵”的状态然后一步步拆解我们到底要弄明白什么以及我是怎么通过动手实验把这些抽象概念变成肌肉记忆的。如果你也对域内那些“高级”攻击手法感到好奇又畏惧或者你是一名蓝队成员想知道攻击者留下的那些“票据”痕迹到底藏在哪里那么这篇笔记或许能给你提供一个清晰的、可复现的路径。2. 实验环境搭建构建一个“麻雀虽小五脏俱全”的微缩靶场纸上谈兵永远不如真枪实弹。要理解黄金票据和白银票据你必须有一个可以随意“折腾”的Active Directory环境。我的选择是在本地用VMware搭建一个最简单的域环境这比在云上或者物理机上操作要方便和安全得多毕竟我们要模拟的是攻击行为。2.1 虚拟机规划与系统准备我用了三台虚拟机这个配置足以演示核心流程域控制器 (DC)一台Windows Server 2019主机名DC01IP192.168.1.10。它同时承担了DNS服务器的角色。安装系统后通过服务器管理器添加“Active Directory 域服务”角色并将其提升为全新林的域控制器我创建的域是lab.local。成员服务器 (Member Server)一台Windows Server 2019主机名SRV01IP192.168.1.20。这台机器用来模拟域内的一台重要服务器比如文件服务器或Web服务器。我将它加入到lab.local域。客户端/攻击机 (Client)一台Windows 10专业版主机名WIN10-CLIENTIP192.168.1.30。它也加入到域中模拟一个已被攻击者初步控制的普通用户工作站。同时我会在这台机器上安装攻击工具如Mimikatz。注意在提升为域控制器和加域的过程中务必为每台机器设置一个复杂且你记得住的本地管理员密码因为一旦成为域控或加入域本地管理员账户如.\Administrator的密码可能会与域管理员账户如LAB\Administrator分离。我在这里踩过坑一度因为密码混淆导致无法登录。2.2 关键账户与服务的创建一个“死”的环境是看不出效果的。为了让攻击演示更真实我特意创建了一些具有代表性的账户和服务特权账户在域控制器上我创建了一个名为sqladmin的域用户并将其加入到Domain Admins组。这个账户将作为我们后续提取Kerberos密钥KRBTGT Hash的“高价值目标”。服务账户在成员服务器SRV01上我创建了一个名为MSSQL_SVC的域用户专门用于运行一个模拟的“SQL Server”服务。服务主体名称SPN是Kerberos认证的核心我使用命令行为其注册SPNsetspn -S MSSQLSvc/SRV01.lab.local:1433 LAB\MSSQL_SVC这个操作意味着域内任何用户如果想通过Kerberos协议访问SRV01上的“SQL服务”都需要向MSSQL_SVC这个账户申请票据。共享资源在SRV01上我创建了一个名为Confidential的文件夹设置共享权限和NTFS权限只允许LAB\MSSQL_SVC账户和Domain Admins组有完全控制权。普通域用户如我创建的labuser是无法访问的。这为我们后续测试白银票据的访问能力创造了条件。环境搭好之后我首先从客户端 (WIN10-CLIENT) 用普通域用户labuser登录尝试访问\\SRV01\Confidential果然被拒绝访问。一切准备就绪攻击模拟可以开始了。3. 攻击链第一步理解Kerberos与票据的基础在直接操作Mimikatz之前我强迫自己先画了几遍Kerberos认证的简化流程图。你必须明白正常流程是怎样的才能理解攻击是如何扭曲这个流程的。这里我尽量用人话解释想象一下你要进入一个有多道门禁的公司域。你有员工卡用户名/密码。第一关认证服务器 (AS)你向第一道门禁AS出示工牌和密码。门禁验证后不直接给你开所有门的权限而是给你一张TGT (Ticket Granting Ticket)。这张TGT是用公司万能门禁卡KRBTGT账户的密钥加密的你自己打不开但证明了你是合法员工。第二关票据授予服务器 (TGS)你想进入研发部的服务器机房某个具体服务。你拿着TGT到第二道门禁TGS说“我要进机房。” TGS验证你的TGT有效后会给你一张ST (Service Ticket)。这张ST是用机房管理员服务账户的密钥加密的上面写着你的身份和权限。进入机房你拿着ST来到机房门口门禁系统服务端用自己的密钥解密ST确认无误后就让你进去了。关键点来了TGT由KRBTGT的密钥加密。谁有KRBTGT的密码哈希Hash谁就能伪造TGT。ST由目标服务账户的密钥加密。谁有服务账户的密码哈希谁就能伪造访问该服务的ST。你的权限信息比如你是不是管理员是放在ST里的一个叫PAC (Privilege Attribute Certificate)的结构里的。黄金票据攻击针对的是第一步攻击者想办法拿到了公司万能门禁卡KRBTGT Hash然后自己随便印TGT想去哪就去哪。白银票据攻击针对的是第三步攻击者拿到了某个机房管理员的密钥服务账户Hash然后自己伪造进入那个机房的ST但这个过程不经过公司中央门禁TGS检查。4. 攻击链第二步获取关键的“原料”——哈希值无论是黄金还是白银票据伪造的前提都是拿到对应的加密密钥也就是NTLM Hash或者AES Key。在现实中攻击者可能通过漏洞利用、密码喷洒、哈希传递等多种方式获取。在我们的实验里我们模拟一种常见场景攻击者已经获得了域内一台机器的本地管理员权限。4.1 提取本地账户与域账户哈希在客户端WIN10-CLIENT上我以本地管理员身份运行Mimikatz。首先提取本机哈希privilege::debug sekurlsa::logonpasswords这个命令会输出当前内存中所有登录会话的凭证信息包括本地账户和最近在此机器上登录过的域账户的NTLM Hash。如果那个高权限域用户sqladmin曾经在这台电脑上登录过他的哈希就可能在这里被捕获。这是一种非常经典的“抓哈希”操作。4.2 提取域控上的KRBTGT账户哈希——黄金票据的钥匙这是黄金票据攻击中最关键、也最困难的一步。因为KRBTGT账户的哈希只存在于域控制器上。我模拟了两种攻击路径域控内存提取如果攻击者通过某种手段比如利用Print Spooler服务漏洞在域控上执行了代码他可以直接在域控上运行Mimikatz用同样的sekurlsa::logonpasswords命令抓取内存KRBTGT的哈希就在其中。卷影复制与DCSync更隐蔽的方式是使用DCSync攻击。这需要攻击者拥有的账户具备复制域目录数据的权限如Domain Admins组权限。假设我们已经控制了sqladmin账户可以在非域控的机器上用Mimikatz模拟域控的复制行为lsadump::dcsync /domain:lab.local /user:krbtgt这个命令会直接让域控制器将KRBTGT账户的凭据哈希发送过来。输出中会包含两个重要的NTLM Hash我们通常使用“AES256”或“NTLM”那个值。请务必记录下这个哈希值、域的SIDSecurity Identifier以及KRBTGT账户的RID通常是502。4.3 提取服务账户哈希——白银票据的钥匙对于白银票据我们需要目标服务账户的哈希。比如我们要伪造访问SRV01上SQL服务的票据就需要MSSQL_SVC账户的哈希。 同样如果该账户在已被我们控制的WIN10-CLIENT上运行过服务或登录过我们可以从内存中抓取。如果没有并且我们获得了足够高的权限如Domain Admins我们也可以使用DCSync来获取lsadump::dcsync /domain:lab.local /user:MSSQL_SVC记下这个账户的NTLM Hash。5. 攻击链第三步伪造票据与效果验证拿到了“原料”就可以开始“铸造”了。这个阶段我强烈建议你打开Wireshark在域内任意一台机器上抓包过滤kerberos协议直观地看票据的请求和响应过程感受“伪造”与“正常”在流量上的区别。5.1 伪造黄金票据 (Golden Ticket)在WIN10-CLIENT上我们当前可能只是一个普通用户labuser。现在我们使用Mimikatz利用之前获取的KRBTGT Hash为自己伪造一张属于任意用户的TGT。这里我直接伪造一个域管理员的TGTkerberos::golden /user:Administrator /domain:lab.local /sid:S-1-5-21-...你的域SID /krbtgt:KRBTGT的NTLM Hash /id:500 /ptt参数解释/user 你想冒充的用户这里用Administrator。/domain 域名。/sid 域的SID去掉末尾的RID部分。/krbtgt KRBTGT账户的NTLM Hash。/id 用户的RID500代表管理员。/ptt “Pass The Ticket”直接将伪造的票据注入到当前会话的内存中。执行成功后Mimikatz会提示“Golden ticket for ‘Administrator lab.local’ successfully submitted for current session”。此时神奇的事情发生了。我们打开一个新的命令行窗口注意需要新开一个因为票据注入到了当前会话尝试访问之前拒绝我们访问的\\SRV01\Confidential共享。访问成功了我们甚至可以用dir \\dc01\c$这样的命令直接列出域控制器C盘的内容。这一切都不需要知道域管理员Administrator的密码是什么因为我们伪造的TGT让KDC域控完全信任我们就是管理员。黄金票据的威力在于它赋予了你在整个域内、对所有服务、持续很长时间默认10年的完全访问权限而且不需要与KDC进行任何进一步的交互。5.2 伪造白银票据 (Silver Ticket)现在我们清除掉内存中的黄金票据或者重启机器回到普通用户labuser的状态。我们尝试伪造一张只针对特定服务SRV01的MSSQL服务的白银票据。kerberos::golden /user:LABUSER /domain:lab.local /sid:域SID /target:SRV01.lab.local /service:MSSQLSvc /rc4:MSSQL_SVC账户的NTLM Hash /ptt参数解释/user 这里可以任意指定甚至可以是fakeuser因为服务端只验证票据本身不反向找KDC验证用户。/target 服务所在的主机名。/service 服务类型必须与注册的SPN匹配。/rc4 服务账户的NTLM Hash。执行并注入后我们再次尝试访问\\SRV01\Confidential。访问也成功了因为共享服务SMB在验证时接受了我们伪造的、用MSSQL_SVC密钥加密的ST。但是如果我们此时尝试访问\\DC01\c$或者其他服务会被拒绝。因为白银票据是“专用券”只对特定的服务/服务器组合有效。它的最大特点是绕过KDC。在Wireshark里你能看到当你使用白银票据访问服务时客户端根本没有向域控的88端口Kerberos发送TGS-REQ请求而是直接拿着ST就去访问服务了。6. 防御与检测视角蓝队如何发现“幽灵票据”作为攻击方伪造票据很爽。但作为防御方我们必须知道如何发现这些异常。在实验的最后阶段我把角色切换成蓝队在域控和成员服务器上部署监控。6.1 监控Kerberos事件日志 (Event ID)这是最直接的检测手段。在域控制器上需要启用“审核Kerberos服务票证操作”策略然后重点看两个事件Event ID 4769 已请求Kerberos服务票证。这是正常流程。但我们需要关注异常属性Ticket Encryption Type 攻击者伪造票据时可能使用较弱的加密类型如RC4而现代环境通常使用AES。大量RC4加密的4769事件可能是警报。Ticket Options 正常票证会有一些特定标志位。例如黄金票据伪造的TGT在用于请求ST时其Ticket Options中的Forwardable等标志可能与正常情况不同这需要深入分析。最关键的对比Client Address请求来源IP和Client Name请求账户的历史行为。如果一个平时只在办公室电脑活动的用户突然从一台服务器IP请求了大量高权限服务的票证这极其可疑。Event ID 4672 分配给新登录的特殊权限。当使用黄金票据注入的会话尝试执行高权限操作如DCSync时可能会触发此事件且登录进程为Kerberos这可以与来源IP、账户结合分析。在成员服务器服务端上可以监控安全日志中的Event ID 4624 帐户已成功登录并特别关注Logon Type为3网络登录且Authentication Package为Kerberos的事件。记录下这些成功Kerberos网络登录的源账户和源IP建立基线。任何偏离基线的访问例如一个从未访问过该SQL服务器的开发账户突然登录都值得调查。6.2 使用专业工具进行狩猎日志分析有时不够实时和直观。我们可以使用像Rubeus、KekeoMimikatz作者的另一工具这样的工具或者PowerShell模块Get-KerberosTicket在疑似受害主机上直接枚举当前会话中的Kerberos票据。例如在PowerShell中你可以检查票据的某些属性# 需要安装 ActiveDirectory 模块 klist更深入的分析需要专业工具。一个黄金票据的典型特征是票据的Start Time可能早于该账户的密码最后修改时间或者票据的有效期长得离谱默认10年。而白银票据的检测更困难因为它不经过KDC所以域控上看不到4769事件。防守方必须在服务端也就是被伪造访问的目标服务器上加强监控分析接收到的ST是否来自合法的TGS这几乎不可能或者更实际一点监控服务账户本身的异常登录事件Event ID 4624。6.3 根本性防御措施检测是后置的加固才是根本。通过这次实验我总结了几条核心防御建议保护KRBTGT账户这是域安全的“命门”。定期如每半年或每年更改KRBTGT账户密码两次。因为Kerberos协议设计需要修改两次才能使旧的黄金票据完全失效。微软提供了专门的脚本New-KrbtgtKeys.ps1来安全执行此操作。实施最小权限原则严格限制域管理员组、企业管理员组等特权组的成员。为服务账户设置强密码最好超过25位避免被破解并定期轮换。避免服务账户拥有域内过高权限。启用高级审计策略不仅开启基本的审核策略更要启用“审核Kerberos身份验证服务”和“审核Kerberos服务票证操作”并确保日志被集中收集SIEM和分析。限制加密类型在域组策略中禁用不安全的Kerberos加密类型如DES RC4-HMAC强制使用AES加密。这能增加攻击者获取有效哈希和伪造票据的难度。部署Credential Guard仅限Win10/Server2016这是一项基于虚拟化的安全功能能将Kerberos等凭据的哈希值隔离在一个受保护的内存区域使Mimikatz等工具无法直接从LSASS进程内存中读取到明文密码或哈希。这是缓解此类攻击非常有效的手段。7. 总结与反思从“ZQH”项目中获得的实战体感回过头看“ZQH”这个项目它带给我的远不止几条命令和概念。它让我对Active Directory的安全有了立体的认知。攻击链不是孤立的点从初始访问、权限提升、凭据窃取到横向移动、权限持久化黄金票据和白银票据是其中极具破坏力的环节。它们之所以危险是因为它们巧妙地利用了Kerberos协议本身的信任机制。对我个人而言最大的收获有两点第一理解了“为什么检测困难”。尤其是白银票据它是一种“本地验证”的绕过不产生中心化的认证日志4769这让传统的基于域控日志的检测模型部分失效。防守必须前移和下沉到每一台服务器上去部署精细化的登录审计。第二体会了“假设性思维”在安全中的重要性。作为蓝队不能只假设攻击者会走正门爆破密码。必须假设KRBTGT的哈希可能已经泄露假设服务账户的密码可能已被获取。然后基于这些假设去设计检测规则比如监控KRBTGT密码更改事件后是否还有用旧哈希生成的票据在活动比如为关键服务账户建立严格的访问白名单任何非白名单IP或账户的登录尝试都视为高危。最后一个非常实用的建议在学习过程中一定要像我这样自己动手搭环境。每一个错误比如SPN注册失败、票据注入后不生效都是一次加深理解的机会。当你亲手用伪造的票据打开那扇原本禁止通行的门时你对域安全的理解会比读十篇论文都来得深刻。这个“ZQH”项目虽然代号随意但它确实成了我理解Windows域认证安全的一个关键里程碑。希望这份详细的笔记能帮你少走一些弯路更快地抓住这些核心攻防技术的脉络。