Kerberos
En autenticación de empresa, Kerberos es el protocolo basado en tickets que usa Active Directory para demostrar identidad entre clientes y servicios sin enviar contraseñas por la red. Entender su intercambio de tickets es requisito previo para entender casi todo lo que ocurre en una intrusión interna sobre un parque Windows.
Cómo funciona
La versión 5 del protocolo está especificada en el RFC 4120. Un centro de distribución de claves, que en un parque Windows es el controlador de dominio, ejecuta dos servicios. El servicio de autenticación verifica al usuario al iniciar sesión y le emite un ticket-granting ticket, cifrado de forma que solo lo pueda leer el propio centro. El servicio de concesión de tickets lo cambia después por un ticket de servicio cada vez que el usuario necesita llegar a un servicio concreto.
El ticket de servicio es la parte interesante. Va cifrado con una clave derivada de la contraseña de la cuenta bajo la que corre ese servicio, y el cliente se lo presenta al servicio, que lo descifra con su propia clave. Nada de la contraseña del usuario cruza la red, y el servicio no tiene que contactar con el controlador de dominio para validar el ticket. Esa última propiedad es lo que hace tan duraderos los ataques basados en tickets.
Qué sale mal
El diseño es sólido; lo que explotamos son los despliegues de alrededor. Como cualquier usuario autenticado puede pedir un ticket de servicio para cualquier cuenta que tenga un service principal name, y como ese ticket va cifrado con una clave derivada de una contraseña, el dominio le entrega material crackeable a cualquiera con una cuenta corriente. Eso es el kerberoasting, y funciona porque las cuentas de servicio tienen contraseñas elegidas por personas, no porque Kerberos esté roto.
Las cuentas con la preautenticación desactivada entregan material equivalente sin necesidad de ninguna credencial, y eso es el AS-REP roasting. Comprometer la cuenta que firma los tickets permite a un atacante falsificarlos sin más, que es un golden ticket y es la razón de que la clave de esa cuenta sea la joya de la corona del dominio. Y los tipos de cifrado antiguos dejados activos por compatibilidad hacen el crackeo fuera de línea muchísimo más rápido que los modernos.
Dónde aparece esto en una auditoría
En una prueba interna enumeramos las cuentas con service principal name, los tipos de cifrado que el dominio va a emitir y las cuentas con la preautenticación desactivada, porque esas tres listas predicen casi todo lo que viene después. El informe se escribe contra las cuentas y contra la política, nunca contra el protocolo, y las recomendaciones son contraseñas gestionadas, retirada de service principal names obsoletos y jubilación del cifrado antiguo donde el parque lo aguante. Esto forma parte de cómo probamos la autenticación de Active Directory desde dentro.