# Forest

<table data-header-hidden data-full-width="true"><thead><tr><th width="175.99993896484375" align="center"></th><th width="227.60003662109375" align="center" valign="middle"></th></tr></thead><tbody><tr><td align="center"><strong>Platform</strong></td><td align="center" valign="middle">HackTheBox</td></tr><tr><td align="center"><strong>O.S</strong></td><td align="center" valign="middle"><mark style="color:blue;">Windows</mark></td></tr><tr><td align="center"><strong>Level</strong></td><td align="center" valign="middle"><mark style="color:green;">Easy</mark></td></tr><tr><td align="center"><strong>Skills</strong></td><td align="center" valign="middle"><p>AS-REP Roasting</p><p>LDAP enumeration</p><p>WriteDACL</p></td></tr></tbody></table>

## Fase 1: Reconocimiento

Escaneo inicial de todos los puertos de la máquina objetivo.

```yang
nmap -sS -p- --open -n -Pn -vvv 10.10.10.161 -oN target 
```

<figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2FCFhuGEWJOZZGN6KeNeT2%2Fimage.png?alt=media&#x26;token=a76d44b3-4f02-4bac-8689-f4133b593a81" alt=""><figcaption></figcaption></figure>

Una vez escaneados los puertos abiertos, haré un escaneo de versiones (**-sV**) y un lanzamiento de scripts automáticos para cada puerto (**-sC**).

```yang
nmap -sCV -p88,135,389,445,5985 10.10.10.161 -oN ports
```

<figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2Fp4D6hHysPvvUSE34v5ih%2Fimage.png?alt=media&#x26;token=eae16824-a21c-4f96-b45e-0386cb58b66d" alt=""><figcaption></figcaption></figure>

Al no ver nada relevante, decido obtener más información básica acerca de la máquina objetivo: su nombre, nombre del dominio (si pertenece a uno), etc. Así que con ayuda de `crackmapexec` realizo una enumeración básica a través del protocolo SMB.

```yang
crackmapexec smb 10.10.10.161
```

<figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2FoBSWnoRgAR7RTbyqeMkD%2Fimage.png?alt=media&#x26;token=092c68c5-62a2-4ccb-b757-09b164248e4a" alt=""><figcaption></figcaption></figure>

Al obtener estos valores, decido añadir el nombre del host, el nombre del dominio y el FQDN (nombre\_host.nombre\_dominio) a mi fichero DNS (**/etc/hosts**), para que así resuelva estos nombres sin ningún inconveniente.

Lo siguiente que intento es observar si el host tenía la enumeración de shares habilitada, así no dispusiera de un usuario válido del dominio. Ya les adelanto que sin éxito.

Así que se me ocurre realizar una enumeración de objetos a través de LDAP, con la esperanza de que tuviera habilitado el acceso anónimo.

<div align="left"><figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2Fw9Ym79NavnLbqq6EeIwf%2Fimage.png?alt=media&#x26;token=bdaf4749-f315-4248-8dd9-6a9577be212c" alt=""><figcaption></figcaption></figure></div>

Efectivamente, sin proporcionar credenciales válidas, me ha dejado listar todos los objetos del dominio.

Mi objetivo con esto es sacar principalmente nombres de usuarios válidos e incluso, si existe, información adicional de cada usuario.&#x20;

Para realizar esta tarea de manera más amena hago uso de `jxplorer`.

<div align="left"><figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2FDlkADPCawRO8lDHdgwQn%2Fimage.png?alt=media&#x26;token=da8f1fa9-d33e-454e-8500-5cbd5c883f65" alt=""><figcaption></figcaption></figure></div>

Una vez conectado procedo a buscar usuarios y anotarlos todos en un fichero que ya usaré posteriormente para diversas acciones 😏.

Tener en cuenta que los nombres de usuarios que debemos guardar, son los que salen en el **UserPrincipalName**, ya que ese es el nombre con el cual se autentican contra el dominio.

<div align="left"><figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2FzBlV68UWQT24HU56mjS0%2Fimage.png?alt=media&#x26;token=951f9622-e87c-4ecd-af5e-4b71d44824e8" alt=""><figcaption></figcaption></figure></div>

<div align="left"><figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2FtSSX0nUqJ6Cq3NRkwrse%2Fimage.png?alt=media&#x26;token=1c7da776-d6cc-4c06-b2f2-a1e8b00ab27b" alt=""><figcaption></figcaption></figure></div>

## Fase 2: Explotación

Al tener una lista de usuarios válidos a nivel de dominio y al estar el puerto 88 abierto, me hace pensar que la autenticación interna seguramente se esté realizando a través de Kerberos (digo pensar como si fuera algo difícil, cuando esta autenticación es la más típica y lógica en entornos AD 😆).

Vale, ya sin bromas malas, en el proceso de autenticación kerberos se pueden producir varios ataques y uno de ellos es el `AS-REP Roasting`.

{% hint style="info" %}
¿En qué consiste?

En el proceso de autenticación en el protocolo Kerberos, suceden varias 'etapas' -> Para mejor entendimiento de esto, recomiendo ir y echarle un vistazo al artículo: [https://deephacking.tech/humilde-intento-de-explicar-kerberos/](https://deephacking.tech/humilde-intento-de-explicar-kerberos/) . Les aseguro que les hará ver todo este proceso y ataque más claro.
{% endhint %}

Bien, pues existen algunos usuarios configurados en el AD que tienen la preautenticación deshabilitada, esto significa que el **KDC no requiere que estos usuarios firmen su solicitud AS-REQ** con su contraseña (usando un timestamp cifrado), lo que permite que un atacante (yo 😆) pueda **solicitar un AS-REP cifrado sin conocer la contraseña** del usuario (que es nuestro caso).

Para simular este paso, existe una librería de `impacket` que nos automatiza el proceso y hace la petición al KDC por nosotros. Esta se llama `GetNPUsers`, vamos a ver como funciona en la práctica:

<figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2FNbTmQXckcUS2gsRt06iz%2Fimage.png?alt=media&#x26;token=0ebc0f5a-7dc7-4cc8-8f9b-3628434f63fd" alt=""><figcaption></figcaption></figure>

Para el uso simplemente tenemos que poner los parámetros vistos en el pantallazo anterior. Los últimos 2 son opcionales, aunque es recomendable especificar un formato que luego reconozca alguna herramienta de cracking offline (en este caso john, aunque ese mismo formato sirve también para hashcat) y además es cómodo almacenar el o los hashes encontrados en un fichero de salida en vez de simplemente mostrarlo por pantalla.

Ok, pues comprobamos que la cuenta del usuario `svc-alfresco` no requiere una preautenticación kerberos y por lo tanto nos ha respondido el KDC a nuestro AS-REQ con la clave de sesión cifrada con el hash de la contraseña del usuario.

{% hint style="info" %}
Las cuentas de servicio de Windows suelen tener esta preautenticación deshabilitada debido a que muchos servicios antiguos (bases de datos, ERP, aplicaciones internas) **no implementan correctamente Kerberos**, especialmente la parte de preautenticación y, por lo tanto, para que funcionen, **los admins desactivan la preauth** como “solución rápida”.
{% endhint %}

También pueden existir más causas como que estas cuentas se usen para tareas automáticas y para evitarse dolores de cabeza con el timestamp de Kerberos, los admins suelen desactivar esta función.

Volviendo al proceso, voy a crackear el trozo encriptado que hemos logrado capturar.

Para ello usaré `hashcat`.

El modo **18200** lo podemos encontrar en la web oficial de los ejemplos de hashcat:

{% embed url="https://hashcat.net/wiki/doku.php?id=example_hashes" %}

```yang
hashcat -a 0 -m 18200 hash.hash /usr/share/wordlists/rockyou.txt --status --status-timer 8
```

<figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2FyyaDRnuMI7iG3RveIa22%2Fimage.png?alt=media&#x26;token=d4077972-9086-40b2-bb7a-da0807be38ef" alt=""><figcaption></figcaption></figure>

Observo que se ha crackeado con éxito y que la contraseña del usuario `svc-alfresco` es ‘**s3rvice**’.

Compruebo si esta credencial es válida para realizar una conexión remota por `winrm`.

```yang
crackmapexec winrm 10.10.10.161 -u 'svc-alfresco' -p 's3rvice'
```

<figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2FDALaSXxaZzOdpAyHUCn7%2Fimage.png?alt=media&#x26;token=84d43ff2-3913-4017-a649-9d34aa3c7bfd" alt=""><figcaption></figcaption></figure>

Perfecto!

Me conecto desde mi kali con ayuda de `Evil-Winrm` y extraigo la flag del usuario, situada en su desktop.

<figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2FmJI7Q0re188Xo5WFR6j6%2Fimage.png?alt=media&#x26;token=eb256560-aa91-46db-9d79-723d7972f3eb" alt=""><figcaption></figcaption></figure>

## Fase 3: Post-Explotación

Lo primero que realizo es una enumeración de los grupos de los cuales forma parte mi usuario actual.

Puedo observar que existen unos cuantos grupos que no son los por defecto...

<figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2FHr2XNGcHrTH9ZW0xU1qF%2Fimage.png?alt=media&#x26;token=5465a064-00f9-43a7-995d-274800287eac" alt=""><figcaption></figcaption></figure>

Así que, sin perder mucho tiempo realizo una extracción de toda la información del dominio con `Bloodhound-Python`, para posteriormente analizarla detenidamente con `Bloodhound` y descubrir si estos grupos a los que pertenece mi usuario poseen alguna posible ruta de escalada.

La instalación de la herramienta de extracción utilizada es la siguiente:

```bash
# Creación de entorno virtual con python para que no cause problemas con más dependencias
python3 -m venv nombre_entorno

# Activación del entorno
source nombre_entorno/bin/activate

# Instalación del recolector de bloohound para python
pip install bloodhound
```

<figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2FNVJCjJIbex4lFQ182r0C%2Fimage.png?alt=media&#x26;token=a8d76179-cb64-4a9d-8473-1d841fb5df7f" alt=""><figcaption></figcaption></figure>

Recolectada la información, procedo a subir el zip que me ha generado mi herramienta a Bloodhound.

<figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2FVeLQxdgljQ3tZxtexKES%2Fimage.png?alt=media&#x26;token=821a9479-cecb-4bea-8847-e28f9bed8778" alt=""><figcaption></figcaption></figure>

Bueeeeno, al analizar el grupo ‘**Account operators**’ puedo ver que posee control total del grupo ‘**Exchange Windows Permissions**’ que, a su vez, tiene la ACE ‘**WriteDacl**’ sobre el dominio.

Bien, resumiendo esto, mi usuario posee la capacidad de leer y **modificar** las ACEs dentro de las DACL del dominio, es decir que me puedo otorgar permisos interesantes 😏.

Para empezar con la explotación de esa ACE vulnerable, tengo que formar parte del grupo ‘**Exchange Windows Permissions**’. Al tener control total sobre este grupo, pues simplemente agrego mi usuario a este grupo 😆.

Tener en cuenta que para realizar esta acción, he decidido hacerlo desde una consola `PowerShell`.

Puedes invocar una en kali, simplemente con el comando `pwsh`. 😉

<figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2Fhrl20Jfry8hSnXWZmPci%2Fimage.png?alt=media&#x26;token=44673b79-a9e9-4d45-b44b-d53e9bf5036c" alt=""><figcaption></figcaption></figure>

Ok, al pertenecer al grupo que quería desde un principio, puedo ahora agregar la ACE que yo quiera.

{% hint style="success" %}
En este caso, he optado por otorgarme permisos **DCSync**, para así poder actual como otro domain controller y poder leer información sensible del sistema (hashes de usuarios).
{% endhint %}

Para realizar esta tarea, decido utilizar la librería `dacledit` de impacket, ya que me parece súper cómoda.

<figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2F0MoyFHOOBfiyugGzpJ1Y%2Fimage.png?alt=media&#x26;token=d1d64b6c-ceb4-4f84-a12a-6461910e7297" alt=""><figcaption></figcaption></figure>

El comando leído, significa lo siguiente:

{% hint style="success" %}
Estoy creando una ACE (-action write), que le conceda permisos DCSync (-rights DCSync) al usuario svc-alfresco (-principal svc-alfresco) y que esta modificación la haga en la DACL del dominio en general, representado el objeto con el distinguishedname (-target-dn ‘DC=htb,DC=local’). Y por último que esta acción la realice el usuario svc-alfresco, el cual es el que posee la ACE ‘WriteDACL’ sobre este objeto (el dominio).
{% endhint %}

Al tener permisos DCSync, solo queda volcar los secretos del DC.

<figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2FfBRtvz1K3z3v3M3C9R4z%2Fimage.png?alt=media&#x26;token=1685a1c8-d323-4f60-8f8f-303329bbfe4d" alt=""><figcaption></figcaption></figure>

Y al ver tener en mi mano el hash NTLM del administrador, solo me queda realizar un PtH y conectarme a la máquina como admin.

La flag del root se encuentra en el desktop.

<figure><img src="https://1013496781-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FdV6HDOsFEFEo7m3Rwr8R%2Fuploads%2FmSMdLt1jVevYhPQePXFC%2Fimage.png?alt=media&#x26;token=16384f18-601a-4ffa-b05a-201b6675417a" alt=""><figcaption></figcaption></figure>
