eladshamir/internal-monologueAtaque de Monólogo Interno: Recuperando Hashes NTLM sin Tocar LSASS
Mimikatz, desarrollado por Benjamin Delpy (@gentilkiwi), es una herramienta de post-explotación bien valorada, que permite a los atacantes extraer contraseñas en texto plano, hashes NTLM y tickets Kerberos de la memoria, así como realizar ataques como pass-the-hash, pass-the-ticket o construir un golden ticket. Se podría decir que el uso principal de Mimikatz es recuperar credenciales de usuario de la memoria del proceso LSASS para su uso en movimientos laterales posteriores a la explotación.
Recientemente, Microsoft ha introducido Credential Guard en Windows 10 Enterprise y Windows Server 2016, que utiliza seguridad basada en virtualización para aislar secretos, y es muy efectivo para evitar que Mimikatz recupere hashes directamente de la memoria. Además, Mimikatz se ha convertido en un objetivo principal de la mayoría de las soluciones de protección de endpoints, y son muy agresivos en sus esfuerzos por detectarlo y prevenirlo. Aunque estos esfuerzos están destinados a fallar, se están convirtiendo cada vez más en una molestia.
NetNTLM es el protocolo de desafío-respuesta de Windows que se utiliza principalmente donde Kerberos no es compatible. En NetNTLM, el servidor envía al cliente un nonce aleatorio de 8 bytes como desafío, y el cliente calcula una respuesta que procesa el desafío con el hash NTLM como clave, que es el hash MD4 de la contraseña del usuario. Hay dos versiones del protocolo de autenticación NetNTLM, y ambas son vulnerables a ciertos ataques. Naturalmente, la versión 1 es significativamente más débil que la versión 2, y por lo tanto a partir de Windows Vista/2008, NetNTLM versión 1 está deshabilitada por defecto.
Debido a que el hash NTLM es la clave para calcular la respuesta, un atacante no necesita necesariamente obtener la contraseña en texto plano de la víctima para autenticarse, por lo que recuperar el hash de la memoria de LSASS usando Mimikatz es casi equivalente a robar una contraseña en texto plano. Chris Hummel publicó un artículo describiendo esta técnica en 2009 y la llamó “Pass the Hash” [https://www.sans.org/reading-room/whitepapers/testing/crack-pass-hash-33219].
En Defcon 2012, Moxie Marlinspike y David Hulton presentaron un ataque “Divide y Vencerás” contra NetNTLMv1 [https://www.youtube.com/watch?v=sIidzPntdCM]. En NetNTLMv1, el cliente recibe el desafío de 8 bytes y calcula la respuesta encriptándolo tres veces usando DES con diferentes partes del hash NTLM como clave. La longitud de clave para DES es efectivamente de 56 bits, que son 7 bytes, mientras que el hash NTLM es de 16 bytes. NetNTLMv1 primero encripta el desafío usando los primeros 7 bytes del hash NTLM como clave, luego encripta el desafío usando los siguientes 7 bytes del hash NTLM como clave, y finalmente encripta el desafío usando los últimos 2 bytes del hash NTLM rellenados con bytes nulos como clave. Efectivamente, esto significa que para recuperar el hash NTLM dado un desafío y respuesta NetNTLMv1, un atacante debe descifrar dos claves DES de 56 bits, lo cual es exponencialmente más fácil que descifrar una sola clave de 128 bits. Moxie y Hulton desarrollaron hardware personalizado para esta tarea y pudieron realizar fuerza bruta en todo el espacio de claves DES en menos de 24 horas, lo que garantiza la recuperación exitosa del hash NTLM en un tiempo razonable. Nótese que a diferencia de los ataques de diccionario o fuerza bruta contra la contraseña, que pueden no ser fructíferos, este ataque garantiza la recuperación exitosa del hash NTLM.
Como lo demostró ToorCon en https://crack.sh, es factible crear una tabla rainbow completa para todas las respuestas posibles de NetNTLMv1 a un desafío elegido, como 0x1122334455667788, lo que permite descifrar el hash NTLM para una respuesta dada en cuestión de minutos. La implicación es que capturar una respuesta NetNTLMv1 para el desafío elegido puede traducirse al hash NTLM correspondiente casi instantáneamente, lo que es casi equivalente a obtener la contraseña debido a Pass the Hash.
Mimikatz se ejecuta comúnmente después de que el atacante ha obtenido acceso elevado al host objetivo. En este punto, el atacante también puede cambiar claves de registro, como LMCompatibilityLevel, que especifica si el host debe negociar NetNTLMv1 o NetNTLMv2. El atacante puede cambiar el valor a 0, 1 o 2, lo que habilita NetNTLMv1 como cliente, y luego intentar autenticarse en un servidor SMB malicioso que capturará la respuesta del cliente, como se describe en la publicación del blog de Optiv [https://www.optiv.com/blog/post-exploitation-using-netntlm-downgrade-attacks].
Dos configuraciones adicionales pueden evitar que la víctima negocie una respuesta NetNTLMv1:
En entornos seguros, donde no se debe ejecutar Mimikatz, un atacante puede realizar un Ataque de Monólogo Interno, en el que invoca una llamada a procedimiento local al paquete de autenticación NTLM (MSV1_0) desde una aplicación en modo usuario a través de SSPI para calcular una respuesta NetNTLM en el contexto del usuario conectado, después de realizar una degradación NetNTLM extendida.
El flujo del Ataque de Monólogo Interno se describe a continuación:
Recientemente he vuelto a probar Internal Monologue en entornos con Credential Guard habilitado y obtuve resultados negativos. No estoy seguro de si Credential Guard no funcionaba correctamente en mi entorno de prueba durante las pruebas iniciales, o quizás algo cambió desde entonces. Actualicé la implementación para adquirir un token de servidor de AcceptSecurityContext de forma dinámica y manipularlo para evitar la trampa de autenticación local, de modo que si NetNTLMv1 sin Seguridad de Sesión Extendida falla, al menos se pueda capturar un desafío-respuesta NetNTLMv2.
El Ataque de Monólogo Interno es posiblemente más sigiloso que ejecutar Mimikatz porque no es necesario inyectar código o volcar memoria hacia/desde un proceso protegido. Debido a que la respuesta NetNTLMv1 se obtiene interactuando con NTLM SSP localmente, no se genera tráfico de red, y el desafío elegido no es fácilmente visible. No se registra ningún evento de autenticación NTLM exitosa en los registros. Los cambios en el registro para la degradación NetNTLM y el robo de tokens/suplantación de otros usuarios pueden activar indicadores.
