Pass-the-Hash y Pass-the-Ticket: autenticarse sin saber la contraseña

Una de las sorpresas al estudiar Windows es descubrir que, en muchos protocolos, no hace falta conocer la contraseña real para iniciar sesión: basta con tener su hash. El sistema calcula internamente el mismo hash de lo que escribes y lo compara con el guardado; si inyectas el hash directamente, la comparación cuadra y entras. A esta técnica se le llama Pass-the-Hash (PtH), y es una de las razones por las que un auditor que consigue dumpear LSASS de un equipo con sesiones activas puede moverse por media red.

En Kerberos la idea se parece: no hace falta reautenticarse si ya se tiene un ticket válido. Si el atacante consigue el TGT de un usuario desde memoria, puede inyectarlo en su propia sesión y pasar a ser ese usuario para cualquier servicio. A eso se le llama Pass-the-Ticket (PtT).

Los dos ataques son pilares del movimiento lateral en entornos Windows. Entenderlos y defender contra ellos es imprescindible en cualquier dominio moderno.

Practica solo contra dominios propios o entornos autorizados, como los laboratorios de whoami-labs. Reutilizar hashes o tickets en sistemas ajenos sin permiso es un delito.

Qué es un hash NTLM#

Cuando un usuario de Windows establece una contraseña, el sistema no la guarda en claro: calcula un hash y guarda ese hash. Los dos formatos históricos son:

• LM (LAN Manager): hash viejísimo, roto, deshabilitado por defecto en versiones modernas.
• NTLM: lo que de verdad se usa hoy. Es un MD4 del Unicode UTF-16 LE de la contraseña. Muy rápido y sin salt.

Un hash NTLM se parece a esto: aad3b435b51404eeaad3b435b51404ee:92937945b518814341de3f726500d4ff. La primera parte es el hash LM (habitualmente aad3b..., el hash vacío) y la segunda el NTLM real.

El problema fundamental de NTLM: no incluye un desafío del cliente que pueda ser reutilizado, y el protocolo acepta directamente el hash como prueba de identidad. En un login tradicional, el sistema toma tu contraseña, calcula su hash y lo manda; si tú ya tienes el hash, saltas el primer paso.

Pass-the-Hash#

Por qué funciona#

En los protocolos basados en NTLM (SMB, RPC, WMI, autenticaciones web NTLM), el cliente demuestra que conoce la contraseña usando su hash para responder a un desafío. El servidor no ve nunca la contraseña: solo verifica que el cálculo coincide. Por tanto, cualquiera que tenga el hash puede responder correctamente, aunque no sepa la contraseña.

De dónde salen los hashes#

• Dumping de LSASS: el proceso de Windows que gestiona autenticación mantiene hashes y tickets en memoria. Herramientas como mimikatz, pypykatz y las funciones de Impacket/nxc los extraen.
• Base de datos NTDS.dit: si consigues acceso a un controlador de dominio o a una copia de seguridad, ahí están los hashes NTLM de todas las cuentas.
• SAM local: en cada equipo Windows, %SystemRoot%\System32\config\SAM guarda los hashes de las cuentas locales.
• Capturas de red (NetNTLMv2 con Responder y relay): no son el hash puro, pero se crackean con hashcat modo 5600.

Cómo se ejecuta el ataque#

Con Impacket:

# Ejecutar un comando como admin remoto sin conocer la contraseña
psexec.py [email protected] -hashes :92937945b518814341de3f726500d4ff

# Listar recursos SMB con un hash
smbclient.py user@IP -hashes :NTHASH

Con NetExec:

nxc smb 192.168.100.0/24 -u administrator -H 92937945b518814341de3f726500d4ff --local-auth
nxc smb 192.168.100.10 -u administrator -H 92937945b518814341de3f726500d4ff -x "whoami"

Un patrón clásico es spray de hash: un usuario local (como Administrador) con la misma contraseña en varios equipos permite entrar a todos con el mismo hash. En empresas con imágenes clonadas es extraordinariamente común.

Pass-the-Ticket#

La idea#

Si Kerberos autentica con tickets, un atacante que consiga un TGT o un TGS en memoria puede exportarlo e inyectarlo en su propia sesión. A partir de ese momento, su cliente de red actúa como si fuera el usuario dueño del ticket.

Cómo se obtienen tickets#

• Dumping de tickets Kerberos en memoria con mimikatz (sekurlsa::tickets /export) o pypykatz.
• Peticiones legítimas al KDC con hashes robados: si tienes el hash NTLM de un usuario, puedes pedir su TGT sin cuenta real (técnica Overpass-the-Hash, también llamada Pass-the-Key).
• Golden Ticket y Silver Ticket: forjados con la clave de KRBTGT o de un servicio tras un compromiso previo del dominio.

Overpass-the-Hash#

Es la mezcla elegante: con el hash NTLM de un usuario, el cliente puede pedir un TGT como si se autenticara con Kerberos:

getTGT.py corp.local/maria -hashes :92937945b518814341de3f726500d4ff
export KRB5CCNAME=maria.ccache
psexec.py corp.local/maria@WS01 -k -no-pass

El servicio ve un cliente que se autenticó por Kerberos, no por NTLM. Es más silencioso en redes que ya monitorizan NTLM.

Golden Ticket y Silver Ticket#

• Golden Ticket: forjado con la clave de KRBTGT, la cuenta que firma todos los TGT del dominio. Permite impersonar a cualquier usuario, incluso inexistente, durante años. Requiere haber dumpeado la clave de KRBTGT previamente (DCSync).
• Silver Ticket: forjado con la clave de un servicio concreto. Permite acceder solo a ese servicio, pero sin pasar por el KDC: no hay evento 4769.

Son la pesadilla defensiva por excelencia. Una vez emitidos, la única forma real de invalidarlos es rotar KRBTGT dos veces seguidas.

Las herramientas que vas a usar#

Hay un ecosistema pequeño pero muy consolidado alrededor de estas técnicas:

Para auditorías operadas desde Linux (lo habitual con Kali), Impacket + nxc + pypykatz cubren el 90% del trabajo sin necesidad de tocar Windows en el equipo del auditor.

Pass-the-Ticket paso a paso en un laboratorio#

En un laboratorio autorizado donde dumpeaste un ccache (ticket exportado):

# Dumpear tickets desde memoria con pypykatz (si tienes LSASS)
pypykatz lsa minidump lsass.dmp -k /tmp/tickets/

# O recibir un ccache ya exportado por mimikatz
# Apuntar la variable para que impacket lo use
export KRB5CCNAME=/tmp/tickets/maria.ccache

# Usarlo para autenticarse sin contraseña
psexec.py corp.local/maria@WS01 -k -no-pass
smbclient.py corp.local/maria@WS01 -k -no-pass

klist lista los tickets en tu caché actual. Si el TGT contenía privilegios de admin del dominio, acabas de heredarlos sin tocar ningún endpoint de autenticación. Este es el nivel de sigilo que hace que PtT sea tan atractivo en operaciones avanzadas y tan temido por los equipos defensivos de Blue Team y de respuesta a incidentes.

Un flujo típico de movimiento lateral#

En un laboratorio autorizado:

1. Shell inicial en una estación con privilegios locales (p. ej. por una explotación web).
2. Dumpeo de LSASS con secretsdump.py o lsass por fichero: hashes y tickets en memoria.
3. Spray del hash local por la red con nxc para encontrar otras máquinas con el mismo admin.
4. Overpass-the-Hash con un hash de dominio encontrado para obtener su TGT y moverse por Kerberos.
5. Cadena hasta Domain Admin: una sesión interactiva de un admin en cualquier equipo visitado deja su TGT en memoria.
6. DCSync final para extraer la base completa de hashes, incluido KRBTGT.

Toda esta cadena es exactamente lo que BloodHound modela: las aristas «HasSession», «AdminTo», «CanRDP» y «ForceChangePassword» son los puentes.

Defensas#

Credential Guard#

Función de Windows 10/11 y Server que aísla LSASS en una máquina virtual ligera (VBS). Mimikatz no puede leerlo desde el host. Es la defensa más efectiva contra el dumping, aunque no la aplicable en todos los escenarios (requiere hardware moderno).

Protected Users#

El grupo nativo Protected Users aplica estos límites a sus miembros: no se cachean credenciales, no se usa NTLM, no se delegan, no se usa RC4. Un admin en ese grupo es mucho más difícil de impersonar.

LAPS#

LAPS (Local Administrator Password Solution) hace que cada equipo tenga una contraseña de administrador única, aleatoria y rotada. Mata el ataque de hash spray: un hash robado en WS01 no funcionará en WS02 porque son contraseñas distintas.

Tiering#

Separar admins por niveles:

• Tier 0 (dominio y DCs): nunca inician sesión en servidores normales ni estaciones.
• Tier 1 (servidores de aplicación): nunca inician sesión en estaciones.
• Tier 2 (estaciones): nunca saltan arriba.

Si se respeta, un hash de Tier 2 nunca llega a comprometer un DC.

Desactivar o firmar NTLM#

Cuando sea factible, desactivar NTLM por completo y forzar Kerberos. Si no, al menos exigir firma SMB y LDAP para cerrar los ataques de relay.

Rotar KRBTGT#

En un dominio bien gestionado, KRBTGT se rota dos veces al año. Dos rotaciones seguidas (con un intervalo mínimo para que cada TGT activo expire) invalidan cualquier Golden Ticket.

Monitorización específica#

• Eventos 4624 tipo 9: logons «NewCredentials» inusuales.
• Eventos 4648: logons explícitos con credenciales distintas (típico de PtH).
• Peticiones Kerberos sin PAC o con SID anómalos.
• Detecciones de volcado de LSASS por EDR.

Errores comunes#

• Mismo admin local en todas las máquinas sin LAPS. Un hash spray compromete la red completa.
• Admins de dominio iniciando sesión en estaciones. El hash queda en LSASS y vale oro.
• Dejar NTLM habilitado «por compatibilidad». Es el canal para PtH y relay.
• No rotar KRBTGT. Un Golden Ticket forjado hoy sigue valiendo durante años.
• Ignorar el dumping de memoria. Sin EDR o Credential Guard, un sysadmin comprometido deja sus hashes servidos.

Preguntas frecuentes#

¿Pass-the-Hash funciona en Linux?#

El concepto general sí: muchos protocolos aceptan la prueba sin contraseña. Pero el mundo Windows es donde NTLM está omnipresente y donde la técnica tiene nombre y herramientas. En Linux se habla más de reutilización de tickets Kerberos o de claves SSH.

¿Un hash crackeado y Pass-the-Hash son lo mismo?#

No. Crackear un hash recupera la contraseña en claro; Pass-the-Hash usa el hash tal cual, sin recuperarla. PtH es mucho más rápido cuando funciona: no hace falta conocer la contraseña.

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

Golden usa la clave de KRBTGT y permite impersonar a cualquiera en todo el dominio. Silver usa la clave de un servicio concreto y da acceso solo a ese servicio, sin pasar por el KDC.

¿Credential Guard es suficiente?#

Reduce mucho el riesgo, pero no cubre todos los escenarios (algunos equipos antiguos no lo soportan, y hay bypasses en combinaciones específicas). Hay que combinarlo con tiering y LAPS.

¿Dónde practico?#

En los laboratorios enlazados al final de esta lección, que incluyen escenarios con hashes dumpeados y pivoting por NTLM/Kerberos.

Resumen#

• Pass-the-Hash: autenticarse en protocolos NTLM usando el hash NTLM robado, sin necesitar la contraseña.
• Pass-the-Ticket: inyectar un TGT o TGS robado en la propia sesión para actuar como el usuario original.
• Overpass-the-Hash: usar un hash NTLM para pedir un TGT nuevo, moviéndose por Kerberos.
• Golden/Silver Ticket: forjar tickets con claves robadas (KRBTGT o cuenta de servicio) para persistencia extrema.
• Las defensas: Credential Guard, Protected Users, LAPS, tiering, firma SMB/LDAP, rotación de KRBTGT y detección específica.

Fuentes y lecturas recomendadas#

• Impacket: psexec.py, secretsdump.py, getTGT.py
• Microsoft: LAPS
• Microsoft: Credential Guard
• MITRE ATT&CK T1550.002: Pass-the-Hash
• MITRE ATT&CK T1550.003: Pass-the-Ticket