Pass-the-Hash y Pass-the-Ticket: mecánica y detección para equipos azules

El robo de credenciales sigue siendo una de las vías más fiables para que un intruso se mueva por un dominio Windows, y dos técnicas están en su centro: Pass-the-Hash (PtH) y Pass-the-Ticket (PtT). Ambas abusan del diseño de los protocolos de autenticación en lugar de un único fallo parcheable, y por eso los defensores necesitan comprenderlas a fondo. Este artículo adopta el enfoque entender para defender: explicamos qué son estas técnicas, cómo operan a nivel conceptual, dónde reside el material de credenciales y —sobre todo— las señales de detección concretas y los pasos de fortalecimiento que permiten a un equipo azul detectar y contener el movimiento lateral. Aquí no hay recetas de ataque, solo el conocimiento que un defensor necesita para construir una monitorización resistente y reducir el radio de impacto de un host comprometido.

Qué son realmente Pass-the-Hash y Pass-the-Ticket

En un entorno Windows, los usuarios rara vez reintroducen su contraseña para cada recurso. En cambio, el sistema operativo guarda artefactos de autenticación en memoria para probar la identidad en nombre del usuario. En la autenticación NTLM ese artefacto es un hash equivalente a la contraseña; en Kerberos es un ticket, ya sea un Ticket-Granting Ticket (TGT) o un ticket de servicio. Pass-the-Hash es la reutilización de un hash NTLM robado para autenticarse como un usuario sin conocer nunca la contraseña en texto claro. Pass-the-Ticket es la idea equivalente para Kerberos: se presenta un ticket robado o falsificado para obtener acceso. El punto estratégico para los defensores es que ambas técnicas convierten un único endpoint comprometido en una plataforma de lanzamiento, porque los artefactos recolectados allí son válidos en otros lugares del dominio.

Cómo funcionan las técnicas a alto nivel

Ambas técnicas comparten una condición previa: un atacante que ya ha logrado ejecución de código privilegiada en un host y puede leer la memoria protegida del proceso LSASS, el subsistema de Windows que almacena en caché el material de credenciales para el inicio de sesión único. Una vez extraído ese material, PtH reproduce el hash contra servicios que aceptan NTLM, y PtT inyecta un ticket válido en una sesión de inicio de sesión para que los servicios basados en Kerberos confíen en él. Variantes como Overpass-the-Hash tienden un puente entre ambos mundos usando un hash NTLM para solicitar un TGT de Kerberos. El hilo común es que el atacante nunca necesita la contraseña: el secreto que necesita es el artefacto derivado, y ese artefacto está diseñado para ser reproducible por software legítimo. Por eso la respuesta defensiva es por capas: no se puede simplemente parchear un protocolo que se comporta según lo especificado.

Superficie de ataque: dónde reside el material de credenciales

Comprender la superficie indica qué proteger. El reservorio principal es la memoria de LSASS en cualquier host donde una cuenta privilegiada haya iniciado sesión recientemente de forma interactiva, por Escritorio Remoto o mediante un servicio que almacena credenciales. Reservorios secundarios incluyen la base de datos local SAM, los verificadores de inicio de sesión de dominio en caché, la base de datos NTDS.dit en los controladores de dominio y las copias de seguridad o instantáneas de máquinas virtuales que contengan cualquiera de ellos. Las cuentas muy privilegiadas —administradores de dominio, cuentas de servicio con amplios derechos y operadores de copia de seguridad— son las joyas de la corona, porque un solo hash o ticket recolectado de una de ellas puede abrir todo el directorio. El corolario defensivo es un principio de higiene de credenciales: nunca dejar que una cuenta de Nivel 0 se autentique en una estación de trabajo de menor confianza, porque al hacerlo se siembra en la memoria de esa máquina un secreto que domina el dominio.

Señales de detección: registros, Event IDs y telemetría

La detección es donde ganan los equipos azules. Como estas técnicas reutilizan protocolos legítimos, ningún evento por sí solo es una prueba concluyente; en su lugar se correlacionan varias señales débiles en una fuerte. Vigile los registros de seguridad de Windows en busca del Event ID 4624 (inicio de sesión correcto) con Logon Type 3 (red) o Type 9 (NewCredentials), sobre todo cuando el paquete de autenticación sea NTLM en cuentas que deberían usar Kerberos. Empareje 4624 con 4776 (validación de credenciales NTLM) y 4672 (privilegios especiales asignados) para detectar inicios de sesión de red privilegiados que no coincidan con los patrones normales. Para el abuso de Kerberos, supervise 4768 (TGT solicitado) y 4769 (ticket de servicio solicitado); los tickets con tipos de cifrado inusuales, tiempos de vida no coincidentes o solicitudes para cuentas que nunca inician sesión interactivamente merecen escrutinio. Los tickets falsificados suelen producir un tiempo de vida que excede la política del dominio, una anomalía fuerte.

La telemetría del endpoint cierra la brecha. Un EDR de calidad marca solicitudes sospechosas de handle a LSASS —el acceso al proceso con derechos como PROCESS_VM_READ desde un proceso que no es del sistema es una alerta de alto valor— así como la carga de controladores inusuales y la inyección de material de tickets en sesiones de inicio de sesión. Sysmon añade precisión: Event ID 10 (ProcessAccess) apuntando a lsass.exe, Event ID 1 (creación de proceso) para patrones conocidos de herramientas de credenciales y Event ID 3 (conexión de red) para conexiones laterales de estación a estación. La señal de comportamiento más duradera es el propio movimiento lateral: una cuenta que se autentica desde una máquina que nunca ha usado, en un horario en que nunca trabaja, hacia hosts que nunca toca. Establecer una línea base de las rutas de autenticación normales y alertar sobre las desviaciones detecta PtH y PtT incluso cuando la herramienta es novedosa.

Mitigación y fortalecimiento

El control más eficaz es la segmentación por niveles de credenciales: dividir cuentas y sistemas en niveles administrativos (Nivel 0 para controladores de dominio e infraestructura de identidad, Nivel 1 para servidores, Nivel 2 para estaciones de trabajo) y prohibir que las credenciales de nivel alto inicien sesión en niveles inferiores. Solo eso niega al atacante los artefactos joya de la corona en objetivos blandos. Habilite Credential Guard, que usa seguridad basada en virtualización para aislar los secretos de LSASS del sistema operativo en ejecución, encareciendo drásticamente la extracción. Despliegue la protección de LSASS (RunAsPPL / Protected Process Light) para que el código ordinario no pueda abrir un handle de lectura al proceso. Use el grupo de seguridad Usuarios protegidos para las cuentas sensibles, que desactiva NTLM, el cifrado Kerberos débil y el almacenamiento de credenciales en caché para sus miembros.

Reduzca la cantidad de lugares donde aterrizan los secretos. Aplique el principio de mínimo privilegio para que el trabajo diario nunca use una cuenta de administrador de dominio; proporcione cuentas de administrador separadas y sin correo, usadas solo desde estaciones de trabajo de acceso privilegiado (PAW) fortalecidas. Configure restricciones de inicio de sesión con Denegar el inicio de sesión localmente y Denegar el inicio de sesión a través de Escritorio Remoto para mantener las cuentas de Nivel 0 fuera de las máquinas ordinarias. Rote la contraseña de la cuenta krbtgt de forma programada —dos veces, con retardo— para invalidar los Golden Tickets falsificados. Desactive NTLM donde sea posible y audite dónde sigue siendo necesario. Segmente la red para que una estación comprometida no pueda alcanzar a sus pares directamente, y exija firma SMB y enlace de canal LDAP para atenuar el abuso de tipo relay. Por último, acorte los tiempos de vida de los tickets Kerberos dentro de la tolerancia operativa para que los tickets robados caduquen rápido.

Errores comunes que debilitan las defensas

Incluso los equipos maduros se sabotean. Un error frecuente es habilitar Credential Guard en las estaciones de trabajo pero dejar que un administrador de dominio inicie sesión en servidores donde no está habilitado, resembrando secretos recolectables. Otro es tratar las reglas de detección como algo que se configura y se olvida: las líneas base de autenticación se desvían a medida que cambia el parque, de modo que una regla ajustada el año pasado ahora entierra alertas reales en ruido. Los equipos también confían demasiado en un único Event ID; como 4624 y 4769 se disparan constantemente, alertar sobre ellos sin correlación produce fatiga de alertas y nada más. Las copias de seguridad son un punto ciego: una copia de NTDS.dit sin proteger entrega todos los hashes del dominio. Por último, olvidar rotar krbtgt tras un incidente deja intacta la persistencia de tickets falsificados, incluso cuando se cree haber expulsado al intruso.

Lista de verificación del defensor

Use esto como lista de trabajo. Identidad: implemente niveles administrativos; coloque las cuentas sensibles en Usuarios protegidos; use PAW para todo trabajo privilegiado; rote krbtgt dos veces de forma programada y tras cualquier sospecha de compromiso. Fortalecimiento de host: habilite Credential Guard y RunAsPPL; mantenga la protección de LSASS verificada, no solo configurada; restrinja los derechos de inicio de sesión local y RDP por nivel. Detección: recopile y centralice los Event IDs de seguridad 4624, 4672, 4768, 4769, 4776; despliegue Sysmon con monitorización de ProcessAccess en lsass.exe; establezca líneas base de rutas de autenticación normales y alerte sobre desviaciones; cace tickets con tiempos de vida o tipos de cifrado anómalos. Contención: segmente la red, exija firma SMB y enlace de canal LDAP, desactive el NTLM heredado y ensaye un runbook de incidentes que incluya la rotación de krbtgt y el restablecimiento de credenciales privilegiadas.

Preguntas frecuentes

¿Sigue siendo relevante Pass-the-Hash si usamos Kerberos en todas partes? Sí. Muchos entornos recurren a NTLM para casos límite —conexiones directas por IP, aplicaciones antiguas o servicios mal configurados— y cualquier superficie NTLM residual mantiene PtH viable. Además, Pass-the-Ticket apunta directamente a Kerberos, así que migrar de protocolo no sustituye el aislamiento de credenciales ni la monitorización.

¿Detiene la autenticación multifactor estas técnicas? El MFA es esencial en el punto de inicio de sesión interactivo, pero PtH y PtT reutilizan artefactos creados después de una autenticación correcta. Una vez que el hash o el ticket existen en memoria, el MFA ya no está en el circuito. Por eso los controles duraderos son el aislamiento de artefactos (Credential Guard, protección de LSASS), la segmentación por niveles y la detección de comportamiento, y no solo la fortaleza de la autenticación.

Conclusión

Pass-the-Hash y Pass-the-Ticket perduran porque explotan los mismos mecanismos que hacen cómodo el inicio de sesión único. No hay un solo parche que los elimine; en cambio, los defensores ganan haciendo que los artefactos recolectados sean difíciles de obtener, inútiles fuera de un alcance estrecho y ruidosos cuando se abusa de ellos. Concéntrese en la segmentación por niveles de credenciales, en funciones de aislamiento de memoria como Credential Guard y RunAsPPL, en restricciones de inicio de sesión disciplinadas y en una detección correlacionada construida sobre Event IDs de Windows y telemetría de endpoint. Cuando esas capas trabajan juntas, una única estación de trabajo comprometida sigue siendo una única estación comprometida, y la técnica más confiable del intruso se convierte en su error más visible.