> For the complete documentation index, see [llms.txt](https://4lec4st.gitbook.io/4lec4st/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://4lec4st.gitbook.io/4lec4st/writes-ups/hack-the-box/easy/escapetwo.md).

# EscapeTwo

## Información de la máquina

<figure><img src="/files/OL2g0NSSJp0Fz0B6qLRw" alt=""><figcaption></figcaption></figure>

`EscapeTwo` es una máquina Windows de dificultad fácil diseñada para un escenario de vulneración total del dominio, donde se proporcionan las credenciales de un usuario con pocos privilegios. Usamos estas credenciales para acceder a un recurso compartido de archivos que contiene un documento de Excel dañado. Modificando su estructura de bytes, extraemos las credenciales. Estas se distribuyen por todo el dominio, revelando las credenciales válidas de un usuario con acceso a `MSSQL`, lo que nos otorga acceso inicial. La enumeración del sistema revela las credenciales `SQL`, que se distribuyen para obtener acceso a `WinRM`. Un análisis posterior del dominio muestra que el usuario tiene derechos de escritura sobre una cuenta que administra `ADCS`. Esto se utiliza para enumerar `ADCS`, lo que revela una configuración incorrecta en `Active Directory Certificate Services`. Aprovechar esta configuración incorrecta nos permite recuperar el hash de la cuenta `Administrador`, lo que finalmente resulta en la vulneración total del dominio.

Empezamos la máquina con estas credenciales -> rose:KxEPkKe6R8su

***

## Reconocimiento

Empezaremos haciendo un ping a la máquina víctima para ver si está encendida y ante que nos enfrentamos.

<figure><img src="/files/4djfLAdA4hRW68mHX85E" alt=""><figcaption></figcaption></figure>

Si recibimos respuesta, significa que la máquina está en línea. Además, observamos que el **TTL** (Time To Live) es 127, lo que indica que es un sistema Windows.

{% hint style="success" %}
Esto sucede porque Hack The Box virtualiza las máquinas, lo que a menudo reduce el TTL en un punto respecto al valor estándar.

En entornos reales tendrían los siguientes valores:

TTL Linux **→** 64

TTL Windows **→** 128
{% endhint %}

Empezaremos haciendo un primer reconocimiento para ver los puertos abiertos en el sistema.

<figure><img src="/files/oZ8zpKb99LV711lGWKWZ" alt=""><figcaption></figcaption></figure>

**1. `-p-` → Escaneo de todos los puertos (1-65535)**

Por defecto, `nmap` solo escanea los **1000 puertos más comunes**.\
Con `-p-`, forzamos a que escanee **los 65,535 puertos** de la máquina objetivo, lo que puede ser útil para encontrar servicios que corren en puertos poco convencionales.

**2. `--open` → Filtrar solo los puertos abiertos**

Cuando escaneamos un sistema, muchos puertos pueden estar cerrados o filtrados por un firewall.\
Este parámetro hace que `nmap` **solo muestre los puertos abiertos**, reduciendo el ruido y facilitando el análisis.

**3. `-sS` → Stealth Scan (Escaneo Sigiloso con SYN)**

Es conocido como **"TCP SYN Scan"**, y funciona de la siguiente manera:

* `nmap` envía un paquete **SYN** (solicitud de conexión).
* &#x20;Si el puerto está abierto, el servidor responde con **SYN-ACK**.
* En lugar de completar la conexión con un **ACK**, `nmap` responde con un **RST (Reset)**, interrumpiendo la comunicación.

**4. `--min-rate 5000` → Velocidad mínima de paquetes (5000 por segundo)**

Por defecto, `nmap` ajusta dinámicamente la velocidad de los paquetes según la respuesta de la red.\
Con `--min-rate 5000`, obligamos a `nmap` a **no enviar menos de 5000 paquetes por segundo**, acelerando el escaneo.

**5. `-n` → Deshabilitar resolución DNS**

Normalmente, `nmap` intenta resolver el nombre de dominio de las IPs escaneadas (DNS lookup).\
Con `-n`, evitamos esta resolución de nombres, lo que **acelera el escaneo** y evita que los servidores DNS registren nuestra actividad.

**6. `-Pn` → Omitir detección de host (Host Discovery Off)**

Por defecto, `nmap` envía paquetes ICMP (ping) para ver si un host está activo antes de escanearlo.\
Si un firewall bloquea los pings, `nmap` puede marcarlo como "host down" y no escanearlo.

**7. `-oG`** **→ Exportar el contenido en formato grepeable**

Todo el resultado del escaneo lo exportaremos en un archivo llamado allPorts **.**

El escaneo revela muchos puertos abiertos. Ahora haremos un escaneo más detallado.

<figure><img src="/files/ophogblsbdlXZO7CAJqS" alt=""><figcaption></figcaption></figure>

**1. `-p<puertos>` → Escaneo de puertos específicos**

Con `-p<puertos>`, le indicamos que **solo** escanee los puertos que queremos

**2. `-sCV` → Escaneo de versiones y scripts básicos**

Este parámetro en realidad es **dos combinaciones en una**:

* **`-sC`** → Activa los **NSE scripts por defecto** en `nmap` (similar a usar `--script=default`).\
  Ejecuta scripts básicos para enumerar información del servicio detectado, como banners, versiones, etc.
* **`-sV`** → Realiza **fingerprinting de versiones**, intentando identificar la versión exacta del software en cada puerto abierto.

**3. `-oN` → Guardar el resultado en formato Normal**

Por defecto, `nmap` muestra los resultados en pantalla, pero con **`-oN targeted`**, guardamos el resultado en un archivo en **formato legible para humanos**.

<figure><img src="/files/19JGWDPLDYu6y80aF23p" alt=""><figcaption></figcaption></figure>

Añadiremos el nombre del dominio, hostname para asi poder resolver a estos.

<figure><img src="/files/lLwVxRFDAZ5KIRxiiQHF" alt=""><figcaption></figcaption></figure>

## Credenciales válidas del dominio

Disponemos de unas credenciales válidas de dominio: el nombre de usuario `rose` y la contraseña `KxEPkKe6R8su`. Usando la herramienta `nxc` (NetExec, sucesor de CrackMapExec), verificamos que tenemos acceso al puerto 445, que corresponde al protocolo SMB (Server Message Block), comúnmente usado para compartir archivos, impresoras y recursos en sistemas Windows.

<figure><img src="/files/3YBUaUD7UcfdIdyVVjtR" alt=""><figcaption></figcaption></figure>

Comprobamos si tenemos acceso al servicio WinRM (Windows Remote Management) ya que, si pudieramos, podríamos usar la herramienta `evil-winrm` para obtener una shell interactiva. Sin embargo, nuestras credenciales no tienen permiso para acceder por este medio.

<figure><img src="/files/iTUEROjfPhowuBdQuw1g" alt=""><figcaption></figcaption></figure>

Verificamos si podemos acceder al servicio LDAP (Lightweight Directory Access Protocol), que se ejecuta normalmente en el puerto 389. Este servicio permite realizar consultas al Active Directory y, al tener acceso, podemos usarlo para enumerar usuarios, grupos, y otros objetos del dominio.

<figure><img src="/files/xScKyQ41ckTxCZoMH5Ru" alt=""><figcaption></figcaption></figure>

## AS-Rep Roast Attack - Fail

{% hint style="success" %}
El ataque **AS-REP Roasting** se aprovecha de cuentas de dominio que tienen deshabilitado el atributo `Do not require Kerberos preauthentication`. En este caso, un atacante puede solicitar un Ticket Granting Ticket (TGT) sin necesidad de autenticarse previamente. El controlador de dominio devuelve un mensaje cifrado con la clave de la cuenta, el cual puede ser crackeado offline para obtener la contraseña en texto claro.
{% endhint %}

Utilizando `nxc` con el módulo LDAP, extraemos los usuarios que forman parte del dominio. Esta enumeración también puede hacerse con otras herramientas como `rpcclient`, que permite interactuar con el servicio de gestión remota de Windows.

<figure><img src="/files/GoILUygnAKtsSekGiU2p" alt=""><figcaption></figcaption></figure>

Guardamos la lista de usuarios obtenida en un archivo de texto para usarlos posteriormente como diccionario en el ataque.

<figure><img src="/files/ctyNjrH5B5Cogs9oYCwD" alt=""><figcaption></figcaption></figure>

Ahora, con la herramienta `GetNPUsers.py` de la suite Impacket, intentamos obtener los TGT (Ticket Granting Ticket) de las cuentas de usuario sin preautenticación Kerberos.

{% hint style="success" %}
El TGT es el primer ticket que se emite en el protocolo Kerberos tras la autenticación inicial. Es emitido por el KDC (Key Distribution Center) y permite al usuario solicitar otros tickets de servicio. En el AS-REP Roast, si una cuenta tiene desactivada la preautenticación, el TGT puede ser solicitado sin autenticarse y se devuelve cifrado con la clave del usuario.
{% endhint %}

<figure><img src="/files/ivTtwCjCCjcgDRE0ibh3" alt=""><figcaption></figcaption></figure>

Al ejecutar `GetNPUsers`, no conseguimos ningún TGT, lo que indica que no hay cuentas configuradas sin preautenticación Kerberos en este dominio, por lo tanto el ataque AS-REP Roasting no se efectúa.

<figure><img src="/files/cpZfem5ECAUepseaJw6h" alt=""><figcaption></figcaption></figure>

## Kerberoasting Attack - Fail

{% hint style="success" %}
El **Kerberoasting** es un ataque contra cuentas que tienen servicios registrados en el dominio (cuentas con Service Principal Names, o SPN). El atacante, autenticado en el dominio, puede solicitar un ticket de servicio (TGS) para estos SPNs. Este ticket está cifrado con la contraseña del servicio asociado y puede ser crackeado offline para obtener dicha contraseña.
{% endhint %}

Ahora, con la herramienta `GetUserSPNs.py` de Impacket, solicitamos todos los SPNs registrados en el dominio junto con sus respectivos tickets de servicio.

<figure><img src="/files/FMFLU2lEqcdL7boEv9go" alt=""><figcaption></figcaption></figure>

Ejecutamos el script y redirigimos la salida (los hashes de los tickets TGS) a un archivo de texto. En este caso, se identifican dos SPNs con sus respectivos hashes, lo que indica que hay dos cuentas de servicio vulnerables a Kerberoasting.

<figure><img src="/files/t6DtVa8Sda2Zke0ZfVJJ" alt=""><figcaption></figcaption></figure>

Utilizamos `John the Ripper` con un diccionario de contraseñas para intentar crackear los hashes obtenidos. Sin embargo, no conseguimos descubrir las contraseñas asociadas, lo que puede deberse a que estas son complejas o no están incluidas en nuestro diccionario.

## Initial access

### Enumeración SMB

Mediante enumeración SMB, listamos los recursos compartidos del servidor utilizando herramientas como `nxc smb shares` o `smbclient -L`. Encontramos un recurso personalizado llamado **Accounting Department**, además de los compartidos estándar que suelen estar en entornos de Active Directory como `SYSVOL`, `NETLOGON` y `Users`...

<figure><img src="/files/eCf7DYJj2h3aZEUBgZgg" alt=""><figcaption></figcaption></figure>

Utilizando las credenciales del usuario `rose`, accedemos al recurso compartido "Accounting Department". Dentro encontramos dos archivos con extensión `.xlsx` (hojas de cálculo de Excel). Procedemos a descargarlos localmente para analizarlos.

<figure><img src="/files/RHlYk11xKxDYvROTRcwC" alt=""><figcaption></figcaption></figure>

Al intentar abrir los archivos en Excel, nos aparece un error de archivo dañado o ilegible. Esto sugiere que los archivos no contienen una hoja de cálculo válida, o que fueron alterados de alguna manera.

<figure><img src="/files/0NctUQ0oSfHGExaFP4vQ" alt=""><figcaption></figcaption></figure>

### Credentials via descompress file .xlsx

Los archivos `.xlsx` son en realidad archivos `.zip` con una estructura de carpetas XML definida por el formato Office Open XML. Por eso, podemos usar `unzip` o cualquier descompresor para inspeccionar su contenido. Al descomprimirlos, se revelan múltiples archivos, entre ellos `sharedStrings.xml`, que almacena todas las cadenas de texto de la hoja de cálculo.

<figure><img src="/files/MFt9k3C0FjJZaYWATNIA" alt=""><figcaption></figcaption></figure>

Al abrir el archivo `xl/sharedStrings.xml`, vemos que contiene credenciales (nombres de usuario y contraseñas en texto claro o enmascaradas), lo que sugiere que los datos estaban guardados directamente en la hoja sin ningún tipo de protección.

<figure><img src="/files/nIFjZtjtOnfFJmy7y8oj" alt=""><figcaption></figcaption></figure>

Extraemos los nombres de usuario del archivo XML y los guardamos en un archivo de texto (`users.txt`) para poder usarlos en ataques posteriores, como password spraying.

<figure><img src="/files/z0L5cx8jBMedB4qSAflq" alt=""><figcaption></figcaption></figure>

De la misma forma, extraemos las contraseñas encontradas y las almacenamos en un archivo (`passwords.txt`), que combinaremos con la lista de usuarios en pruebas de autenticación.

<figure><img src="/files/RNzbCcCPexknnMCrnYaX" alt=""><figcaption></figcaption></figure>

### Password Sprying

Con `nxc` realizamos un ataque de password spraying: probamos cada contraseña con todos los usuarios de forma controlada para evitar bloqueos por intentos fallidos. Así conseguimos acceso con el usuario `oscar` y la contraseña `86LxLBMgEWaKUnBG`.

<figure><img src="/files/84ixMorY9oWfvVBNrQVR" alt=""><figcaption></figcaption></figure>

Utilizamos las nuevas credenciales para volver a listar los recursos compartidos del servidor, pero no obtenemos acceso a ningún recurso adicional respecto a los que ya habíamos vist

<figure><img src="/files/Fa5UNhrtmWvmXXTBciA9" alt=""><figcaption></figcaption></figure>

### MSSQL credential access

El puerto correspondiente a Microsoft SQL Server (1433) está abierto. Probamos las credenciales `oscar:86LxLBMgEWaKUnBG` con `nxc mssql`, y aunque obtenemos un resultado positivo `[+]`, **no** vemos el mensaje `!Pwned`.\
**Diferencia:**

* `[+]` indica que la autenticación fue exitosa.
* `!Pwned` aparece cuando el usuario tiene permisos elevados (como ejecutar comandos con `xp_cmdshell`) o cuando el acceso es especialmente útil para una post-explotación inmediata

<figure><img src="/files/MoKkDrSx5nz6lT4lIzz1" alt=""><figcaption></figcaption></figure>

Al revisar nuevamente `sharedStrings.xml`, descubrimos el nombre de usuario `sa`.\
**¿Qué es `sa`?**\
`sa` es la cuenta **System Administrator** por defecto de Microsoft SQL Server. Tiene todos los privilegios y puede ejecutar cualquier comando dentro del servidor SQL.\
Probamos con la contraseña `MSSQLP@ssw0rd!` y esta vez sí obtenemos el mensaje `!Pwned`, lo cual indica que hemos logrado un acceso privilegiado al servidor SQL.

<figure><img src="/files/VzJC9wSDVthD74O2awuG" alt=""><figcaption></figcaption></figure>

Utilizamos la herramienta `mssqlclient.py` de Impacket para conectarnos de forma interactiva al servidor SQL como `sa`. Esto nos permite ejecutar consultas SQL directamente desde la terminal.

<figure><img src="/files/TUO5Zr6A9W8onY5a1KQW" alt=""><figcaption></figcaption></figure>

`xp_cmdshell` es una función extendida de SQL Server que permite ejecutar comandos del sistema directamente desde una consulta SQL.\
Por defecto, suele estar deshabilitada por seguridad.\
La activamos usando `enable_xp_cmdshell`

<figure><img src="/files/kzLmwV8PNjZeQPzhj9cw" alt=""><figcaption></figcaption></figure>

Utilizamos [revshells.com](https://www.revshells.com/) para generar una reverse shell en PowerShell codificada en **base64**.\
**¿Por qué en base64?**\
Al ejecutar comandos por `xp_cmdshell`, a veces se limitan los caracteres especiales. Codificar el payload en base64 permite evitar problemas de codificación, evasión de detección y asegurar que todo el contenido del comando llegue correctamente.

<figure><img src="/files/4AFDjNovrZcaIlav0iBN" alt=""><figcaption></figcaption></figure>

Copiamos el payload generado en PowerShell codificado en base64 y lo ejecutamos desde `mssqlclient` con `xp_cmdshell`, lo que hará que la máquina víctima intente conectarse a nuestro equipo en modo reverso.

<figure><img src="/files/D0oRPxEbxSGHpxgh6unH" alt=""><figcaption></figcaption></figure>

Configuramos nuestro listener con `rlwrap` (para tener historial de comandos) y `nc` (Netcat) escuchando en el puerto 443. Al ejecutarse la reverse shell en la máquina víctima, se establece una conexión de vuelta hacia nuestro listener, dándonos acceso remoto a una shell en la máquina comprometida.

<figure><img src="/files/j7HPOFCtN6kIGKcxVwfV" alt=""><figcaption></figcaption></figure>

## Shell ryan&#x20;

### **Credentials Exposed in SQL Server Configuration File**

Durante la enumeración del sistema de archivos desde la shell o desde recursos compartidos SMB, encontramos un directorio llamado **SQL2019**, lo cual sugiere que esta máquina tiene instalada una instancia de Microsoft SQL Server 2019.

<figure><img src="/files/cQrsFiJo8cwZxUpV6RzL" alt=""><figcaption></figcaption></figure>

Dentro del directorio `SQL2019`, hay una subcarpeta llamada **ExpressADV\_ENU** que contiene el archivo `sql-Configuration.INI`. Este archivo se utiliza durante la instalación de SQL Server y, a menudo, incluye configuraciones importantes, incluyendo credenciales si no se eliminan correctamente tras la instalación

<figure><img src="/files/yxDiIkeEFalOHzdJnVZB" alt=""><figcaption></figcaption></figure>

Al abrir el archivo `sql-Configuration.INI`, observamos una contraseña nueva que no coincide con ninguna de las que habíamos encontrado anteriormente. Este tipo de archivos puede revelar credenciales en texto plano si no han sido limpiados después de la instalación del servidor SQL.

<figure><img src="/files/lgl89cerhOKdIg3uyAEF" alt=""><figcaption></figcaption></figure>

### Password Spraying <a href="#password-spraying-1" id="password-spraying-1"></a>

Añadimos la nueva contraseña al archivo `pass.txt`, y con `nxc ldap` realizamos un ataque de **password spraying**: probamos esa contraseña contra todos los usuarios conocidos del dominio. Como resultado, descubrimos que esta contraseña funciona con dos usuarios:

* `ryan`
* `sql_svc`\
  Esto nos da potencial acceso con ambos.

<figure><img src="/files/6pAAhXXCeJ2c25Hx5fK9" alt=""><figcaption></figcaption></figure>

Probamos si el usuario `ryan` tiene acceso al servicio **WinRM (Windows Remote Management)** usando `nxc winrm`. El resultado nos muestra `!Pwned`, lo cual indica que las credenciales son válidas **y** que el usuario tiene permiso para acceder remotamente mediante WinRM. Esto nos permite obtener una shell remota de forma interactiva usando **Evil-WinRM**.

<figure><img src="/files/bFYRRy6rJQJBPN8YvF6s" alt=""><figcaption></figcaption></figure>

### Evil-winrm access

Usamos la herramienta `evil-winrm` para conectarnos a la máquina con el usuario `ryan`.

{% hint style="success" %}
**¿Qué es Evil-WinRM?**\
`evil-winrm` es una herramienta de acceso remoto para sistemas Windows que aprovecha el servicio WinRM. Permite obtener una shell interactiva, subir archivos, ejecutar scripts de PowerShell, entre otras funciones útiles para la post-explotación.
{% endhint %}

Una vez dentro, validamos que hemos obtenido acceso a la máquina como `ryan` y localizamos la primera flag, confirmando que se ha logrado el acceso inicial con éxito.

<figure><img src="/files/BWPCe5RzXVY6eeLqw6t7" alt=""><figcaption></figcaption></figure>

## Auth sa\_svc

### Bloodhound

Para continuar con la post-explotación, necesitamos analizar las relaciones y permisos dentro del dominio Active Directory. Para ello, utilizamos **BloodHound**, una herramienta que permite mapear rutas de ataque dentro de un dominio Windows a través del análisis de relaciones entre usuarios, grupos, equipos y permisos delegados.

{% hint style="success" %}
**¿Qué es BloodHound?**\
Es una herramienta de análisis de gráficos que identifica posibles rutas de ataque en Active Directory. Representa visualmente cómo un atacante podría moverse lateralmente o escalar privilegios dentro de una red Windows.
{% endhint %}

{% hint style="success" %}
**¿Qué es el collector de NetExec?**\
NetExec (`nxc`) incluye una funcionalidad que permite recolectar automáticamente toda la información necesaria para BloodHound: relaciones de usuarios, pertenencia a grupos, permisos delegados, ACLs, etc. El resultado es un archivo `.zip` que luego puede ser cargado en la interfaz de BloodHound para su análisis.
{% endhint %}

<figure><img src="/files/fi8SCfb5rHB5sUZ27lVp" alt=""><figcaption></figcaption></figure>

El archivo `.zip` generado por el collector de NetExec lo movemos a nuestro directorio de trabajo para tenerlo organizado. Podemos renombrarlo si queremos, aunque no es estrictamente necesario.

<figure><img src="/files/QwZ9Whd3MvumSpIg0xRa" alt=""><figcaption></figcaption></figure>

Para ejecutar BloodHound y cargar los datos, se recomienda seguir la guía oficial de BloodHound, donde se detallan los pasos para ejecutar la interfaz gráfica y cargar el archivo `.zip` con la información recolectada.

{% embed url="<https://bloodhound.specterops.io/get-started/quickstart/community-edition-quickstart#bloodhound-community-edition-quickstart>" %}

Una vez desplegado BloodHound, accedemos a su interfaz gráfica y cargamos el archivo `.zip`. Luego, en la ventana de "exploración", podemos buscar cualquier entidad del dominio (usuarios, equipos, grupos) para investigar relaciones y permisos.

<figure><img src="/files/d7LvEg3wDd0ya5xukfjs" alt=""><figcaption></figcaption></figure>

Buscamos al usuario `ryan` y observamos que tiene el permiso **WriteOwner** sobre el usuario `ca_svc`.\
Este permiso indica que `ryan` puede cambiar el propietario del objeto `ca_svc`, lo cual puede usarse como primer paso para escalar privilegios mediante la toma de control completo de ese usuario.

<figure><img src="/files/CLoGLLZWXdXT3N3UrMDn" alt=""><figcaption></figcaption></figure>

### Gain control ca\_svc

Utilizamos **bloodyAD**, una herramienta diseñada para automatizar la explotación de delegaciones de permisos en Active Directory. En este caso, aprovechamos que el usuario `ryan` tiene el permiso **WriteOwner** sobre `ca_svc`, lo cual nos permite cambiar el propietario del objeto y asignarnos permisos completos (`GenericAll`).

Una vez completado este proceso, obtenemos control total sobre la cuenta `ca_svc`.

<figure><img src="/files/FUQLAg5kxc9xaJaLSjYf" alt=""><figcaption></figcaption></figure>

Con esto, obtenemos el control completo sobre la cuenta `ca_svc` .

### Shadow Credential Attack

Como tenemos acceso total al usuario ca\_svc, usaremos certipy-ad para efectuar el ataque shadow credential attack. Al finalizar, obtuvimos un TGT válido y la caché de credenciales (.ccache) para ca\_svc, así como su hash NTLM, sin necesidad de modificar la contraseña ni generar alertas visibles.

**Explicación:**

* **¿Qué es Certipy-AD?**\
  Es una herramienta ofensiva escrita en Python que permite enumerar, explotar y abusar de configuraciones vulnerables en Active Directory Certificate Services (ADCS). También permite realizar autenticaciones Kerberos, solicitar certificados, realizar Pass-the-Cert, entre otras funciones.
* **¿Qué es el ataque Shadow Credentials?**\
  Este ataque permite registrar una clave pública maliciosa (usando atributos como `msDS-KeyCredentialLink`) en el objeto del usuario víctima, sin necesidad de conocer su contraseña. Una vez hecho esto, el atacante puede obtener un TGT válido y autenticarse como ese usuario usando Kerberos (PKINIT), de forma completamente indetectable para muchas soluciones de seguridad, ya que no se cambia la contraseña ni se generan eventos sospechosos.

El resultado es:

* TGT válido para `ca_svc`
* Archivo `.ccache` (credenciales Kerberos)
* Hash NTLM del usuario

<figure><img src="/files/znCobAOgxeBicA3lrP8l" alt=""><figcaption></figcaption></figure>

## Administrator access

### ESC4 exploitation <a href="#esc4-exploitation-case-with-certipy-a-d" id="esc4-exploitation-case-with-certipy-a-d"></a>

* **¿Qué es ESC4?**\
  Es una de las vulnerabilidades dentro del ecosistema ADCS. Se produce cuando un usuario tiene **GenericAll** u otros permisos peligrosos sobre una plantilla de certificado que permite autenticación de cliente.\
  Esto le permite al atacante modificar la plantilla para emitir certificados en nombre de cualquier otro usuario, incluyendo administradores.
* **¿Qué es ADCS?**\
  Active Directory Certificate Services es un componente de Windows Server que permite implementar una infraestructura de clave pública (PKI) para emitir certificados digitales dentro de un entorno de Active Directory.

Si no se configuran adecuadamente los permisos sobre las plantillas, los atacantes pueden explotarlas para obtener acceso privilegiado al dominio.

<figure><img src="/files/j3djal6vfsm1YosFnG2N" alt=""><figcaption></figcaption></figure>

Este comando con **certipy-ad** nos permite buscar plantillas de certificados vulnerables a varios vectores (incluido ESC4).\
En este caso se detecta que `DunderMifflinAuthentication`:

* Permite autenticación como cliente
* Está habilitada
* El usuario `ca_svc` (o su grupo) tiene permisos como WriteDACL, WriteOwner, FullControl

Esto la convierte en una plantilla vulnerable a ESC4.

```bash
certipy-ad find -u ca_svc@sequel.htb -hashes ':3b181b914e7a9d5508ea1e20bc2b7fce' -dc-ip 10.10.11.51 -vulnerable -stdout
```

<figure><img src="/files/hXbBIyJ4e9LePzumlRrD" alt=""><figcaption></figcaption></figure>

Seguiremos los siguientes pasos para poder abusar del ESC4 en el ADCS.

{% embed url="<https://gzzcoo.gitbook.io/pentest-notes/active-directory-pentesting/active-directory-certificate-services-adcs#esc4>" %}

Con los permisos de `ca_svc`, modificamos los parámetros de la plantilla para poder emitir certificados personalizados.\
Antes de realizar cambios, guardamos la configuración original por seguridad.

Esto nos permite emitir certificados válidos en nombre de cualquier usuario del dominio, incluyendo el usuario `Administrator`.

<figure><img src="/files/gN7mBUSOP6NENqsnjFFa" alt=""><figcaption></figcaption></figure>

Se confirmó que:

* Los permisos peligrosos siguen existiendo
* La plantilla sigue marcada como vulnerable
* La explotación sigue siendo posible

```bash
certipy-ad find -u ca_svc@sequel.htb -hashes ':3b181b914e7a9d5508ea1e20bc2b7fce' -dc-ip 10.10.11.51 -vulnerable -stdout
```

<figure><img src="/files/8FXy5soZ3Hfu1hoRqLUw" alt=""><figcaption></figcaption></figure>

Utilizamos `certipy-ad` para solicitar un certificado con el **UPN (User Principal Name)** del usuario `Administrator`.\
Este certificado fue guardado en formato `.pfx`, lo que nos permite usarlo posteriormente para autenticarnos como ese usuario mediante técnicas como **Pass-the-Cert**.

<figure><img src="/files/9HDWK8LnGUrL4iqU5SIi" alt=""><figcaption></figcaption></figure>

Realizamos una autenticación Kerberos como `Administrator` usando el certificado `.pfx` generado previamente.\
Esto nos permite:

* Obtener un TGT válido
* Recuperar el hash NTLM del usuario `Administrator`

Todo sin necesidad de conocer su contraseña.

<figure><img src="/files/28IpYLHtRZEKw0ZSrGWO" alt=""><figcaption></figcaption></figure>

### Pass The Hash and Administrator access

Ya con el **hash NTLM** del usuario `Administrator`, probamos acceder por **WinRM**, un protocolo que permite ejecución remota de comandos en sistemas Windows. Verificamos que el acceso está permitido.

<figure><img src="/files/qW63RVOPnuaKa4zsem9Q" alt=""><figcaption></figcaption></figure>

Utilizamos **Evil-WinRM**, una herramienta que facilita el acceso remoto interactivo a través de WinRM cuando se tienen credenciales válidas.\
Con ello, logramos acceso remoto a la máquina como `Administrator`.

<figure><img src="/files/n9KxFH1YbIKOFBmVCynw" alt=""><figcaption></figcaption></figure>

Con acceso como `Administrator`, ya podemos leer la flag `root.txt`  y completar la máquina con privilegios máximos.

<figure><img src="/files/tFZ3KeBrek9LGrdqY7Sd" alt=""><figcaption></figcaption></figure>

***

## Conclusion

La máquina *EscapeTwo* simula un entorno corporativo realista donde, partiendo de un usuario de bajo privilegio, se consigue comprometer completamente un dominio Windows. A través de una secuencia bien estructurada de técnicas —desde la explotación de recursos SMB, extracción de credenciales en archivos .xlsx corruptos, ataques como password spraying y abuso de servicios como MSSQL y WinRM— se logra escalar privilegios progresivamente. El uso de herramientas como BloodHound permite identificar configuraciones inseguras en Active Directory, como el mal uso de ADCS, que finalmente otorgan el control total del dominio.
