Kerberoasting y ataques Golden Ticket

Para comprender los ataques Kerberoasting y Golden Ticket, necesita tener clara la emisión de tickets de servicio de Kerberos. Cuando un cliente quiere acceder a un servicio (por ejemplo, un servidor SQL), presenta su Ticket Granting Ticket (TGT) al Ticket Granting Service (TGS) del controlador de dominio. El TGS emite un Service Ticket cifrado con el hash de la contraseña de la cuenta de servicio. El cliente presenta este ticket al servicio, que lo descifra con su propio hash para verificar su autenticidad. Esto significa que los tickets de servicio están cifrados con la credencial del servicio de destino, un detalle fundamental que aprovecha Kerberoasting.

Kerberoasting es un ataque que aprovecha el hecho de que cualquier usuario de dominio autenticado puede solicitar un ticket de servicio de Kerberos para cualquier servicio registrado con un SPN (Service Principal Name). El atacante solicita tickets de servicio para cuentas con SPN, captura los datos cifrados de los tickets y, posteriormente, intenta crackear la contraseña de la cuenta de servicio sin conexión, sin más interacción con Active Directory y sin riesgo de bloqueo de la cuenta. Las cuentas de servicio suelen tener contraseñas débiles, contraseñas antiguas anteriores a los requisitos modernos de complejidad o contraseñas que nunca caducan, lo que las hace muy vulnerables al cracking sin conexión.

De forma predeterminada, los hashes de los tickets de servicio capturados mediante Kerberoasting están cifrados con RC4-HMAC (hash NTLM) (por compatibilidad), que es más rápido de crackear que los tickets de Kerberos con AES-256. El atacante introduce los hashes $krb5tgs$23$ capturados en Hashcat o John the Ripper para realizar ataques de diccionario y de fuerza bruta sin conexión. Las listas de palabras habituales, como RockYou, combinadas con conjuntos de reglas, pueden crackear la mayoría de las contraseñas débiles de cuentas de servicio en cuestión de minutos u horas mediante hardware de GPU para consumidores. Una vez crackeada, el atacante obtiene la contraseña en texto plano de la cuenta de servicio, que puede utilizar para autenticarse directamente.

Las medidas de mitigación de Kerberoasting se centran en tres áreas: fortaleza de las contraseñas: las cuentas de servicio deben tener contraseñas largas y aleatorias (de más de 25 caracteres) que resistan el cracking sin conexión incluso con clústeres de GPU; Group Managed Service Accounts (gMSA): Windows administra automáticamente las contraseñas de gMSA (valores aleatorios de 240 caracteres que se rotan cada 30 días), lo que hace que Kerberoasting sea inviable desde el punto de vista computacional; cifrado exclusivo con AES: configure las cuentas de servicio para que requieran tickets AES-256 (msDS-SupportedEncryptionTypes), cuyo cracking es exponencialmente más lento que el de RC4; y detección: genere alertas ante un volumen inusual de solicitudes TGS (ID de evento 4769) para cuentas de servicio desde estaciones de trabajo no habituales.

La cuenta KRBTGT es una cuenta especial integrada de Active Directory cuyo hash de contraseña se utiliza para firmar y cifrar todos los TGT de Kerberos del dominio. El controlador de dominio utiliza el hash de KRBTGT para crear TGT y validar los TGT entrantes. Por ello, el hash de KRBTGT es la credencial más valiosa de un entorno de Active Directory: cualquiera que la posea puede crear tickets de Kerberos arbitrarios y completamente válidos para cualquier usuario, incluidos usuarios inexistentes, con cualquier pertenencia a grupos y durante cualquier período de validez. En muchas organizaciones, la contraseña de KRBTGT normalmente nunca se ha cambiado, porque el proceso de cambio requiere una coordinación cuidadosa.

Un ataque Golden Ticket crea un TGT de Kerberos falsificado y completamente válido utilizando el hash de contraseña comprometido de la cuenta KRBTGT. El atacante utiliza el comando kerberos::golden de Mimikatz para generar un TGT para cualquier usuario (a menudo una cuenta falsa similar a Administrator), con cualquier pertenencia a grupos (normalmente incluyendo Domain Admins) y cualquier período de validez (habitualmente establecido en 10 años). Este ticket falsificado es indistinguible de un ticket legítimo para el controlador de dominio, porque es criptográficamente válido: se firmó con el hash real de KRBTGT. Un Golden Ticket proporciona control completo, persistente e ilimitado sobre el dominio.

Los Golden Ticket son especialmente peligrosos porque persisten incluso después de descubrir y limpiar el ataque original. Cambiar la contraseña del usuario objetivo no sirve de nada: el ticket fue falsificado y no se basó en las credenciales reales del usuario. La única medida de corrección consiste en cambiar dos veces la contraseña de KRBTGT (una vez para invalidar los tickets existentes y una segunda vez porque en todo momento hay dos claves de KRBTGT para permitir la rotación). Sin embargo, los cambios de contraseña de KRBTGT requieren una coordinación cuidadosa: si se realizan incorrectamente, interrumpen la autenticación de Kerberos en todo el dominio. Muchas organizaciones son reacias a aplicar esta medida correctiva, por lo que los Golden Ticket pueden seguir siendo válidos indefinidamente.

Un Silver Ticket es similar a un Golden Ticket, pero su alcance es más limitado. Utiliza el hash de la cuenta del servicio objetivo (en lugar de KRBTGT) para falsificar un ticket de servicio únicamente para ese servicio concreto. Por ejemplo, con el hash de la cuenta de servicio de un servidor SQL, un atacante puede falsificar un ticket de servicio que le conceda cualquier acceso a ese servidor SQL. Los Silver Ticket son más difíciles de detectar que los Golden Ticket porque omiten por completo el controlador de dominio: el ticket falsificado va directamente del atacante al servicio, sin contacto con el KDC. La mitigación requiere proteger los hashes de las cuentas de servicio y supervisar patrones de acceso anómalos en los servicios sensibles.

Los atacantes obtienen el hash de KRBTGT mediante el ataque DCSync, que abusa del protocolo legítimo de replicación de dominios de Active Directory. El Directory Replication Service (DRS) permite que los controladores de dominio sincronicen entre sí los datos de AD, incluidos los hashes de contraseñas. Un atacante con privilegios de DCSync (normalmente Domain Admin, Enterprise Admin o cualquier cuenta con permisos de Replicating Directory Changes All) puede suplantar a un controlador de dominio y solicitar la replicación del hash de cualquier cuenta. El comando lsadump::dcsync de Mimikatz realiza este ataque completamente a través de la red: no es necesario ejecutar código en el propio controlador de dominio.

Detectar el uso de Golden Ticket es difícil, pero posible si se buscan anomalías en los metadatos de los tickets de Kerberos: tickets con períodos de validez inusualmente largos (los tickets reales tienen una validez de TGT de 10 horas; los Golden Ticket suelen configurarse para 10 años); el ID de evento 4769 cuando el tipo de cifrado del ticket es RC4 (0x17) aunque AES-256 (0x12) sea el valor predeterminado del dominio; nombres de cuenta en los tickets que no existen en AD; y ausencia del ID de evento 4768 (solicitud de TGT) antes del ID de evento 4769 (solicitud de ticket de servicio): los Golden Ticket omiten la fase de solicitud de TGT porque el propio TGT está falsificado. Una regla de Microsoft Sentinel o Defender for Identity puede marcar estos patrones automáticamente.

Una defensa por capas contra los ataques de Kerberos incluye: utilizar gMSA para todas las cuentas de servicio, a fin de hacer inviable Kerberoasting; habilitar el cifrado exclusivo con AES para todas las cuentas, especialmente las cuentas de servicio de alto valor, para maximizar la dificultad del cracking; restringir los privilegios de DCSync: auditar las cuentas con permisos de replicación y eliminar los permisos de aquellas que no deban tenerlos; habilitar Microsoft Defender for Identity (anteriormente ATA), que proporciona detección de amenazas con reconocimiento de Kerberos, incluidas alertas en tiempo real sobre Golden Ticket, Kerberoasting y DCSync; e implementar un modelo de administración por niveles para que, incluso si se compromete una cuenta de nivel 2, no pueda utilizarse para acceder a credenciales de nivel de controlador de dominio.

Ponga a prueba su comprensión de los conceptos de CompTIA Security+ (SY0-701) de esta lección.

En esta lección aprendió lo siguiente: Kerberoasting solicita tickets de servicio para cuentas registradas con SPN y los crackea sin conexión, y se contrarresta mediante gMSA, contraseñas seguras y cifrado exclusivo con AES; los ataques Golden Ticket utilizan el hash de KRBTGT para falsificar TGT ilimitados, lo que proporciona un control persistente del dominio que se mantiene hasta que se restablece dos veces la contraseña de KRBTGT; y los ataques DCSync replican el hash de KRBTGT a través de la red sin ejecutar código en el controlador de dominio, por lo que es necesario auditar estrictamente los privilegios de DCSync. A continuación, exploraremos el marco MITRE ATT&CK para asignar las técnicas de los atacantes a las defensas.