[Nota del editor: Andrew Schwartz, de TrustedSec, es coautor de este blog] Un día, mientras navegábamos por YouTube, dimos con una presentación de Tal Be'ery y Michael Cherny en la Black Hat 2015. En su charla y posterior resumen, Watching the Watchdog: Protecting Kerberos Authentication with Network Monitoring, Be'ery y Cherny esbozaron algo de lo que nunca habíamos oído hablar... el ataque Diamond Privilege Attribute Certificate (PAC). Ambos hemos estado interesados en la falsificación de tickets durante el último año, por lo que esta técnica captó inmediatamente nuestra atención y nos inició en un viaje de examen y armamento PoC. ¿El resultado? El Diamond Ticket.
Lecturas relacionadas
Billete Dorado vs Billete Diamante
Tanto los ataques Golden como los ataques Diamond Ticket requieren acceso a la clave KRBTGT. Sin embargo, es casi seguro que los ataques Diamond Ticket también requieran acceso a la clave AES256. Mientras que los ataques Golden Ticket aprovechan la capacidad de falsificar un ticket de concesión de ticket (TGT) desde cero, los ataques Diamond Ticket aprovechan la capacidad de descifrar y volver a cifrar TGT auténticos solicitados a un controlador de dominio (DC).
Diamond PAC vs Diamond Ticket
El ataque original de Diamond PAC:
- Solicita un TGT sin PAC
- Asegura que la cuenta de servicio para el servicio al que se va a acceder no tenía el bit bit NA en su atributo UserAccountControl (UAC).
- Falsifica un PAC y lo firma con la clave KRBTGT
- Inyecta el PAC en el ticket de servicio resultante incluyendo el PAC en el campo enc_authorization_data de la TGS-REQ
El bit NA del atributo UAC tiene el valor 33554432 (véase la figura 1).
Después de establecer el bit NA en el atributo UAC de una cuenta de servicio, las solicitudes de ticket de servicio a esa cuenta de servicio no tienen PAC (véase la Figura 2).
Siempre que se incluyan datos de autorización dentro de enc_authorization_data de una TGS-REQ (véase la figura 3), se copian en la sección datos_de_autorización de la parte cifrada del ticket de servicio resultante.
Diamond PAC aprovechó este comportamiento para inyectar un PAC en el ticket de servicio resultante cuando la cuenta de servicio de destino no tenía el bit bit NA (ver Figura 4).
Observe la diferencia de tamaño de la salida de billetes entre la Figura 2 y la Figura 4.
Como muestra la Figura 5, el billete pertenece a Loki, pero el PAC tiene información de usuario diferente (es decir, Thor).
Gracias a losparches Kerberos/AD de noviembre de 2021 , ya no es posible utilizar un TGT sin un PAC en los DC totalmente actualizados. Así que supimos inmediatamente que esta versión del ataque ya no funcionaría. Pero, después de leer sobre ello, nos preguntamos por qué el ataque tenía que ser tan complejo. En el proceso de simplificación del ataque, eliminamos la mayoría de sus requisitos, haciéndolo posible en DC totalmente actualizados.
La clave KRBTGT era un requisito, y el ataque hacía uso de cualquier otra cuenta válida para solicitar un TGT. ¿Por qué no descifrar ese TGT, modificarlo como quisiéramos, recalcular las firmas PAC y volver a cifrarlo? Denominamos a este método ataque Diamond Ticket.
Armar a Rubeus
Hemos implementado nuestro Ticket Diamante en Rubeus con un nuevo comando - diamante
-dentro de este PR. En la siguiente demostración, utilizaremos este nuevo comando para crear y utilizar un Ticket Diamante.
Comenzamos el ataque intentando acceder al archivo C$ (CIFS) en un DC, utilizando nuestro usuario con pocos privilegios(Loki). Como muestra la Figura 6, obtenemos una respuesta de Acceso denegado .
Asumiendo que hemos comprometido previamente la clave KRBTGT, podemos utilizar el nuevo comando diamante
en Rubeus para crear un Ticket Diamante. Este comando solicita primero un TGT normal para el usuario con privilegios bajos Loki (véase la figura 7). A continuación, el comando descifra el TGT, modifica las partes relevantes, recalcula las firmas y vuelve a cifrar el TGT (véase la figura 8).
El ticket resultante puede utilizarse como cualquier otro TGT, pero ahora con modificaciones. Como muestra la Figura 9, solicitamos un ticket de servicio al servicio CIFS en nuestro DC de destino(Earth-DC).
Por último, en el mismo terminal, ahora podemos acceder al archivo C$ en el DC, autenticándonos como un usuario distinto de la cuenta que solicitó el TGT (véase la Figura 10).
Ventajas OPSEC
Hay muchas formas posibles de detectar el uso de Golden Ticket o las acciones necesarias para acceder a la clave KRBTGT (como DCSync). Una técnica: Supervisar las solicitudes de ticket de servicio (TGS-REQs) que no tengan su correspondiente solicitud TGT (AS-REQ). Sin embargo, tenga en cuenta que es más probable que la técnica Diamond Ticket eluda este tipo de detección solicitando un TGT válido antes de utilizar el ticket resultante. Además, debido a que el ticket es creado primero por un DC, es más probable que algunos valores (por ejemplo, las horas del ticket) sean correctos por defecto, en lugar de requerir el cálculo de las horas adecuadas para la creación del OPSEC Golden Ticket.
Guía de detección
La investigación original de Diamond PAC enumeraba lo siguiente como orientación para la detección basada en la red:
- Una AS-REQ con una PA-PAC-REQUEST en falso
- La adición de datos de autorización en un mensaje TGS posterior
- El servicio de destino bit NA se establece en falso, lo que requiere PAC para la autorización
Dada nuestra técnica mejorada, esta orientación no es aplicable. El ataque Diamond Ticket no requiere solicitar un TGT sin un PAC, enviar un PAC falsificado dentro de un archivo enc_authorization_data de una TGS-REQ, o establecer el bit bit NA en ninguna cuenta de servicio.
Sin embargo, parte de la lógica de detección de un ataque con billetes dorados (por ejemplo, las acciones necesarias para acceder a la clave KRBTGT ) también podría aplicarse a la detección de un ataque con billetes diamantes. Muchas otras técnicas que pueden utilizarse para detectar cualquier tipo de billete falsificado (Dorado, Plateado o Diamante) dependen en gran medida del nivel de cuidado que se tenga durante la creación del billete; por ejemplo, establecer tiempos de billete diferentes de los que deberían ser.
Ninguno de estos métodos es una bala de plata garantizada para detectar este ataque, al igual que no existen balas de plata para detectar los Golden Tickets.
Una nueva visión de los billetes
Este post ha tratado de demostrar un armamento PoC mínimo de Diamond Tickets, aunque una implementación al estilo Mimikatz. Esta investigación puede extenderse fácilmente para proporcionar un control y manipulación total de cualquier ticket, dadas las claves adecuadas.
Al concluir nuestra investigación y crear un armamento PoC, Elad Shamir nos envió la charla DerbyCon 2014 de Tim Medin, Atacar a Microsoft Kerberos pateando al perro guardián de Hades. En esta charla, Tim discute la misma técnica en el contexto de los tickets de servicio.
Aunque nuestra técnica es una versión ligeramente diferente de los Billetes de Oro y Plata, puede ser una alternativa útil y preferible en determinados entornos.
