Recortando el Diamond Ticket de Kerberos

Este blog fue coescrito con Charlie Clark (@exploitph)

Introducción

El "Diamond Ticket" de Kerberos, al igual que un diamante en bruto, ha sido malinterpretado y subestimado desde su concepción inicial. Cuando se publicó por primera vez la prueba de concepto (PoC), carecía del pulido de una técnica completamente desarrollada; su "talla" era tosca, su "claridad" estaba nublada por la falta de contexto operativo, y su "color" estaba sesgado por conceptos erróneos. Con el tiempo, esto ha generado una serie de malentendidos sobre su verdadero propósito y potencial.

En esta publicación, refinaremos la comprensión del diamond ticket, sacando a la luz su brillo. Al centrarnos en la seguridad operativa (OPSEC), buscamos dar a este concepto la precisión y el peso o "quilate" que merece, para ofrecer un método más seguro de trabajar con la falsificación de tickets de Kerberos. No solo abordaremos estos conceptos erróneos, sino que también presentaremos una versión más enfocada en OPSEC para los Ticket Granting Tickets (TGTs) y demostraremos cómo se puede aplicar el concepto a los Service Tickets (STs).

Diamante imperfecto

Antes de poder apreciar el brillo de un "Diamond Ticket" optimizado, debemos examinar su forma actual. Al igual que un diamante en bruto, la PoC en su estado actual demostrada en Rubeus representa una implementación mínima viable con un margen significativo de mejora. No solo abordaremos estos conceptos erróneos, sino que también presentaremos una versión más enfocada en OPSEC para los Ticket Granting Tickets (TGTs) y demostraremos cómo se puede aplicar el concepto a los Service Tickets (STs). Una parte clave de esto implica examinar las limitaciones en la PoC relacionadas con el Privilege Attribute Certificate (PAC), un componente crítico de un ticket de Kerberos.

A diferencia de los Golden Tickets, que implican falsificar un TGT completamente desde cero usando solo la clave KRBTGT y metadatos esenciales, los Diamond Tickets toman un enfoque más “genuino”. Comienzan con una solicitud AS-REQ legítima al controlador de dominio (DC) para obtener un TGT válido mediante AS-REP, que luego se descifra, se modifica (por ejemplo, atributos del PAC) y se vuelve a cifrar usando la clave AES256 de KRBTGT. La única diferencia entre los tickets Diamond y los Golden o Silver es este intercambio AS inicial, lo que hace que el flujo de autenticación parezca más legítimo en la superficie. Esta legitimidad percibida es posiblemente la característica más malinterpretada de Diamond. Si bien imita el comportamiento real de Kerberos, modificaciones evidentes como intercambiar membresías de grupo en el PAC o solicitar un TGT para loki y alterarlo a thor siguen siendo trivialmente detectables con el registro y la inspección adecuados.

Este método aumenta la autenticidad del ataque al comenzar con un ticket válido y firmado, preservando gran parte de la estructura del ticket original, junto con un intercambio AS-REQ/REP previo en lugar de que un ticket aparezca de la nada (la razón principal por la que pensamos que Diamond sería una idea útil). Sin embargo, la PoC tiene limitaciones que generan brechas de seguridad operativa (OPSEC). Específicamente, el PAC se modifica solo mínimamente. Si bien el PAC incluye membresías de grupo, estas se dejan en valores predeterminados predefinidos (520,512,513,519,518) similares a los de otras herramientas de ataque, que son bien conocidos y pueden servir como un indicador claro de compromiso (IOC) si el PAC puede descifrarse. Además, el PAC carece de otros detalles críticos que lo alinearían más estrechamente con un ticket legítimo, como información precisa de la sesión de inicio de sesión y atributos del dispositivo.

Las implicaciones de estas brechas son significativas. Los entornos de Kerberos que aplican una validación estricta del PAC (por ejemplo, el grupo Protected Users o estaciones de trabajo de acceso privilegiado) o que emplean soluciones de monitoreo avanzadas pueden señalar estas discrepancias, haciendo que el enfoque "genuino" operacionalizado en la PoC sea menos sigiloso de lo previsto. Además, dado que el PAC se firma usando la clave de la cuenta KRBTGT, cualquier alteración a su estructura que no tenga en cuenta estas brechas puede potencialmente romper la compatibilidad con ciertas implementaciones de Kerberos o configuraciones de monitoreo.

En esta sección, analizaremos la implementación actual de la PoC que se encuentra en Rubeus, desglosando su metodología paso a paso desde la solicitud inicial del TGT hasta su descifrado, modificación y proceso de recifrado. También examinaremos las deficiencias técnicas del enfoque actual y exploraremos por qué abordar estos problemas, particularmente en torno al PAC, es crucial para mejorar el OPSEC y la viabilidad práctica del Diamond Ticket en escenarios del mundo real.

Creemos un Diamond Ticket en su forma actual de PoC:

Rubeus.exe diamond /krbkey:<aes256_krbtgt_key> /user:loki /password:Mischief$ /enctype:aes /domain:marvel.local /dc:earth-dc.marvel.local /ticketuser:thor /ticketuserid:1104 /nowrap

Figura 1: Diamond Ticket predeterminado de Rubeus

Al proporcionar los valores de /servicekey y /ticket a la función describe de Rubeus, podemos descifrar y examinar el PAC de nuestro Diamond Ticket recién creado.

Figura 2: Diamond Ticket descifrado con la PoC original

Al observar el resultado anterior, Rubeus completó los grupos predeterminados en el PAC y dejó muchos de los campos en blanco o incorrectos, lo cual no es seguro desde el punto de vista de OPSEC si un defensor o una herramienta de seguridad obtiene visibilidad sobre el PAC.

Examen del PAC con una lupa o con la función “Describe” de Rubeus

Al igual que un joyero con una lupa, a veces necesitas acercarte a un ticket de Kerberos para ver de qué está realmente hecho. En lugar de diamantes, estás inspeccionando blobs de tickets cifrados con la función /describe de Rubeus.

Los tickets de Kerberos están en el centro de la autenticación y la autorización en entornos de Active Directory (AD). Garantizan que los usuarios estén debidamente autenticados antes de acceder a recursos de red, y forman la columna vertebral de la comunicación segura dentro de un dominio.

Para entender cómo se toman las decisiones de acceso, ayuda mirar dentro del ticket mismo.

Ticket (mayormente cifrado): Esta sección contiene los datos relacionados con el cliente, cifrados con la clave de largo plazo del servicio. Se usa para validar y autorizar el acceso del cliente a los recursos. Una parte vital de esta sección es el PAC, que lleva los datos de privilegios e identidad del usuario necesarios para decisiones de control de acceso detalladas.

El siguiente diagrama es un mapa de visualización que te ayudará, como lector, a entender el contexto del PAC.

Figura 3: Diagrama del ticket (concepto original de
"I've Got a Golden Twinkle In My Eye", presentado en el SANS Pentest and Hackfest Summit 2022)

Puntos clave del diagrama:

• El PAC reside dentro del campo Authorization-Data del ticket y está cifrado para proteger su confidencialidad.
• Para los TGT, se usa la clave de la cuenta KRBTGT para el cifrado.
• Para los ST, se usa la clave específica del servicio para el cifrado.
• El PAC contiene:
• Atributos del usuario: Como el SID (identificador de seguridad) y el nombre de dominio de inicio de sesión, cruciales para identificar al usuario dentro del dominio.
• Membresías de grupo: Información sobre a qué grupos pertenece el usuario, lo que ayuda a determinar sus derechos de acceso.
• Datos de políticas: Puntos de datos como PasswordMustChange, que aseguran que se sigan las políticas del dominio (por ejemplo, la expiración de contraseñas).

Esta estructura garantiza tanto la confidencialidad como la integridad del PAC, lo que lo convierte en una fuente confiable para las decisiones de autorización entre servicios.

Por qué el PAC es necesario

Aunque el ticket de Kerberos por sí mismo prueba la identidad del usuario, el PAC cumple un papel vital al vincular la autenticación con la autorización. El PAC es el conjunto de datos que los servicios usan para determinar qué puede hacer el usuario una vez autenticado.

Funciones clave del PAC:

• Identidad del usuario: El PAC incluye el SID del usuario, que lo identifica de forma única dentro del dominio, asegurando una identificación adecuada en toda la red.
• Autorización: Las membresías de grupo dentro del PAC definen a qué recursos y servicios puede acceder el usuario.
• Aplicación de políticas: Atributos como PasswordMustChange aplican políticas de seguridad de toda la organización, como forzar a los usuarios a cambiar sus contraseñas después de cierto período.
• Confianza entre dominios: El PAC puede incluir información de confianza para la autenticación entre dominios, permitiendo que usuarios de un dominio accedan a recursos en otro dominio.

A continuación, desglosaremos cada campo de nuestro ticket de ejemplo anterior y explicaremos su función e importancia para mantener una autenticación segura:

1. Información del servicio

• ServiceName: krbtgt/MARVEL.LOCAL
• Este campo indica el servicio asociado con el ticket. El servicio KRBTGT es el servicio de TGT, que es el componente central en la autenticación Kerberos. Es responsable de emitir y renovar los TGT. En este caso, el servicio es específico del dominio MARVEL.LOCAL.
• ServiceRealm: MARVEL.LOCAL
• El ServiceRealm no indica dónde está ubicado el servicio, sino que especifica el dominio desde donde se solicitó o emitió el ticket. En escenarios entre dominios, al solicitar un ticket para un servicio en un dominio externo, el ServiceRealm refleja el dominio local donde el cliente inició la solicitud, no necesariamente el dominio del servicio mismo.

2. Información del usuario

• UserName: thor (NT_PRINCIPAL)
• Este campo representa el nombre de usuario de la cuenta que solicita el ticket. En este caso, es thor, un identificador de un usuario en el dominio MARVEL.LOCAL. El término NT_PRINCIPAL indica que es un principal de usuario NT (Windows) estándar.
• UserRealm: MARVEL.LOCAL
• Este es el dominio Kerberos en el que reside el usuario.

3. Validez del ticket

• StartTime: 13/1/2025 6:42:04 p. m.
• El StartTime marca cuándo el ticket se vuelve válido. Se usa para aplicar restricciones basadas en el tiempo, evitando que el ticket se use antes de esta marca de tiempo. Agrega un elemento de seguridad temporal al ticket.
• EndTime: 14/1/2025 4:42:04 a. m.
• El EndTime define la expiración del ticket. Después de este momento, el ticket ya no es válido, lo que evita que se usen tickets vencidos para un acceso no autorizado.
• RenewTill: 20/1/2025 6:42:04 p. m.
• Este es el último momento en el que el ticket puede renovarse. La renovación garantiza que los usuarios no necesiten volver a autenticarse constantemente. Es particularmente útil para sesiones largas donde los usuarios necesitan acceso continuo sin volver a ingresar sus credenciales.

4. Indicadores del ticket

• Flags: name_canonicalize, pre_authent, initial, renewable, forwardable
• Estas banderas indican ciertos comportamientos del ticket:
  • name_canonicalize: Garantiza que el nombre del usuario esté en una forma canónica (estandarizada y normalizada).
  • pre_authent: Esto significa que el usuario debe pasar por una preautenticación antes de que se pueda emitir el ticket. Esto asegura que se necesite una verificación adicional, lo que fortalece la seguridad.
  • initial: Marca el ticket como el inicial, es decir, se emitió al comienzo de la sesión del usuario.
  • renewable: El ticket se puede renovar sin volver a autenticar al usuario, lo cual es útil para mantener el acceso a largo plazo.
  • forwardable: Esta bandera permite que el ticket se pase entre servicios para una autenticación entre servicios sin interrupciones.

5. Información de cifrado

• KeyType: aes256_cts_hmac_sha1
• El KeyType especifica el algoritmo de cifrado (etype) usado para la clave de sesión. En este caso, usa AES-256 con HMAC-SHA1 para la integridad, lo cual es un algoritmo de cifrado sólido y moderno, diseñado para proteger las comunicaciones de la sesión contra manipulaciones y acceso no autorizado.
• Base64(key): s2loS0ukhVb9HBn+YyrgyBBZCyQS0RFXLsoq7/OpCXc=
• Este campo contiene la clave de sesión usada para asegurar las comunicaciones entre el usuario y el servicio, codificada en Base64. Esta clave es un secreto compartido que se establece durante el proceso de emisión del ticket. Garantiza que solo las partes autorizadas puedan descifrar los datos de la sesión y usar su contenido.

6. Datos cifrados

• Block One Plain Text: 6382043D30820439
• Este campo representa parte de los datos cifrados del ticket en su forma bruta. Esto se agregó para realizar ataques contra tickets cifrados con DES. Es un bloque de datos binarios que necesitaría la clave de cifrado para descifrarse en un formato legible.

7. PAC descifrado 

El PAC contiene información crítica del usuario y detalles de la sesión, que se descifran a partir del ticket. Aquí tienes un desglose de lo que contiene:

• LogonInfo:
• LogonTime: 30/12/2024 8:53:25 PM
  • La marca de tiempo de cuando el usuario inició sesión. Es útil para rastrear la actividad del usuario y detectar inicios de sesión no autorizados.
• PasswordLastSet: 17/2/2023 7:24:59 PM
  • La fecha en que el usuario cambió su contraseña por última vez. Esto ayuda a determinar si las credenciales del usuario están actualizadas y si la contraseña sigue dentro de un período de validez seguro.
• PasswordCanChange: 18/2/2023 7:24:59 PM
  • La fecha en que se le permite al usuario cambiar su contraseña. Esto se usa para evitar que un usuario cambie su contraseña antes de tiempo, manteniendo la integridad del sistema.
• LogonCount: 407
  • La cantidad de inicios de sesión exitosos del usuario. Un conteo alto podría indicar un alto nivel de acceso, mientras que un conteo inesperadamente bajo podría generar inquietudes.
• BadPasswordCount: 0
  • La cantidad de intentos de inicio de sesión fallidos. Un conteo de cero significa que el usuario no ha tenido ningún intento fallido de inicio de sesión, lo que indica un historial de inicio de sesión seguro.
• UserFlags: (32) EXTRA_SIDS
  • Indicadores que dan información adicional sobre la cuenta del usuario. El indicador EXTRA_SIDS indica que el usuario está asociado con identificadores de seguridad (SID) adicionales.
• LogonServer: EARTH-DC
  • El controlador de dominio que autenticó al usuario. Ayuda a rastrear dónde se procesó la solicitud de autenticación.
• Groups: 520,512,513,519,518
• Una lista de los RID de grupo a los que pertenece el usuario. Estos RID son importantes para definir a qué recursos tiene acceso el usuario.

8. Información del cliente y del solicitante

• ClientId: 13/1/2025 6:42:04 PM
• Esta marca de tiempo indica el momento exacto en que el cliente (en este caso, thor) solicitó el ticket. Ayuda a sincronizar los eventos y registros de autenticación.
• Client Name: thor
• El nombre de usuario del cliente que solicitó el ticket. Confirma la identidad del usuario o sistema que inició la solicitud.
• RequestorSID: S-1-5-21-208534352-3953284921-3886779260-1104
• El SID de la entidad que solicita el ticket, por lo general el usuario. Este campo garantiza que la cuenta que solicitó el ticket sea la misma cuenta para la que se está usando. Microsoft agregó esto para protegerse contra el error de suplantación de samaccountname.

9. Sumas de verificación y firmas*

• ServerChecksum:
• Signature Type: KERB_CHECKSUM_HMAC_SHA1_96_AES256
• Este es el tipo de suma de verificación usada para validar la integridad del ticket. En este caso, se basa en HMAC-SHA1 y cifrado AES-256.
• Signature: 1D4FF0E68C986BF62ADF85F2 (VALID)
• El valor de suma de verificación que se usa para comprobar que el ticket no fue alterado. El estado VALID indica que la integridad del ticket está intacta.
• KDCChecksum:
• Signature type: KERB_CHECKSUM_HMAC_SHA1_96_AES256
• Esto se usa para proteger la suma de verificación del servidor, algo útil sobre todo en tickets que no están cifrados ni firmados con la clave KRBTGT (por ejemplo, los tickets de servicio).
• Signature: 7C50B4A42F460F3B97F3F2D5 (VALID)
• Esta suma de verificación garantiza que el ticket se mantenga seguro mientras el KDC lo procesa.

* Solo como recordatorio, tal como se indica en nuestra publicación de blog anterior, “Las sumas de verificación de Ticket y FullPAC no están presentes en los TGT ni en las referencias. Solo están presentes en los tickets de servicio”.

Por qué importan estos campos

Cada atributo de un ticket de Kerberos contribuye a su seguridad e integridad general. Los campos garantizan que se verifique la identidad del usuario, que su acceso a los servicios esté debidamente controlado, y que el ticket no pueda ser alterado durante la transmisión.

Mejora de claridad / relleno de fracturas

Así como el relleno de fracturas mejora la claridad de un diamante al revelar su verdadero brillo, la función LDAP de Rubeus descubre y extrae detalles vitales de AD, llevando información crítica a la superficie para la construcción del PAC. Rubeus tiene una función /ldap que aprovecha las consultas LDAP y monta el recurso compartido SYSVOL de un controlador de dominio para recuperar información crítica para construir un PAC. El PAC es un componente central de los tickets de Kerberos y es esencial tanto para la autenticación como para la autorización dentro de AD. A continuación, desglosamos en detalle técnico cómo opera la función LDAP de Rubeus. El archivo Networking.cs maneja cómo Rubeus interactúa con LDAP en un dominio de AD dado para recuperar los datos de usuario y de dominio, respectivamente. Tras una conexión exitosa, que requiere autenticación con credenciales, se consulta la raíz del dominio mediante GetLDAPSearchRoot.

Rubeus funciona de la siguiente manera:

• Consulta Active Directory mediante LDAP para extraer atributos de usuario y membresías de grupo.
• Monta el recurso compartido SYSVOL de un controlador de dominio para recuperar cuentas y directivas de grupo.
• Extrae las directivas de Kerberos y de contraseñas para construir un PAC falsificado.

1. Establecimiento de la conexión LDAP

Rubeus usa la biblioteca System.DirectoryServices.Protocols para comunicarse con un controlador de dominio de AD. La conexión se establece mediante LDAP (puerto 389) o LDAPS (puerto 636). Si se usa LDAPS, la conexión se cifra mediante TLS. El objeto LdapConnection se inicializa con el nombre de servidor o la dirección IP del controlador de dominio, y la autenticación se realiza con las credenciales proporcionadas (contraseña en texto plano, hash NTLM o ticket de Kerberos).

A. Vinculación con el controlador de dominio:

• Rubeus se vincula al servicio LDAP en el controlador de dominio mediante Simple Bind (con un nombre de usuario y contraseña) o SASL Bind (con autenticación NTLM o Kerberos).
• Una vinculación exitosa permite a Rubeus consultar objetos de usuario, grupos y directivas de seguridad del dominio.

B. Ejecución de consultas LDAP:

• Rubeus envía tres (3) consultas LDAP para recopilar la información del PAC.

Figura 4: Captura de Wireshark del tráfico LDAP 

2. Montaje de SYSVOL

Rubeus interactúa con los recursos compartidos SYSVOL e IPC$ para extraer objetos de directiva de grupo (GPO):

• Proceso de montaje:
• Usa SMB (puerto 445) para autenticarse con el controlador de dominio y acceder a SYSVOL.
• Accede a:
• \<DC>\IPC$ → Se usa para acceso administrativo (conexión inicial)
• \<DC>\SYSVOL → Almacena las GPO de todo el dominio (conexión que reemplaza a la anterior)
• Directivas extraídas de SYSVOL:
• GptTmpl.inf: Almacena la configuración de la directiva de contraseñas (p. ej., MinimumPasswordLength).
• Parameters: Almacena la configuración de la directiva de Kerberos (p. ej., MaxTicketAge).

3. Extracción de atributos de usuario

Una vez que se monta SYSVOL y se extraen las políticas correspondientes, Rubeus consulta LDAP para recuperar los atributos de usuario de Active Directory. Estos atributos se usan para construir el PAC, que es crucial para la autenticación Kerberos. El PAC incluye información relacionada con la identidad del usuario, las membresías de grupo, los permisos y más, todo lo cual es necesario para otorgar o negar acceso dentro del dominio.

Para construir el PAC, Rubeus recupera atributos LDAP específicos que representan la información de la cuenta del usuario, sus membresías de grupo y su configuración de seguridad.

4. Extracción de políticas de contraseñas y Kerberos desde SYSVOL

Rubeus extrae las políticas Kerberos y de contraseñas del dominio raíz de Active Directory (AD) principalmente desde el archivo GptTmpl.inf, que se almacena en el directorio SYSVOL para los objetos de política de grupo (GPO). Este archivo contiene configuraciones clave relacionadas con las políticas de contraseñas (por ejemplo, longitud mínima de contraseña, expiración de contraseña) y las políticas de tickets Kerberos (por ejemplo, tiempo de vida del ticket, políticas de renovación).

El directorio SYSVOL es una carpeta compartida que almacena información pública del dominio para Active Directory, incluidas las configuraciones de política de grupo y los scripts. Es esencial para distribuir actualizaciones de políticas a los controladores de dominio y garantiza la aplicación consistente de estas políticas en todas las máquinas del dominio. Rubeus accede a este directorio para recuperar configuraciones a nivel de dominio, que son fundamentales para aplicar políticas de seguridad y garantizar la configuración correcta de los comportamientos de autenticación.

Rubeus extrae las políticas de contraseñas y Kerberos al leer las configuraciones de política de grupo almacenadas en SYSVOL:

\<DC>\SYSVOL\<domain>\Policies\{GUID}\Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf

Al leer el archivo GptTmpl.inf , Rubeus puede recuperar las políticas de contraseñas y Kerberos configuradas del dominio. Estas configuraciones dictan comportamientos cruciales como los requisitos de complejidad de contraseñas, la frecuencia con la que se deben cambiar las contraseñas y cuánto tiempo permanecen válidos los tickets Kerberos. Esta información es vital para la autenticación Kerberos, donde el PAC debe construirse con las políticas adecuadas en mente para garantizar el cumplimiento y la seguridad.

Estas configuraciones de política pueden tener un impacto directo en el comportamiento de autenticación y autorización del usuario, como:

• Los tiempos de expiración de tickets para la autenticación Kerberos, que afectan cuánto tiempo puede un usuario acceder a los recursos sin necesidad de volver a autenticarse.
• La expiración y complejidad de contraseñas, que aplican contraseñas seguras y cambios regulares para reducir el riesgo de ataques de fuerza bruta basados en contraseñas.

La siguiente tabla resume las políticas Kerberos y de contraseñas más críticas que Rubeus extrae del archivo GptTmpl.inf:

Figura 5: Captura de Wireshark al recuperar las políticas de contraseñas y Kerberos

5. Recortando el Diamond Ticket

El TGT Kerberos es esencial para autenticar usuarios en un dominio y dar acceso a servicios sin necesidad de iniciar sesión repetidamente. Al extraer las políticas Kerberos y los atributos LDAP, Rubeus puede forjar un TGT válido que imita el comportamiento de un ticket Kerberos legítimo. Este ticket forjado permite a los atacantes o evaluadores evadir los mecanismos de autenticación estándar y escalar privilegios dentro del dominio.

Para los tickets Golden y Silver, el parámetro /ldap ha sido una función integral, que permite a Rubeus interactuar con recursos basados en LDAP y extraer datos específicos del usuario, como membresías de grupo y atributos de usuario. Esta funcionalidad LDAP es una parte clave para hacer que los tickets forjados parezcan legítimos, al garantizar que los atributos relacionados con LDAP críticos en el PAC se completen correctamente.

Sin embargo, al trabajar con los Diamond tickets en Rubeus, esta misma funcionalidad originalmente no existía, ya que solo creamos una PoC mínima viable para mostrar la técnica. Como resultado, los atributos relacionados con LDAP dentro del PAC a menudo quedaban en blanco o incorrectos (ver Figura 2), lo que disminuía la autenticidad del Diamond ticket falsificado. Los Diamond tickets no aprovechaban del todo los atributos LDAP disponibles, lo que los hacía menos confiables y más difíciles de usar en ataques o pruebas sofisticadas.

Agregar integración de LDAP a los Diamond Tickets

Para resolver este problema, decidimos modificar los archivos ForgeTicket.cs y Diamond.cs de Rubeus para admitir el parámetro /ldap en los Diamond tickets. Esta mejora garantiza que los atributos LDAP se extraigan correctamente y se incluyan en el PAC al crear un Diamond ticket. Así, el PAC resultante ahora refleja el contexto real del usuario, lo que hace que el Diamond ticket falsificado sea más genuino y confiable.

Con nuestro código modificado, ahora vamos a suministrar /ldap a diamond, junto con un /ldapuser y /ldappassword suministrados, los cuales luego se pueden combinar en /ldap 🙂

Nuevo comando de Diamond Ticket en Rubeus:

Rubeus.exe diamond /krbkey:<aes256_krbtgt_key> /user:loki /password:Mischief$ /enctype:aes /domain:marvel.local /dc:earth-dc.marvel.local /ticketuser:thor /ticketuserid:1104 /nowrap /ldap /ldapuser:loki /ldappassword:Mischief$

Figura 6: Salida que muestra la acción Diamond de Rubeus con el nuevo resultado cuando se suministran /ldap, /ldapuser y /ldappassword

La transformación completa: cada campo corregido

Hagamos una comparación detallada de un diamond ticket descifrado sin /ldap frente a nuestro nuevo ticket:

La mejora de /ldap transforma casi todos los campos del PAC con datos auténticos:

Campos críticos de autenticación

• LogonTime: Ahora refleja el último inicio de sesión real del usuario en lugar de la hora actual
• LogonCount: El conteo real (41) frente al artificial (460) evita anomalías estadísticas
• LogonServer: Se completa con el servidor de autenticación real

Cumplimiento normativo de la política de contraseñas

• PasswordLastSet: Fecha actual en lugar de 2023
• PasswordCanChange: Calculado correctamente según la política del dominio
• PasswordMustChange: Ahora está completo, y aplica la antigüedad máxima de la contraseña

Precisión de la identidad del usuario

• FullName: "Thor Odenson" en lugar de "Loki"
• ProfilePath: Ubicación válida del perfil móvil
• HomeDirectory: Directorio de inicio real del usuario
• HomeDirectoryDrive: Asignación de unidad correcta

Grupos de seguridad y permisos

• Groups: Membresías reales (512,525,513) en lugar de los IOC predeterminados (520,512,513,519,518)
• UserFlags: Limpio (0) en lugar de un EXTRA_SIDS sospechoso
• ExtraSIDs: Se eliminaron los SID falsos (S-1-5-21-0-0-0-497,S-1-18-1)

Control de cuenta

• UserAccountControl: (16400) NORMAL_ACCOUNT, NOT_DELEGATED en lugar del sospechoso DONT_EXPIRE_PASSWORD

Mejoras de OPSEC logradas

Con la integración de LDAP, creamos un contexto de usuario completo y auténtico que incluye:

• Un tiempo de sesión válido que coincide con la actividad real del usuario
• Atributos de identidad precisos que coinciden con los registros de AD
• Membresías de grupo reales sin patrones de IOC
• Fechas adecuadas de aplicación de la política de contraseñas
• Indicadores legítimos de control de cuenta
• Sin SID adicionales sospechosos ni atributos artificiales
• Asignaciones completas de perfil y directorio

Esta precisión integral de los campos transforma el Diamond Ticket, de una falsificación detectable, en un ticket de apariencia auténtica que puede superar incluso las validaciones estrictas de PAC.

Cómo agregar la integración /OPSEC a los Diamond Tickets

También implementamos compatibilidad con la bandera /opsec en los Diamond Tickets para garantizar que el tráfico de red generado durante la creación del ticket coincida con el comportamiento genuino de Windows Kerberos. Cuando está habilitada, el intercambio AS-REQ/AS-REP sigue el patrón estándar de autenticación en dos pasos de Windows: primero envía una solicitud AS-REQ sin preautenticación, y luego responde al error PREAUTH_REQUIRED del KDC con una solicitud preautenticada formateada correctamente. Esto hace que el tráfico de red durante la generación del Diamond Ticket sea indistinguible del de clientes Windows unidos legítimamente al dominio. La bandera impone cifrado exclusivo con AES256 y opciones KDCOptions adecuadas, lo que elimina los indicadores a nivel de red que podrían distinguir tickets falsificados de los flujos de autenticación Kerberos auténticos.

Gracias a Joe Dibley (@JoeDibley2) por su ayuda al implementar la función /opsec en Diamond.

Figura 7: Acción de ticket diamond de Rubeus con el nuevo argumento /opsec

Figura 8: Captura de Wireshark que muestra una AS-REQ con apariencia más genuina enviada

Con /ldap y /opsec en su lugar, tus tickets Diamond no solo se mezclan con el entorno. Resisten una inspección minuciosa con toda la claridad, el corte y el grado de algo real, y coinciden con tickets Kerberos legítimos incluso en la red o en el PAC.

Funcionalidad de tickets de servicio

Así como volver a tallar un diamante mejora su claridad y valor, hemos refinado la técnica del Diamond Ticket extendiéndola a los tickets de servicio mediante modificaciones a Rubeus. Originalmente limitada a los TGT, este avance pone en duda la relevancia continua de los Silver Tickets, que carecen de la legitimidad visible de un flujo de autenticación genuino y son más fáciles de detectar en entornos modernos. Al hacerlo, difuminamos las líneas entre el sigilo y la legitimidad, haciendo que los anticuados Silver Tickets se vean toscos y poco refinados en comparación.

Quizás recuerdes esta línea de nuestra publicación de blog original:

Al concluir nuestra investigación y crear un POC de weaponization, Elad Shamir nos envió la charla de Tim Medin en DerbyCon 2014, 'Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades.' En su charla, Tim analiza la misma técnica, pero en el contexto de los tickets de servicio.

Esto fue en julio de 2022, cuando lanzamos por primera vez el POC inicial del Diamond Ticket.

Ahora que hemos tenido más tiempo para profundizar, pensamos que no hay mejor momento para retomar el concepto y aplicarlo directamente a los tickets de servicio.

Qué hay de nuevo

Nuestra actualización te permite aplicar la técnica de falsificación Diamond a los tickets de servicio, que normalmente se emiten a partir de un TGT legítimo. Con este cambio, ahora puedes falsificar un TGS directamente usando:

• Un blob de ticket Kerberos legítimo o falsificado
  
• La clave de servicio AES (es decir, la clave usada para cifrar el ticket de servicio)

Esta mejora permite la creación directa de tickets de servicio falsificados usando un TGT válido o previamente falsificado. El resultado es mayor flexibilidad para la manipulación de tickets Kerberos, especialmente en escenarios que requieren mayor discreción operativa.

Nuevo comando de Diamond Ticket en Rubeus:

Rubeus.exe diamond /enctype:aes /domain:marvel.local /dc:earth-dc.marvel.local /ticketuser:thor /ticketuserid:1104 /ldap /ldapuser:loki /ldappassword:Mischief$ /nowrap /opsec /ticket:<output_of_service_ticket> /service:<SPN> /servicekey:<aes256_service_key>

Figura 9: Resultado de terminal que muestra el uso de un ticket y /servicekey proporcionado a Diamond

Figura 10: POC final de la capacidad de Diamond para falsificar un Service Ticket

Conclusión

A través de este proceso de recortar el Diamond Ticket, transformamos lo que alguna vez fue una prueba de concepto rudimentaria en una técnica pulida que merece consideración seria dentro de las cadenas de ataque modernas a Kerberos. Al agregar integración con LDAP, implementar controles OPSEC adecuados y extender la funcionalidad a los service tickets, abordamos las limitaciones fundamentales que antes relegaban a los Diamond Tickets al terreno de las curiosidades teóricas.

Las mejoras que implementamos cambian fundamentalmente el cálculo de riesgo tanto para atacantes como para defensores. Observa cómo se comparan ahora los Diamond Tickets con las técnicas tradicionales de falsificación de tickets:

Tabla comparativa de falsificación de tickets Kerberos

Aunque los Diamond Tickets todavía conllevan riesgo de detección (sobre todo porque evitan LSASS para la comunicación entre el cliente y el DC), ofrecen un punto medio convincente. Los tickets Golden y Silver simplemente aparecen de la nada sin ningún flujo de autenticación. ¿Los Diamond Tickets? En realidad pasan por intercambios reales de AS-REQ/AS-REP o TGS-REQ/TGS-REP. Combina este tráfico de red legítimo con nuestros datos PAC poblados vía LDAP, y obtienes un ticket que puede pasar inspección en múltiples niveles.

¿El fin de los Silver Tickets?

Ahora que extendimos la funcionalidad de Diamond a los service tickets, debemos preguntarnos: ¿los Silver Tickets tradicionales están muertos? ¿Para qué falsificar un service ticket que aparece de la nada cuando puedes crear uno con autenticación real detrás? Los Silver Tickets todavía tienen su lugar cuando no puedes tocar un DC bajo ninguna circunstancia. Pero si eres un operador que valora el sigilo por encima de la conveniencia, los service tickets falsificados con Diamond son la evolución natural.

Implicaciones para los defensores

Para los equipos azules, estas mejoras resaltan por qué el monitoreo integral de Kerberos importa más que nunca. Sí, todavía puedes detectar tickets falsificados, pero definitivamente subimos la vara. Los defensores deben enfocarse en:

• Observar los patrones de autenticación, no solo el contenido del PAC
• Estar atentos a patrones extraños de comunicación entre el cliente y el DC
• Construir reglas de SIEM que conecten múltiples indicadores
• Recordar que incluso una autenticación de apariencia "normal" podría estar ocultando tickets falsificados

Mirando hacia adelante

La técnica pulida de Diamond Ticket demuestra que los ataques a Kerberos siguen evolucionando. A medida que los defensores construyen mejor detección, los atacantes se adaptan para mezclarse más eficazmente. Este constante ir y venir empuja a ambos lados a mejorar. Al final del día, el Diamond Ticket mejorado demuestra que los ataques más peligrosos suelen ser los que parecen más legítimos. Se mezclan tan bien que distinguir lo falso de lo real se convierte en una verdadera prueba de habilidad defensiva.

Agregamos estas nuevas funciones a Rubeus en este pull request.

Gracias a Joe Dibley (@JoeDibley2) por su ayuda para implementar la función /opsec en Diamond, a Elad Shamir (@elad_shamir) y Ceri Coburn (@_EthicalChaos_) por su ayuda en revisar esta publicación, y a las incontables personas en Huntress a quienes sometí a leer y revisar esta publicación de blog.