Extracción de contraseñas de cuentas de servicio con Kerberoasting

En nuestra publicación sobre reconocimiento de LDAP, exploramos cómo un atacante puede realizar reconocimiento para descubrir cuentas de servicio a las que apuntar en un dominio de Active Directory (AD). Ahora veamos una forma en que un atacante puede comprometer esas cuentas y explotar sus privilegios: Kerberoasting. Esta técnica es especialmente alarmante porque no requiere privilegios de administrador en el dominio, es muy fácil de realizar y prácticamente indetectable.

Kerberoasting: Visión general

Kerberoasting es un ataque que abusa de una característica del protocolo Kerberos para recolectar hashes de contraseñas de cuentas de usuario de Active Directory: Cualquier usuario de dominio autenticado puede solicitar tickets de servicio para una cuenta especificando su Nombre Principal de Servicio (SPN), y el servicio de concesión de tickets (TGS) en el controlador de dominio devolverá un ticket que está cifrado utilizando el hash NTLM de la contraseña de la cuenta.

Por lo tanto, una vez que un adversario ha descubierto SPNs de cuentas de servicio utilizando una táctica como LDAP reconnaissance, pueden recopilar tickets para todas esas cuentas. Al llevar esos datos fuera de línea, pueden realizar un ataque de fuerza bruta para descifrar la contraseña en texto plano de cada cuenta de servicio, sin ningún riesgo de detección o bloqueo de cuentas.

Solo se necesitan unos minutos para que un atacante obtenga acceso a un dominio, recolecte tickets y comience el proceso de cracking. A partir de ahí, es solo cuestión de tiempo hasta que hayan comprometido una o más cuentas de servicio, las cuales pueden usar para robar o cifrar datos sensibles o causar otros daños.

Los adversarios se centran en las cuentas de servicio por varias razones. En primer lugar, estas cuentas a menudo tienen privilegios mucho más extensos que otras cuentas de usuario de AD, por lo que comprometerlas otorga al atacante más acceso. Además, las contraseñas de las cuentas de servicio rara vez cambian, por lo que es probable que el adversario mantenga el acceso durante mucho tiempo. Para entender los tipos de acceso que se pueden obtener utilizando Kerberoasting, mire la lista de SPNs de Active Directory mantenida por Sean Metcalf.

Kerberoasting: Cómo funciona

Paso 1. Obtenga los SPN de las cuentas de servicio.

. Existen muchas formas de obtener estos SPNs, incluyendo:

• Consultas de PowerShell y reconocimiento LDAP
• Módulo de Active Directory para PowerShell
• Script GetUserSPNs en el Kerberoast toolkit
• Comando Get-NetUser de PowerSploit

Paso 2. Solicite tickets de servicio para los SPN de la cuenta de servicio.

Simplemente ejecute un par de líneas de PowerShell, y se devolverá y almacenará en memoria un ticket de servicio a su sistema.

      Add-Type –AssemblyName System.IdentityModel
New-Object System.IdentityModel.Tokens.KerberosRequestorSecurityToken –ArgumentList ‘MSSQLSvc/jefflab-sql02.jefflab.local:1433’
      

Paso 3. Extraer tickets de servicio utilizando Mimikatz.

Mimikatz extraerá tickets locales y los guardará en disco para descifrado offline. Simplemente instale Mimikatz y emita un único comando:

Paso 4. Romper los tickets.

Los tickets de Kerberos están cifrados con la contraseña de la cuenta de servicio asociada con el SPN especificado en la solicitud del ticket. Las herramientas de Kerberoasting proporcionan un script de Python para descifrar los tickets y proporcionar sus contraseñas en texto claro ejecutando un diccionario de hashes de contraseñas contra ellos. Puede requerir algo de configuración para asegurarse de tener el entorno requerido para ejecutar el script, pero este blog cubre esos detalles.

Alternativamente, puede recopilar tickets de Kerberos utilizando el script GetUserSPNs y descifrarlos con la herramienta de recuperación de contraseñas Hashcat.

Protección contra ataques de Kerberoasting

La mitigación principal para los ataques de Kerberoasting es asegurarse de que todas las cuentas de servicio utilicen contraseñas largas y complejas que sean más difíciles de descifrar, y cambiarlas regularmente para minimizar el tiempo que la cuenta podría ser utilizada por un adversario que logra descifrar una contraseña. El uso de cuentas de servicio administradas por grupo es una mejor práctica para asignar contraseñas aleatorias y complejas que se pueden rotar automáticamente.

Dado que los adversarios descifran los tickets de forma offline, el proceso no genera tráfico de red, lo que hace que esa parte del ataque sea indetectable. Pero puedes detectar los pasos anteriores mediante el monitoreo de Active Directory con una solución de seguridad sólida. En particular, las cuentas de servicio normalmente se utilizan desde los mismos sistemas de las mismas maneras, así que presta atención a las solicitudes de autenticación anómalas. Además, monitorea los picos en las solicitudes de tickets de servicio.

Finalmente, los especialistas en seguridad también recomiendan deshabilitar el cifrado basado en RC4. De lo contrario, incluso si una cuenta de usuario admite cifrado AES, un atacante puede solicitar un ticket cifrado con RC4, el cual es más fácil de descifrar que uno creado usando cifrado AES.

Kerberoasting permite a un atacante con cualquier cuenta de dominio estándar solicitar tickets cifrados para cuentas de servicio y luego descifrar sus contraseñas sin conexión, donde no se aplica ninguna política de bloqueo y el controlador de dominio no está involucrado.

¿Qué es Kerberoasting?

Tiene éxito contra cuentas débilmente protegidas, y el 76 % de las organizaciones no gobiernan ni supervisan completamente las identidades no humanas, incluidas las cuentas de servicio, según el Netwrix 2026 Data and Identity Security Report.

El ataque comienza con una lista de esas cuentas, que un atacante puede crear mediante LDAP reconnaissance.

Kerberoasting es un ataque de Active Directory (AD) que convierte una función normal de Kerberos en una oportunidad para descifrar contraseñas. Kerberos permite que cualquier usuario autenticado solicite un ticket de servicio a un controlador de dominio, y el ticket se cifra con una clave derivada de la contraseña de la cuenta de servicio.

Cómo los atacantes extraen contraseñas de cuentas de servicio con Kerberoasting

La extracción se realiza en cuatro pasos, y Rubeus junto con GetUserSPNs.py de Impacket combinan los tres primeros en un solo comando mientras Hashcat se encarga del cuarto.

1. Encuentra las cuentas que tienen SPNs

2. Solicite tickets de servicio para los SPNs

Un atacante que recopila esos tickets puede adivinar contraseñas contra ellos sin conexión hasta que uno se descifra. Los objetivos son cuentas de usuario con service principal names (SPNs), incluyendo la mayoría de las service accounts. El ataque no requiere derechos elevados para comenzar.

Un atacante con cualquier cuenta de dominio puede listar cuentas con SPNs mediante una consulta LDAP, una consulta de PowerShell o el módulo Active Directory para PowerShell. Rubeus y GetUserSPNs.py también enumeran cuentas kerberoastables por sí mismos, y Rubeus puede informar estadísticas sobre ellas sin enviar solicitudes de tickets.

Un SPN nombra una instancia de servicio en tres partes, como en MSSQLSvc/jefflab-sql02.jefflab.local:1433Expand, que indica la clase de servicio, el host y el puerto. La clase de servicio sugiere a qué puede acceder una cuenta comprometida, como el acceso a bases de datos para MSSQLSvc.

Dos líneas de PowerShell solicitan un ticket para un SPN nombrado, y Windows lo almacena en memoria.

Rubeus automatiza la solicitud para cada cuenta kerberoastable y puede guardar los resultados en un archivo.

Kerberos verifica la identidad y deja la autorización al servicio (RFC 4120), por lo que el controlador de dominio no verifica si el solicitante puede usar el servicio antes de emitir un ticket. Por lo tanto, cualquier usuario autenticado recibe un ticket cifrado con una clave derivada de la contraseña de la cuenta del servicio.

3. Extraer los tickets de servicio

Impacket's GetUserSPNs.py hace lo mismo con su opción -request, que genera los tickets en un formato que John the Ripper y Hashcat aceptan.

Cuando existe una cuenta con la preautenticación de Kerberos deshabilitada, la opción /nopreauth de Rubeus solicita tickets de servicio enviando mensajes AS-REQ (Solicitud de Servicio de Autenticación) a través de ella.

4. Rompe los tickets

Un ticket solicitado con las líneas de PowerShell anteriores permanece en la memoria hasta que el atacante lo exporta. Mimikatz lista los tickets en la sesión actual y los escribe en archivos para descifrado offline con un solo comando.

Rubeus y GetUserSPNs.py con -request omiten este paso, porque generan hashes que se pueden crackear directamente.

Por qué importa el tipo de cifrado del ticket

El cracking se ejecuta en el hardware del atacante, por lo que no se aplica ninguna política de bloqueo y el controlador de dominio no ve nada después de la solicitud del ticket. Hashcat prueba las contraseñas contra cada ticket y recupera la contraseña en texto claro cuando una suposición la descifra. Acepta el formato que genera GetUserSPNs.py y tiene un modo separado para cada tipo de cifrado.

Netwrix Threat Prevention bloquea ataques DCSync, Kerberoasting y Pass-the-Hash en Active Directory en tiempo real. Solicite una demostración.

Los tickets RC4 se descifran más rápido

El tipo de cifrado de un ticket, RC4 (Rivest Cipher 4) o AES (Advanced Encryption Standard), determina qué tan rápido un atacante puede adivinarlo, y Microsoft cambió sus valores predeterminados en 2026.

Los atacantes pueden solicitar RC4 para cuentas que soportan AES

Los tickets AES ralentizan la adivinación pero aún ceden ante contraseñas débiles

La clave de un ticket RC4 es el hash NT LAN Manager (NTLM) de la cuenta, un hash sin sal de la contraseña (RFC 4757). Sin sal, la misma contraseña genera la misma clave para cada cuenta, y cada intento cuesta una computación de hash.

Rubeus solicita por defecto el tipo de cifrado más alto soportado por cada cuenta, pero su opción /usetgtdeleg solicita tickets RC4 para cuentas que soportan AES, y su opción /rc4opsec omite las cuentas habilitadas para AES.

GetUserSPNs.py de Impacket también solicita RC4 por defecto a menos que se establezca -no-rc4. Eliminar RC4 de los tipos de cifrado compatibles con la cuenta de servicio cierra esa vía de degradación.

Los tres tipos son vulnerables, por lo que la longitud y la aleatoriedad de la contraseña determinan el resultado.

La actualización de abril de 2026 cambió el controlador de dominio predeterminado

Protegiendo cuentas de servicio contra Kerberoasting

Las claves AES provienen de una derivación de clave salada que realiza 4.096 iteraciones por defecto (RFC 3962), haciendo que cada intento sea más costoso. La opción /aes de Rubeus apunta a cuentas habilitadas para AES y solicita sus tickets AES, y Hashcat tiene un modo separado para cada tipo de cifrado de ticket.

El cambio no afecta a las cuentas que permiten explícitamente RC4 mediante ese atributo, y se respeta tal como está escrito un valor predeterminado de dominio establecido explícitamente. Esas cuentas aún pueden recibir tickets RC4, por lo que son las primeras que se deben encontrar.

La actualización KB5073381 de Microsoft comenzó con eventos de auditoría en enero de 2026. El 14 de abril de 2026, cambió la configuración predeterminada del controlador de dominio para que las cuentas sin un valor explícito de msDS-SupportedEncryptionTypes se asuman que solo admiten AES-SHA1, y las actualizaciones lanzadas en o después de julio de 2026 ya no admiten el valor del registro que permitía a los administradores revertir el cambio.

Cada control limita una parte diferente del ataque, y todos usan funciones nativas de Active Directory y Windows.

Mover cuentas de servicio a cuentas gestionadas

Establezca contraseñas largas y aleatorias en el resto

Restablecer contraseñas y aplicar AES

Investigación de Netwrix sobre el ataque BadSuccessor, que abusa de dMSAs para la escalada de privilegios, recomienda auditar quién tiene los derechos CreateChild, WriteProperty, WriteDACL, GenericAll y WriteOwner en las unidades organizativas antes de implementarlos.

Las cuentas de servicio administradas en grupo (gMSAs) usan contraseñas aleatorias de 120 caracteres que Active Directory rota, por lo que los atacantes no tienen nada débil para adivinar. Las cuentas de servicio administradas delegadas (dMSAs) también tienen Active Directory gestionando las credenciales.

Para cuentas que no pueden moverse, MITRE ATT&CK recomienda contraseñas de idealmente 25 o más caracteres. La generación aleatoria importa tanto como la longitud, porque las listas de palabras para crackear se construyen a partir de contraseñas que las personas eligen.

Las claves AES se generan cuando se establece o cambia una contraseña, por lo que una cuenta cuya contraseña es anterior al soporte AES no tiene ninguna hasta que se restablece, y una cuenta solo AES sin ellas no puede recibir tickets.

Elimine los SPN que las cuentas no necesitan

Pruebe cada servicio antes de restringirlo, porque los servicios que no soportan AES, incluidos algunos dispositivos no Windows, dejan de autenticarse una vez que se elimina RC4.

Restablezca la contraseña primero, luego verifique el atributo msDS-SupportedEncryptionTypes de la cuenta para configuraciones explícitas de RC4 y restrínjalo a AES128 y AES256 (valor 24).

Cada SPN en una cuenta de usuario hace que esa cuenta sea solicitada, así que enumérelos todos y compárelos con un servicio en ejecución.

Controla quién puede agregar SPNs

Limitar los privilegios de la cuenta de servicio

Registrar solicitudes de tickets de servicio

La cuenta krbtgt aparece en los resultados por diseño y no es algo que deba cambiarse. Para cualquier otro SPN que apunte a un host dado de baja o a una aplicación retirada, verifíquelo con setspn -L <account>Expand y elimínelo con setspn -D <SPN> <account>Expand.

En targeted Kerberoasting, un atacante con GenericAll, GenericWrite, WriteProperty o Validated Write para Service Principal Name en una cuenta añade un SPN a esta, haciendo que la cuenta sea vulnerable al roast. Revise las listas de control de acceso en las cuentas de servicio y elimine esos derechos de quienes no gestionan la cuenta. Normalmente, los miembros del grupo integrado Account Operators los poseen.

Habilite la subcategoría Audit Kerberos Service Ticket Operations en los controladores de dominio, que registra cada solicitud como Evento ID 4769. MITRE recomienda vigilar solicitudes anómalas que usan RC4, indicado como Ticket Encryption Type 0x17, mientras que los tickets AES muestran 0x11 o 0x12.

El roasting a través de una cuenta sin preautenticación envía mensajes AS-REQ en su lugar, por lo que esas solicitudes se registran como Evento ID 4768, y se aplica la misma verificación RC4 a ellas.

Una contraseña comprometida da al atacante todo lo que la cuenta puede hacer. Elimine las cuentas de servicio de grupos privilegiados como Domain Admins y otorgue solo los derechos que usa el servicio, bajo el principio de mínimos privilegios. Ese trabajo pertenece a un mayor endurecimiento de seguridad de Active Directory.

El repositorio Kerberos-Crypto de Microsoft incluye un script Get-KerbEncryptionUsage.ps1 que lee ambos tipos de eventos, y ejecutarlo con -Encryption RC4 y -SearchScope AllKdcs lista las solicitudes RC4 en todos los controladores de dominio.

Cómo Netwrix ayuda a defenderse contra Kerberoasting

Bloquee intentos de Kerberoasting en tiempo real

Los productos Netwrix añaden tres controles más allá de la configuración nativa de Windows: bloquear el ataque, detectar lo que sigue y evaluar Active Directory para identificar las vulnerabilidades que explota.

Detectar ataques basados en identidad

Netwrix Threat Prevention detiene los intentos de Kerberoasting, DCSync y Pass-the-Hash contra Active Directory antes de que tengan éxito. Esto brinda a los equipos un punto de aplicación en el momento del ataque, que la revisión de registros no puede ofrecer.

Evaluar la postura de seguridad de Active Directory

Comience con las cuentas que aún permiten RC4

Netwrix Threat Manager identifica el robo de credenciales, el movimiento lateral y la escalada de privilegios, que son ataques basados en la identidad que pueden seguir a una contraseña de cuenta de servicio comprometida. También detecta cuando se añade un SPN a una cuenta privilegiada, el paso de configuración del Kerberoasting dirigido.

Kerberoasting solo necesita una contraseña débil de cuenta de servicio, por lo que la defensa funciona mejor como una secuencia aplicada cuenta por cuenta.

Netwrix PingCastle evalúa la seguridad de Active Directory e identifica configuraciones erróneas, rutas de ataque y exposición de privilegios.

Las cuentas que no pueden convertirse en cuentas gestionadas necesitan contraseñas largas y aleatorias para resistir intentos de adivinanza sin conexión. La solicitud de ticket es el único paso que los defensores aún pueden observar, por lo que registrarla cubre lo que la higiene de contraseñas no puede.

Después del cambio predeterminado de Microsoft en abril de 2026, las cuentas que permiten explícitamente RC4, ya sea en la cuenta o mediante un valor predeterminado de dominio establecido explícitamente, aún pueden recibir tickets RC4, por lo que tienen prioridad. Mueva lo que pueda a cuentas gestionadas, luego restablezca el resto y restrínjalas a AES.

Solicite una demostración para ver cómo Netwrix Threat Prevention detiene los intentos de Kerberoasting contra sus cuentas de servicio de Active Directory antes de que tengan éxito.