Pentest de Active Directory: Kerberoasting Paso a Paso en Lab GOAD

Kerberoasting es el ataque que paga renta en casi todo engagement interno, porque no necesita mas que una sola cuenta de dominio valida y convierte tickets de servicio pedidos en silencio en cracking de password offline, sin privilegios especiales y sin exploit ruidoso. En esta guia montas un lab con GOAD, el Game of Active Directory de Orange Cyberdefense, y corres la cadena completa: entender como Kerberos emite tickets, enumerar service principal names, pedir los tickets, crackearlos offline con hashcat y luego cerrar el ciclo con la deteccion y el hardening que de verdad lo detienen. Todo corre contra tus propios domain controllers, en una red aislada, bajo autorizacion escrita; la meta es fluidez en el mecanismo, no un trofeo.

Como funciona la autenticacion Kerberos

Kerberos es un protocolo de tickets con tres partes: el cliente, el Key Distribution Center que vive en el domain controller, y el servicio. Primero el cliente prueba quien es con un AS-REQ y recibe un Ticket Granting Ticket, cifrado con la clave de la cuenta krbtgt para que solo el KDC lo lea. Cuando el cliente quiere alcanzar un servicio, presenta el TGT en un TGS-REQ y pide un ticket de servicio; el KDC responde con un TGS cifrado usando la clave propia de la cuenta de servicio, derivada del password de esa cuenta. El cliente entrega ese ticket al servicio, que lo descifra para probar autorizacion. El detalle critico es que el KDC le da a cualquier usuario autenticado un ticket de servicio para cualquier servicio, y ese ticket esta cifrado con una clave derivada de un password elegido por un humano.

Por que funciona Kerberoasting

Ese unico hecho de diseno es toda la vulnerabilidad. Cualquier usuario de dominio puede pedir un TGS para cualquier cuenta con un Service Principal Name registrado, y el ticket devuelto esta cifrado con la clave derivada del password de la cuenta de servicio. Llevate el ticket offline y puedes brute-forcear el password sin volver a tocar el dominio, porque la verificacion ocurre en tu propio hardware. Empeora cuando el ticket vuelve como RC4 (etype 23, el hash $krb5tgs$23$), que crackea mucho mas rapido que AES. Las cuentas de servicio son las victimas perfectas: suelen cargar passwords debiles, antiguos y puestos por humanos, rara vez rotan, y a menudo estan sobre-privilegiadas porque alguien les dio domain admin hace anos para que un installer funcionara.

Montando el lab GOAD

GOAD trae un bosque Active Directory multi-dominio deliberadamente vulnerable, construido para exactamente esta practica. Provisionalo con Ludus o por el camino de Vagrant y Ansible en un hypervisor con suficiente RAM, porque un bosque realista quiere varias VMs de Windows Server y un host de ataque Kali o Windows. Manten todo el entorno en una red aislada sin ruta a produccion ni internet, porque GOAD es intencionalmente debil y nunca debe tocar nada real. Una vez que los domain controllers estan arriba y tienes una cuenta de dominio de bajo privilegio, tienes la posicion inicial exacta de un atacante que acaba de phishear a un solo usuario de helpdesk, el punto de entrada realista que Kerberoasting esta disenado para explotar.

Enumeracion: encontrar las cuentas de servicio

No puedes rostizar lo que no ves, asi que primero enumera cuentas con un SPN. Desde Windows, setspn -T domain -Q */* lista los service principal names registrados, mientras Get-DomainUser -SPN de PowerView filtra directo a cuentas de usuario con un SPN puesto, que son los objetivos crackeables. Desde Linux, un ldapsearch autenticado por servicePrincipalName=* hace lo mismo. Mete el dominio en BloodHound y no solo lista usuarios kerberoasteables sino que muestra cuales pertenecen a grupos de alto valor, para que priorices la cuenta de servicio que ademas resulta estar en Domain Admins. Anota los tipos de cifrado que cada cuenta soporta; una cuenta que aun permite RC4 es el objetivo mas blando del tablero.

Pedir y extraer los tickets

Elegidos los objetivos, pide los tickets. Desde un foothold en Windows, Rubeus.exe kerberoast /outfile:hashes.txt pide un TGS por cada cuenta kerberoasteable y escribe los hashes en formato crackeable; agrega /tgtdeleg o filtra por usuario para quedar callado. Desde Linux con Impacket, GetUserSPNs.py DOMAIN/user:password -dc-ip 10.0.0.10 -request hace lo mismo en un comando y vuelca los blobs $krb5tgs$. Si puedes, apunta a proposito a cuentas que respondan con hashes RC4; si el KDC devuelve AES etype 18 ($krb5tgs$18$), igual puedes crackearlo, solo mucho mas lento. Cada hash que juntas queda ahora completamente desconectado de la red, exactamente por eso el siguiente paso ocurre en tu propia maquina.

Crackear los tickets offline

Offline es donde Kerberoasting se vuelve cruel. Dale los hashes a hashcat con modo -m 13100 para tickets TGS RC4 o -m 19700 para AES, apuntalo a una wordlist fuerte como rockyou mas reglas dirigidas, y deja trabajar la GPU. Un password de servicio debil cae en segundos; un password humano de doce caracteres con estructura predecible a menudo cae en horas. Como la verificacion es local, no hay lockout, ni rate limit, ni entrada de log en el dominio que te delate. Esa asimetria es todo el punto: la politica de passwords del defensor es lo unico entre una sola cuenta de bajo privilegio y una credencial de servicio crackeada que puede tener mucho mas acceso que la cuenta con la que empezaste.

Post-crack: convertir un password en poder de dominio

Una cuenta de servicio crackeada rara vez es el final; es un pivot. Inicia sesion como la cuenta de servicio y vuelve a correr BloodHound desde su contexto para mapear que puede alcanzar, porque las cuentas de servicio suelen tener admin local en muchos servidores o estar en grupos privilegiados. Si la cuenta es un servicio de SQL o de backup, quiza posea caminos a un domain controller via delegacion o abuso de DACL. Por eso Kerberoasting se valora tanto en engagements reales: convierte la posicion inicial mas debil posible, un usuario comun, en credenciales provisionadas para maquinas y por tanto confiadas mucho mas de lo que cualquier cuenta humana deberia.

Deteccion: la vista del defensor

Cada Kerberoast deja rastro si lo estas vigilando. El Event ID 4769 de Windows registra cada peticion TGS, y el delator es el campo de tipo de cifrado: una rafaga de eventos 4769 con tipo de cifrado 0x17 (RC4) de un solo usuario contra muchos servicios distintos en una ventana corta es la firma de una corrida de rostizado. Alerta sobre ese patron en tu SIEM en vez de sobre eventos individuales, porque un 4769 es normal y mil en un minuto no. La deteccion unica mas fuerte es un SPN honeypot: crea una cuenta de servicio senuelo con un SPN, nunca la uses para nada, y dispara una alerta de severidad alta en el instante en que alguien pida su ticket, porque ningun proceso legitimo lo hara jamas.

Mitigacion y hardening

El fix apunta a la crackeabilidad, no a la peticion. Reemplaza las cuentas de servicio administradas por humanos con group Managed Service Accounts, cuyos passwords de 240 caracteres generados por maquina rotan automaticamente y son practicamente imposibles de crackear offline. Donde un gMSA aun no sea posible, impone un password muy largo y aleatorio en cada cuenta de servicio y rotalo. Desactiva RC4 en todo el dominio para que los tickets vuelvan solo como AES, lo que sube el costo de cracking por ordenes de magnitud, y audita cada cuenta de servicio por privilegio innecesario para que hasta una credencial crackeada no lleve a ningun lado. Suma el SPN honeypot y la deteccion de 4769 encima, y has reducido tanto las probabilidades de un crack exitoso como el radio de dano si ocurre uno.

Errores y un checklist

Los errores comunes cortan en ambos sentidos. Los atacantes se hacen atrapar pidiendo todos los tickets de golpe en vez de dosificar y apuntar, o pierden dias crackeando un hash AES que pudieron saltar por uno RC4. Los defensores se creen seguros porque impusieron una politica de passwords a los usuarios mientras sus cuentas de servicio aun cargan un password de una decada y RC4 habilitado. Antes de llamar al dominio endurecido, confirma que ninguna cuenta de usuario permite RC4, que cada cuenta de servicio es un gMSA o tiene un password largo y aleatorio, que existe un SPN honeypot que alerta, que la deteccion de anomalias 4769 esta viva, y que ninguna cuenta kerberoasteable esta en un grupo privilegiado. Pruebalo rostizando tu propio dominio y viendo dispararse el honeypot.

Un primo cercano: AS-REP roasting

Una vez que Kerberoasting hace clic, su hermano cuesta casi nada agregar. El AS-REP roasting apunta a cuentas con pre-autenticacion de Kerberos deshabilitada, un ajuste que deja al KDC devolver un AS-REP cifrado con la clave derivada del password del usuario antes de que el usuario haya probado nada. Eso significa que puedes pedir el blob de esa cuenta sin ninguna credencial y crackearlo offline igual que un TGS. Enumera las victimas con Get-DomainUser -PreauthNotRequired en PowerView o GetNPUsers.py en Impacket, luego dale el hash $krb5asrep$ resultante al modo -m 18200 de hashcat. La historia defensiva es identica en espiritu: nunca deshabilites la pre-autenticacion, impone passwords fuertes y alerta sobre la peticion anomala. Correr ambos ataques uno tras otro en GOAD te ensena que toda la familia de bugs de roasting se reduce a la misma raiz, una clave de cifrado derivada de un password humano debil que cualquiera puede pedir.

FAQ

Necesito derechos de admin para Kerberoast? No, y eso es justo lo que lo hace peligroso. Cualquier cuenta de dominio autenticada puede pedir tickets de servicio y llevarlos offline; sin elevacion, sin exploit y sin acceso especial, por eso es uno de los primeros movimientos tras cualquier foothold.

Habilitar AES detiene Kerberoasting del todo? No, lo hace mucho mas dificil, no imposible. Los tickets AES igual pueden pedirse y crackearse, solo mucho mas lento, asi que un password de servicio debil sigue vulnerable incluso bajo AES. El fix durable son passwords gMSA que ninguna wordlist alcanzara, combinados con least privilege para que un crack no rinda nada.

Takeaway practico: levanta GOAD, corre la cadena una vez desde una sola cuenta de bajo privilegio hasta un ticket de servicio crackeado hasta un pivot privilegiado, luego cambia al lado azul y construye el SPN honeypot y la deteccion de 4769 hasta que tu propio rostizado los encienda. Kerberoasting no es una tecnica exotica; es una consecuencia de diseno de Kerberos chocando con passwords de servicio debiles. Rota a gMSA, mata RC4, quita privilegio y vigila la peticion, y conviertes un pago confiable del atacante en un callejon sin salida.