search
Medium Articles 📚🎵GitHub 👾KerberosCity

unitySupport

Dificultad: Easy - OS: Windows

chevron-right¯\_( ͡° ͜ʖ ͡°)_/¯ Machine infohashtag

Support se centra en una máquina Windows dentro de un entorno de Active Directory y propone un recorrido que combina técnicas de enumeración de servicios, ingeniería inversa y ataques de delegación en entornos corporativos. Desde el inicio, se expone un vector de entrada a través de un recurso compartido SMB que permite acceso anónimo. A partir de allí, se accede a un ejecutable sospechoso que se analiza mediante decompilación para descubrir credenciales codificadas que permiten autenticarse en el servicio LDAP de la misma máquina. Este primer tramo del reto establece el uso de técnicas fundamentales de enumeración de red y análisis estático de binarios.

Una vez obtenido acceso al servicio LDAP gracias a la contraseña extraída del ejecutable, el atacante puede realizar consultas al directorio y obtener información clave sobre los usuarios. Este descubrimiento revela un usuario legítimo del sistema, junto con su contraseña filtrada en un campo del directorio. Con estas credenciales, se obtiene una sesión remota a través de WinRM, lo cual permite pivotar a una fase más avanzada del ataque. Aquí, se recurre a herramientas de post-explotación como SharpHound y BloodHound para analizar relaciones dentro del dominio, exponiendo privilegios mal configurados que el usuario comprometido tiene sobre el controlador de dominio.

La fase final del desafío explota estas configuraciones débiles mediante un ataque de delegación restringida basada en recursos (Resource-Based Constrained Delegation). Esta técnica permite al atacante suplantar identidades dentro del entorno del dominio y ejecutar código como el usuario más privilegiado del sistema, NT AUTHORITY\SYSTEM.

hashtag
Enumeración de puertos/servicios

┌──(root㉿kali)-[/home/kali/Documents/HTB]
└─# nmap -sCV --open -T4 -v -n 10.10.11.174
chevron-right📌 Parámetros hashtag

  • sCV:

    • -sC → Ejecuta scripts de detección predeterminados → Usa los scripts de nmap ubicados en /usr/share/nmap/scripts/, los cuales buscan información adicional en los puertos abiertos.

    • -sV → Detección de versiones → Intenta identificar el software y su versión en los puertos abiertos.

  • -n → No resuelve nombres de dominio (reduce el tiempo del escaneo).

  • --open → Muestra solo puertos abiertos → Filtra la salida para no mostrar puertos cerrados o filtrados.

  • -T4 → Ajusta la velocidad del escaneo → T4 es un nivel "agresivo" que acelera el escaneo, útil en redes rápidas.

  • -v → Modo verbose → Muestra más detalles sobre el progreso del escaneo.

Resultado:

PORT     STATE SERVICE       VERSION
53/tcp   open  domain        Simple DNS Plus
88/tcp   open  kerberos-sec  Microsoft Windows Kerberos (server time: 2025-05-12 03:51:57Z)
135/tcp  open  msrpc         Microsoft Windows RPC
139/tcp  open  netbios-ssn   Microsoft Windows netbios-ssn
389/tcp  open  ldap          Microsoft Windows Active Directory LDAP (Domain: support.htb0., Site: Default-First-Site-Name)
445/tcp  open  microsoft-ds?
464/tcp  open  kpasswd5?
593/tcp  open  ncacn_http    Microsoft Windows RPC over HTTP 1.0
636/tcp  open  tcpwrapped
3268/tcp open  ldap          Microsoft Windows Active Directory LDAP (Domain: support.htb0., Site: Default-First-Site-Name)
3269/tcp open  tcpwrapped
5985/tcp open  http          Microsoft HTTPAPI httpd 2.0 (SSDP/UPnP)
|_http-server-header: Microsoft-HTTPAPI/2.0
|_http-title: Not Found
Service Info: Host: DC; OS: Windows; CPE: cpe:/o:microsoft:windows

Host script results:
| smb2-security-mode: 
|   3:1:1: 
|_    Message signing enabled and required
| smb2-time: 
|   date: 2025-05-12T03:52:11
|_  start_date: N/A
|_clock-skew: -8m58s

En síntesis:

Añadimos el controlador de dominio (DC) que nos muestra nmap a nuestro archivo /etc/hosts

Nota: de esta forma logramos que el sistema pueda resolver correctamente ese nombre cuando se utilicen herramientas que lo requieran. En entornos de Active Directory, muchos servicios como Kerberos, SMB o WinRM necesitan que el nombre de dominio esté correctamente mapeado a una IP para funcionar. Si este mapeo no existe, comandos y herramientas que dependen del nombre del dominio podrían fallar.

hashtag
SMB Enumeration con Enum4linux-ng

Ahora vamos a extraer más información del objetivo con enum4linux-ng conectándonos como guest

chevron-right📌 Parámetros hashtag

Este comando realiza una enumeración agresiva sobre el objetivo support.htb, autenticándose como el usuario SUPPORT/guest con una contraseña vacía. Vamos a desglosarlo:

  • -A: modo agresivo. Ejecuta todos los módulos disponibles para recopilar la máxima cantidad de información, incluyendo:

    • Enumeración de usuarios y grupos.

    • Listado de shares y permisos.

    • Información sobre el sistema operativo y configuración del dominio.

    • Enumeración de políticas de contraseñas y SID.

  • support.htb: nombre del host objetivo, debe resolverse a una IP válida (por /etc/hosts o DNS).

  • -u SUPPORT/guest: usuario con el que se autentica. Aquí se usa el dominio SUPPORT y el nombre de usuario guest.

  • -p "": contraseña vacía (comillas dobles para especificar que es un string vacío).

Encontramos el FQDN que también es importante agregarlo al fichero /etc/hosts. El DNS domain es el contenedor lógico (support.htb), y el FQDN es la identificación completa de un equipo específico dentro de ese contenedor (dc.support.htb).

hashtag
¿Por qué es válido usar el usuario guest en herramientas como enum4linux?

En muchos sistemas Windows mal configurados (o con configuraciones predeterminadas antiguas), existe una cuenta de invitado llamada Guest o guest que permite autenticación con privilegios mínimos o incluso sin contraseña. Aunque tiene accesos limitados, puede usarse para:

  • Enumerar shares públicos (smbclient -L).

  • Obtener información básica del dominio o de usuarios a través de rpcclient o enum4linux.

  • Validar si el sistema permite autenticación anónima

De los recursos que se enumeraron del SMB hay uno que se llama support-tools allí vamos a ingresar para inspeccionar su contenido usando smbclient.

hashtag
Extracción de credenciales hardcodeadas mediante Reverse Engineering

El recurso que nos interesa descargar para analizar de forma local es el UserInfo.exe.zip. Si analizamos las secuencias de caracteres con strings vamos a ver que se trata de un programa codeado en .NET. Entonces lo siguiente que debemos hacer es decompilarlo con alguna tool como ILSpy para analizar su código fuente en busca de credenciales hardcodeadas. Para instalar y ejecutar este programa en kali seguimos estos pasos:

Luego descomprimimos el UserInfo.exe.zip y abrimos el ejecutable con ILSpy

Las funciones críticas que nos interesan son LdapQuery y Protected, allí encontraremos la forma en que el binario codifica las contraseñas y también un posible usuario del sistema.

chevron-right📌 Funciones críticashashtag

hashtag
1. Función crítica: Protected.getPassword()

Esta función está diseñada para ocultar una contraseña embebida dentro del binario. Utiliza una estrategia de ofuscación común: codifica la contraseña con Base64 y luego aplica una operación de doble XOR (primero con una clave estática "armando" y luego con el valor constante 0xDF). Al ejecutarse, esta función devuelve la contraseña en texto claro, necesaria para autenticarse en el servidor LDAP.

Importancia crítica: Esta función actúa como la clave de acceso a los servicios internos del dominio. Oculta credenciales en el binario, pero permite recuperarlas mediante ingeniería inversa.

hashtag
2. Función crítica: LdapQuery()

LdapQuery() es el segundo componente esencial. Una vez que getPassword() retorna la contraseña en texto claro, esta función la utiliza para establecer una conexión LDAP contra el servidor support.htb. Crea un objeto DirectoryEntry con el usuario support\ldap y la contraseña obtenida, y luego instancia un DirectorySearcher que permite consultar objetos del directorio activo.

Importancia crítica: Esta función transforma la contraseña en un vector de acceso real al dominio. Gracias a ella, el binario puede interactuar con el servidor LDAP y realizar consultas, como buscar usuarios por nombre. Es la funcionalidad principal de la herramienta, cuya intención aparente es listar información de usuarios del sistema.

hashtag
3. Relación entre ambas funciones

  • getPassword() alimenta al la función LdapQuery() con la credencial necesaria.

  • LdapQuery() aprovecha esa credencial para autenticarse y ejecutar búsquedas LDAP.

  • Estas dos funciones forman una cadena de ejecución crítica, en la que la primera rompe la ofuscación y la segunda establece una conexión de red privilegiada.

Juntas, habilitan la extracción de información sensible del dominio, como la lista de usuarios, atributos de cuenta, y potencialmente datos filtrados.

Este patrón es típico de aplicaciones internas que intentan ocultar credenciales pero que, al quedar embebidas en un ejecutable, pueden ser recuperadas fácilmente mediante reversing.

Entonces la contraseña que vamos a descifrar es

0Nv32PTwgYjzg9/8j5TbmvPd3e7WhtWWyuPsyO76/Y+U193E

Y vamos a hacerlo con CyberChefarrow-up-right. Pero primero repasemos cómo es cifrada la contraseña:

  • La función getPassword() en el binario replica exactamente esta lógica:

    1. Decodifica la contraseña de Base64.

    2. Aplica un XOR con la clave "armando" (cíclico).

    3. Aplica un XOR con 0xDF.

    4. Devuelve la contraseña como string.

  • La función LdapQuery() usa esta contraseña para conectarse a un servidor LDAP con el usuario support\ldap.

chevron-right📌 ¿Qué es XOR?hashtag

XOR (abreviación de "exclusive OR") es una operación lógica a nivel de bits. Toma dos valores binarios (bits) y devuelve:

  • 1 si son diferentes (uno es 0 y el otro es 1),

  • 0 si son iguales (ambos 0 o ambos 1).

A nivel de bytes, si hacés un XOR entre dos bytes, estás comparando cada bit uno a uno.

hashtag
¿Cómo se descifra en CyberChef?

Para revertir este proceso y obtener la contraseña original, replicamos las operaciones en orden inverso:

1. From Base64

Decodificamos el string para obtener los bytes ofuscados.

2. XOR con "armando"

Aplicamos XOR con la clave armando. Esto revierte la primera capa del cifrado.

3. XOR con DF (hex)

Aplicamos un XOR final con el valor 0xDF a cada byte. Esto revierte la segunda capa aplicada durante el cifrado.

hashtag
User enumeration con imapcket-lookupsid

Y así logramos descifrar la contraseña: nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz que corresponde al usuario ldap. Ahora, algo que puede suceder en otro escenario como este es que no contemos con un usuario para usar junto con la contraseña, entonces lo que podemos hacer es enumerar usuarios con el script impacket-lookupsid para luego armar una lista de usuarios, validarlos con kerbrute y buscar aquel que haga el match con la contraseña mediante la técnica password spraying. Para obtener la lista de usuarios parceada diseñe el siguiente script en bash que tira de impacket-lookupsid y edita el output del script para volcar los nombres en limpio dentro de una lista llamada users_enum.txt. Para obtenerlo podes ir al siguiente repositorio lookupsid_enum.sharrow-up-right

Usaremos la lista de usuarios que generamos para validarlos con Kerbrute. Aunque este paso no es estrictamente necesario, nos permite confirmar cuáles de esos usuarios existen realmente en el Active Directory

chevron-right📌 Parámetros hashtag

  • userenum: modo de enumeración de usuarios. Envia solicitudes AS_REQ sin preautenticación para verificar qué usuarios existen (basado en la respuesta del KDC).

  • -d support.htb: el dominio en el que se está realizando la enumeración. Se utiliza para construir el SPN o principal Kerberos (user@DOMAIN).

  • --dc dc.support.htb: servidor objetivo, usualmente el controlador de dominio (Domain Controller). Se conecta al puerto 88 (Kerberos).

  • usernames.txt: archivo con la lista de posibles usuarios a validar.

  • -v: salida detallada que indica cuál usuario es válido, inválido, o si hubo errores de comunicación.

hashtag
Password spraying con Kerbrute

Una vez que nos aseguramos que todos los usuarios de la lista son válidos podemos buscar el match con la contraseña usando el módulo passwordspray de kerbrute

chevron-right📌 Parámetros hashtag

  • passwordspray: modo de ataque. Usa una sola contraseña contra múltiples usuarios para evitar bloqueos de cuenta. Es ideal para ambientes con políticas de lockout agresivas.

  • -d support.htb: define el nombre del dominio de Active Directory. Este valor se usará para construir los tickets Kerberos (principalmente en el campo user@REALM → usuario@support.htb).

  • --dc dc.support.htb: indica el FQDN o IP del Domain Controller al que se enviarán las solicitudes Kerberos (puerto 88 por defecto).

  • usernames.txt: archivo de entrada que contiene la lista de usuarios a probar.

  • 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz': contraseña que se probará contra todos los usuarios del archivo. Se encierra entre comillas simples para evitar que caracteres como ^, $, % sean interpretados por el shell.

  • -v: modo verbose, imprime el resultado de cada intento, útil para análisis en tiempo real.

chevron-right⚠️ Error detectado: Clock skew is too great (VALID LOGIN WITH ERROR)hashtag

Este error significa que hay una diferencia importante de tiempo entre la máquina atacante (Kali) y el servidor Kerberos del dominio (dc.support.htb). Kerberos es muy estricto con el tiempo y, por defecto, no permite diferencias mayores a 5 minutos entre cliente y servidor.

hashtag
¿Por qué es importante?

  • Kerberos usa timestamps en sus tickets.

  • Si hay desincronización, el servidor puede rechazar tickets válidos creyendo que son viejos, futuros o reusados (ataques de repetición).

  • Aunque kerbrute detectó que las credenciales son correctas, otros ataques Kerberos (como TGT, AS-REP roasting, o Pass-the-Ticket) van a fallar mientras este problema no se corrija.

¿Cómo solucionamos esto? Sincronizando el reloj de Kali automáticamente:

Una vez que logramos obtener un nuevo par de credenciales lo más recomendable es testear a que servicios nos podemos conectar/logear, de esta forma tendremos una idea de por donde continuar el ataque/intrusión. Para automatizar esta tarea diseñe un script en bash que lo podes obtener del siguiente repositorio: service_validation.sharrow-up-right

hashtag
LDAP Enumeration con Ldapsearch

Aprovechando que tenemos autorización para autenticarnos al LDAP vamos a realizar una búsqueda LDAP autenticada con ldapsearch dentro del dominio support.htb y extraeremos objetos del dominio en busca de

  • Usuarios y atributos (nombres, grupos, descripciones, contraseñas en campos como info, etc.).

  • Grupos y membresías.

  • Equipos del dominio.

  • Configuraciones de políticas o relaciones de confianza.

En este caso si filtramos la información por el sammacountname: y vemos las 36 líneas anteriores que corresponden al usuario en cuestión podremos leer toda la información de cada uno. Al revisar toda la información de los usuarios vamos a encontrar unas credenciales hardcodeadas pertenecientes al usuario support

  • grep -i "samaccountname: support" → busca (ignorando mayúsculas/minúsculas) la línea que contiene el nombre de cuenta support

  • -B 36 → muestra las 36 líneas anteriores a la línea que contiene el resultado buscado, para así capturar todo el bloque de atributos de esa entrada de usuario

chevron-right📌 Parámetros hashtag

  • ldapsearch → herramienta de línea de comandos para realizar consultas a servidores LDAP

  • -x → usa autenticación simple (no SASL)

  • -H ldap://10.10.11.174 → dirección y protocolo del servidor LDAP (controlador de dominio del CTF)

  • -D 'ldap@support.htb' → usuario con el que se autentica la consulta, en formato UPN

  • -w 'nvEfEK16^1aM4$e7AclUf8x$tRWxPWO1%lmz' → contraseña del usuario ldap

  • -b "DC=support,DC=htb" → base DN que define el punto de partida de la búsqueda, corresponde a la raíz del dominio

  • > ldap_enum.txt → redirige la salida de la consulta al archivo ldap_enum.txt para su análisis offline

Nota: en el formato de salida LDIF (LDAP Data Interchange Format), cada entrada de usuario comienza con una línea que contiene su dn: (Distinguished Name) y termina antes del siguiente dn: o al final del archivo.

Ahora que conseguimos otro par de credenciales nuevas podemos chequear cuales son los servicios a los que podemos acceder con el script service_validation.sh

hashtag
Active Directory Privilege Escalation Mapping con Bloodhound

Tenemos acceso a WinRM, por lo que podemos ingresar usando EvilWinRM y enumerar manualmente las características del usuario support en busca de privilegios o grupos para explotar

Por ahora lo que destaca de esta enumeración es el grupo SUPPORT\Shared Support Accounts y el privilegio SeMachineAccountPrivilege pero vamos a realizar una enumeración más exhaustiva con bloodhound para ver si existe alguna relación entre estos objetos y el domain controller que podamos explotar para lograr escalar privilegios. Para enumerar info con Bloodhound tenemos dos opciones:

1) Con bloodhound-python

Si no conoces esta herramienta a continuación te dejo un artículo introductorio para que puedas comprender su uso

hashtag
Primeros pasos en BloodHoundarrow-up-right

chevron-right📌 Parámetroshashtag

¿Qué hace?

  • Usa la herramienta bloodhound-python, una reimplementación de SharpHound para Linux, escrita en Python.

  • Se conecta al dominio support.htb usando el usuario y contraseña indicados.

  • -dc support.htb: especifica el FQDN del Domain Controller.

  • -ns 10.10.11.174: DNS que resuelve el nombre del DC.

  • -c All: indica que recolecte todas las categorías posibles, como:

    • ACLs, Trusts, Sessions, SPN targets, Group Memberships, etc.

  • --zip: empaqueta los resultados en un archivo .zip, listo para ser cargado directamente en la GUI de BloodHound.

  • -v: modo verbose, imprime información durante el proceso.

2) Con el módulo --bloodhound de nxc

chevron-right📌 Parámetroshashtag

¿Qué hace?

  • Utiliza nxc (NextCollector), una herramienta moderna escrita en Go, compatible con BloodHound.

  • Se conecta al servidor LDAP del Domain Controller (10.10.11.174) usando el usuario support.

  • Usa el plugin --bloodhound para recolectar datos útiles para gráficos de relaciones en BloodHound.

  • Se especifica un servidor DNS/Nameserver con -ns 10.10.11.174.

  • El parámetro -c selecciona qué tipos de datos recolectar, como:

    • Group: grupos de AD.

    • LocalAdmin: miembros del grupo Administradores locales.

    • RDP, DCOM, PSRemote: relaciones de acceso remoto.

    • Session, LoggedOn: sesiones activas.

    • Acl: delegaciones y permisos.

    • Trusts, Container: relaciones entre objetos y dominios.

📌 Resultado:

  • Genera archivos JSON con los datos recolectados para importar en BloodHound.

  • No requiere Python ni Windows, lo que lo hace ideal para ambientes mínimos o contenedores.

Una vez que tenemos el archivo con toda la información recolectada abrimos la gui de Bloodhound y volcamos el .zip para ver el mapa de relaciones entre objetos del dominio.

Si buscamos específicamente qué relaciones tiene el grupo SUPPORT\Shared Support Accounts con el dominio vamos a encontrar lo siguiente:

Este resultado nos indica lo siguiente:

  • BloodHound muestra que ese grupo tiene permisos excesivos (GenericAll) sobre el Domain Controller (DC.SUPPORT.HTB), lo que significa que tiene control total sobre ese equipo dentro del dominio.

  • Esto nos indica que podemos realizar una escalada de privilegios mediante la técnica llamada Resource-Based Constrained Delegation (RBCD).

  • Con RBCD, podriamos crear una máquina falsa, configurar delegación hacia el DC, y obtener un ticket Kerberos como Administrator, consiguiendo una shell como NT AUTHORITY\SYSTEM

  • Recordemos que el usuario support es miembro del grupo Shared Support Accounts por lo tanto también contamos indirectamente con el permiso GenericAll, entonces podemos usar esta cuenta para explotar el RBCD

hashtag
Resource-Based Constrained Delegation (RBCD) con Impacket

Si no conoces el funcionamiento de las delegaciones en Kerberos te recomiendo que antes leas el siguiente artículo donde explico los 3 tipos de delegación, Unconstrained Delegation, Constrained Delegation y Resource-Based Constrained Delegation, el último es el que explotáremos a continuación

hashtag
Kerberos delegationarrow-up-right

Paso 1) Crear y agregar una cuenta con impacket-addcomputer

¿Qué hace el script impacket-addcomputer?

Este script agrega una nueva cuenta de máquina (Computer Account) al dominio. Por defecto, en muchos entornos de Active Directory los usuarios del dominio tienen el privilegio de crear objetos de computadora (hasta 10, por defecto).

Objetivo del ataque: Agregar un equipo controlado por el atacante al dominio, lo cual habilita los siguientes escenarios:

  • Obtener un TGT para esa máquina (como si fuera legítima).

  • Realizar ataques de delegación como RBCD (Resource-Based Constrained Delegation).

  • Generar tickets Kerberos para suplantar usuarios privilegiados (como Administrator)

chevron-right📌 Parámetroshashtag

  • impacket-addcomputer → Script de la suite Impacket que permite agregar una cuenta de máquina (computer object) en Active Directory si el usuario tiene privilegios suficientes (como es común con cuentas autenticadas del grupo Domain Users).

  • -computer-name 'ATTACKCOMPUTER$' → Define el nombre que tendrá la nueva cuenta de máquina. El signo $ indica que es un objeto de tipo "computer", como se espera en AD.

  • -computer-pass 'AttackPassword123' → Contraseña asignada a la cuenta de computadora que se está creando. Será usada luego para autenticarse o generar tickets Kerberos (TGT).

  • -dc-ip 10.10.11.174 → Dirección IP del Domain Controller (DC) con el que se comunicará el script. Esto evita depender de la resolución DNS del nombre del dominio.

  • 'support.htb/support:Ironside47pleasure40Watchful' → Cadena de autenticación con el formato DOMINIO/usuario:contraseña. En este caso:

    • Dominio: support.htb

    • Usuario: support

    • Contraseña: Ironside47pleasure40Watchful

chevron-right📌 Explicación del outputhashtag

  • El usuario support con su contraseña fue capaz de autenticarse correctamente en el DC.

  • El script solicitó la creación de un nuevo objeto de tipo computadora (ATTACKCOMPUTER$) en el dominio support.htb.

  • La operación fue exitosa. El nuevo objeto ahora forma parte del dominio y está listo para ser utilizado en ataques Kerberos avanzados.

Paso 2) Desde la sesión de EvilWinRM verificamos si la cuenta de equipo que acabamos de crear fue agregada correctamente al dominio Active Directory. Esto es importante antes de lanzar ataques de delegación. El comando que vamos a usar desde PowerShell es el siguiente

  • Get-ADComputer → Cmdlet de PowerShell del módulo ActiveDirectory que permite consultar información de objetos de tipo "computadora" en el dominio. Requiere privilegios de red o ejecución local con acceso al dominio.

  • -Identity "ATTACKCOMPUTER$" → Especifica el nombre de la computadora que queremos buscar. El símbolo $ indica que es una cuenta de equipo, como se utiliza en AD para distinguirlas de cuentas de usuario.

Paso 3) Con impacket-rbcd vamos a configurar la delegación basada en recursos (RBCD) para esta nueva cuenta, permitiéndole actuar en nombre de otros usuarios sobre un objetivo (como el DC$). A las cuentas que tienen esta configuración se las denomina "delegantes autorizados".

hashtag
¿Qué hace este comando?

Este comando permite configurar delegación basada en recursos (RBCD) en un entorno Active Directory. En concreto, modifica el atributo msDS-AllowedToActOnBehalfOfOtherIdentity del equipo víctima (-delegate-to) para permitir que otro objeto (en este caso, un equipo que controlamos) pueda impersonar usuarios mediante el mecanismo S4U2Proxy.

Esto es esencial para explotar RBCD: primero se agrega una cuenta de equipo al dominio (con impacket-addcomputer), luego se le dan permisos sobre otro host con este comando.

chevron-right📌 Parámetroshashtag

  • -action write → Indica que se realizará una escritura en el atributo de delegación del objetivo. Es decir, se va a modificar la ACL del equipo de destino (-delegate-to) para permitir la delegación.

  • -delegate-from 'ATTACKCOMPUTER$' → Especifica quién recibirá los permisos de delegación. Es el nombre del equipo (objeto en el dominio) que podrá actuar en nombre de otros usuarios.

  • -delegate-to 'DC$' → Define quién será el objetivo de la delegación. Este es el nombre del equipo sobre el que queremos que ATTACKCOMPUTER$ pueda hacer impersonación (típicamente el DC).

  • -dc-ip 10.10.11.174 → IP del Domain Controller que se usará para hacer las consultas y modificaciones LDAP.

  • 'support.htb/support:Ironside47pleasure40Watchful' → Credenciales del usuario con permisos suficientes para modificar objetos en el dominio. Se usa el formato DOMINIO/usuario:contraseña.

chevron-right📌 Explicación del outputhashtag

  • [*] Accounts allowed to act on behalf of other identity: Muestra los objetos que actualmente tienen permiso para usar delegación sobre el equipo objetivo (en este caso, DC$).

  • [*] Delegation rights modified successfully! Confirmación de que la modificación fue exitosa. Se aplicó la nueva entrada ACL en msDS-AllowedToActOnBehalfOfOtherIdentity.

  • [*] ATTACKCOMPUTER$ can now impersonate users on DC$ via S4U2Proxy ¡Objetivo logrado! Ahora ATTACKCOMPUTER$ puede pedir tickets de servicio (TGS) para el DC$ en nombre de otros usuarios, lo que habilita el ataque RBCD.

Paso 4) Ahora podemos usar el equipo controlado (ATTACKCOMPUTER$) para impersonar usuarios (como Administrator) hacia el equipo víctima (DC$) usando S4U2Proxy. El siguiente paso es solicitar un TGT con impersonación utilizando impacket-getTGT.

chevron-right📌 Parámetroshashtag

  • support.htb/ATTACKCOMPUTER\$ → Especifica el nombre de usuario y el dominio. El símbolo \$ es necesario para escapar el carácter $ en shell, ya que indica una variable.

  • -p 'AttackPassword123' → Usa la contraseña en texto claro. Internamente, Impacket genera el hash NTLM automáticamente.

  • -dc-ip 10.10.11.174 → Dirección IP del Controlador de Dominio (DC) con el que se realiza la autenticación.

chevron-right📌Outputhashtag

[*] Saving ticket in ATTACKCOMPUTER$.ccache → El ticket TGT obtenido se guarda en un archivo .ccache, que puede utilizarse posteriormente en otros ataques Kerberos, como la solicitud de un TGS con getST o el uso directo mediante KRB5CCNAME.

En un ataque de Resource-Based Constrained Delegation (RBCD), obtener un TGT (Ticket Granting Ticket) es obligatorio antes de poder solicitar un TGS (Ticket Granting Service), ya que Kerberos requiere primero autenticarse con el KDC mediante un TGT para luego autorizar el acceso a un servicio específico mediante un TGS. En este contexto, la herramienta getTGT.py de Impacket se usa para generar ese TGT y lo guarda en un archivo .ccache, generalmente con un nombre basado en el dominio y el usuario. Para que getST.py pueda utilizar ese TGT y solicitar un TGS, es necesario exportar la variable de entorno KRB5CCNAME apuntando al archivo .ccache generado, de esta forma getST.py sabe automáticamente qué ticket utilizar. Por tanto, el flujo correcto en un ataque RBCD implica ejecutar getTGT.py, exportar KRB5CCNAME con el archivo generado, y luego usar getST.py con los parámetros adecuados para obtener un TGS válido e impersonar a un usuario objetivo.

Paso 5) Ahora vamos a configurar la variable de entorno KRB5CCNAME para que las herramientas que requieran de autenticación Kerberos (como impacket-psexec, evil-winrm, smbclient, etc.) utilicen el ticket Kerberos TGT, previamente generado y guardado en el archivo ATTACKCOMPUTER$.ccache. Este ticket TGT nos va a permitir obtener un TGS para impersonar al usuario Administrator. En otras palabras, es el paso que "inyecta" el ticket en el entorno para continuar el ataque sin volver a autenticarnos con contraseña o hash.

chevron-right📌 Parámetroshashtag

  • export → Comando de Bash que define una variable de entorno disponible para todos los procesos que se ejecuten desde esa terminal.

  • KRB5CCNAME → Variable de entorno específica de las herramientas que usan Kerberos. Define la ruta al archivo .ccache que contiene el ticket de Kerberos activo.

  • $(pwd) → Ejecuta el comando pwd (print working directory) y devuelve el directorio actual. Esto asegura que se use la ruta absoluta al archivo del ticket.

  • /ATTACKCOMPUTER$.ccache → Nombre del archivo que contiene el ticket TGT generado para el equipo ATTACKCOMPUTER$, el cual fue previamente agregado al dominio.

Paso 6) Ahora vamos a solicitar un Ticket de Servicio (TGS) válido para acceder al SPN cifs/dc.support.htb pero impersonando al usuario Administrator. Lo hacemos usando la cuenta de equipo delegada (ATTACKCOMPUTER$) que controlamos nosotros, gracias a la delegación S4U2Proxy que configuramos previamente.

chevron-right📌 Parámetroshashtag

  • support.htb/ATTACKCOMPUTER$ → Credenciales del equipo que tiene configurada la delegación. Lo usamos para autenticarnos y pedir el ticket TGS.

  • -spn cifs/dc.support.htb → SPN (Service Principal Name) del servicio al que queremos acceder. En este caso, CIFS (SMB) del DC.

  • -impersonate Administrator → Usuario que queremos suplantar (impersonar). En este ataque, buscamos suplantar al Administrator.

  • -dc-ip 10.10.11.174 → IP del Domain Controller (servidor de Active Directory) que procesará la petición Kerberos.

Aquí es donde ocurre la impersonación real:

  • S4U2Self: se pide un ticket de servicio (TGS) para el usuario Administrator, validado por el KDC (porque ATTACKCOMPUTER$ está autorizado para representar a otros).

  • S4U2Proxy: se solicita un segundo ticket válido para acceder al servicio cifs/dc.support.htb en nombre de Administrator.

chevron-right📌Outputhashtag

  • Password: → El script solicita la contraseña de ATTACKCOMPUTER$ si no se proporcionó el hash ni un TGT precargado.

  • [*] Impersonating Administrator → Se inicia el proceso de suplantación de Administrator.

  • [*] Requesting S4U2self → Solicita un TGS para el propio ATTACKCOMPUTER$ en nombre de Administrator (paso 1).

  • [*] Requesting S4U2Proxy → Solicita un TGS para Administrator hacia el SPN cifs/dc.support.htb (paso 2).

  • [*] Saving ticket in Administrator@cifs_dc.support.htb@SUPPORT.HTB.ccache → Guarda el ticket final como archivo .ccache.

Paso 7) Cargamos el ticket Kerberos (ccache) que obtuvimos con getST y que representa al usuario Administrator. Este ticket será usado automáticamente por cualquier herramienta compatible con Kerberos (como impacket-psexec), sin necesidad de ingresar contraseña ni hash. Es un paso esencial para simular que ya tenemos un "pase VIP" firmado por el KDC (Key Distribution Center).

Paso 8) Utilizamos el ticket cargado en el paso anterior con impacket-psexec, luego este se conecta al Domain Controller (dc.support.htb) y nos abre una sesión remota como Administrator. No nos pide credenciales porque ya tenemos un TGS válido en el archivo .ccache

chevron-right📌 Parámetroshashtag

  • -k → Indica que se usará autenticación Kerberos en vez de NTLM.

  • -no-pass → No solicita contraseña, ya que se usará el ticket .ccache.

  • dc.support.htb → Hostname del Domain Controller al que se conectará.

Si trasladamos todo este procedimiento a un gráfico, observaríamos algo así

chevron-right📌 Algunas aclaraciones más sobre lo visto en este ataquehashtag

1) ¿Cómo sabe el KDC que la cuenta ATTACKCOMPUTER$ está en el ACL del DC$?

El KDC no almacena ni consulta directamente el atributo msDS-AllowedToActOnBehalfOfOtherIdentity. Lo que hace es lo siguiente:

  • Cuando solicitamos un TGS en modo S4U2Proxy (es decir, queremos actuar en nombre de otro usuario, en este caso el Administrator), el KDC valida que el servicio objetivo (el SPN) haya autorizado al solicitante a actuar en nombre de otros.

  • El SPN pertenece a una cuenta de equipo o de servicio, en este caso, DC$, y es esa cuenta la que contiene el atributo msDS-AllowedToActOnBehalfOfOtherIdentity.

Entonces:

  • El KDC revisa el atributo msDS-AllowedToActOnBehalfOfOtherIdentity de la cuenta dueña del SPN solicitado (DC$).

  • Si en ese atributo está el SID de ATTACKCOMPUTER$, el KDC acepta la solicitud S4U2Proxy y emite el TGS.

Conclusión: El KDC no “sabe” directamente del ACL, pero sí consulta en LDAP si el solicitante (ATTACKCOMPUTER$) está autorizado a actuar en nombre de otros según la configuración de la cuenta de destino del SPN.

2) ¿Cómo es posible que el KDC nos devuelva un TGS del servidor CIFS si no modificamos especificamente su atributo msDS-AllowedToActOnBehalfOfOtherIdentity para agregar la cuenta ATTACKCOMPUTER$ como hicimos con el DC?

Esto tiene una respuesta corta y una importante distinción técnica:

  • En el comando que usamos con impacket-getST, el SPN solicitado es cifs/dc.support.htb, que pertenece a la cuenta del DC (DC$).

  • Anteriormente, cuando usamos impacket-rbcd -delegate-to DC$, ya habíamos agregado la cuenta ATTACKCOMPUTER$ al atributo msDS-AllowedToActOnBehalfOfOtherIdentity de DC$.

  • Por lo tanto, aunque el SPN diga cifs/dc.support.htb, sigue siendo parte de la cuenta DC$, y esa es la que autoriza la suplantación en ese servicio.

Importante: Si solicitáramos un TGS para cifs/otherhost.support.htb, que está en otra cuenta de equipo distinta, no funcionaría, salvo que modifiquemos el atributo msDS-AllowedToActOnBehalfOfOtherIdentity de ese otro host también.

3) ¿Qué es msDS-AllowedToActOnBehalfOfOtherIdentity?

Es un atributo de un objeto de equipo (computer object) en Active Directory, introducido con Windows Server 2012 para permitir una forma más flexible de delegación basada en recursos.

¿Qué almacena este atributo?

Contiene una ACL (Access Control List), en formato Security Descriptor, que define qué cuentas pueden actuar en nombre de otros usuarios cuando se accede a ese recurso. Específicamente, este atributo le dice a un equipo objetivo (en este caso el DC$):

“Si una petición llega desde el equipo ATTACKCOMPUTER$, está permitido que actúe como si fuera otro usuario (en este caso como Administrator).”

4) ¿Qué es un "delegante autorizado"?

En el contexto de RBCD, un "delegante autorizado" es cualquier cuenta (usualmente de equipo o servicio) que haya sido incluida en el atributo msDS-AllowedToActOnBehalfOfOtherIdentity del recurso objetivo.

Dicho de otro modo:

  • El objeto víctima, en este caso el DC, es quien define quién puede suplantar usuarios para acceder a él.

  • Cuando modificamos ese atributo con impacket-rbcd -action write, estamos diciendo:

    “Este equipo que creamos (ATTACKCOMPUTER$) ahora es un delegante autorizado para acceder al DC como cualquier otro usuario.”

hashtag
Resource-Based Constrained Delegation (RBCD) con Impacket y Rubeus

1) Creamos una cuenta de equipo controlada por nosotros con impacket-addcomputer: FAKE-COMP01$

2) Nos conectamos a la cuenta support con EvilWinRM y cargamos el binario de Rubeus con upload (previamente este binario debe encontrarse en el directorio desde donde ejecutamos EvilWinRM, de lo contrario no se podrá cargar en el equipo de support). Luego verificamos que la cuenta FAKE-COMP01$ fue creada correctamente.

3) Modificamos el atributo msDS-AllowedToActOnBehalfOfOtherIdentity del DC$, con impacket-rbcd, para permitir que FAKE-COMP01$ pueda impersonar otros usuarios. Hasta aca el procedimiento es similar al anterior.

4) Obtener el hash NTLM de FAKE-COMP01$. Generamos el hash NTLM (rc4_hmac) con Rubeus para utilizarlo en la solicitud de ticket TGT. Luego solicitamos un TGT para FAKE-COMP01$ que se nos imprimirá en base64, finalmente, mediante S4U2Proxy, vamos a impersonar al usuario Administrator. Solicitamos un TGS para Administrator hacia cifs/dc.support.htb y Rubeus lo inyecta directamente (/ptt).

chevron-right📌 Parámetroshashtag

Rubeus.exe hash /password:Password123 /user:FAKE-COMP01$ /domain:support.htb

Este comando calcula los hashes Kerberos derivados de una contraseña en texto claro, útiles para autenticación sin necesidad de contraseña explícita.

  • /password:Password123 → Especifica la contraseña en texto claro de la cuenta objetivo.

  • /user:FAKE-COMP01$ → Indica el nombre del objeto (en este caso, una cuenta de equipo) cuya contraseña será usada.

  • /domain:support.htb → Nombre del dominio al que pertenece la cuenta.

Resultado: Se devuelven los valores hash de tipo rc4_hmac, aes128_cts_hmac_sha1, aes256_cts_hmac_sha1 y des_cbc_md5, que pueden usarse para autenticar sin contraseña en otros comandos como asktgt o s4u.

Rubeus.exe asktgt /user:FAKE-COMP01$ /rc4:58A478135A93AC3BF058A5EA0E8FDB71 /domain:support.htb /dc:dc.support.htb /nowrap

Este comando solicita un Ticket Granting Ticket (TGT) usando el hash NTLM previamente calculado.

  • /user:FAKE-COMP01$ → Nombre de la cuenta de equipo que solicita el TGT.

  • /rc4:58A478135A93AC3BF058A5EA0E8FDB71 → Proporciona el hash NTLM de la contraseña. Evita tener que pasar la contraseña en texto claro.

  • /domain:support.htb → Nombre del dominio Kerberos.

  • /dc:dc.support.htb → Dirección del controlador de dominio a contactar.

  • /nowrap → Evita que la salida base64 del ticket se divida en varias líneas (útil para copiar/pegar fácilmente).

Resultado: Se imprime en pantalla el TGT en formato .kirbi codificado en base64, junto con sus detalles como tiempos de validez y tipo de cifrado.

Rubeus.exe s4u /user:FAKE-COMP01$ /rc4:58A478135A93AC3BF058A5EA0E8FDB71 /impersonateuser:Administrator /msdsspn:cifs/dc.support.htb /domain:support.htb /dc:dc.support.htb /ptt

Este comando solicita un Ticket Granting Service (TGS) utilizando el flujo S4U2Proxy, permitiendo a la cuenta FAKE-COMP01$ obtener acceso en nombre del usuario Administrator.

  • /user:FAKE-COMP01$ → Especifica la cuenta delegante autorizada (agregada previamente al dominio).

  • /rc4:58A478135A93AC3BF058A5EA0E8FDB71 → Hash NTLM de la cuenta, usado para autenticación.

  • /impersonateuser:Administrator → Usuario objetivo que se desea suplantar (impersonate) en la solicitud del ticket.

  • /msdsspn:cifs/dc.support.htb → SPN del servicio al cual se desea acceder en nombre de Administrator. En este caso, CIFS del controlador de dominio.

  • /domain:support.htb → Nombre del dominio al que pertenecen las cuentas y servicios.

  • /dc:dc.support.htb → Dirección del Domain Controller que responderá la solicitud Kerberos.

  • /ptt → Inyecta automáticamente el TGS obtenido en la sesión actual (Pass-the-Ticket), lo que permite su uso inmediato sin pasos adicionales.

5) Con el ultimo ticket (TGS) que generamos, lo copiamos y lo pasamos a un archivo en nuestro equipo atacante (ticket.kirbi.b64), para luego editarlo y eliminar la indentación y los saltos de línea del ticket.

6) Decodificamos y convertimos este ticket .kirbi a formato .ccache . Luego exportamos el ticket como variable de entorno para permitir que nuestras tools compatibles con Kerberos lo utilicen automáticamente

7) Finalmente accedemos como Administrator con impacket-psexec

hashtag
Resource-Based Constrained Delegation (RBCD) con Impacket, Powermad y Powerview

1) Para esta última poc vamos a necesitar descargar los binarios de Powermadarrow-up-right y Powerviewarrow-up-right en nuestro equipo

chevron-right📌 Powermad y Powerviewhashtag

Powermad es un script en PowerShell que nos permite interactuar con el Directorio Activo para crear y administrar cuentas de equipo (machine accounts).

¿Para qué se usa? Se utiliza principalmente para:

  • Crear cuentas de equipo en un dominio (machine accounts), algo que cualquier usuario autenticado puede hacer por defecto en muchos entornos AD.

  • Automatizar esta creación como parte de ataques como RBCD (Resource-Based Constrained Delegation).

  • Simular que una máquina legítima se une al dominio con una contraseña conocida (controlada por el atacante).

PowerView es una herramienta de enumeración de Active Directory escrita en PowerShell. Forma parte de la suite PowerSploit y es una de las más utilizadas en pentesting.

¿Para qué se usa? Se usa para:

  • Enumerar objetos del dominio: usuarios, grupos, máquinas, GPOs, trusts, etc.

  • Buscar relaciones de delegación (como unconstrained o RBCD).

  • Buscar privilegios y permisos indebidos.

  • Identificar controladores de dominio y estructuras del bosque.

  • Consultar atributos como msDS-AllowedToActOnBehalfOfOtherIdentity.

2) Una vez que tenemos los binarios vamos a conectarnos desde ese directorio a la cuenta support con EvilWinRM y luego cargaremos ambos scripts

3) Creamos una cuenta de equipo (machine account) con Powermad. Esto simula la incorporación de un equipo al dominio.

chevron-right📌 Parámetroshashtag

New-MachineAccount -MachineAccount SERVICEA -Password $(ConvertTo-SecureString '123456' -AsPlainText -Force) -Verbose

  • -MachineAccount → Especifica el nombre de la nueva cuenta de equipo que se quiere crear en el dominio. En este caso: SERVICEA$.

  • -Password → Define la contraseña asociada a la cuenta de equipo. Se convierte en objeto SecureString para cumplir con los requisitos del parámetro.

  • $(ConvertTo-SecureString '123456' -AsPlainText -Force) → Convierte la contraseña '123456' en formato plano a un objeto seguro (SecureString) requerido por el parámetro anterior.

  • -Verbose → Muestra información detallada del proceso mientras se ejecuta el comando, útil para verificar que se creó correctamente.

$ComputerSid = Get-DomainComputer SERVICEA -Properties objectsid | Select -Expand objectsid

  • Get-DomainComputer SERVICEA → Consulta los atributos del objeto SERVICEA en Active Directory.

  • -Properties objectsid → Solicita específicamente el atributo objectsid, que contiene el SID único de la cuenta de equipo.

  • | Select -Expand objectsid → Extrae el valor del SID en una forma usable y lo guarda en la variable $ComputerSid.

$SD = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$ComputerSid)"

  • New-Object Security.AccessControl.RawSecurityDescriptor → Crea un nuevo descriptor de seguridad (SD) en formato bruto, que luego será convertido a binario.

  • -ArgumentList "O:BAD:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;$ComputerSid)" → Define los permisos que tendrá el SID (la cuenta SERVICEA) sobre el objeto que se va a modificar (el DC).

    • "O:BAD" → Define el propietario (Owner) y el grupo primario del objeto (no relevantes en este contexto).

    • "A;;...;;;$ComputerSid" → Especifica una ACE (Access Control Entry) que otorga múltiples permisos (CCDCLCSWRP...) al SID extraído previamente.

Luego se convierte este SD en bytes:

  • New-Object byte[] → Crea un arreglo de bytes del tamaño requerido para el descriptor.

  • GetBinaryForm($SDBytes, 0) → Llena el arreglo con la representación binaria del descriptor de seguridad.

Get-DomainComputer dc | Set-DomainObject -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes}

  • Get-DomainComputer dc → Obtiene el objeto del equipo DC (el Domain Controller) desde Active Directory.

  • | Set-DomainObject → Permite modificar atributos arbitrarios del objeto recibido.

  • -Set @{'msds-allowedtoactonbehalfofotheridentity'=$SDBytes} → Modifica el atributo msds-allowedtoactonbehalfofotheridentity del DC, permitiendo que la cuenta SERVICEA actúe en nombre de otros usuarios en ese sistema (esencial para RBCD).

4) Ahora vamos a solicitar un TGS usando Impacket-getST (ataque S4U2Proxy). Desde Kali, usando la cuenta SERVICEA$, obtenemos un ticket de servicio para Administrator hacia cifs/dc.support.htb. Luego vamos a exportar el ticket Kerberos TGS para que lo use impacket-psexec

5) Por ultimo vamos a usar impacket-psexec con el ticket TGS inyectado para ejecutar comandos (RCE) como nt authority\system.

Last updated