Resucitando a los no muertos: cómo acelerar las búsquedas de NetNTLMv1 sin GPU

Este artículo forma parte de una serie en curso de nuestros propios especialistas, en la que comparten la investigación de vanguardia en seguridad ofensiva que utilizan para reforzar nuestros servicios líderes a nivel mundial de Detección y Respuesta Gestionadas (MDR) y proteger a los clientes frente a las amenazas en constante evolución de la era de la IA.

Los ciberataques rara vez tienen éxito gracias a una única técnica ingeniosa utilizada por sí sola. Lo más habitual es que triunfen porque los atacantes descubren las suposiciones, los atajos y los mecanismos obsoletos que las organizaciones han ido acumulando con el tiempo. Estas debilidades no siempre son evidentes. Permanecen ocultas en tu entorno durante años, sobreviviendo a actualizaciones, migraciones y revisiones de código.

Según nuestra experiencia como evaluadores de penetración, algunos de los hallazgos más valiosos surgen al identificar una tecnología en uso que ya no cumple con los requisitos de seguridad actuales. Un protocolo obsoleto, una configuración olvidada, una dependencia heredada o una decisión de diseño errónea pueden brindar a los atacantes la oportunidad de obtener acceso inicial, escalar privilegios, moverse lateralmente y establecer un sistema de comando y control (C2). Entender estos riesgos ayuda a las organizaciones a planificar y aplicar medidas correctivas allí donde tengan mayor impacto a la hora de cerrar vulnerabilidades críticas y reducir la superficie de ataque en general.

Este artículo analiza uno de estos ejemplos, explicando cómo los mecanismos de autenticación obsoletos pueden crear vulnerabilidades explotables en entornos modernos, para que los defensores puedan detectarlas primero.

Un protocolo que se niega a desaparecer

NetNTLMv1 (oficialmente llamado protocolo NTLMv1 de desafío-respuesta) es un protocolo de autenticación heredado de Microsoft que se usa para verificar la identidad de un usuario sin compartir su contraseña real por la red. NetNTLMv1 se refiere específicamente a la carga útil de red que se intercambia durante este proceso de inicio de sesión.

Ahora se considera obsoleto y de alto riesgo debido a dos fallos de diseño importantes:

• Criptografía débil (cifrado DES): NetNTLMv1 usa claves DES (Data Encryption Standard) de 56 bits para cifrar. Como el cifrado de 56 bits es matemáticamente débil, un atacante que capture una respuesta de NetNTLMv1 en la red puede descifrar fácilmente las claves DES para extraer directamente el hash NT subyacente del usuario, sin importar la longitud o la complejidad de la contraseña.
• Ataques predecibles o precalculados: con herramientas como las tablas de consulta precalculadas (tablas arcoíris), un atacante que controle el desafío del servidor puede buscar la respuesta del cliente en segundos para realizar ingeniería inversa de las claves secretas del usuario. Más sobre esto más adelante...

NetNTLMv1 es un hallazgo útil durante las pruebas de penetración porque sigue apareciendo con frecuencia en entornos de Active Directory a través de sistemas heredados, hosts mal configurados, dispositivos obsoletos y algún que otro controlador de dominio que nadie quiere tocar.

A pesar de su antigüedad y su escasa seguridad, los consultores de Sophos siguen encontrándolo durante evaluaciones en el mundo real. En miles de pruebas de penetración y operaciones del equipo rojo, las oportunidades de degradar el protocolo a NetNTLMv1 siguen siendo sorprendentemente comunes.

La vía de ataque te resultará familiar si has dedicado tiempo a probar redes internas:

1. Obligar a un objetivo (a ser posible, un controlador de dominio) a que se autentique contigo
2. Forzar la negociación a NetNTLMv1 proporcionando un desafío de servidor en lugar de permitir un protocolo más seguro: PetitPotam, PrinterBug, Coercer y la resolución de nombres envenenada conducen todos al mismo destino
3. Con el desafío estático «1122334455667788», la respuesta ya no es algo que tengas que descifrar por fuerza bruta. Se convierte en algo que puedes buscar

Todo esto funciona gracias a la clave DES de 56 bits de NetNTLMv1, ahora obsoleta (sustituida por el Estándar de Cifrado Avanzado (AES), que admite claves de 128, 192 y 256 bits). El proceso es el siguiente:

1. Una respuesta NetNTLMv1 toma el hash NT de la víctima
2. Rellena (amplía) el hash hasta 21 bytes, dividiéndolo en tres segmentos de 7 bytes
3. A continuación, utiliza cada segmento de 7 bytes como clave DES para cifrar el mismo desafío del servidor de 8 bytes
4. Cuando el desafío es fijo y conocido, recuperar el hash NT se convierte en tres problemas independientes de recuperación de claves DES frente a texto plano conocido
5. El tercer segmento es trivial: el relleno deja solo 2 bytes de entropía real, lo que crea tan solo 65 536 posibilidades
6. Las CPU modernas las recuperan casi al instante, y cada uno de los dos primeros fragmentos contiene un espacio de claves DES completo de 56 bits

Aquí es donde entran en escena las tablas arcoíris.

Tablas arcoíris

Una tabla arcoíris es un archivo de búsqueda predefinido de gran tamaño que se puede usar para descifrar hashes de contraseñas criptográficas. En lugar de calcular cada intento de contraseña en tiempo real, los ciberdelincuentes usan estas bases de datos predefinidas para relacionar los hashes robados sin sal con sus contraseñas originales en texto plano. Los hashes de contraseñas modernos suelen incluir un valor aleatorio único, lo que significa que los atacantes no pueden confiar en una sola tabla precalculada y deben descifrar cada hash individualmente.

En 2021, Mandiant publicó un conjunto completo de tablas arcoíris DES para NetNTLMv1 destinado a este escenario de desafío fijo: 4.096 archivos de aproximadamente 2 GB cada uno, que cubren todo el espacio de claves 2^56 (unos 9 TB en total).

Si los atacantes disponen de una respuesta de autenticación NetNTLMv1 capturada, pueden usar tablas arcoíris para recuperar las claves DES derivadas del hash NT de la víctima. Los atacantes pueden usar esas claves recuperadas para reconstruir el propio hash NT. El verdadero reto consiste en realizar la búsqueda con la eficiencia suficiente para que el ataque sea viable. Para los ciberdelincuentes, el tiempo es dinero. Los ataques deben ofrecer un retorno de la inversión adecuado para que el esfuerzo merezca la pena.

Las herramientas estándar del sector, como Crackalack y el clásico rcrack, dan por sentado en gran medida que las unidades de procesamiento gráfico (GPU) son imprescindibles para esta tarea. Es una elección de diseño sensata, pero en operaciones de pruebas a gran escala, el tiempo de la GPU suele ser el recurso más valioso disponible. Cuando una búsqueda de NetNTLMv1 acapara esos recursos durante horas, crea un cuello de botella para otras cargas de trabajo maliciosas que realmente necesitan la aceleración de la GPU.

El impuesto de la GPU

Entonces, ¿una búsqueda en una tabla arcoíris realmente necesita una GPU para completar su tarea?

La opinión generalizada dice que sí. Las cadenas arcoíris son la secuencia precalculada de funciones criptográficas de hash y reducción alternadas que se usan dentro de una tabla arcoíris para revertir los hashes de contraseñas. Seguir una cadena arcoíris para un solo endpoint requiere unos cientos de miles de operaciones DES. Con unos 880 000 endpoints por texto cifrado, el precálculo de una búsqueda implica aproximadamente 388 000 millones de operaciones DES. A primera vista, parece una carga de trabajo justificable para una GPU.

La realidad es más matizada, porque el proceso de búsqueda no es puramente computacional. La fase de búsqueda también requiere leer en streaming tablas arcoíris de varios gigabytes desde el disco. Cuando los conjuntos de datos alcanzan esa escala, las E/S secuenciales se convierten en un componente significativo del tiempo de ejecución, incluso con almacenamiento NVMe de alta velocidad. Mientras las GPU realizan operaciones DES, también están esperando a que lleguen los datos.

Las CPU multinúcleo modernas son más que capaces de gestionar la carga de trabajo criptográfica. Por eso, el factor limitante no siempre es la velocidad a la que se pueden ejecutar las operaciones DES, sino la eficiencia con la que el sistema puede mover datos entre el almacenamiento, la memoria y los recursos de cálculo.

Esto cambia la rentabilidad del ataque. Dedicar GPU a las búsquedas en tablas arcoíris significa consumir el recurso más valioso de un equipo de descifrado para una carga de trabajo que solo es parcialmente compatible con la GPU. Cada hora que se dedica a regenerar cadenas de tablas arcoíris es una hora en la que esas mismas GPU no están disponibles para tareas que se benefician mucho más del paralelismo masivo, como el descifrado de contraseñas, los ataques de handshake WPA o las cargas de trabajo de bcrypt.

Al investigar esto en nuestro entorno de pruebas seguro, una búsqueda completa de degradación de NetNTLMv1 podía monopolizar las GPU durante hasta ocho horas. Las GPU permanecieron ocupadas durante toda la ejecución, a pesar de que gran parte del trabajo consistía en transmitir datos desde el disco y realizar operaciones que las CPU modernas gestionan de forma eficiente.

Esto plantea una pregunta obvia: si partes importantes del flujo de trabajo están limitadas por la E/S o son compatibles con la CPU, ¿es realmente necesario que la búsqueda se ejecute en una GPU?

Bitslicing de DES, 256 a la vez

Si el objetivo es liberar las GPU, no basta con trasladar la carga de trabajo a una CPU. Una implementación sencilla alcanza unos 144 millones de operaciones DES por segundo en un procesador EPYC de 64 núcleos. A ese ritmo, un solo precálculo sigue tardando unos 45 minutos, y la mayor parte del tiempo se dedica a generar subclaves DES en lugar de a realizar el cifrado.

La solución es el «bitslicing». En lugar de tratar un registro de la CPU como un único valor de 64 bits, el «bitslicing» lo trata como múltiples carriles de 1 bit y realiza varias operaciones DES en paralelo. Cada S-box DESi se convierte en una red compacta de operaciones booleanas construida a partir de instrucciones AND, OR, XOR y ANDNOT.

Hay dos optimizaciones adicionales que hacen que este enfoque sea práctico a gran escala:

• AVX2 amplía el «slice»: al sustituir una palabra de 64 bits por un vector AVX2 de 256 bits, el paralelismo se multiplica por cuatro, lo que permite procesar 256 operaciones DES simultáneamente en lugar de 64.
• La secuencia de claves desaparece: en una cadena arcoíris, el sistema deriva las claves de forma determinista. En lugar de reconstruir la secuencia de claves DES para cada operación, una correspondencia precalculada conecta directamente cada bit de la subclave con su bit de clave de origen. Como la generación de la secuencia de claves suponía aproximadamente el 85 % del coste en la implementación escalar, eliminarla supone una mejora sustancial del rendimiento.

En conjunto, estas optimizaciones aumentan el rendimiento total hasta unos 2.1 mil millones de operaciones DES por segundo en un único procesador EPYC de 64 núcleos, lo que supone unas 15 veces más rápido que la implementación original. Un proceso que antes tardaba unos 45 minutos ahora se completa en aproximadamente tres, sin consumir ni un solo ciclo de la GPU.

Tres fases y un extra

Este proceso sigue el flujo de trabajo estándar de las tablas arcoíris, pero lo divide en tres herramientas independientes para que cada fase se pueda optimizar por separado.

1. Precálculo genera unos 880 000 endpoints candidatos para el texto cifrado de destino. Esta es la fase en la que más se usa el DES, y donde el «bitslicing» aporta la mayor parte de la mejora de rendimiento.
2. Búsqueda analiza las tablas arcoíris ordenadas en busca de endpoints coincidentes. Como ordenamos las tablas una vez al principio, la búsqueda se convierte en un recorrido lineal en streaming por los datos. En este punto, la carga de trabajo ya no depende tanto de la criptografía como de las lecturas secuenciales del disco —justo el escenario para el que está diseñado el almacenamiento NVMe moderno.
3. Comprobación toma el pequeño número de candidatos coincidentes y recorre cada cadena usando el «bitslicing» de DES hasta recuperar la clave correcta de 7 bytes.

Además, hay una ventaja extra. El tercer bloque de NetNTLMv1 solo contiene 2 bytes de entropía, lo que lo hace lo suficientemente pequeño como para atacarlo por fuerza bruta de forma local y casi al instante. No hacen falta tablas arcoíris. No hace falta una GPU.

Ampliando el alcance

El conjunto de tablas es grande, pero tiene una propiedad útil: se fragmenta de forma natural.

En nuestro centro de datos tenemos varios sistemas 4U, cada uno equipado con un par de CPU compatibles con AVX2 y una copia local de su parte de las tablas v1 ordenadas en almacenamiento NVMe. Un envoltorio ligero distribuye el trabajo por todo el clúster y recoge los resultados.

Cuantos más sistemas añadas, más pequeño se vuelve cada fragmento y menos datos tiene que buscar cada servidor. El rendimiento escala casi de forma lineal.

Velocidades de descifrado

Entonces, ¿a qué velocidad puede funcionar esta metodología para agilizar el proceso de descifrado? De principio a fin, en un pequeño clúster de sistemas EPYC de doble CPU y 64 núcleos, alcanzamos los siguientes tiempos:

La misma búsqueda de downgrade que antes ocupaba las GPU hasta ocho horas ahora se completa en menos de 20 minutos en un solo servidor, y aún más rápido en un pequeño clúster, sin consumir ni un solo ciclo de GPU. Las GPU siguen disponibles para el resto de la cola de descifrado mientras la búsqueda se ejecuta de forma independiente en las CPU.

Pero hay una pega. Sigues necesitando una respuesta NetNTLMv1 capturada que utilice el desafío estático. Aunque puedes configurar herramientas como Responder para obtenerla a veces, el éxito depende en última instancia del entorno de destino. Cuando funciona, la búsqueda es extraordinariamente eficiente. Cuando no, las GPU son el plan B.

Por qué es importante esto en un contexto de seguridad ofensiva

A la escala a la que operamos como probadores de penetración de Sophos —una escala que comparten tanto los grupos de ciberdelincuencia organizados como las APT— cada ciclo de la GPU cuenta. Una búsqueda basada en la GPU puede ser rápida por sí sola, pero sigue acaparando el recurso más limitado de la infraestructura de descifrado para una carga de trabajo que está parcialmente limitada por la E/S y que está perfectamente al alcance de las CPU modernas. Trasladar la búsqueda a la CPU transforma una dependencia en serie en una ejecución en paralelo: la búsqueda se ejecuta en las CPU, mientras que las GPU siguen estando disponibles para descifrar contraseñas y otras cargas de trabajo que requieren mucha aceleración. La ventaja añadida es que reduce la necesidad de tener que hablar constantemente de comprar más GPU.

Me gusta especialmente el ajuste en la sección «Búsqueda» porque refuerza el argumento central del artículo: la búsqueda deja de ser un problema puramente criptográfico y se convierte, en parte, en un problema de movimiento de datos, que es precisamente la razón por la que la GPU no tiene por qué ser el cuello de botella.

Qué pueden hacer los defensores

La lección que se desprende de esto va mucho más allá de NetNTLMv1. Los actores maliciosos se aprovechan de la disponibilidad de tecnología heredada que sigue en uso mucho después de que su integridad de seguridad haya caducado. Los protocolos obsoletos, los sistemas operativos sin soporte, la criptografía débil, las configuraciones olvidadas y la infraestructura envejecida suelen ofrecer la vía más fácil de acceso a entornos que, por lo demás, son modernos. Las evaluaciones de seguridad periódicas ayudan a descubrir estas debilidades ocultas antes de que lo hagan los atacantes, lo que permite a las organizaciones priorizar las medidas correctivas allí donde tengan mayor impacto a la hora de reducir el riesgo y reducir la superficie de ataque. Las vulnerabilidades más peligrosas suelen ser aquellas que todo el mundo da por desaparecidas desde hace años.

Consigue el código: v1-nightshift

¿Quieres probar nuestro proceso por ti mismo? Para respaldar nuestros flujos de trabajo de investigación y pruebas de NetNTLMv1, hemos desarrollado v1-nightshift, una herramienta de búsqueda en tablas arcoíris basada en la CPU, diseñada para descargar las búsquedas de NetNTLMv1 de las GPU.

El proyecto está escrito en C y solo depende de un compilador de C y de pthreads. Funciona con las tablas arcoíris públicas de NetNTLMv1 de Mandiant e incluye las herramientas necesarias para ordenar esas tablas y realizar búsquedas eficientes. Las compilaciones se gestionan mediante «make», con aceleración AVX2 opcional que se activa con «AVX2=1» en sistemas x86-64.

Como los binarios son específicos de cada arquitectura, debes compilar el proyecto en el sistema en el que vaya a ejecutarse.

GitHub: v1-nightshift