Pass-the-Hash en Active Directory: detección y mitigación

¿Qué es Pass-the-Hash?

Pass-the-Hash es una técnica de autenticación que reutiliza material de autenticación derivado de NTLM robado en lugar de la contraseña en texto claro del usuario. En la práctica, el atacante roba material reutilizable de un sistema Windows comprometido y luego lo usa para acceder a otro host o servicio como ese usuario.

En este artículo, el alcance es deliberadamente limitado: Windows, Active Directory, NTLM y movimiento lateral. No es un artículo genérico sobre robo de credenciales. El foco es el modelo operativo específico que hace que Pass-the-Hash siga siendo relevante en entornos AD empresariales: una estación o servidor comprometido, material de autenticación reutilizable presente en ese sistema y un segundo host que todavía acepta autenticación basada en NTLM.

Esta distinción importa porque Pass-the-Hash suele mezclarse con varias técnicas cercanas:

Password spraying prueba contraseñas comunes contra muchas cuentas y no requiere hashes robados.
Pass-the-Ticket reutiliza tickets Kerberos robados, no material derivado de NTLM.
Overpass-the-Hash parte de material derivado de NTLM para obtener material de autenticación Kerberos y luego pivotar a acceso basado en Kerberos.
Kerberoasting solicita tickets de servicio y los crackea offline para recuperar contraseñas de cuentas de servicio.

Pass-the-Hash es, por tanto, un problema distinto: el atacante ya dispone de material de autenticación reutilizable y no necesita conocer la contraseña en texto claro para seguir avanzando.

Cómo funciona Pass-the-Hash

MITRE clasifica Pass-the-Hash como T1550.002, una sub-técnica de Use Alternate Authentication Material. La idea central es sencilla: después de un inicio de sesión, Windows y algunos flujos de autenticación conservan material de autenticación, y ese material puede llegar a reutilizarse si un atacante consigue robarlo.

En entornos Windows, NTLM sigue siendo la razón principal por la que Pass-the-Hash continúa siendo operativamente relevante. Si un objetivo remoto acepta NTLM, el atacante puede en algunos casos presentar material derivado de NTLM robado y autenticarse sin conocer nunca la contraseña en texto claro. Por eso reducir el uso de NTLM y limitar los lugares en los que aterrizan credenciales reutilizables son defensas centrales.

En la práctica, el material reutilizable suele proceder de una de estas rutas:

Memoria LSASS en un endpoint o servidor comprometido, después de que la víctima haya iniciado sesión
Hives SAM / SECURITY para material asociado a cuentas locales de la máquina
Cuentas de administrador local compartidas reutilizadas en varios sistemas
Credential dumping después de que el atacante ya haya obtenido privilegios de administrador local o ejecución equivalente en un host

La documentación de Microsoft sobre Credential Guard es especialmente útil aquí porque explica con precisión qué protege la función: secretos NTLM, Kerberos y Credential Manager aislados mediante virtualización, en lugar de quedar únicamente expuestos en el espacio normal de LSASS. Eso no elimina todo riesgo de robo de credenciales, pero sí cambia de forma material la superficie de ataque de las cadenas PtH clásicas.

Requisitos previos para que un ataque Pass-the-Hash tenga éxito

Pass-the-Hash suele funcionar solo cuando coinciden varias condiciones.

1. El atacante ya ha comprometido un host Windows

Pass-the-Hash rara vez es el primer movimiento. Normalmente el atacante empieza con phishing, malware, acceso remoto expuesto, mala higiene de privilegios locales u otra vía inicial. PtH se convierte después en una técnica de movimiento lateral.

2. Hay material de autenticación reutilizable en el sistema comprometido

Este es el requisito central. Si cuentas privilegiadas inician sesión en sistemas de menor confianza, si los administradores usan RDP sin protecciones adicionales o si los servidores acumulan secretos de administración reutilizables en LSASS, el atacante tiene algo que robar.

3. El siguiente objetivo sigue aceptando autenticación NTLM

La técnica se vuelve mucho más difícil si el entorno ha reducido su dependencia de NTLM, ha endurecido los flujos de administración remota o ha eliminado rutas críticas que dependen de autenticación NTLM reutilizable.

4. La credencial comprometida mantiene privilegios útiles en otros sistemas

Un hash robado de una cuenta de poco valor sirve de poco. El material realmente peligroso es el de un administrador local reutilizado en muchos equipos, una cuenta de helpdesk con mucho alcance o una cuenta AD privilegiada que inicia sesión en servidores miembro.

5. La higiene administrativa es lo bastante débil como para permitir una cadena de saltos

Por eso Pass-the-Hash está tan ligado al movimiento lateral y no solo al robo de credenciales. Si las contraseñas de administrador local son únicas, si los administradores usan estaciones dedicadas y si las credenciales privilegiadas no aterrizan en sistemas de menor nivel, el atacante pierde la ruta que hace valioso el PtH.

La cadena de ataque

Una secuencia típica de Pass-the-Hash en un entorno AD se parece a esto.

Paso 1 - Obtener ejecución en un primer host

El atacante compromete una estación o un servidor mediante phishing, malware, software vulnerable o una vía de acceso ya existente.

Paso 2 - Extraer material reutilizable

Una vez que dispone de los privilegios necesarios en ese host, el atacante apunta a LSASS o a almacenes locales de credenciales para extraer material reutilizable. MITRE asocia explícitamente herramientas como Mimikatz con el uso de Pass-the-Hash: su módulo SEKURLSA::Pth «puede suplantar a un usuario, con solo un hash de contraseña, para ejecutar comandos arbitrarios».

Paso 3 - Identificar la mejor cuenta para reutilizar

El atacante no necesita todas las cuentas. Necesita la cuenta que abra el siguiente salto. En entornos reales esto suele significar:

una cuenta de administrador local reutilizada
una identidad de helpdesk o de administración de endpoints
una cuenta de administración de servidores que ha tocado muchos hosts
una cuenta AD privilegiada que nunca debió aterrizar en ese endpoint

Paso 4 - Autenticarse contra otro host usando una ruta que todavía acepta NTLM

A partir de ese punto, el atacante se mueve lateralmente mediante protocolos administrativos, creación remota de servicios, acceso SMB administrativo, WMI, tareas programadas u otras rutas de gestión Windows que todavía aceptan ese material reutilizado.

Paso 5 - Repetir hasta alcanzar un nivel privilegiado superior

El peligro de Pass-the-Hash no es un único salto. El peligro es la cadena. Una estación comprometida lleva a otro contexto de administración, luego a un servidor de gestión, después a un sistema donde existen credenciales de más valor y, en última instancia, al control de dominio o de bosque. Esa es la misma lógica operativa descrita más ampliamente en las rutas de ataque de Active Directory hacia Domain Admin: cada frontera débil de credenciales facilita el siguiente salto.

Pass-the-Hash vs Overpass-the-Hash vs Pass-the-Ticket

Estas técnicas están relacionadas, pero no son intercambiables.

Pass-the-Hash sigue centrado en material de autenticación derivado de NTLM y en rutas de acceso que todavía aceptan NTLM.

Overpass-the-Hash empieza con material derivado de NTLM, pero lo usa para obtener material de autenticación Kerberos y pivotar luego a acceso basado en Kerberos.

Pass-the-Ticket no utiliza material derivado de NTLM; reutiliza directamente tickets Kerberos robados.

Esta distinción importa tanto para la detección como para la remediación. Si los defensores colapsan estas técnicas en un único concepto, suelen construir una estrategia de detección débil y aplicar controles equivocados al problema equivocado.

Detección

No existe un único evento de Windows que diga «esto fue Pass-the-Hash». Una estrategia útil de detección es una estrategia de correlación.

La estrategia de detección de Windows de MITRE para T1550.002 es correcta en su planteamiento: señala autenticaciones NTLM LogonType 3 anómalas que ocurren sin un evento de logon de dominio correspondiente, correlacionadas con el contexto de procesos, sesión y red, en lugar de depender de un solo indicador aislado.

Qué conviene vigilar

Patrones alrededor de 4624

4624 (An account was successfully logged on — una cuenta inició sesión correctamente) es útil cuando importa dónde aparece la sesión, qué tipo de logon utiliza y qué contexto de cuenta resulta inesperado en ese sistema.

Ejemplos de alto valor:

un logon de red que coloca una identidad administrativa en un host que rara vez toca
movimiento lateral repetido desde una estación comprometida hacia varios pares o servidores
el mismo contexto de administrador local apareciendo en varios endpoints

4672 en el destino

4672 (Special privileges assigned to new logon — se asignaron privilegios especiales a un nuevo inicio de sesión) es útil cuando un nuevo inicio de sesión recibe privilegios especiales en el sistema de destino. No es un detector de PtH por sí solo, pero ayuda a identificar qué logons remotos realmente importan.

Contexto NTLM cuando esté disponible

Si tu telemetría captura contexto de autenticación NTLM, ese dato es valioso porque PtH depende de rutas de acceso que todavía aceptan NTLM. El objetivo no es alertar sobre cada evento NTLM. El objetivo es identificar actividad administrativa basada en NTLM que resulte inesperada para las cuentas, los sistemas o los caminos observados.

Movimiento privilegiado inusual entre hosts

Las señales más fuertes suelen venir del comportamiento, no de un único ID de evento:

la misma identidad administrativa apareciendo en varios hosts en una ventana corta
contexto de administrador local reutilizado en hosts que deberían tener contraseñas locales únicas
actividad administrativa iniciada desde una estación de trabajo fuera del flujo normal de administración

Señales EDR de credential dumping y acceso a LSASS

Pass-the-Hash suele depender primero de robo de credenciales. Si el EDR ve acceso sospechoso a LSASS, comportamiento de credential dumping y, a continuación, actividad administrativa remota desde el mismo host, esa correlación suele valer más que una regla basada en un único evento.

Ejemplo de framing de detección

No plantees la detección como «4624 significa Pass-the-Hash». Un framing mejor es:

comportamiento sospechoso de acceso a credenciales en el host A
seguido de logon remoto o actividad administrativa basada en NTLM en el host B
usando un contexto de cuenta que no encaja con el sistema de origen habitual ni con el flujo normal de administración

Ese es el nivel al que PtH se detecta de verdad en operaciones reales.

Dependencia del monitoreo

Si el monitoreo de AD y Windows es débil, esta técnica será fácil de pasar por alto. Por eso la supervisión de seguridad AD: los Event IDs que importan forma parte de la misma familia de controles que la detección de Pass-the-Hash.

Remediation

La remediación de Pass-the-Hash no es una sola configuración. Es una estrategia para reducir los lugares donde existen credenciales reutilizables, reducir las rutas que todavía aceptan NTLM y limitar hasta dónde puede viajar un contexto administrativo robado.

1. Habilitar Credential Guard donde esté soportado

Microsoft indica que Credential Guard protege los hashes de contraseña NTLM, los Ticket Granting Ticket (TGT) de Kerberos y las credenciales que las aplicaciones almacenan como credenciales de dominio, aislándolos mediante seguridad basada en virtualización. Es uno de los controles más directos contra las cadenas clásicas de robo de credenciales que hacen posible PtH.

Antes de planificar un despliegue, comprueba qué está ya activado. Desde Windows 11, versión 22H2 y Windows Server 2025, Credential Guard está habilitado de forma predeterminada en los sistemas unidos al dominio que cumplen los requisitos de hardware y licencia y que no son controladores de dominio. En muchos entornos actuales, el trabajo consiste en confirmar que sigue activado, no en activarlo desde cero.

Advertencias importantes documentadas por Microsoft, según los límites de protección de Credential Guard:

algunas capacidades de autenticación quedan bloqueadas, por lo que conviene probar las aplicaciones antes del despliegue
las cuentas locales y las cuentas Microsoft no están protegidas. Credential Guard protege los secretos derivados del dominio, por lo que el material de las cuentas locales detrás de un administrador local reutilizado permanece expuesto
las credenciales suministradas para autenticación NTLM no están protegidas: Microsoft indica que si se solicita a un usuario que introduzca credenciales para autenticación NTLM y las introduce, esas credenciales son vulnerables y pueden leerse desde la memoria LSASS
los tickets de servicio Kerberos tampoco están protegidos; solo lo está el TGT de Kerberos
Microsoft indica explícitamente que no recomienda habilitar Credential Guard en controladores de dominio: ahí no aporta seguridad adicional y puede provocar problemas de compatibilidad con aplicaciones

2. Usar Remote Credential Guard o Restricted Admin para flujos RDP

Microsoft documenta dos protecciones distintas para flujos administrativos basados en RDP, y atribuye a ambas la prevención de Pass-the-Hash. Cuál usar depende de cuánto confíes en el host remoto.

Remote Credential Guard redirige las solicitudes Kerberos de vuelta al dispositivo que inicia la conexión, de modo que ni la credencial ni sus derivados llegan nunca al host remoto. Es adecuada para conexiones a un host que consideras de confianza.

Restricted Admin es la opción que Microsoft recomienda para los escenarios de soporte helpdesk, y es el punto que más se suele interpretar al revés. Microsoft indica que Remote Credential Guard no se recomienda para trabajos de helpdesk: si la sesión se abre hacia un cliente ya comprometido, el atacante puede usar ese canal abierto para crear sesiones en nombre del usuario y acceder a sus recursos durante un tiempo limitado tras desconectarse la sesión. Para helpdesk, Microsoft indica que las conexiones RDP solo deben iniciarse con el modificador /RestrictedAdmin.

Matices importantes tomados de la documentación de Microsoft:

Remote Credential Guard solo funciona con RDP
el servidor y el cliente deben autenticarse mediante Kerberos, y Remote Credential Guard no permite fallback a NTLM, porque eso expondría credenciales
solo se soporta para conexiones directas al host de destino, no a través de Remote Desktop Connection Broker o Remote Desktop Gateway
el host remoto debe estar unido a un dominio de Active Directory; no puede usarse para conectar con un dispositivo unido solo a Microsoft Entra ID (un cliente unido a Microsoft Entra sí puede conectarse a un host unido a AD)
no soporta autenticación compuesta, por lo que las pruebas de compatibilidad siguen siendo necesarias
Restricted Admin tiene su propio coste: requiere pertenecer al grupo Administrators en el host remoto y no ofrece inicio de sesión único hacia otros sistemas

3. Eliminar la reutilización de contraseñas de administrador local con Windows LAPS

Las contraseñas locales compartidas son una de las formas más sencillas de hacer escalable Pass-the-Hash. Microsoft cita «la protección contra ataques de tipo pass-the-hash y de desplazamiento lateral» como el primer beneficio de Windows LAPS. Despliega el Windows LAPS integrado en lugar del antiguo MSI de Microsoft LAPS, que Microsoft dejó obsoleto a partir de Windows 11 23H2.

Si la misma contraseña de administrador local existe en decenas o cientos de endpoints, la compromisión de un solo sistema puede convertirse en una campaña de movimiento lateral. Windows LAPS no implementado: por qué las contraseñas de administrador local compartidas siguen importando debe tratarse por tanto como una exposición directa relacionada con PtH, no como un simple tema de higiene secundaria.

4. Evitar que credenciales privilegiadas aterricen en hosts de menor confianza

La documentación de Microsoft sobre Credential Guard es directa en este punto. Credential Guard no impide que un atacante con malware en el PC use los privilegios asociados a cualquier credencial, por lo que Microsoft recomienda «usar PC dedicados para cuentas de alto valor, como los IT Pros y los usuarios con acceso a activos de alto valor». Es uno de los controles anti-PtH más prácticos porque reduce la probabilidad de que material de autenticación privilegiado termine en estaciones de trabajo de propósito general.

Eso puede adoptar varias formas:

estaciones administrativas dedicadas
jump hosts de administración con alcance de rol estricto
administración por tiers que impide que sistemas de nivel inferior recojan credenciales de niveles superiores
identidades administrativas separadas en lugar de uso diario con privilegios

5. Reducir el uso de NTLM siempre que sea posible

Pass-the-Hash sigue siendo operativamente útil porque NTLM sigue siendo operativamente útil. Si rutas críticas de administración continúan dependiendo de NTLM, el atacante conserva más margen de movimiento. Reducir NTLM, eliminar dependencias innecesarias y evitar fallbacks silenciosos reduce de forma directa la exposición a PtH.

Por la misma razón, PtH y los ataques NTLM Relay: secuestro de la autenticación en AD deben revisarse juntos. Son técnicas distintas, pero ambas sobreviven gracias a la misma deuda de protocolo.

6. Proteger las cuentas que más merece la pena robar

Para identidades altamente privilegiadas conviene considerar controles que hagan menos aceptable, desde el punto de vista operativo, el uso de NTLM y el almacenamiento de secretos reutilizables:

evitar iniciar sesión con cuentas privilegiadas en sistemas de propósito general
usar el grupo Protected Users cuando el entorno pueda asumir sus restricciones
revisar las cuentas privilegiadas obsoletas: riesgo oculto en Active Directory y eliminar identidades antiguas que mantengan un alcance excesivo
endurecer la seguridad de contraseñas en Active Directory: errores de configuración que importan para que malas prácticas de contraseñas no amplifiquen el impacto de un solo contexto administrativo robado

Protected Users es potente, pero no sale gratis. Microsoft documenta que sus miembros no pueden autenticarse mediante NTLM, no pueden usar cifrado DES ni RC4 en la preautenticación Kerberos, no pueden ser objeto de delegación restringida ni no restringida, y no pueden renovar los TGT de Kerberos más allá de una vida útil inicial de cuatro horas. En el dispositivo, CredSSP y Windows Digest dejan de almacenar en caché credenciales en texto claro, NTLM deja de almacenar en caché la función unidireccional NT, y el inicio de sesión sin conexión deja de funcionar. Microsoft también advierte contra añadir miembros de Domain Admins o Enterprise Admins antes de realizar pruebas, porque es posible bloquear esas cuentas. Eso lo convierte en un control fuerte para cuentas de alto valor, pero no en un cambio para desplegar sin validación.

Validación tras el endurecimiento

No cierres la remediación de Pass-the-Hash solo porque se haya habilitado un control. Hay que validar la ruta de extremo a extremo.

confirmar que las cuentas privilegiadas ya no inician sesión en sistemas de menor tier que expongan su material de autenticación
verificar que Windows LAPS rota realmente contraseñas únicas de administrador local en el alcance previsto
probar la compatibilidad de Credential Guard en sistemas representativos antes del despliegue amplio y confirmar después que sigue habilitado
validar que los flujos administrativos por RDP usan Remote Credential Guard o Restricted Admin donde corresponde
revisar si las rutas administrativas que permanecen siguen dependiendo de NTLM o de fallbacks silenciosos
probar si un endpoint comprometido todavía puede alcanzar otros sistemas usando un contexto de administrador local reutilizado

El criterio correcto de éxito no es «hemos habilitado un control». El criterio correcto es: «un único contexto administrativo robado ya no permite al atacante recorrer la misma cadena».

Cómo EtcSec detecta exposición relacionada

EtcSec no necesita una taxonomía artificial de Pass-the-Hash para aportar valor aquí. El valor está en las exposiciones relacionadas que hacen viable PtH.

Las familias de controles más relevantes alrededor de PtH son:

En conjunto, estos controles indican si el entorno todavía conserva los ingredientes que permiten que una credencial Windows robada se convierta en una cadena de movimiento lateral.

Controles relacionados

Pass-the-Hash rara vez es el único problema de identidad del entorno. Si lo que quieres es reducir movimiento real de atacante y no simplemente mejorar un punto de una checklist, conviene revisar PtH junto con Windows LAPS no implementado: por qué las contraseñas de administrador local compartidas siguen importando, WDigest habilitado: por qué reaparecen credenciales en texto claro en LSASS, los ataques NTLM Relay: secuestro de la autenticación en AD, las cuentas privilegiadas obsoletas: riesgo oculto en Active Directory, la supervisión de seguridad AD: los Event IDs que importan y la guía de detección y prevención de Kerberoasting. Esos controles vecinos son los que determinan si Pass-the-Hash sigue siendo una técnica practicable dentro de tu entorno AD.