Kerberoasting y ataques a credenciales de AD: deteccion y defensa

El Kerberoasting es una de las técnicas más habituales que los defensores observan contra Active Directory (AD) y, sin embargo, sigue siendo ampliamente malinterpretada por los equipos encargados de detenerla. Este artículo adopta un punto de vista estrictamente defensivo: explicamos qué es la técnica, cómo funciona el protocolo Kerberos subyacente, por qué ciertas cuentas quedan expuestas y, sobre todo, cómo los equipos azules la detectan, la mitigan y se endurecen frente a ella. El objetivo es entender para defender. No encontrará aquí instrucciones operativas de ataque, sino la telemetría, los controles y las listas de verificación que un ingeniero de detección o un administrador de AD necesita para elevar el coste del ataque y reducir la ventana en la que puede tener éxito.

Qué es el Kerberoasting

El Kerberoasting es una técnica de acceso a credenciales que abusa de una función legítima de Kerberos: cualquier usuario de dominio autenticado puede solicitar un ticket de servicio para una cuenta de servicio que tenga registrado un Service Principal Name (SPN). Parte de ese ticket se cifra con una clave derivada de la contraseña de la cuenta de servicio. Como la solicitud en sí es un comportamiento normal del protocolo, genera poco ruido, y como el posterior descifrado de la contraseña ocurre sin conexión, el controlador de dominio (DC) nunca ve los intentos de adivinación. El riesgo se concentra, por tanto, en las contraseñas débiles de cuentas de servicio y el cifrado heredado. Desde la perspectiva del defensor, la técnica se entiende mejor como un desajuste entre una vieja función de comodidad y el hardware moderno de descifrado. Está clasificada en MITRE ATT&CK como T1558.003, dentro de la táctica de Acceso a Credenciales.

Cómo funciona la autenticación Kerberos

Para defenderse de la técnica necesita un modelo mental funcional de Kerberos. Cuando un usuario inicia sesión, recibe un Ticket-Granting Ticket (TGT) del Key Distribution Center (KDC), que se ejecuta en el controlador de dominio. Cuando ese usuario quiere después acceder a un servicio — un SQL Server, un grupo de aplicaciones web, un recurso compartido — presenta el TGT y solicita un ticket de servicio (TGS) para el SPN específico. El KDC devuelve un TGS cuya porción de servicio está cifrada con la clave a largo plazo de la cuenta propietaria del SPN. Legítimamente, el cliente reenvía ese ticket al servicio destino, que lo descifra para validar la solicitud. La suposición de diseño es que solo el servicio (que conoce su propia contraseña) puede leer la porción cifrada. Esa suposición se rompe cuando la contraseña de la cuenta es lo bastante débil como para recuperarse sin conexión, porque cualquiera que obtenga el ticket puede intentar derivar la clave. Este flujo le indica exactamente dónde situar su telemetría: en el KDC, en los eventos de solicitud de ticket.

Cómo funciona el ataque a alto nivel

A alto nivel, la técnica tiene tres etapas conceptuales que un defensor debe reconocer. Primera, la enumeración: identificar qué cuentas tienen SPN registrados, ya que solo esas son atacables. Segunda, la solicitud de tickets: obtener tickets TGS para esos SPN mediante llamadas de protocolo ordinarias y autenticadas que parecen acceso normal a servicios. Tercera, la recuperación sin conexión: llevarse la porción cifrada completamente fuera de la red e intentar recuperar la contraseña en el hardware propio del adversario, sin más contacto con su dominio. La conclusión crucial para el equipo azul es que solo las dos primeras etapas son visibles para usted; la tercera ocurre fuera de la red. Por eso la prevención (contraseñas fuertes, cifrado moderno, cuentas gestionadas) importa tanto como la detección: una vez que un ticket con contraseña débil ha salido del entorno, ninguna alerta puede recuperarlo.

Superficie de ataque y exposición

La superficie expuesta es el conjunto de cuentas con SPN. En la mayoría de los entornos incluye cuentas de servicio para bases de datos (MSSQLSvc), servidores web, aplicaciones de negocio a medida y diversos productos de proveedores que históricamente requerían un usuario de dominio para ejecutarse. Dos categorías merecen escrutinio especial. La primera son las cuentas de servicio privilegiadas — cualquier cuenta con SPN que además sea miembro de Domain Admins, Enterprise Admins u otros grupos de alto nivel. Son las exposiciones de mayor valor porque recuperar su contraseña otorga privilegio inmediato. La segunda son las cuentas obsoletas: cuentas de servicio creadas hace años con una contraseña elegida por una persona que nunca se ha rotado. Inventariar esta superficie es un proyecto defensivo en sí mismo. Debería poder responder, en cualquier momento, cuántas cuentas con SPN existen, cuáles son privilegiadas, cuáles usan cifrado heredado y cuándo cambió cada contraseña por última vez. Si no puede responder, esa brecha es su primer hallazgo.

Detección: registros, Event IDs y telemetría

La detección se centra en los eventos de ticket de servicio Kerberos en los controladores de dominio. La señal clave es el Event ID 4769 ("Se solicitó un ticket de servicio Kerberos"). Por sí solo, este evento es de volumen extremadamente alto y benigno, así que alertar de forma ingenua es inútil; el arte está en el enriquecimiento. Priorice los eventos 4769 donde el Ticket Encryption Type sea 0x17 (RC4-HMAC) en lugar de 0x12 (AES256), porque una degradación a RC4 en una cuenta que debería admitir AES es un fuerte indicador. Correlacione por volumen y diversidad: un único principal que solicita tickets de servicio para un número inusualmente grande de SPN distintos en poco tiempo es mucho más sospechoso que el recuento bruto de eventos. Vigile el Event ID 4768 (TGT solicitado) para el contexto inicial de autenticación y empareje 4769 con la cuenta solicitante, el host de origen y una línea base horaria. Las plataformas modernas de EDR y detección de amenazas de identidad (por ejemplo Microsoft Defender for Identity) traen analíticas propias de Kerberoasting; si opera una, ajuste y valide sus alertas. Por último, considere una cuenta de servicio señuelo (honeypot): un SPN falso con contraseña larga y aleatoria sin uso legítimo, de modo que cualquier solicitud 4769 sobre ella dispare una alerta de alta fidelidad.

Mitigación y endurecimiento

En la prevención es donde se gana. El control más eficaz es eliminar las contraseñas de cuentas de servicio elegidas por personas: migre a Group Managed Service Accounts (gMSA) o Managed Service Accounts delegadas, cuyas contraseñas son valores aleatorios de más de 120 caracteres que AD rota automáticamente y que ninguna persona conoce. Una contraseña de gMSA es computacionalmente inviable de recuperar sin conexión, lo que retira la cuenta del riesgo por completo. Donde aún no sea posible un gMSA, imponga contraseñas largas y aleatorias (25+ caracteres) en cada cuenta con SPN, ya que la longitud es la palanca directa contra el descifrado sin conexión. Desactive RC4 y exija cifrado AES para Kerberos, tanto a nivel de directiva de dominio como en los atributos de cada cuenta (msDS-SupportedEncryptionTypes), probando antes las dependencias heredadas. Aplique segmentación por niveles (tiering): ninguna cuenta de servicio debería ser a la vez portadora de SPN y miembro de un grupo muy privilegiado — separe los roles. Imponga un calendario de rotación para las cuentas manuales restantes y elimine los SPN de las cuentas que ya no los necesiten.

Ataques de credenciales de AD relacionados

El Kerberoasting rara vez está solo; pertenece a una familia de técnicas de credenciales de AD que un defensor debe tratar en conjunto. El AS-REP Roasting (T1558.004) apunta a cuentas con la preautenticación Kerberos desactivada, produciendo material descifrable sin siquiera necesitar una cuenta de dominio válida — audite el flag DONT_REQ_PREAUTH y elimínelo donde no sea estrictamente necesario. Las técnicas Pass-the-Ticket y Pass-the-Hash reutilizan autenticadores robados en lugar de descifrarlos, por lo que importan los controles de higiene de credenciales como Credential Guard, la protección de LSASS y restringir dónde inician sesión las cuentas privilegiadas. Las falsificaciones de Golden y Silver Ticket abusan de las claves de KRBTGT y de cuentas de servicio respectivamente, otra razón para rotar KRBTGT con regularidad y proteger los secretos de las cuentas de servicio. Verlos como una superficie conectada, y no como alertas aisladas, ayuda a priorizar los controles — secretos fuertes, cifrado moderno, tiering y gestión de acceso privilegiado — que reducen varios a la vez.

Errores comunes

Varios errores recurrentes socavan programas por lo demás buenos. El primero es alertar sobre el volumen bruto de 4769: sin enriquecimiento de tipo de cifrado y diversidad, el ruido entierra la señal y la regla se desactiva en una semana. El segundo es suponer que AES está impuesto cuando una sola aplicación heredada fuerza silenciosamente RC4 para toda la cuenta — verifique siempre el tipo de cifrado negociado en eventos reales, no solo en la directiva. El tercero es la cuenta de servicio privilegiada que se deja tal cual porque "la app la necesita" — esa es precisamente la exposición que convierte un hallazgo de baja gravedad en una ruta hacia el compromiso del dominio. El cuarto es dar por terminada una migración a gMSA cuando un puñado de servicios heredados tercos aún corren bajo cuentas manuales; ahí se concentra el riesgo. El quinto es desactivar la preautenticación para diagnosticar y olvidar reactivarla, abriendo silenciosamente el AS-REP Roasting. Registre cada uno como una tarea de higiene permanente.

Lista de verificación del defensor

Use esta lista como revisión periódica. Inventario: mantenga una lista viva de todas las cuentas con SPN, marcando las privilegiadas y las de cifrado heredado. Cifrado: exija AES y desactive RC4 donde las dependencias lo permitan, verificado contra eventos 4769 reales. Cuentas gestionadas: migre las cuentas de servicio a gMSA/dMSA; fije una fecha objetivo para retirar las manuales restantes. Contraseñas: para cualquier cuenta manual, imponga secretos aleatorios de 25+ caracteres y un calendario de rotación. Tiering: asegúrese de que ninguna cuenta con SPN tenga pertenencia a grupos de alto nivel. Detección: despliegue analíticas enriquecidas de 4769 (tipo de cifrado + diversidad de SPN + línea base) y valide que se disparan en una prueba controlada. Honeypot: levante una cuenta SPN señuelo con alertas de alta fidelidad. Flags adyacentes: audite y elimine el DONT_REQ_PREAUTH innecesario y confirme que la rotación de KRBTGT esté programada. Respuesta: documente el playbook para una detección confirmada — rotar el secreto afectado, buscar uso posterior y revisar la exposición de acceso privilegiado.

Preguntas frecuentes

¿Se puede prevenir por completo el Kerberoasting o solo detectar? Se puede prevenir eficazmente como amenaza práctica. Migrar las cuentas con SPN a gMSA/dMSA, o imponer contraseñas aleatorias muy largas con cifrado solo AES, hace la recuperación sin conexión computacionalmente inviable. La detección sigue siendo valiosa como defensa en profundidad y para atrapar excepciones mal configuradas, pero los secretos fuertes son lo que elimina el riesgo de raíz.

¿Por qué el Event ID 4769 es tan ruidoso y cómo lo hago útil? Cada acceso normal a un servicio genera un 4769, así que los recuentos brutos no significan nada. Se vuelve útil mediante el enriquecimiento: filtre solicitudes RC4 (0x17) en cuentas capaces de AES, correlacione un único solicitante que toca muchos SPN distintos rápidamente, establezca una línea base por cuenta y reserve las alertas de alta fidelidad para los SPN señuelo que ningún proceso legítimo debería solicitar jamás.

Conclusión

El Kerberoasting perdura no porque sea sofisticado, sino porque tantos entornos siguen arrastrando contraseñas débiles de cuentas de servicio y cifrado RC4 heredado. Para los defensores, el camino es claro y duradero: inventaríe sus cuentas con SPN, muévalas a cuentas gestionadas, imponga AES, separe el privilegio de la identidad de servicio y construya detección enriquecida sobre los eventos de ticket Kerberos con un honeypot como cable trampa. Trátelo junto a sus parientes — AS-REP Roasting, falsificación de tickets y reutilización de credenciales — como una única superficie conectada de seguridad de identidad. Haga eso y convertirá un favorito fiable del atacante en una técnica ruidosa cuando se intenta e inútil cuando tiene éxito. Entiéndalo y podrá defenderse de él.