企业官网建设流程全解析

序言：从窃听到伪造，信任体系的崩塌

在上一篇文章《Active Directory 攻防（一）：Kerberoasting 实战》中，我们聊了如何利用 Kerberos 协议中 TGS-REP 阶段的“正常机制”，将服务票据带回家离线破解。那是一种“合法索取，非法利用”的优雅战术。
如果说 Kerberoasting 是在皇宫的宴会上，趁人不备偷走了一块带有牙印的糕点，带回家慢慢分析是谁咬的；那么今天我们要讲的两种技术，则是直接对 Kerberos 协议的信任根基下手。

AS-REP Roasting，针对的是那些防守松懈的入口。当系统为了“方便”而关闭了预认证，攻击者甚至不需要知道你的密码，就能拿到加密的凭证，这就像是保安还没看你的身份证，就把通行证递给了你，而你接过后直接拿回家破解上面的防伪水印。

而黄金票据，则是整个 AD 域安全体系中最为致命的终极武器。它不再是利用某个配置失误，而是直接利用了 Kerberos 协议的设计本质：KDC 只认票不认人。当你掌握了“造币厂”的底版，你就可以凭空创造出域控都无法拒绝的伪造票据，自立为王。今天，我们继续深入这座黑暗森林，剖析这两种足以让任何企业内网沦陷的核武器。

第一章：无声的窃取——AS-REP Roasting

很多人把 AS-REP Roasting 和 Kerberoasting 混为一谈，因为它们都是“拿回家烤”。但从协议层面看，它们处于完全不同的阶段，攻击前提也截然不同。

1.1 预认证：KDC 的第一道门禁

在 Kerberos 协议的第一阶段（AS-REQ & AS-REP），客户端向 KDC 索要 TGT（票据授予票据）。KDC 凭什么把这张长期通行证发给你？它必须确认你是谁。
默认情况下，Windows 域要求预认证。
当你发送 AS-REQ 时，你必须附带一个用你自己的密码哈希加密的时间戳。KDC 收到请求后，会去 NTDS.dit 数据库里查你的密码哈希，尝试解密那个时间戳。如果解得开，且时间没被篡改（防重放），KDC 确信：这货确实是张三。然后，KDC 才会把用张三哈希加密的 Session Key 和用 KRBTGT 哈希加密的 TGT 发给他。
这是合理的安全设计。但在庞大的企业网络中，总有例外。

1.2 漏洞触发：当门禁失效

有些老旧的第三方应用（比如某些基于 Java 的老系统、或者某些 Linux 机器加入域的配置），在进行 Kerberos 认证时会出问题。为了兼容这些“奇葩”系统，运维人员往往会在 AD 用户属性里勾选一个致命的选项：“不要求 Kerberos 预身份验证”。
一旦关闭了预认证，逻辑就变成了这样：

1. 客户端发 AS-REQ：“我是张三，给我 TGT。”（不带任何加密证明）
2. KDC（是个死脑筋）：“哦，你是张三啊，我不查你身份了，直接把 TGT 给你。为了你以后能用这个 TGT，我顺便把用你密码哈希加密的 Session Key 也一起给你吧。”
   攻击者视角：
   任何在域内有有效账号的攻击者（哪怕是个最底层的普通域用户），都可以遍历域内用户，向 KDC 发送针对“关闭了预认证”的用户（如张三）的 AS-REQ。KDC 会毫无保留地把 AS-REP 发给你。
   而在 AS-REP 中，包含着一段用张三密码哈希加密的数据。你拿回家，用字典去碰撞，一旦解密成功，你就拿到了张三的明文密码或哈希。
   区别：

• Kerberoasting：需要域用户权限，针对注册了 SPN 的服务账户。
• AS-REP Roasting：不需要域用户权限（只要能连上域控网络），针对关闭了预认证的普通用户。

1.3 实战狩猎：寻找不需要暗号的账户

在实战中，第一步是找出域内哪些账户关闭了预认证。这其实是一个 LDAP 查询。
工具箱：Empire 的 PowerView
老牌的 PowerView 提供了一个现成的模块：

# 查询域内关闭了预认证的账户Get-DomainUser-PreauthNotRequired

它的底层原理是向域控发送 LDAP 查询，过滤条件为(userAccountControl:1.2.840.113556.1.4.803:=4194304)。这个掩码就代表“不需要预认证”。
工具箱：Rubeus
作为红队神兵，Rubeus 自然也集成了这个功能。它的优势在于，查到目标后可以直接发请求并格式化输出哈希。

Rubeus.exe asreproast /outfile:C:\Temp\asrep_hashes.txt

工具箱：Impacket (GetNPUsers.py)
如果你在 Linux 环境下，或者只有一组通过弱口令爆破出来的域凭据，Impacket 是最好的选择。它甚至不需要你事先知道哪些账户关闭了预认证，只要你提供一个域用户账号，它会自动通过 LDAP 查询，然后发起 AS-REQ。

# 使用已知域用户自动查询并请求 AS-REPpython3 GetNPUsers.py corp.local/zhangsan:Password123-request-formathashcat-outputfileasrep_hashes.txt

1.4 离线烘烤与破解策略

拿到的哈希文件内容长这样：

$krb5asrep$23$zhangsan@CORP.LOCAL:9e8b8c...[省略]...

注意这里的$23，它同样代表 RC4-HMAC 加密。与 Kerberoasting 类似，如果目标是现代的 AES 加密，破解难度会呈指数级上升。但幸运的是（对攻击者来说），关闭预认证的账户往往是历史遗留的老系统，支持 RC4 的概率极高。
Hashcat 破解：
AS-REP Roasting 对应的 Hashcat Mode 是18200。

hashcat-m18200asrep_hashes.txt rockyou.txt-rbest64.rule

破解逻辑和 Kerberoasting 完全一致，本质上都是算力的碰撞。一旦破解出明文密码，如果这个账户是个运维管理员，那么恭喜你，你以零成本获得了一个高权限跳板。

1.5 蓝队雷达与修复

检测：
AS-REP Roasting 的检测相对容易一些，因为它的行为特征很明显：在没有预认证的情况下，发出了 AS-REQ 并成功收到了 AS-REP。
在域控的安全日志中，关注Event ID 4768（Kerberos 身份验证票据请求）。

• 如果Pre-Authentication Type字段为0，意味着没有进行预认证。
• 如果这个事件频繁出现，或者针对同一个账户在短时间内出现多次，基本可以断定有人在扫盲。
  根治：
• 绝对不要关闭预认证。对于老旧系统，宁愿麻烦一点去修改应用配置，也不要为了兼容性牺牲整个域的安全底线。
• 定期审计域内账户，使用Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}找出并修复这些定时炸弹。

第二章：权力的本质——黄金票据的诞生

如果说前文的攻击都是利用漏洞，那么黄金票据则是对 Kerberos 协议设计哲学的降维打击。在讲实操之前，我们必须先理解它的底层逻辑。

2.1 深入理解 TGT：上帝的授权书

在 Kerberos 体系中，客户端要访问服务，必须先拿着 TGT 向 KDC 换取 ST（服务票据）。
那么 TGT 里面到底装了什么？
TGT 本质上是一个数据包，用KRBTGT 账户的密码哈希加密。里面包含了：

1. 用户信息：谁在请求（如用户名、SID、所属组）。
2. Session Key：客户端与 KDC 后续通信的密钥。
3. 授权数据：这是最核心的。包含了用户的 PAC（Privilege Attribute Certificate，特权属性证书）。PAC 里详细记录了用户在哪些组里（比如 Domain Admins）。
   KDC 的致命盲点：
   当客户端拿着 TGT 去换 ST 时，KDC 会用 KRBTGT 的哈希解开 TGT。KDC完全信任 TGT 里的内容。如果 TGT 里的 PAC 说这个用户是 Domain Admins 组的，KDC 就会信以为真，并在随后发出的 ST 里写入“此人是域管”。
   简单来说：KDC 只认 KRBTGT 哈希加密的票，票里写什么，KDC 就认什么。

2.2 攻击逻辑：我自己造一张上帝的授权书

如果攻击者拿到了 KRBTGT 账户的哈希，他就可以在自己的电脑上，离线伪造一个 TGT。
他可以在伪造的 TGT 里写入：

• 用户名：随便写，甚至写一个域里不存在的用户名。
• 用户 SID：写一个高权限的 SID。
• 组信息：写上 Domain Admins、Enterprise Admins 等最高权限组。
  只要这个伪造的 TGT 是用正确的 KRBTGT 哈希加密的，当攻击者拿着它去 KDC 换 ST 时，KDC 解密成功，看到里面的 PAC 写着“你是域管”，KDC 就会乖乖地给你发放访问任何服务的 ST。
  这就是黄金票据。它绕过了 AS-REQ 阶段（不需要密码），直接伪造了第二阶段的通行证。它的有效期可以长达 10 年（Kerberos 默认策略）。

2.3 为什么需要 DCSync？

要伪造黄金票据，前提是拿到 KRBTGT 的哈希。怎么拿？
常规思路是：拿下域控，在上面跑 Mimikatz，从 LSASS 内存里抠出来。
但如果你无法直接登录域控呢？或者域控开了凭据保护（Credential Guard）你抠不出来呢？
2015 年，Benjamin Delpy（Mimikatz 的作者）和 Vincent Le Toux 发现了一个震惊业界的协议滥用技术：DCSync。
AD 域的多个 DC 之间需要同步数据，使用的协议是DRSUAPI（Directory Replication Remote Protocol）。域控之间通过这个协议互相复制 NTDS.dit 数据库。
DCSync 的精髓在于：域内任何拥有“复制目录更改”权限的账户，都可以伪装成域控，向真正的域控发送复制请求，要求它把数据库里的内容（包括 KRBTGT、域管的哈希）发过来。
谁默认有这个权限？

• Domain Admins
• Enterprise Admins
• 以及一个经常被忽视的组：DC（域控制器）组。这意味着，如果你拿下一了一台域控的本地 System 权限，哪怕它不是 PDC，你也能直接 DCSync。
  实战流程：

1. 通过各种手段（如零日漏洞、配置失误）拿到了一台域控的 System 权限。
2. 不需要抓取 LSASS 内存（规避 EDR）。
3. 直接在域控上或通过代理，使用 Mimikatz 向主域控发起 DCSync 请求。
4. 拿到 KRBTGT 哈希，撤离。

第三章：伪造皇权：黄金票据的实战锻造

手握 KRBTGT 哈希，我们就可以开始“铸币”了。

3.1 铸币所需的原材料

在本地伪造一张完整的黄金票据，你需要以下四个核心要素：

1. 域名：如CORP.LOCAL。
2. 域 SID：域的安全标识符。注意，是域 SID，不是用户 SID。域 SID 是去掉最后一段数字的（如S-1-5-21-123456789-...-1000去掉1000）。
3. KRBTGT 账户的 NTLM Hash：这是加密伪造票据的密钥。
4. 要伪造的用户名：随便写，如hacker，但通常为了方便，会写一个域里已存在的域管名字，避免某些奇怪的后端校验。

3.2 Mimikatz 铸币厂实操

第一步，使用 DCSync 获取原材料（如果你已经拿到了 System 权限的 shell）：

mimikatz.exe "lsadump::dcsync /domain:corp.local /user:krbtgt" exit

在输出中，你会看到：

• Object Security ID：域 SID。
• Hash NTLM：KRBTGT 的哈希。
  第二步，开始锻造。伪造的命令通常这样写：

mimikatz.exe "kerberos::golden /domain:corp.local /sid:S-1-5-21-123456789-... /krbtgt:9c4a8e... /user:Administrator /ptt" exit

参数解析：

• kerberos::golden：开启黄金票据锻造模块。
• /domain：域名。
• /sid：域 SID。
• /krbtgt：哈希值。
• /user：你想伪造的身份。
• /ptt：Pass The Ticket。伪造完成后，直接将票据注入到当前进程的内存中。
  执行完毕后，当前 CMD 窗口就拥有了上帝的权限。

3.3 神格降临：验证与利用

不要关闭这个 CMD 窗口，在这个窗口里执行：

dir \\DC01.corp.local\c$

如果直接列出了域控 C 盘的目录，恭喜你，你的黄金票据生效了。
你可以通过 PsExec、WMI 或直接建立 IPC$ 连接，在域控上执行任何命令。

3.4 隐匿与 OPSEC：做聪明的神

在实战中，直接用 Mimikatz 落地有极大风险。现在的 EDR 对 Mimikatz 的特征码查杀极严。作为一名合格的成年人，我们需要更优雅的方式。
方案一：Rubeus
Rubeus 同样支持黄金票据的生成与注入，且用 C# 编写，更容易做免杀处理。

Rubeus.exe golden /domain:corp.local /sid:S-1-5-... /krbtgt:9c4a8e... /user:Administrator /ptt

方案二：离线锻造，跨平台注入
如果目标环境严苛，你甚至可以在你自己的 Linux 笔记本上，使用ticketer.py(Impacket套件) 离线生成一个.ccache格式的票据文件。

python3 ticketer.py-domaincorp.local -domain-sid S-1-5-...-nthash9c4a8e... Administrator

然后，通过设置环境变量KRB5CCNAME，使用 Impacket 的其他工具（如wmiexec.py、secretsdump.py）带着这个票据直接发起攻击。整个过程不碰目标机器的磁盘，流量侧走的是标准 Kerberos 协议，极具伪装性。
关于加密类型的选择：
在锻造时，最好指定/rc4或/aes256。如果域环境已经禁用了 RC4，你却伪造了一个 RC4 的 TGT，去请求 ST 时会被拒绝。实战中，通常先 DCSync 出 AES 哈希来伪造，兼容性更好。

第四章：白银与黄金——票据的对比学

说到黄金票据，就不得不提它的孪生兄弟——白银票据。理解它们的区别，能加深对整个攻防体系的认知。

4.1 服务票据的伪造

白银票据伪造的是ST（服务票据），而不是 TGT。
它的原理是：如果你拿到了某个服务账户的哈希（比如通过 Kerberoasting 破解了 MSSQL 服务账户的明文），你可以直接伪造一张访问该 MSSQL 服务的 ST。

4.2 优势与劣势分析

第五章：蓝队的终极反击——抗击上帝

当攻击者手里握着黄金票据时，防守方往往会感到一种无力感。因为你面对的不是一个在运行的木马，而是一个在协议深处合法游走的幽灵。但蓝队并非无计可施。

5.1 幽灵日志：抓取看不见的请求

正如前文所说，黄金票据是凭空出现的，它没有经过 AS-REQ 阶段。因此，在域控的安全日志中，你会发现一个极其诡异的现象：
异常特征：

• 没有对应的Event ID 4768（TGT 请求成功）。
• 但却突然出现了大量的Event ID 4769（服务票据请求成功）。
• 4769 日志中的请求者，可能是一个根本不存在于 AD 中的用户名。
  如果你在 SIEM 中设置了“有 4769 无 4768”的关联告警，恭喜你，你抓住了黄金票据的尾巴。

5.2 KRBTGT 重置：两道铁门的更替

发现黄金票据后，最紧迫的任务是让现有的假票据失效。
很多新手运维的第一反应是：改 KRBTGT 账户的密码！
这是一个致命的错误。
Windows 域控制器为了保证数据复制的容错性，KRBTGT 账户保留了当前密码和上一次历史密码两个哈希。如果你只改了一次密码，攻击者伪造的旧票据依然可以用上一次的哈希解开。
微软官方的修复指南（重点）：
必须重置 KRBTGT 密码两次。

1. 第一次重置后，当前密码失效，但上一次的历史密码变成了你刚改的那个新密码。攻击者伪造的票据（用最老的哈希）依然有效。
2. 等待一段复制时间（确保所有 DC 同步完毕）。
3. 第二次重置后，最老的哈希被挤出历史列表。此时，所有伪造的黄金票据彻底作废。
   注意：重置 KRBTGT 是一个高风险操作，会导致当前正在进行的 TGT 认证失效，可能引发短暂的业务中断。在实际操作中，应分步骤、分站点进行。

5.3 架构级防御：让 DCSync 无处遁形

黄金票据的前置是拿到 KRBTGT，而拿到 KRBTGT 大多通过 DCSync。切断 DCSync 的路径，就等于切断了黄金票据的生产线。

1. 收紧 DCSync 权限：审计DC组和Domain Admins组成员。任何非域控的机器账户绝不能拥有“复制目录更改”权限。在 AD 的“用户和计算机”管理单元中，查看域根目录的属性 -> 安全 -> 高级。将“完全控制”和“复制目录更改”的权限限制在最小范围内。
2. 管理员账户隔离：严禁域管账户登录日常办公机或 Web 服务器。域管凭据只能出现在域控上。这是阻断 DCSync 攻击链最有效的手段。
3. 监控 DRSUAPI 调用：在域控上监控网络层面的 DRSUAPI 调用。如果有非域控 IP 向域控发起 IDL_DRSBind 请求，这极大概率是 DCSync 攻击。

5.4 从微弱信号中寻找痕迹：PAC 验证

高级的蓝队还可以通过 PAC 验证来发现异常。如前所述，PAC 里包含了用户的组信息。
虽然攻击者可以伪造任何组信息，但企业内部的网络架构往往是有规律的。比如，一个一直处于“普通业务服务器”网段的机器，突然以“Enterprise Admins”的身份发起大量 CIFS（文件共享）请求，这种行为模式的异常，可以通过 UEBA（用户实体行为分析）系统捕捉到。

第六章：结语：信任的崩塌与重建

Active Directory 的攻防，本质上是对信任边界的争夺。AS-REP Roasting 利用了配置的松懈，让未经身份验证的信任随意流通；而 Golden Ticket 则更彻底，它直接获取了信任的根基——那个用于盖章的印章。当印章落入敌手，所有基于印章的信任体系都会瞬间崩塌。

在这些攻击面前，传统的边界防御显得如此脆弱。你以为关了门，但攻击者拿着你自己造的通行证，从你的正门大摇大摆地走进去。作为防守方，我们需要清醒地认识到：

• 不存在绝对安全的系统，Kerberos 的设计在当年是伟大的，但随着算力的提升和攻防视角的转换，它的“信任逻辑”成为了软肋。
• 安全不能依赖于单点。哪怕 KRBTGT 被攻破，如果你有完善的日志关联分析（无 4768 有 4769），你依然有时间止损。
• 最关键的，是控制权限的蔓延。不要让普通机器能轻易拿到高权限，DCSync 的泛滥正是因为管理员毫无顾忌地滥用 Domain Admins。