Pass-the-hash

La autenticación NTLM nunca envía la contraseña. El servidor emite un desafío, el cliente calcula una respuesta usando el hash NT de la contraseña, y el servidor la verifica contra el hash que él guarda. En ningún punto de ese intercambio necesita nadie el texto en claro. Si un atacante tiene el hash, puede calcular la respuesta, y el servidor lo acepta.

Esto no es un fallo de implementación. Es lo que significa un protocolo de desafío y respuesta construido sobre un hash almacenado. La consecuencia es la parte que sorprende: el hash no es una forma protegida de la contraseña, es un equivalente de la contraseña, y hay que tratarlo exactamente con el mismo cuidado.

Obtener el hash exige derechos de administrador local en una máquina donde esa cuenta se haya autenticado, que es lo que significa en la práctica el credential dumping. El material está en la memoria del proceso de la autoridad de seguridad local, en la base de cuentas locales cuando son cuentas locales, o en cachés de credenciales. En cuanto un atacante lo tiene, lo usa contra cualquier sistema que acepte NTLM y en el que esa cuenta tenga derechos.

Las variantes importan porque las correcciones difieren. El pass-the-hash usa el hash NT contra NTLM. El pass-the-key usa ese mismo material para obtener en su lugar un ticket de Kerberos, lo que produce actividad de Kerberos de aspecto normal y es lo que elige un atacante en un parque que vigila NTLM. El pass-the-ticket roba un ticket de Kerberos ya emitido y lo reproduce, sin necesitar hash alguno.

La única condición que convierte esto en la técnica de movimiento más rápida de un parque Windows es la reutilización de credenciales. Una contraseña de administrador local horneada en una imagen y clonada en todos los puestos de trabajo produce un hash que autentica contra todos ellos. Lo sacamos de la primera máquina que comprometemos y ya tenemos el parque, sin escalar nada, sin romper nada y sin un solo inicio de sesión fallido.

La segunda condición es dónde aterrizan las credenciales privilegiadas. Un administrador de dominio que abre una sesión remota contra un puesto comprometido deja material en ese puesto. También lo dejan un servicio que corre bajo una cuenta privilegiada, una tarea programada y un técnico de soporte que se conecta a ayudar a un usuario. El atacante no necesita llegar al controlador de dominio; necesita esperar en una máquina que el administrador va a visitar. En los encargos comprometemos rutinariamente un puesto corriente y después simplemente esperamos, y el parque viene a nosotros.

La tercera es que es silencioso. Una autenticación con éxito usando una credencial válida produce un evento de inicio de sesión correcto, que es el evento más frecuente del parque. No hay ningún fallo sobre el que alertar ni ningún malware que detectar. Lo que lo distingue es un contexto para el que hay que escribir una regla: esta cuenta, en esta máquina, a esta hora, cuando no lo había hecho nunca.

La razón de que la técnica sobreviva veinticinco años después de describirse es que eliminar NTLM del todo rompe cosas. Los parques lo mantienen habilitado para un puñado de aplicaciones, y con un puñado basta.

Estos tres se usan indistintamente en los informes de incidente y necesitan respuestas distintas.

La fila que conviene leer dos veces es la última. Restablecer la contraseña de una cuenta comprometida invalida el hash de inmediato y no le hace nada a un ticket ya emitido. Una respuesta a incidentes que restablece contraseñas y declara la cuenta limpia, sin tener en cuenta la vida del ticket, deja al intruso autenticado.

Creer que un cambio de contraseña lo arregla todo. Invalida el hash. Los tickets emitidos sobreviven, igual que cualquier otra credencial que recogiera esa misma intrusión.

Usar la misma contraseña de administrador local en toda una imagen. Esta es la condición previa. Aleatorizar la contraseña por máquina le quita a la técnica su valor principal con un solo cambio.

Dejar que los administradores inicien sesión de forma interactiva en puestos corrientes. Cada una de esas sesiones deja material en una máquina más fácil de comprometer que cualquier cosa que el administrador esté protegiendo.

Suponer que los parques que solo usan Kerberos son inmunes. Son inmunes al pass-the-hash y no al pass-the-ticket ni al overpass-the-hash, que usan el mismo material robado por otro protocolo.

Tratarlo como un problema de malware. No hace falta ningún binario malicioso. La técnica es un protocolo usado según su especificación, con una credencial que el atacante tiene.

La corrección estructural es impedir que la misma credencial valga en dos sitios. Aleatoriza las contraseñas de administrador local por máquina, para que un hash recuperado valga exactamente una máquina. Después decide dónde se les permite aparecer a las credenciales privilegiadas: cuentas administrativas que no puedan iniciar sesión en puestos de trabajo, máquinas administrativas dedicadas, y sesiones remotas que no dejen material reutilizable en el destino. Para esto último existe el modo de administración restringida del escritorio remoto.

Protege el material en reposo y en memoria. Credential Guard aísla los secretos frente al sistema operativo en las configuraciones compatibles. El grupo de usuarios protegidos impide el cacheo que hace funcionar a varias de estas técnicas. Los dos son eficaces y los dos hay que probarlos contra cargas reales antes de un despliegue amplio.

Reduce NTLM de forma deliberada: audita dónde se sigue usando, cosa que el propio sistema operativo te dirá, retira las aplicaciones que lo exigen, y restríngelo por política en lugar de apagarlo en todo el parque un viernes.

Para la detección, las señales útiles salen de la correlación y no de ningún evento aislado. Una cuenta autenticándose desde una máquina que no ha usado nunca. Una cuenta local autenticándose por red, que en un parque bien llevado debería ser raro. Autenticaciones contra muchas máquinas en una ventana corta desde un mismo origen. Y eventos de inicio de sesión con credenciales explícitas en máquinas donde nadie debería estar haciendo eso. Esos son los patrones que hacen visible el movimiento lateral cuando los eventos individuales parecen perfectamente normales.

En un informe interno, el pass-the-hash se escribe como el paso de movimiento que es, dentro de un camino: aquí obtuvimos el material, este era el material, aquí era válido, y hasta aquí llegó. Escrito como hallazgo aislado no significa casi nada, porque el problema no es la técnica. El problema son la reutilización y la exposición de credenciales.

La evidencia es la cuenta, la máquina de origen, las máquinas de destino donde se aceptó y las marcas de tiempo, para que el cliente pueda localizar sus propios eventos. Los valores de hash no se imprimen en el cuerpo del informe.

La severidad la decide el alcance. El hash de una cuenta local válido en una máquina es una observación. El mismo hash válido en cuatrocientas máquinas es crítico antes de usarse para nada, y el hallazgo se escribe contra la imagen y contra el proceso que la produjo, no contra la máquina en la que casualmente empezamos. Cuando el material recuperado pertenecía a una cuenta con derechos sobre el directorio, el hallazgo se escribe como compromiso total del dominio con el camino a la vista.

Recuperar y reutilizar material de credenciales es una parte rutinaria de probar hasta dónde llega un atacante desde un único punto de apoyo.

¿Sigue siendo posible el pass-the-hash en 2026? Sí. Es una propiedad de NTLM y no un error, y NTLM sigue habilitado en la mayoría de los parques Windows por compatibilidad. Credential Guard, el grupo de usuarios protegidos y las contraseñas de administrador local por máquina lo reducen mucho, y pocos parques tienen las tres cosas en todas partes.

¿Hay que romper el hash? No, y ese es el asunto. El protocolo demuestra el conocimiento del hash, así que con el hash basta. Romperlo solo hace falta cuando se necesita el texto en claro, por ejemplo para autenticarse en un sitio que no acepta NTLM.

¿La autenticación multifactor lo detiene? Por este camino, no. La autenticación multifactor se aplica a los flujos de inicio de sesión interactivo; la autenticación NTLM entre máquinas no presenta ningún segundo factor, y por eso el movimiento a nivel de red no se ve afectado por una política que cubre la puerta principal.

¿Qué cambio aislado ayuda más? Aleatorizar la contraseña de administrador local en cada máquina. Es un cambio bien soportado, no rompe flujos de trabajo, y convierte la versión de este ataque que alcanza a todo el parque en una que alcanza a una sola máquina.