Attacking Kerberos
Antes de comenzar con este recorrido practicó y conocer algunas de las herramientas más importantes para el pentesting de Kerberos y AD, te recomiendo que leas el siguiente artículo para comprender cómo funciona el proceso de autenticación en Kerberos y cuales son sus principales actores dentro del mismo.
Kerberos Pre-Authentication Abuse
Nota: en el módulo nos facilitan el diccionario para este primer escenario y nos aconseja agregar el DC a nuestro archivo /etc/hosts para que las herramientas puedan dirigir mejor los ataques y evitar el problema del virtual host.
┌──(root㉿kali)-[/home/kali/Documents/THM/AttackingKerberos]
└─# echo "10.10.52.78 CONTROLLER.local" >> /etc/hosts La primer tarea que nos propone este módulo es enumerar usuarios con Kerbrute
El protocolo Kerberos incluye una característica denominada pre autenticación, cuyo propósito es dificultar ataques offline al exigir al usuario cifrar un timestamp con su clave secreta antes de obtener un Ticket Granting Ticket (TGT). Sin embargo, esta misma característica puede ser aprovechada por atacantes para realizar una enumeración silenciosa de usuarios válidos en un dominio, sin necesidad de autenticación previa.
¿Cómo funciona este ataque?
Durante la fase inicial del protocolo Kerberos, el cliente envía un mensaje AS-REQ al Key Distribution Center (KDC) para solicitar un TGT. Si el usuario solicitado no existe, el KDC responde con el error KDC_ERR_C_PRINCIPAL_UNKNOWN. En cambio, si el usuario sí existe y tiene habilitada la pre autenticación, el KDC responde con un error KRB5_PREAUTH_REQUIRED, indicando que espera un timestamp cifrado para proceder con la autenticación. Esta diferencia de comportamiento permite a un atacante distinguir usuarios válidos de inválidos, sin necesidad de conocer contraseñas ni autenticarse en el dominio.
Kerbrute ejecuta una enumeración de nombres de usuario del dominio sin necesidad de credenciales, basándose únicamente en la respuesta del KDC ante solicitudes AS-REQ sin pre autenticación.
El funcionamiento es simple: la herramienta toma una lista de posibles nombres de usuario (wordlist) y envía una solicitud TGT por cada uno. Si el KDC responde con un error PRINCIPAL UNKNOWN, se descarta el nombre; en cambio, si el error recibido es KRB5_PREAUTH_REQUIRED, se confirma la existencia del usuario.
Ejemplo de enumeración de usuarios con Kerbrute:
┌──(root㉿kali)-[/home/kali/Documents/THM/AttackingKerberos]
└─# kerbrute userenum --dc CONTROLLER.local -d CONTROLLER.local User.txt
__ __ __
/ /_____ _____/ /_ _______ __/ /____
/ //_/ _ \/ ___/ __ \/ ___/ / / / __/ _ \
/ ,< / __/ / / /_/ / / / /_/ / /_/ __/
/_/|_|\___/_/ /_.___/_/ \__,_/\__/\___/
Version: dev (n/a) - 05/22/25 - Ronnie Flathers @ropnop
2025/05/22 02:21:34 > Using KDC(s):
2025/05/22 02:21:34 > CONTROLLER.local:88
2025/05/22 02:21:34 > [+] VALID USERNAME: admin1@CONTROLLER.local
2025/05/22 02:21:34 > [+] admin2 has no pre auth required. Dumping hash to crack offline:
$krb5asrep$18$admin2@CONTROLLER.LOCAL:ea626eaea8ed4f0259045b4a67f12523$ff9334bcc6f1ad4c6046f2e0af1abe0822349fa79d263c298b295ba9ca206ed22b3ce4ffc6ecfd2ebed15096c7d3fa132ef08929460e3949ec15d1ef163ba84f44bb43d68f79e0be342dbcaccae5c1de71512def87606282061932f09c462a8f5305bf5e3291fb9beaffecd94521ab67fd4af16dd73ca982384981ea25917a4bdb8b2e8086212d4a9ffc1c3817c7d4fb860202dbfe513cf66449a84aee1eb712c213e7c5d0a2095717ba835b527e4c64b9e2969d6727b605501810220c6650575be9d2e83ff8bea948e4ec43884b1c68cca4da8059ee5416f02b2c78036ba74f853aa5d9b79deeb4048f21184fd7b7384ae3fd1e4839a75ee27c134851406d06140c784b8a675358
2025/05/22 02:21:34 > [+] VALID USERNAME: admin2@CONTROLLER.local
2025/05/22 02:21:34 > [+] VALID USERNAME: administrator@CONTROLLER.local
2025/05/22 02:21:36 > [+] VALID USERNAME: machine2@CONTROLLER.local
2025/05/22 02:21:36 > [+] VALID USERNAME: machine1@CONTROLLER.local
2025/05/22 02:21:36 > [+] VALID USERNAME: httpservice@CONTROLLER.local
2025/05/22 02:21:36 > [+] VALID USERNAME: sqlservice@CONTROLLER.local
2025/05/22 02:21:36 > [+] VALID USERNAME: user2@CONTROLLER.local
2025/05/22 02:21:36 > [+] VALID USERNAME: user1@CONTROLLER.local
2025/05/22 02:21:36 > [+] user3 has no pre auth required. Dumping hash to crack offline:
$krb5asrep$18$user3@CONTROLLER.LOCAL:5b7ce24a57bd62840af44b283688d712$e90ed6ed560436648d18c220d1a950ef0b192feadcf5e41b100e71936c435cf86cce6471a85715e0168a4747a8a74e7120b557ad5b7f2959ba618957fb1dddd35bedeb70d6afed2430651843e1fe05f6f9d2af3fb9ae198e223239abe95085c818bca398f84360cb9e89a58f3922650c07b97afc17eb306e6f6e95cd4ecebd97c0b163972a31c29bbd7b2d57648dd386391d050492c8c297b88741124e2ee336ebdc8675a4770daf824457a2ea7ad71580fb84ebe16f59b82f108e385d989fe04803b97c1bae17a6e68b97abf2748e176b76d91528d23283dd920774fc0a51971181f05b994dd4ed8e87de1fe868f5b329464b1a80aceb5e05c4f036585ba84addc1e634083cc220
2025/05/22 02:21:36 > [+] VALID USERNAME: user3@CONTROLLER.local
2025/05/22 02:21:36 > Done! Tested 100 usernames (10 valid) in 2.234 secondsAS-REP Roasting
Este segundo ataque no está incluido en el primer escenario, recién lo vemos en la tarea 5, pero podemos realizarlo ya que pudimos encontrar dos cuentas de Active Directory que tienen deshabilitada la pre autenticación en Kerberos. El procedimiento es el siguiente: obtener hashes AS-REP de cuentas con pre autenticación deshabilitada y crackearlos offline con John the Ripper para recuperar contraseñas de usuarios del dominio.
Harvesting Tickets con Rubeus
La segunda tarea que se nos propone es recolectar tickets Kerberos del equipo objetivo. Para hacer esto nos dan acceso al equipo por RDP con las siguientes credenciales:
Nombre de usuario: Administrador
Contraseña: P@$$W0rd
Domain: controller.local
El equipo objetivo ya tiene instalado Rubeus para que podamos realizar el ataque desde la cmd sin tener que cargar el binario al equipo previamente.
Y de esta forma obtuvimos el TGT de los usuarios CONTROLLER-1$@CONTROLLER.LOCAL y Administrator@CONTROLLER.LOCAL
¿Qué se puede y que no se puede hacer con un TGT?
No podés crackearlo como si fuera un hash de Kerberos
RC4-HMAC.No podés extraer la contraseña directamente del ticket porque desconocemos cual es la clave del KDC.
No sirve para bruteforce porque nunca sabremos si lo que se descifró es correcto (no hay contenido predecible).
Se podría intentar un Pass-the-Ticket
Password-Spraying con Rubeus
Lo primero que vamos a hacer es agregar el nombre de dominio al /etc/hosts del equipo windows para que Rubeus lo resuelva correctamente. Luego usaremos la contraseña que obtuvimos con John para encontrar el usuario al que pertenece.
Y así encontramos el usuario que hace el match con la contraseña User3:Password3
Kerberoasting con Rubeus e Impacket
Tarea 4: Kerberoasting es una técnica de post-explotación en entornos Active Directory que permite a un atacante, con credenciales válidas de cualquier usuario del dominio, extraer tickets de servicio Kerberos (TGS) asociados a cuentas con Service Principal Names (SPN). Esta técnica aprovecha el hecho de que, en Kerberos, los tickets TGS son cifrados por el controlador de dominio utilizando la clave secreta del servicio objetivo, que en el caso de Active Directory corresponde al hash NTLM de la contraseña de la cuenta de servicio. Un atacante autenticado puede solicitar estos tickets sin necesidad de interactuar directamente con el servicio, capturarlos y guardarlos para su posterior análisis.
La viabilidad del ataque radica en que el contenido cifrado del TGS tiene una estructura predecible, lo que permite realizar ataques de diccionario o fuerza bruta de manera offline. Si la contraseña asociada a la cuenta de servicio es débil o predecible, es posible descifrar el ticket y obtener la contraseña en texto claro, sin generar alertas en el dominio.
Si ya estamos dentro del equipo windows, la primer forma de obtener estos hashes desde cmd es con Rubeus de la siguiente forma:
El segundo metodo de obtencion de hashes es con impacket-GetUserSPNs, este otro método lo realizamos desde la consola de kali, no tenemos que estar necesariamente dentro del equipo objetivo
Nota: si al usar el script de impacket tenemos el siguiente error KRB_AP_ERR_SKEW(Clock skew too great) quiere decir que la diferencia de tiempo entre nuestra máquina Kali y el controlador de dominio (DC) es demasiado grande. Kerberos es muy sensible al tiempo, y por defecto solo permite una diferencia de hasta 5 minutos entre cliente y servidor. Entonces para sincronizar nuestro equipo con el DC vamos a usar ntpdate <IP_objetivo>
Al usar impacket-GetUserSPNs para extraer los hashes vamos a agregarle en la última parte del comando el >> hashes.txt para que todos los hashes capturados se almacenen allí y luego podamos crackearlos directamente con John the Ripper.
Una vez que crackeamos los hashes vamos a tener las contraseñas de los servicios http y sql en nuestro poder.
Nota: en esta tarea nos recomiendan el siguiente diccionario para crackear los hashes: Active Directory Wordlists
Una forma de rastrear objetivos para probar un kerberoasting es usando BloodHound. Si todavía no conoces esta herramienta, te recomiendo que leas el siguiente artículo introductorio
Realizando una recolección de data con SharpHound, podemos visualizar cuentas con SPN y ver si son miembros de grupos como Domain Admins o si tienen privilegios especiales. En la GUI de BloodHound, podemos buscar la query predefinida: Find Kerberoastable Accounts. Esto nos da una lista de objetivos ideales para Kerberoasting
AS-REP Roasting con impacket-GetNPUsers y Rubeus
En un ataque AS-REP Roasting, el atacante explota una debilidad en cuentas de Active Directory que tienen deshabilitada la preautenticación Kerberos. En este escenario, el servidor KDC responde con un mensaje cifrado (AS-REP) utilizando una clave derivada directamente de la contraseña del usuario. Este mensaje puede ser interceptado por un atacante y posteriormente sometido a un ataque de diccionario o fuerza bruta de manera offline. Lo que hace viable este ataque es que el contenido del mensaje cifrado presenta una estructura predecible y estandarizada, lo que permite al atacante verificar si una contraseña probada es correcta basándose en la validez del resultado del descifrado.
En contraste, los tickets TGT (Ticket Granting Ticket) y TGS (Ticket Granting Service) no son vulnerables al mismo tipo de ataque debido a que están cifrados con claves que no dependen del usuario. El TGT es cifrado con la clave secreta del servicio krbtgt, mientras que el TGS lo está con la clave del servicio de destino. Estas claves no están disponibles para el atacante y no es posible derivarlas a partir de contraseñas de usuario, lo que impide verificar offline si una contraseña es correcta. Por lo tanto, aunque un atacante pueda capturar estos tickets, no puede realizar un ataque de fuerza bruta sin acceso a las claves internas del dominio, lo que refuerza la resistencia de Kerberos frente a ciertos vectores de ataque.
El procedimiento del ataque es sencillo, debemos descargar los hashes con impacket-GetNPUsers o Rubeus y luego crackearlos con John the Ripper o Hashcat
Ahora solo debemos crackear estos hashes con John:
Para descargar los hashes usando Rubeus vamos a conectarnos al ssh del equipo objetivo y ejecutarlo desde su cmd
Y así podemos obtener las credenciales de los usuarios Admin2 y User3
Pass the Ticket con mimikatz
Pass-the-Ticket es una técnica de post-explotación utilizada en entornos Windows basados en Active Directory, mediante la cual un atacante puede reutilizar tickets Kerberos legítimos extraídos de la memoria del proceso LSASS (Local Security Authority Subsystem Service). Este proceso, responsable de la gestión de credenciales y autenticaciones, almacena en memoria tickets TGT (Ticket Granting Ticket) y TGS (Ticket Granting Service), así como otros elementos sensibles. Herramientas como Mimikatz permiten extraer estos tickets en formato .kirbi, que pueden ser inyectados posteriormente en otra sesión para suplantar la identidad de un usuario dentro del dominio, sin necesidad de conocer su contraseña. Esta técnica es especialmente útil cuando el ticket capturado pertenece a una cuenta con privilegios elevados, como un administrador de dominio, ya que permite escalar privilegios o realizar movimiento lateral en la red.
El ataque Pass-the-Ticket no implica la creación ni modificación de tickets, sino la reutilización de uno previamente emitido y aún válido, lo que lo convierte en una técnica silenciosa y difícil de detectar si no se cuenta con mecanismos de monitoreo adecuados. Su eficacia depende del acceso inicial a una máquina comprometida desde la cual se pueda extraer la memoria del LSASS, y del hecho de que los tickets de Kerberos suelen permanecer en memoria mientras son válidos. Por tanto, si un atacante consigue obtener un TGT de una cuenta privilegiada, puede usarlo para autenticarse en servicios y recursos dentro del dominio, actuando con los mismos permisos del usuario legítimo.
El equipo objetivo ya tiene instalado Mimikatz para que podamos realizar el ataque desde la cmd sin tener que cargar el binario al equipo previamente. Entonces para realizar esta prueba de concepto primero vamos a conectarnos al ssh del equipo objetivo y ejecutar mimikatz desde el cmd. Luego vamos a habilitar los privilegios de depuración para acceder a la memoria del proceso LSASS, desde donde extraeremos y exportáremos los tickets de Kerberos activos, entre ellos el Ticket Granting Ticket (TGT) perteneciente a la cuenta de administrador del dominio. Posteriormente, inyectamos dicho ticket en la sesión que tenemos en ssh utilizando Mimikatz, lo que nos permite suplantar al administrador sin necesidad de conocer su contraseña. Finalmente, verificamos que el ticket ha sido cargado correctamente mediante el comando klist.
Golden/Silver Ticket Attack con Mimikatz
En un entorno de Active Directory, los ataques de Golden Ticket y Silver Ticket son técnicas de suplantación basadas en la manipulación de tickets Kerberos, y aunque ambos permiten autenticación sin necesidad de credenciales válidas, difieren en su alcance y discreción. Un Golden Ticket se genera al comprometer la cuenta de servicio krbtgt, que es utilizada por el KDC (Key Distribution Center) para firmar todos los Ticket Granting Tickets (TGT) del dominio. Con el hash NTLM de esta cuenta, un atacante puede forjar TGTs arbitrarios para cualquier cuenta, incluso para un administrador de dominio, y obtener acceso a cualquier servicio Kerberos en el dominio. Esto convierte al Golden Ticket en un arma extremadamente poderosa, pero también más susceptible a detección por mecanismos de seguridad que supervisan la emisión de tickets en el KDC.
En contraste, un Silver Ticket se basa en la suplantación de un Service Ticket (TGS) directamente, sin necesidad de interactuar con el KDC. Para generarlo, el atacante necesita conocer el SPN (Service Principal Name) del servicio objetivo, el nombre de usuario asociado y el hash NTLM de la cuenta de servicio. Esto se puede lograr, por ejemplo, mediante un ataque de Kerberoasting. Una vez generado, el ticket puede ser inyectado con herramientas como Mimikatz, permitiendo el acceso al servicio en cuestión (como un servidor SQL), incluso si el usuario originalmente comprometido no tenía permisos para ello. Aunque su alcance es limitado al servicio objetivo, el Silver Ticket es más sigiloso, ya que no requiere comunicación con el KDC y, por ende, puede evadir ciertas medidas de detección basadas en logs del controlador de dominio.
Primero vamos a ver el paso a paso de como generar un golden ticket con cuenta del krbtgt:
Ahora vamos a ver como es el paso a paso para obtener un silver ticket con una cuenta de servicio y una cuenta de administrador:
Ejemplo de silver ticket con cuenta de admin:
Nota: el comando kerberos::golden es el más comúnmente utilizado tanto para generar Golden Tickets como Silver Tickets en Mimikatz. No existe un comando alternativo exclusivo con el nombre kerberos::silver u otro específico para Silver Tickets en la herramienta.
En síntesis: el tipo de ticket lo determina la clave usada y el tipo de ticket generado.
Kerberos Skeleton Key (backdoor) con Mimikatz
La última tarea de esta sala no tiene una poc para testear este tipo de ataques, sin embargo sí es importante comprender de qué se trata este tipo de backdoor que podemos usar con mimikatz. A diferencia de los ataques basados en tickets dorados (Golden Ticket) o plateados (Silver Ticket), una puerta trasera Kerberos representa un mecanismo de persistencia altamente sigiloso que modifica directamente el comportamiento del proceso de autenticación Kerberos en un dominio comprometido. Esta técnica consiste en la implantación de una clave maestra en la memoria del controlador de dominio, mediante la cual se altera la validación de las marcas de tiempo cifradas contenidas en los mensajes AS-REQ del protocolo Kerberos. Normalmente, estas marcas de tiempo son cifradas con el hash NTLM del usuario, y el controlador de dominio las valida intentando descifrarlas con ese mismo hash. Sin embargo, cuando se introduce una clave maestra, el sistema también intentará descifrar la marca de tiempo utilizando dicha clave, lo que permite la autenticación con una contraseña maestra predefinida, incluso si la contraseña real del usuario es desconocida. Esta puerta trasera, que funciona exclusivamente con cifrado RC4, permite a un atacante acceder a cualquier cuenta del dominio con una contraseña universal —por ejemplo, "mimikatz", cuyo hash NTLM correspondiente es 60BA4FCADC466C7A033C178194C03DF6. La técnica emula el comportamiento de un rootkit, ya que su modificación ocurre únicamente en memoria, lo que la hace extremadamente difícil de detectar mediante auditorías tradicionales.
La implantación de una clave maestra en la memoria del controlador de dominio consiste en modificar el proceso de validación del mensaje de autenticación inicial en Kerberos, conocido como AS-REQ (Authentication Service Request). Durante el flujo normal de autenticación, el cliente cifra una marca de tiempo con su propia clave derivada del hash NTLM de su contraseña y la envía al KDC (Key Distribution Center) como parte del proceso de preautenticación. El controlador de dominio, al recibir el mensaje, intenta descifrar esa marca de tiempo utilizando el hash correspondiente al usuario que realiza la solicitud. Si la marca de tiempo puede ser descifrada correctamente, se considera que el usuario posee la clave válida y se le emite un Ticket Granting Ticket (TGT).
Cuando se introduce una clave maestra, este comportamiento se altera: el controlador de dominio, además de intentar descifrar la marca de tiempo con la clave del usuario legítimo, también la prueba contra una clave implantada en memoria —la llamada "Skeleton Key". Esto significa que cualquier intento de autenticación, independientemente de la contraseña provista, será exitoso si la marca de tiempo fue cifrada con esta clave maestra. De este modo, un atacante puede autenticarse como cualquier usuario del dominio utilizando una contraseña única y predefinida, sin necesidad de conocer las credenciales originales. Este mecanismo representa una manipulación fundamental del proceso de pre autenticación Kerberos, permitiendo el acceso total al dominio sin generar cambios persistentes en disco, lo que contribuye a la dificultad de su detección.
Los comandos para usar el modulo skeleton son los siguientes:
Last updated