---

Enumeración

Reconocimiento de Puertos

Como en todo proceso de pentesting, comenzaremos con la fase de reconocimiento, una de las más importantes de cara a las fases posteriores. Utilizaremos la herramienta nmap para descubrir los puertos abiertos en el endpoint.

Una vez identificados los puertos abiertos, lanzamos un escaneo más avanzado con los scripts por defecto de NSE (Nmap Scripting Engine) y detección de versiones:

Los scripts NSE realizan comprobaciones automáticas como detección de vulnerabilidades básicas, enumeración de servicios e información adicional como usuarios, versiones y configuraciones.

Del escaneo extraemos información de interés:

• El dominio es redelegate.vl y el DC se llama dc.redelegate.vl.

• Lo añadimos al archivo /etc/hosts:

echo "<IP> dc.redelegate.vl redelegate.vl" | sudo tee -a /etc/hosts

• La presencia simultánea de Kerberos (88), LDAP (389), SMB (445) y WinRM (5985) indica que estamos ante un Domain Controller de Active Directory.

• SQL Server instalado MSSQL (1433).

• El puerto 21 con login anónimo es nuestro primer punto de entrada.

---

Enumeración FTP — Acceso Anónimo

El escaneo ha revelado que el FTP permite login anónimo, lo que es inmediatamente llamativo en un DC.

Nos conectamos y listamos el contenido disponible, donde encontramos tres archivos:

CyberAudit.txt
TrainingAgenda.txt
Shared.kdbx

Los descargamos todos a nuestra máquina atacante:

ftp> mget *

Revisamos los archivos de texto.

CyberAudit.txt es el más relevante: es el resultado de una auditoría de seguridad interna que menciona que las contraseñas del dominio siguen el patrón SeasonYear!.

Es decir, combinaciones como Fall2024!, Winter2023!, Spring2022!, etc.

TrainingAgenda.txt hace referencia a una agenda de formación interna, pero confirma el mismo patrón de contraseñas mencionado en el audit.

Shared.kdbx es una base de datos KeePass cifrada.

KeePass es un gestor de contraseñas ampliamente utilizado en entornos corporativos. El archivo está protegido por una contraseña maestra, que tendremos que crackear.

---

Crackeo del KeePass — keepass2john + Hashcat

Para crackear el archivo .kdbx primero lo convertimos a un formato que hashcat pueda procesar, usando keepass2john:

keepass2john Shared.kdbx > keepass.hash

keepass2john extrae el hash de la contraseña maestra del archivo KeePass y lo transforma al formato John / Hashcat.

Ahora generamos una wordlist personalizada basada en la pista del audit (SeasonYear!):

Spring2024!
Summer2024!
Autumn2024!
Fall2024!
Winter2024!

Crackeamos con hashcat usando el modo -m 13400 que corresponde a KeePass:

hashcat -m 13400 keepass.hash seasons.txt

En pocos segundos obtenemos la contraseña maestra.

Abrimos la base de datos con keepassxc:

Dentro encontramos las credenciales del usuario del servicio SQL.

---

Enumeración MSSQL — RID Brute Forcing

Con las credenciales obtenidas del KeePass las validamos con netexec para mssql.

Tras validar las credenciales podemos intentar lanzar el parámetro --rid-brute para listar usuarios.

El RID (Relative Identifier) es la parte variable del SID (Security Identifier) de cada objeto en Active Directory. Haciendo fuerza bruta sobre los RIDs podemos enumerar todos los usuarios, grupos y equipos del dominio sin necesitar privilegios LDAP explícitos.

Lo hacemos con NetExec de nuevo:

netexec mssql dc.redelegate.vl -u sql_svc -p '<password>' --rid-brute

Obtenemos la lista completa de objetos del dominio. Filtramos los usuarios y los guardamos:

Administrator
Guest
krbtgt
marie.curie
helen.frost
FS01$
DC$

Guardamos los nombres de usuario en un archivo de texto.

---

Password Spray — marie.curie

Con la lista de usuarios y el patrón de contraseñas obtenido del audit, realizamos un password spray.

Un password spray es un ataque en el que se prueba una misma contraseña (o pocas contraseñas) contra muchos usuarios. A diferencia del brute force clásico, evita el bloqueo de cuentas porque no se hacen múltiples intentos sobre el mismo usuario.

netexec smb dc.redelegate.vl -u usuarios.list -p passwords.list

Obtenemos un hit:

SMB         10.129.234.50   445    DC               [+] redelegate.vl\Marie.Curie:Fall2024!

Verificamos los privilegios de esta cuenta:

netexec smb dc.redelegate.vl -u marie.curie -p 'Fall2024!'
netexec winrm dc.redelegate.vl -u marie.curie -p 'Fall2024!'
netexec ldap dc.redelegate.vl -u marie.curie -p 'Fall2024!'

Marie.Curie no tiene WinRM, pero sí autenticación válida en el dominio. Esto es suficiente para continuar.

---

Enumeración Active Directory — Bloodhound

Con credenciales válidas del dominio, procedemos a recopilar datos del Active Directory para mapear las relaciones entre objetos y encontrar rutas de ataque.

bloodhound-python -c all -d redelegate.vl -u Marie.Curie -p 'Fall2024!' -ns 10.129.234.50

Accedemos a la interfaz web, importamos los datos y marcamos marie.curie como Owned. Ejecutamos la query predefinida "Shortest Paths from Owned Principals" y encontramos el siguiente esquema de ataque:

ForceChangePassword es un ACL de Active Directory que permite cambiar la contraseña de otro usuario sin necesidad de conocer la contraseña actual. Es un privilegio muy peligroso cuando está mal asignado.

GenericAll sobre una cuenta de máquina permite modificar cualquier atributo de ese objeto en AD, incluyendo su contraseña y sus atributos de delegación Kerberos.

Tenemos un camino claro hasta el Domain Controller.

---

Explotación

Movimiento Lateral — ForceChangePassword sobre helen.frost

Usando el privilegio ForceChangePassword que marie.curie tiene sobre helen.frost, cambiamos la contraseña de esta última:

net rpc password Helen.Frost P@ssw0rd1234 -U redelegate.vl/Marie.Curie%Fall2024! -S dc.redelegate.vl

Verificamos que las nuevas credenciales son válidas para winrm.

netexec winrm dc.redelegate.vl -u helen.frost -p 'P@ssw0rd1235'
# [+] redelegate.vl\helen.frost:Passw0rd123! (Pwn3d!)

Nos conectamos con Evil-WinRM:

evil-winrm -i dc.redelegate.vl -u helen.frost -p 'P@ssw0rd1234'

---

Escalada de Privilegios

Enumerando los privilegios del usuario Helen.Frost en el sistema vemos lo siguiente:

SeEnableDelegationPrivilege es un privilegio de cuenta de dominio que permite a un usuario configurar atributos de delegación Kerberos sobre objetos que controla.

Antes de proceder, necesitamos entender por qué no podemos tomar el camino más directo. Tenemos SeEnableDelegationPrivilege y GenericAll sobre FS01$, lo que en teoría permitiría configurar unconstrained delegation (delegación sin restricciones).

La explotación de unconstrained delegation implica:

1. Añadir una cuenta de máquina al dominio

2. Añadir un registro DNS para esa máquina

3. Configurarla con unconstrained delegation

4. Forzar al DC a autenticarse contra nuestra máquina (con PrinterBug, PetitPotam, etc.)

5. Capturar el TGT del DC

Pero verificamos el MachineAccountQuota del dominio:

netexec ldap dc.redelegate.vl -u marie.curie -p 'Fall2024!' -M maq

El MachineAccountQuota define cuántas cuentas de equipo puede crear un usuario sin privilegios en el dominio. Con valor 0 ningún usuario normal puede añadir equipos al dominio.

Sin embargo, combinando SeEnableDelegationPrivilege con GenericAll sobre FS01$, podemos configurar Constrained Delegation con Protocol Transition (S4U2self + S4U2proxy) sobre esa cuenta de equipo existente.

---

Constrained Delegation — S4U2self + S4U2proxy

Paso 1: Solicitar TGT para helen.frost

Primero obtenemos un TGT válido para helen.frost, ya que lo necesitaremos para operar con sus privilegios desde nuestra máquina atacante:

getTGT.py 'redelegate.vl/helen.frost:Passw0rd123!'

export KRB5CCNAME=helen.frost.ccache

Paso 2: Cambiar la contraseña de FS01$

Como helen.frost tiene GenericAll sobre la cuenta de máquina FS01$, podemos cambiar su contraseña. Esto nos permite posteriormente solicitar un TGT para esa cuenta:

net rpc password "FS01$" "P@ssw0rd1234" -U "redelegate.vl/helen.frost%P@ssw0rd1234" -S dc.redelegate.vl

Verificamos con netexec:

netexec smb dc.redelegate.vl -u 'FS01$' -p 'P@ssw0rd1234'

Paso 3: Configurar TRUSTED_TO_AUTH_FOR_DELEGATION y msDS-AllowedToDelegateTo

Desde la sesión Evil-WinRM de Helen.Frost, configuramos la cuenta FS01$ para delegación restringida con Protocol Transition.

Esto requiere dos cambios en AD:

# 1. Habilitar el flag TrustedToAuthForDelegation (Protocol Transition / S4U2self)

Set-ADComputer "FS01$" -Replace @{
    userAccountControl = (
        (Get-ADComputer "FS01$" -Properties userAccountControl).userAccountControl -bor 0x100000
    )
}

# 2. Configurar el SPN al que FS01$ puede delegar (S4U2proxy)

Set-ADComputer "FS01$" -Replace @{
    "msDS-AllowedToDelegateTo" = "cifs/dc.redelegate.vl"
}

TrustedToAuthForDelegation activa el flag TRUSTED_TO_AUTH_FOR_DELEGATION en el atributo userAccountControl del objeto. Esto permite a la cuenta obtener tickets de servicio en nombre de cualquier usuario sin que ese usuario haya autenticado previamente (Protocol Transition / S4U2self).

msDS-AllowedToDelegateTo define a qué SPNs puede delegar la cuenta. En este caso configuramos cifs/dc.redelegate.vl, que corresponde al servicio SMB/CIFS del Domain Controller.

Verificamos que los cambios se aplicaron correctamente:

Get-ADComputer FS01$ -Properties userAccountControl,msDS-AllowedToDelegateTo

Paso 4: S4U2self + S4U2proxy con getST.py

Ahora usamos getST.py de Impacket para realizar el ataque completo en dos fases:

impacket-getST redelegate.vl/fs01\$:'P@ssw0rd1234' -spn cifs/dc.redelegate.vl -impersonate dc

Lo analizamos:

1. S4U2self: FS01\( solicita al KDC un Service Ticket (ST) para sí mismo en nombre del usuario Administrator. Esto es posible porque tiene el flag TrustedToAuthForDelegation activado. El KDC emite el ST aunque Administrator nunca haya autenticado contra FS01\).

2. S4U2proxy: FS01$ usa ese ST para solicitar otro ST al KDC, esta vez para el servicio cifs/dc.redelegate.vl, también en nombre de Administrator. El KDC lo permite porque cifs/dc.redelegate.vl está en msDS-AllowedToDelegateTo.

El resultado es un ticket de servicio válido que nos permite autenticarnos contra el CIFS del DC como Administrator.

export KRB5CCNAME='Administrator@cifs_dc.redelegate.vl@REDELEGATE.VL.ccache'

Paso 5: DCSync — Volcado de todos los hashes

Con el ticket de servicio CIFS válido como Administrator, podemos ejecutar un DCSync:

impacket-secretsdump -k dc.redelegate.vl -just-dc-user Administrator

DCSync es una técnica que simula el comportamiento de un Domain Controller legítimo solicitando replicación de credenciales al DC real. Utilizando el protocolo MS-DRSR (Directory Replication Service Remote Protocol), podemos extraer los hashes NTLM de todos los usuarios del dominio, incluido el hash del Administrator y el krbtgt.

Paso 6: Pass-the-Hash → Acceso como Administrator

Con el hash NTLM del Administrador realizamos un Pass-the-Hash para obtener una sesión completa:

# Con Evil-WinRM
evil-winrm -i dc.redelegate.vl -u Administrator -H '<NTLM_HASH>'