Kerberoasting no ha muerto: se ha mudado a la nube

Kerberoasting debería ser un problema resuelto. Está documentado, está detectado y aparece en todas las guías de hardening escritas desde 2015. También sigue funcionando, porque la identidad híbrida no eliminó el ataque: eliminó la frontera que lo contenía. La cuenta de servicio que nunca rotaste ya no es solo una ruta hacia un servidor de ficheros. Es una ruta hacia un tenant.

La mecánica no ha cambiado. Cualquier usuario de dominio autenticado puede pedirle a un controlador de dominio un ticket de servicio para cualquier cuenta que tenga un service principal name. El KDC no comprueba si quien lo pide tiene algo que hacer hablando con ese servicio; eso es tarea del servicio, más tarde. Parte del ticket que devuelve va cifrada con una clave derivada de la contraseña de la cuenta de servicio. Te lo llevas offline y atacas esa contraseña en tu propio hardware, a tu ritmo, sin logons fallidos, sin bloqueos de cuenta y sin nada más circulando por la red.

Por qué el ticket sigue siendo crackeable

Tienen que darse dos condiciones, y en la mayoría de los entornos se siguen dando las dos.

La primera es que la cuenta tenga un SPN y una contraseña elegida por una persona. Las cuentas de máquina y las group managed service accounts tienen secretos aleatorios de 120 caracteres y no merecen el tiempo de una máquina de cracking. Una cuenta creada en 2014 para que una aplicación llegara a una base de datos, con una contraseña que alguien tecleó y un flag PasswordNeverExpires, es otra historia.

La segunda es el tipo de cifrado. Los tickets cifrados con AES son más lentos de atacar, pero «más lento» no es «seguro»: cambia el modo de hashcat y la velocidad, no el desenlace, y una contraseña débil cae igual. Importa más que RC4 siga disponible con frecuencia. El KDC emite lo que pide quien solicita, dentro del conjunto que soporta la cuenta, así que si msDS-SupportedEncryptionTypes está sin definir o todavía permite RC4, quien lo pide elige RC4 y lo obtiene. Eso no es un exploit. Es la negociación funcionando exactamente como se diseñó, a favor de quien pregunta.

# Request tickets for every SPN-bearing account the requester can see
GetUserSPNs.py -request -dc-ip 192.0.2.10 acme.local/analyst

# etype 23 (RC4) tickets
hashcat -m 13100 tickets.txt wordlist.txt

# etype 18 (AES256) tickets — different mode, same idea
hashcat -m 19700 tickets.txt wordlist.txt

Todo lo anterior ocurre con un token de usuario estándar. Sin elevación, sin exploit, sin malware.

Qué cambió de verdad la identidad híbrida

El ataque es el mismo. Las consecuencias no.

Cuando las cuentas on-premise se sincronizan con Entra ID, una contraseña recuperada de un ticket de Kerberos puede autenticar en sitios a los que el directorio local nunca llegó. Con password hash synchronisation, la credencial sirve directamente contra recursos en la nube. La cuenta de servicio que existía para lanzar un informe nocturno tiene ahora una ruta de ataque que acaba en una consola SaaS, y el equipo dueño de ese informe no ha oído hablar en su vida de la política de acceso condicional del tenant.

El tejido conectivo entre los dos directorios también merece una mirada. Entra Connect corre bajo cuentas con permisos considerables on-premise, y Seamless SSO crea en Active Directory un objeto de equipo llamado AZUREADSSOACC$ cuya clave Kerberos se comparte con Entra ID. Esa clave no es crackeable: la genera la máquina y es larga. También es, por defecto, una clave que no se rota nunca. La recomendación de Microsoft es renovarla periódicamente; el mecanismo es manual, lo que en la práctica significa que una clave creada durante una migración hace años sigue siendo válida hoy. Nada de eso requiere roasting. Requiere que alguien llegue al directorio una vez y no vuelva a quedarse fuera nunca.

Rotar la contraseña de una cuenta de servicio es un ticket en un backlog. No rotarla es una invitación permanente sin fecha de caducidad.

El fallo práctico es organizativo, no técnico. La identidad on-premise y la identidad en la nube suelen tener dueños distintos, con ventanas de cambio distintas, y las cuentas que hacen de puente entre ambas no son de ninguno de los dos. Son las cuentas que nadie quiere tocar porque nadie tiene claro qué se rompe.

Qué vigilar, y dónde

El crackeo es invisible para ti. Ocurre en hardware que no controlas, contra un fichero que salió de tu red como una respuesta Kerberos corriente. Ahí no hay ninguna oportunidad de detección.

La petición es otra cosa. El evento 4769 en un controlador de dominio registra cada ticket de servicio emitido, incluido el tipo de cifrado del ticket. En un entorno moderno y sano, un ticket RC4 para una cuenta de usuario que lleva un SPN es lo bastante raro como para mirarlo cada vez que aparece.

SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"          // RC4-HMAC
| where ServiceName !endswith "$"               // exclude machine accounts
| where ServiceName != "krbtgt"
| summarize
    Requests = count(),
    DistinctServices = dcount(ServiceName)
    by Account, bin(TimeGenerated, 10m)
| where DistinctServices > 3 or Requests > 10

En esa consulta hay dos señales y se comportan de forma distinta. El tipo de cifrado es la precisa y genera muy poco ruido una vez catalogadas las aplicaciones legacy. El volumen es la burda. El puesto de una persona pide el puñado de servicios que esa persona usa, mientras que una pasada de enumeración pide todo lo que tenga un SPN en el espacio de un minuto. La señal burda sobrevive a un atacante que pida AES, así que quédate con las dos.

La detección más potente disponible aquí no cuesta casi nada. Crea una cuenta sin ningún propósito, dale un SPN que resulte plausible, colócala en la OU correcta, ponle una contraseña de 100 caracteres genuinamente aleatoria y alerta ante cualquier petición de ticket sobre ella. No tiene consumidores legítimos, así que no tiene falsos positivos. Es una de las pocas detecciones de Active Directory cuya precisión no se degrada según cambia el entorno.

El trabajo que de verdad lo cierra

La detección te dice que pasó. Esto evita que pase.

• Audita qué cuentas tienen un SPN, y por qué. Esa lista casi siempre es más larga de lo que espera el equipo responsable, y una parte está muerta.
• Convierte lo que puedas a group managed service accounts. Sus contraseñas son aleatorias, largas y las rota el dominio, lo que elimina el ataque offline por completo en lugar de hacerlo más lento.
• Donde una gMSA no encaje, trata la contraseña como la credencial que es: 25 caracteres o más, generada, guardada en un vault y rotada con un calendario que exista de verdad.
• Pon msDS-SupportedEncryptionTypes solo en AES, una vez hayas encontrado los consumidores legacy que se van a romper. Hacerlo sin ese inventario es como una ventana de cambio se convierte en una caída.
• Asigna a un responsable con nombre las cuentas que hacen de puente entre la identidad on-premise y la de nube, y mete su rotación en un calendario. AZUREADSSOACC$ incluida.

Nada de esto es un consejo nuevo, que es la parte incómoda. Kerberoasting no es un ataque ingenioso y lleva una década sin necesitar serlo. Persiste porque las cuentas de servicio las crean bajo presión de plazos personas que no van a ser sus dueñas, y porque nada en el directorio pregunta nunca si la contraseña elegida en 2014 sigue siendo apropiada para los recursos a los que ahora llega.