Kerberos y su abuso

El truco de Kerberoasting es sencillo de entender: cualquier cuenta autenticada puede pedir un ticket para un servicio, y parte de ese ticket va cifrada con la contraseña de la cuenta de servicio que lo ofrece. El atacante pide el ticket, se lo lleva, y lo ataca fuera de línea a la velocidad de su propio equipo, sin tocar más el dominio ni disparar bloqueos de cuenta. No hay ninguna explotación de un fallo: se usa Kerberos como está diseñado.

En Marisma, svc-respaldo y svc-sql tienen servicio registrado, así que de las dos se puede pedir ticket. Lo que decide el resultado no es pedirlo —eso sale siempre— sino si la contraseña detrás cede al crackeo.

Aquí está el criterio que separa memorizar de entender. Se atacan fuera de línea los dos tickets. El de svc-respaldo cae en segundos: su contraseña era una palabra con un año detrás, de las que un diccionario común revienta. El de svc-sql no cae: tiene una contraseña larga y aleatoria, del tipo que una cuenta gestionada por el propio directorio genera y rota sola. La técnica fue idéntica para las dos; el resultado lo decidió la contraseña, no el ataque.

La conclusión que hay que sacar no es «Kerberoasting funciona», es «Kerberoasting funciona contra contraseñas débiles de cuentas de servicio, y por eso la defensa es la contraseña, no prohibir pedir tickets».

La segunda rendija es distinta. Kerberos, de normal, exige una comprobación previa —una prueba cifrada con tu contraseña— antes de darte el primer ticket. Pero una cuenta puede tener desactivada esa exigencia, por compatibilidad con algo viejo, y entonces cualquiera puede pedir su ticket inicial sin conocer nada y llevárselo a crackear. Eso es AS-REP roasting. No hace falta ni una credencial de servicio: basta saber el nombre de la cuenta, que la enumeración ya dio.

En Marisma, la cuenta c.donoso tiene desactivada la comprobación previa. Su ticket inicial se pide sin credenciales y, como su contraseña también era floja, cede al crackeo igual que svc-respaldo.

Con svc-respaldo crackeada tienes una credencial de servicio válida, y la enumeración ya dijo que svc-respaldo pertenece a un grupo con derecho de reescritura sobre otro que administra el servidor. Ahí está el eslabón que conecta el abuso de Kerberos con el camino de privilegio del módulo siguiente. c.donoso, en cambio, es una cuenta de a pie sin ese enganche: es una credencial más, útil para ampliar el mapa, pero no la que abre la cadena.

Elegir svc-respaldo como la credencial que se lleva a la fase de privilegios —por lo que su cuenta puede hacer, no por haber caído— es el razonamiento correcto.