企业官网建设流程全解析

做内网安全评估时，如果只能挑一种攻击手法给客户解释“域控失陷为什么这么难收拾”，我会选黄金票据。很多企业以为重置几个密码、重装几台终端就能把入侵者扫出门，但一张由攻击者离线伪造的Kerberos TGT，可以在合法协议框架下继续访问域内几乎任何服务，甚至在域管密码已经改掉之后依然有效。这不是什么新漏洞，而是Kerberos设计里一直存在的攻击面，只不过Mimikatz把利用门槛压到了极低。这篇文章从认证原理讲到攻防对抗，再到日志检测和应急处理，适合刚接触域安全的蓝队新人，也适合要给内网做加固的企业管理员。

1. 黄金票据攻击的核心逻辑：为什么一张票据能翻遍整个域

黄金票据名字听着唬人，本质上就是一句话：攻击者拿到了krbtgt账户的密码哈希，然后自己动手签发了一张TGT。要理解这句话的分量，先得把Kerberos的认证流程捋清楚，不然防御的时候你连该看哪条日志都不知道。

1.1 Kerberos认证流程回顾

Windows域环境里，Kerberos是默认的认证协议，整个过程大概分三步走：

1. 客户端拿着用户密码生成的哈希，向域控的AS（Authentication Service）发AS-REQ，请求一张TGT（Ticket Granting Ticket）。域控验证密码没问题后，用krbtgt账户的哈希加密TGT，然后返回给客户端。这一步可以理解为“找门卫办一张全园区通用的门禁卡”。

2. 客户端要访问某台文件服务器，就拿TGT找域控的TGS（Ticket Granting Service）发TGS-REQ，申请一张ST（Service Ticket，服务票据）。TGS会用krbtgt的哈希验证TGT是不是自己签发的，确认没问题后，生成一张ST并用目标服务账户的哈希加密，返回给客户端。

3. 客户端拿ST去访问文件服务器，文件服务器用自己服务账户的哈希解密ST，验证里面有自己需要的用户信息和权限，然后放行。

在整个流程里，krbtgt账户哈希是KDC签发和验证TGT的唯一密钥，地位相当于“园区门禁系统的母卡”。如果这张母卡泄露了，攻击者根本不需要再走门卫，直接自己造卡就行。

1.2 黄金票据的“金”在哪里：krbtgt哈希是关键

攻击者只要拿到krbtgt的NT哈希或者AES256密钥，就能完全仿冒KDC的角色，离线签发任意TGT。伪造的TGT里可以写任意用户名、任意组的SID、任意有效期，甚至可以写一个域里根本不存在的用户。为什么域控验不出来？因为KDC验证TGT时用的是krbtgt哈希，攻击者伪造TGT时用的也是同一个密钥，两边完全对得上。

最坑的地方在于，krbtgt账户的密码默认几乎不会自动轮换。普通用户改了密码马上影响登录，但krbtgt密码改起来麻烦，而且微软没把它做成自动化更新机制。所以很多企业的AD域从搭建那天起，krbtgt哈希就没变过。攻击者只要在域控失陷期间复制走这份哈希，之后哪怕过了半年回来，照样能用一张旧TGT进入域内核心系统。

这就带来了一个很现实的防御困境：黄金票据攻击发生在“所有合法认证都走Kerberos”的体系内部，手段上没有任何畸形流量，单看某一次认证请求，你很难判断那到底是不是真人。唯一的破绽在于，正常用户不可能突然拥有域管理员组的权限，也不可能从一台普通终端去请求文件服务器的ST。

1.3 黄金票据vs白银票据：别傻傻分不清

很多刚开始做域安全的朋友会把黄金票据和白银票据搞混。简单说，黄金票据伪造的是TGT，相当于伪造了“身份”；白银票据伪造的是ST，相当于伪造了一张只针对某个服务（比如文件共享CIFS、HTTP服务）的“准入许可”。

实战中我见过不少把白银票据当黄金票据吹的情况。白银票据因为只需要拿到某台服务器的机器账户哈希，在横向移动时更隐蔽，能直接绕过一些不审计TGS的系统，但影响面窄。黄金票据则是“整域通杀”，只要域策略允许，一张票就能访问域内所有资源。所以后续的方案，我重点围绕黄金票据来讲，因为它的杀伤半径最大，防御和应急也最棘手。

2. 攻击准备工作与Mimikatz落地

黄金票据的利用链条可以拆成两段：第一段是拿到krbtgt哈希，第二段是拿这个哈希去伪造TGT。第一段通常需要域控权限或者能触发DCSync的权限，所以黄金票据很少作为“第一滴血”使用，更多是权限维持和横向移动的工具。

2.1 KRBTGT哈希从哪来

常见获取路径有这几条：

1. 已经拿下域控权限，直接登录域控，用Mimikatz从lsass进程里读取缓存的域凭据。命令是sekurlsa::logonpasswords，运气好能直接看到krbtgt的哈希。不过现在不少环境开了Credential Guard或者LSASS保护，直接抓内存可能失败。

2. 使用DCSync攻击。只要有域管理员、企业管理员，或者被授予“复制目录更改”权限的账户，就可以通过Mimikatz的lsadump::dcsync模拟域控复制请求，从目录中直接提取krbtgt的哈希。这条路径在实战中更常见，因为不需要登录域控就能远程操作。

3. 拿到域控的系统权限后，通过卷影拷贝服务复制一份ntds.dit数据库出来，再用离线工具解析哈希。这个方法通用性很强，但动静较大，需要处理的文件体积也不小。

4. 从域控备份介质、灾难恢复镜像、虚拟机快照里提取。很多企业把域控备份扔在共享存储上，权限控制不当就会变成攻击者的“哈希提款机”。

需要提醒的是，以上操作都需要极高的初始权限。如果攻击者还没有域管权限，那通常得先通过本地管理员、服务漏洞、密码喷洒等方式拿下域控或具有目录复制权限的账户。换句话说，黄金票据是在“已经打穿一部分内网”之后才会用到的进阶武器。

2.2 Mimikatz票据伪造基础命令

拿到哈希之后，核心命令长这样：

kerberos::golden /user:任意用户名 /domain:corp.local /sid:域SID /krbtgt:krbtgt的NT哈希 /id:500 /groups:512 /ptt

这里有几个关键参数不能搞错：

• /user：伪造的TGT里显示的用户名，可以随便写，不影响认证效果；
• /domain：目标域的FQDN，必须和域信息一致；
• /sid：域的SID，注意不是域控机器的SID，是一个S-1-5-21-开头的长串；
• /krbtgt：krbtgt账户的NT哈希，也可以用/aes256指定AES256密钥，二选一；
• /id：伪造用户RID，500表示管理员；
• /groups：伪造用户所属组的RID列表，512是域管理员组，513是域用户组，用逗号分隔；
• /ptt：Pass The Ticket，直接把票据注入当前会话，不生成文件。

如果不加/ptt，Mimikatz会在当前目录生成一个.kirbi票据文件，你可以拷到其他机器再注入。对红队来说，注入内存比留文件干净，毕竟.kirbi文件很容易被AV标记。

2.3 黄金票据的优缺点与适用场景

黄金票据的优点是持久、跨服务、离线可用。拿到krbtgt哈希之后，不依赖攻击机与域控持续通信，也不用担心域管密码被改，只要krbtgt哈希没变，票据就一直有效。你可以把票据的生命周期设置得很长，甚至超过域策略里“最大TGT寿命”，不过要注意设置时间太长反而容易被KDC的续期策略拦下来。

缺点是获取哈希本身门槛高，而且伪造TGT之后用户去请求服务票据，会在域控日志里留下痕迹。如果目标环境的监控比较强，能通过事件ID 4769结合异常账号、异常源IP做关联分析，黄金票据也不是完全无迹可循。

在实战中，我一般建议：

• 想长期维持域权限，用黄金票据；
• 只想快速访问某台文件服务器或某个Web服务，用白银票据；
• 攻防演习中尽量用/ptt直接注入，少留文件；
• 拿到哈希后，优先确认krbtgt的密码是否在近期变更过，如果刚改过，你手里的哈希可能已经过期。

3. 实战演示：从拿到哈希到伪造TGT

理论讲完，直接看一遍实际操作。下面的命令都是在授权测试环境和模拟域里跑的，别在未授权环境里试，这是原则问题。

3.1 环境准备与信息收集

假设攻击者已经获得域管权限，目标域是corp.local，域控主机名是dc01.corp.local。先在域控或可执行DCSync的机器上，用管理员身份打开命令行：

mimikatz # lsadump::dcsync /domain:corp.local /user:krbtgt

正常执行后，Mimikatz会输出类似下面的信息：

RID : 000001f6 (502) User : krbtgt Hash NTLM: 8a5a1f2c3d4e5f6a7b8c9d0e1f2a3b4c

这里Hash NTLM就是我们要的krbtgt NT哈希。如果环境里开了额外保护，DCSync可能被拒绝，那就得回到域控上抓lsass，或者走ntds.dit离线解析，思路是死的，但方法可以换。

接下来要拿到域SID。可以用PowerShell查：

(Get-ADDomain).DomainSID

结果类似S-1-5-21-1234567890-1234567890-1234567890，这个值要原样记录下来。注意千万别拿域控机器自身的SID来用，那是错的，很多新手第一步就栽在这。

3.2 伪造黄金票据的命令拆解

拿到上述两个关键信息后，执行伪造命令：

mimikatz # kerberos::golden /user:opsadmin /domain:corp.local /sid:S-1-5-21-1234567890-1234567890-1234567890 /krbtgt:8a5a1f2c3d4e5f6a7b8c9d0e1f2a3b4c /id:500 /groups:512,513 /ptt

逐项解释一下这几个参数为什么这样填：

• /user:opsadmin：我故意填一个看起来普通的运维账号，避免在日志里出现admin这种扎眼名字。反正TGT里的用户名不影响后续权限，最后起作用的还是组SID。
• /groups:512,513：512是域管理员组，513是普通域用户组。伪造票据时最好把两个都带上，因为某些服务校验要求票据同时包含已验证的域用户组，否则可能被拒绝。
• /id:500：RID填500，表示这个伪造用户的相对标识符是管理员。
• /ptt：直接注入当前会话。执行成功后会看到Golden Ticket相关的提示，这时当前系统内存中已经存在一张伪造的TGT。

为了确认注入结果，可以打开一个普通CMD窗口，输入klist查看当前缓存的Kerberos票据列表。正常情况下能看到Server: krbtgt/CORP.LOCAL的TGT条目，这就说明伪造票据已经进入本次登录会话。

3.3 票据生效后的访问验证与痕迹问题

票据注入后，最直接的验证方式就是访问域控的文件共享，比如执行：

dir \\dc01.corp.local\c$

如果票据生效而且权限正确，你能直接列出域控C盘的目录。这一步靠的是Kerberos自动向KDC申请CIFS服务的ST，而KDC验证TGT后正常签发。整个过程和你用合法管理员账号访问域控几乎一模一样。

在红队视角里，访问完目标后要清理现场。用/ptt注入的票据只存在于内存，重启即消失，这点比生成.kirbi文件干净。但如果想跨机器使用，就得生成票据文件再在其他地方导入，那就容易在磁盘上留下artifact。提交测试报告时，我会把这两条路径的痕迹差异写清楚，方便蓝队做检测。

还要注意，伪造TGT里的用户名如果不存在于AD，访问某些做了“账户映射”的应用时可能会异常。所以演示时最好伪造一个真实存在的账户，或者干脆伪造一个新账户再手动加进域管理员组，这样可以减少兼容性麻烦。

4. 防御视角：如何让黄金票据失效

攻击思路清楚了，防御就好办了。记住一个原则：黄金票据的核心是krbtgt哈希泄露，所以防御的终点不只是“防伪造票据”，而是“防哈希出库”。

4.1 从攻击链路反推安全基线

攻击者要拿到krbtgt哈希，绕不开域控权限或DCSync权限。所以第一层防御，就是极限压缩特权账户的暴露面：

• 域管理员账户数量控制在个位数，尽量不允许普通域管在日常业务终端上登录；
• 域管登录域控时使用特权账号，和日常办公账号完全分离；
• 在域控上启用“受保护的安全支持提供程序”相关的LSASS保护，能在一定程度上阻止内存转储和lsass读取；
• 对拥有“复制目录更改”权限的主体做定期审计，这条权限默认只有域控和域管理员，但有些企业为了运维方便授予了额外账户，风险很大；
• 用LAPS管理所有域内主机的本地管理员密码，防止横向移动时本地管理员哈希被滥用，进而爬向域控。

说白了，黄金票据是“高权限阶段的产物”，你别指望在低层面拦住它，重点是别让攻击者能拿到域控的高权限。

4.2 域控日志与异常检测规则

第二层防御，是让攻击者即使伪造了票据也“不能安心用”。域控的Windows安全日志里有一些关键事件ID很值得盯：

具体到黄金票据，可以预设这些规则：

• 同一用户短时间内从不同IP请求大量TGS，尤其是请求域控的CIFS和LDAP服务；
• 一个普通业务账户突然请求了域管才常访问的服务票据；
• 4768事件中票据生命周期明显超过域策略的范围；
• 源IP来自非特权终端，却访问了域控、备份服务器等重点资产；
• 域控上出现针对LSASS进程的进程访问行为，可以通过Sysmon事件ID 10关联。

有条件的团队可以把以上规则导入SIEM，设置“尝试读取LSASS进程”和“域内高权限服务票据请求”的告警，能显著缩短黄金票据的发现时间。不要指望单条日志能直接告诉你“这是黄金票据”，但多维度关联之后，异常会浮出水面。

4.3 KRBTGT密码重置要点

如果已经确认krbtgt哈希泄露，或者安全基线要求定期轮换，那就得重置krbtgt密码。这件事看着简单，实际坑很多，我见过有人直接改了一次密码，结果域内大量KDC票据失效，业务中断。正确做法是分两步重置：

1. 第一次重置krbtgt密码，然后至少等待12小时以上，确保域内所有KDC和只读域控完成密码同步；
2. 在业务低谷期做第二次重置，这次重置会把之前基于旧哈希签发的黄金票据彻底作废。

微软之所以建议分两次，是因为域内存在复制延迟，如果一次性改完，不同KDC之间密钥不一致，会导致TGT验证时解密失败。两步走能最大程度减少对合法用户的影响。

还要注意，重置krbtgt密码是一个“物理级”的防御动作：所有已签发的TGT都会失效，用户需要重新认证。所以操作之前一定要和业务窗口对齐。重置完成后，立即检查域内备份、VSS快照和系统镜像里是否残留krbtgt哈希，否则备份一旦被攻击者拿到，后面的防御动作全白费。

5. 排查与应急：遇到黄金票据攻击怎么处理

假设监控告警响了，或者客户反映域内出现异常横向行为，你怀疑已经有人用了黄金票据。这时候别急着猜，按步骤来。

5.1 事件ID与日志溯源思路

先在域控上收集近一段时间的安全日志，重点查三类记录：

第一类是DCSync行为记录，即4662事件中目录复制的GUID访问。如果发现某个非域控机器突然访问目录复制权限，基本可以断定哈希已经被拖走。

第二类是可疑的TGS请求，也就是4769事件。黄金票据伪造者注入TGT后，一定需要请求服务票据才能访问目标服务，所以4769几乎必现。查的时候看账户、源IP、请求的服务名三个要素。如果某个账户在短时间内请求了域控CIFS、LDAP、HTTP等一堆服务，就要高度怀疑。

第三类是管理组变更事件，比如4728、4732、4756这些与域管理员组相关的成员变更。攻击者可能直接用票据权限新建一个管理账户，或者把某个普通账户拉入域管理员组，这种变更会留下清晰的事件痕迹。

日志溯源时一定要警惕一个问题：伪造TGT里的用户名不一定真实对应一个AD账户，所以光盯着账户名查没用，要结合源IP、登录会话、网络连接、进程链一起判断。很多攻击者会伪造一个“看起来很正常”的运维账号，单独看记录完全没问题。

5.2 止血与恢复建议

黄金票据最麻烦的点在于“哈希泄露跟票据使用是可以分离的”。攻击者可能已经把票据文件拷走了，你在这台机器上怎么清都清不干净。所以应急思路要分两步走：

第一步是止血：

• 立刻禁用可疑账户，强制重置这些账户密码，并吊销其Kerberos票据；
• 对失陷主机做网络隔离，防止横向扩散延长；
• 清除域控上可疑的登录会话，必要时重启域控，但要注意影响面；
• 排查所有域控、文件服务器、关键业务系统上是否存在计划任务、服务、WMI持久化。

第二步是根除：

• 必须在确认所有横向路径已经清洗后，才执行krbtgt密码的两次重置流程；
• 重置后重新对所有域控做日志审计，确认没有新的异常TGS请求出现；
• 对域内所有主机启动一次完整的凭据泄露自查，重点抓内存里有没有mimikatz痕迹，磁盘里有没有.kirbi文件；
• 如果攻击者已经拿过域控，不要省略取证环节。先保存内存和事件日志，再清理，否则后面溯源没有依据。

应急过程中最容易犯的错，就是只清完一个会话就宣布“搞定了”。黄金票据利用的是域级信任关系，只要krbtgt哈希还暴露着，同一个攻击者随时能重新注入新票据。所以判断是否清干净的标准，不是“当前没有告警”，而是“krbtgt哈希是否已经轮换、备份中是否含旧哈希、域内是否还存在攻击者可控账户”。

6. 常见问题与避坑心得

最后把实战中反复踩过的坑整理一下，希望能帮你节省几小时排错时间。

6.1 票据不生效的几种典型原因

最常遇到的是访问目标时提示“拒绝访问”，但klist里明明能看到注入的TGT。排查顺序一般是：

• 域SID是不是填成了机器SID，填错则票据完全无效；
• /krbtgt后填的到底是不是krbtgt账户的哈希，有些人拿错成普通域管哈希；
• 时间偏差是否超过5分钟，虚拟机快照回滚后特别容易时间漂移；
• 伪造TGT时有没有带513域用户组SID，某些服务会校验PAC里的组信息。

另外，伪造票据里的用户名如果和现有账户冲突，有时也会导致权限校验异常。我习惯直接伪造一个不冲突的新名称，再叠加512组SID，实测更稳。

6.2 工具报错与抓不到哈希

Mimikatz执行lsadump::dcsync时提示“Access denied”，基本是当前会话权限不够，或者执行主体没有被授予目录复制权限。可以换一个拥有更高权限的账户重试。

抓lsass时提示“Error NT_STATUS_ACCESS_DENIED”，通常是LSASS保护已开启，或者AV在拦截进程打开。可以考虑用合法系统工具做内存转储，再离线提取，但这步只建议在授权环境和取证场景下操作。

杀软报毒是必然的，Mimikatz是老牌攻击工具，特征非常明显。在红队测试里更多是套一层免杀或内存加载，但对防御侧来说，看到Mimikatz特征就响警报，本身就是一件好事。

6.3 几条实战经验总结

第一，黄金票据的检测不要执着于抓“伪造的那一下”，因为伪造过程可能完全离线完成，你根本看不到。真正能看到的是伪造后使用票据去请求服务的行为，所以日志检测重心放在4769和异常访问模式上，比放在4768上更靠谱。

第二，krbtgt密码重置不是防御终点。重置完之后，域内凭证备份、历史镜像、运维脚本里都可能残留旧哈希。很多企业重置完密码，结果攻击者从一个月前的备份里又提取出旧哈希，瞬间完成“恢复”，等于白忙活。所以密码重置必须跟着备份清理和镜像轮换一起做。

第三，不要忽视普通主机的凭据保护。攻击者往往不是直接从域控抓哈希，而是先在一台开发测试机上通过本地管理员权限抓到某个高权限账户哈希，再一步步DCSync出krbtgt。缩小高权限账户在整个内网的缓存范围，能显著抬高黄金票据利用门槛。我做过一个评估项目，客户把所有域管账户都限制在特权访问工作站上登录，一周后攻击链路明显变长，攻击者暴露的日志量也成倍增加。

实战里我对黄金票据的感受是：它不是一个“一击必杀”的漏洞，而是一套“失陷后维持控制”的体系。你不可能靠某一条命令彻底封死它，但通过分层防御、日志关联、定期轮换密钥这三板斧，完全可以让攻击者即使拿到了哈希也不敢轻易用——因为一用就会留下清晰痕迹。安全对抗做到最后，比的就是谁更有耐心把细节抠到位。