Tal como en los años 2000
Los teléfonos plegables ganaban popularidad, Windows XP debutaba en las computadoras personales, Apple presentaba el iPod, el intercambio de archivos mediante torrents despegaba y MSN Messenger dominaba el chat en línea. Ese era el panorama tecnológico en 2001. Ese mismo año, Sir Dystic, del grupo Cult of the Dead Cow, publicó SMBRelay, una prueba de concepto que llevó los ataques de NTLM relay de la teoría a la práctica y demostró una nueva y poderosa clase de exploits.
Desde aquel lejano 2001, las debilidades del protocolo de autenticación NTLM quedaron expuestas. En los años siguientes, nuevas vulnerabilidades y métodos de ataque cada vez más sofisticados siguieron moldeando el panorama de la seguridad. Microsoft aceptó el desafío, introdujo medidas de mitigación y, poco a poco, fue desarrollando al sucesor de NTLM: Kerberos. Sin embargo, más de dos décadas después, NTLM continúa integrado en los sistemas operativos modernos y sigue presente en redes corporativas, aplicaciones legacy e infraestructuras internas que aún dependen de sus mecanismos obsoletos de autenticación.
Aunque Microsoft anunció su intención de retirar NTLM, el protocolo todavía está presente y mantiene una puerta abierta para los atacantes, que continúan explotando tanto vulnerabilidades antiguas como otras descubiertas recientemente.
En esta publicación analizaremos en mayor detalle el creciente número de vulnerabilidades relacionadas con NTLM descubiertas durante el último año, así como las campañas cibercriminales que las han aprovechado activamente en distintas regiones del mundo.
Cómo funciona la autenticación NTLM
NTLM (New Technology LAN Manager) es un conjunto de protocolos de seguridad de Microsoft diseñado para ofrecer autenticación, integridad y confidencialidad a los usuarios.
En lo que respecta a la autenticación, NTLM es un protocolo de desafío-respuesta que se utiliza en entornos Windows para autenticar clientes y servidores. Este tipo de protocolos depende de un secreto compartido, por lo general la contraseña del cliente, para verificar la identidad. NTLM se integra sobre los protocolos de aplicación, como HTTP, MSSQL, SMB y SMTP, cuando se requiere autenticación de usuario. Emplea un “three-way handshake” (negociación en tres pasos) entre el cliente y el servidor para completar el proceso de autenticación. En algunos casos se añade un cuarto mensaje para garantizar la integridad de los datos.
El proceso completo de autenticación es el siguiente:
- El cliente envía un NEGOTIATE_MESSAGE para anunciar sus capacidades.
- El servidor responde con un CHALLENGE_MESSAGE para verificar la identidad del cliente.
- El cliente cifra el desafío con su secreto y responde con un AUTHENTICATE_MESSAGE que incluye el desafío cifrado, el nombre de usuario, el nombre del host y el nombre de dominio.
- El servidor verifica el desafío cifrado mediante el hash de la contraseña del cliente y confirma su identidad. El cliente se autentica y establece una sesión válida con el servidor. Según el protocolo de la capa de aplicación, el servidor puede enviar un mensaje de confirmación (o falla) de la autenticación.
Es importante remarcar que el secreto del cliente nunca viaja por la red durante este proceso.
NTLM ha muerto; larga vida a NTLM
Pese a ser un protocolo heredado con debilidades bien documentadas, NTLM sigue utilizándose en sistemas Windows y, por tanto, se explota de forma activa en campañas de amenazas modernas.
Microsoft anunció planes para eliminar por completo la autenticación NTLM. Este proceso comenzará con Windows 11 24H2 y Windows Server 2025 (1, 2, 3), donde NTLMv1 se eliminará por completo y NTLMv2 se desactivará de forma predeterminada en determinados escenarios. A pesar de que se publicaron al menos tres avisos públicos importantes desde 2022 y de una mayor cantidad de documentación y guías de migración, el protocolo persiste, a menudo debido a requisitos de compatibilidad, aplicaciones heredadas o errores de configuración en infraestructuras híbridas.
Como demuestran revelaciones recientes, los atacantes siguen encontrando formas creativas de aprovechar NTLM en ataques de relay y spoofing, incluso mediante nuevas vulnerabilidades. Además, introducen vectores de ataque alternativos inherentes al protocolo, que se analizarán más adelante en esta publicación, en particular en el contexto de descargas automáticas y ejecución de malware mediante WebDAV tras intentos de autenticación NTLM.
Amenazas persistentes en la autenticación basada en NTLM
NTLM, con sus limitaciones estructurales, expone a las organizaciones a una amplia gama de amenazas. Entre ellos se incluyen el reenvío de credenciales (credential forwarding), los ataques basados en coerción, la intercepción de hashes y diversas técnicas de intermediario (Man-in-the-Middle, MitM), que explotan la falta de controles modernos en el protocolo, como el channel binding y la autenticación mutua. Antes de analizar las campañas de explotación actuales, es esencial repasar las principales técnicas de ataque implicadas.
Filtración de hashes
La filtración de hashes (hash leakage) es la divulgación no intencionada de hashes de autenticación NTLM, que suele producirse mediante archivos diseñados de forma especial, rutas de red maliciosas o técnicas de phishing. Se trata de una técnica pasiva que no requiere acciones directas del atacante en el sistema objetivo. Un escenario común con este vector de ataque comienza con un intento de phishing que incluye (o enlaza con) un archivo diseñado para explotar comportamientos nativos de Windows. Estos comportamientos inician de forma automática la autenticación NTLM hacia recursos controlados por el atacante. La filtración suele producirse con una interacción mínima del usuario, como previsualizar un archivo, hacer clic en un enlace remoto o acceder a un recurso compartido de red. Una vez que los atacantes obtienen los hashes, pueden reutilizarlos en un ataque de reenvío de credenciales.
Ataques basados en coerción
En los ataques basados en coerción, el atacante fuerza de manera activa al sistema objetivo para que se autentique frente a un servicio controlado por el propio atacante. Este tipo de ataque no requiere interacción del usuario. Por ejemplo, herramientas como PetitPotam o PrinterBug se usan con frecuencia para forzar intentos de autenticación a través de protocolos como MS‑EFSRPC o MS‑RPRN. Una vez que el sistema de la víctima inicia el handshake NTLM, el atacante puede interceptar el hash de autenticación o retransmitirlo a un objetivo diferente, y así hacerse pasar por la víctima en otro sistema. Este último caso tiene un impacto alto, ya que permite acceder de inmediato a recursos compartidos, interfaces de administración remota o incluso a Active Directory Certificate Services, donde los atacantes pueden solicitar certificados de autenticación válidos.
Reenvío de credenciales
El reenvío de credenciales consiste en la reutilización no autorizada de tokens de autenticación NTLM capturados en ocasiones anteriores (por lo general hashes) para hacerse pasar por un usuario en otro sistema o servicio. En entornos donde la autenticación NTLM sigue habilitada, los atacantes pueden aprovechar credenciales obtenidas en ocasiones anteriores (mediante filtración de hashes o ataques basados en coerción) sin necesidad de descifrar contraseñas. Esta técnica se aplica con frecuencia mediante Pass‑the‑Hash (PtH) o técnicas de suplantación de tokens. En redes donde NTLM se mantiene en uso, en especial si junto con configuraciones incorrectas de single sign‑on (SSO) o relaciones de confianza entre dominios, el reenvío de credenciales puede proporcionar un acceso amplio a varios sistemas.
Esta técnica se utiliza a menudo para facilitar el movimiento lateral y la escalada de privilegios, sobre todo cuando se exponen credenciales de alto privilegio. Herramientas como Mimikatz permiten extraer e inyectar hashes NTLM directo en memoria, mientras que scripts como wmiexec.py, PsExec.py y secretsdump.py de Impacket pueden emplearse para ejecutar código de forma remota o extraer credenciales mediante hashes reenviados.
Ataques Man‑in‑the‑Middle (MitM)
Un atacante situado entre un cliente y un servidor puede interceptar, retransmitir o manipular el tráfico de autenticación para capturar hashes NTLM o inyectar cargas maliciosas durante la negociación de la sesión. En entornos donde no se han habilitado controles como el firmado digital o channel binding, estos ataques no solo resultan posibles, sino además bastante fáciles de ejecutar.
Entre los ataques MitM, NTLM relay sigue siendo el método más persistente y con mayor impacto, al punto de seguir siendo relevante más de dos décadas después. Demostrado por primera vez en 2001 mediante la herramienta SMBRelay de Sir Dystic (miembro de Cult of the Dead Cow), NTLM relay continúa utilizándose de forma activa para comprometer entornos de Active Directory en escenarios reales. Entre las herramientas de uso más común se encuentran Responder, NTLMRelayX de Impacket e Inveigh. Cuando un ataque de NTLM relay se ejecuta en la misma máquina desde la que se obtuvo el hash, se conoce también como ataque de reflexión NTLM (NTLM reflection attack).
Explotación en 2025
Durante el último año se identificaron varias vulnerabilidades en entornos Windows donde NTLM sigue habilitado de manera implícita. En esta sección se destacan los CVE más relevantes reportados a lo largo del año y los principales vectores de ataque observados en campañas reales.
CVE‑2024‑43451
CVE‑2024‑43451 es una vulnerabilidad en Microsoft Windows que permite la filtración de hashes NTLMv2 con una interacción mínima o nula del usuario, lo que puede derivar en el compromiso de credenciales.
La vulnerabilidad existe debido a la presencia del motor MSHTML, un componente heredado desarrollado para Internet Explorer. Aunque Internet Explorer se retiró de forma oficial, MSHTML sigue integrado en sistemas Windows modernos para garantizar la compatibilidad con aplicaciones e interfaces que aún dependen de sus capacidades de renderizado o administración de enlaces. Esta dependencia permite que archivos .url invoquen procesos de autenticación NTLM de forma silenciosa a través de enlaces manipulados, incluso sin que se los abra. Aunque abrir el archivo .url malicioso de forma directa garantiza que el exploit se active, la vulnerabilidad también puede activarse mediante otras acciones del usuario, como hacer clic derecho, eliminarlo, seleccionarlo o moverlo a otra carpeta.
Los atacantes pueden explotar esta falla iniciando la autenticación NTLM mediante SMB a un servidor remoto bajo su control (especificado mediante una URL en formato de ruta UNC), lo que les permite capturar el hash del usuario. Una vez obtenido el hash NTLMv2, el atacante puede ejecutar un ataque Pass‑the‑Hash (por ejemplo, con herramientas como WMIExec o PsExec) para obtener acceso a la red haciéndose pasar por un usuario válido, sin necesidad de conocer sus credenciales reales.
Un caso particular de esta vulnerabilidad se presenta cuando los atacantes utilizan servidores WebDAV, un conjunto de extensiones del protocolo HTTP que permite la colaboración en archivos almacenados en servidores web. En este escenario, una interacción mínima con el archivo malicioso, como un clic único o un clic con el botón derecho, desencadena la conexión automática al servidor, la descarga del archivo y su ejecución. Los atacantes aprovechan esta falla para distribuir malware u otras cargas en el sistema de la víctima. También puede combinar este proceso con la filtración de hashes, por ejemplo, instalando una herramienta maliciosa en el sistema objetivo y utilizando los hashes capturados para realizar movimiento lateral con esa misma herramienta.
Microsoft solucionó la vulnerabilidad en las actualizaciones de seguridad de noviembre de 2024. En los entornos parcheados, mover, eliminar, hacer clic con el botón derecho sobre el archivo .url manipulado, etc., ya no desencadena la conexión a un servidor malicioso. Sin embargo, si el usuario abre el archivo explotado, el ataque sigue funcionando.
Tras la divulgación, el número de ataques que explotaban esta vulnerabilidad creció de forma exponencial. Para julio de este año habíamos detectado alrededor de 600 archivos .url sospechosos que presentan las características necesarias para explotar la vulnerabilidad y que pueden representar una amenaza potencial.
Campaña de BlindEagle que distribuye Remcos RAT mediante CVE‑2024‑43451
BlindEagle es un actor de amenazas latinoamericano conocido por campañas versátiles que combinan espionaje y ataques financieros. A finales de noviembre de 2024, el grupo inició una nueva campaña dirigida a entidades colombianas, en la que utilizó la vulnerabilidad CVE‑2024‑43451 en Windows para distribuir Remcos RAT. BlindEagle creó archivos .url como nuevo dropper inicial. Estos archivos se enviaban por correo de phishing, en los que el grupo se hacía pasar por entidades gubernamentales y judiciales colombianas, y utilizaba supuestos problemas legales como señuelo. Una vez que los destinatarios accedían a descargar el archivo malicioso, cualquier interacción con él generaba una solicitud a un servidor WebDAV bajo control de los atacantes, desde donde se descargaba y ejecutaba una versión modificada del troyano Remcos RAT. Esta versión incluía un módulo dedicado al robo de credenciales de billeteras cripto.
Los atacantes ejecutaban el malware de forma automática al especificar el puerto 80 en la ruta UNC. Esto permitía que la conexión se realizara mediante el protocolo WebDAV sobre HTTP y eludiera la conexión mediante SMB. Este tipo de conexión también provoca la filtración de hashes NTLM. Sin embargo, no hemos observado que se haya hecho un uso posterior de esos hashes.
Después de esta campaña y durante todo 2025, el grupo siguió lanzando múltiples ataques con el mismo vector inicial (archivos .url) y continuó distribuyendo Remcos RAT.
Detectamos más de 60 archivos .url utilizados como droppers iniciales en las campañas de BlindEagle. Estos archivos se enviaban en correos que suplantaban a autoridades judiciales colombianas. Todos se comunicaban mediante WebDAV con servidores controlados por el grupo e iniciaban una cadena de ataque que utilizaba ShadowLadder o Smoke Loader hasta cargar Remcos RAT en memoria.
Campañas de Head Mare contra objetivos rusos que abusan de CVE‑2024‑43451
Otra campaña detectada tras la divulgación de Microsoft involucra al grupo hacktivista Head Mare, conocido por perpetrar ataques contra objetivos rusos y bielorrusos.
En campañas anteriores, Head Mare explotó diversas vulnerabilidades como parte de sus técnicas para obtener acceso inicial a la infraestructura de sus víctimas. En esta ocasión se valió de CVE‑2024‑43451. El grupo distribuía un archivo ZIP por correo de phishing con el nombre Договор на предоставление услуг №2024‑34291 (Acuerdo de prestación de servicios núm. 2024‑34291). Este archivo contenía un archivo .url llamado “Сопроводительное письмо.docx” (“Carta de presentación.docx”).
El archivo .url se conectaba a un servidor SMB remoto controlado por el grupo bajo el dominio:
|
1 |
document-file[.]ru/files/documents/zakupki/MicrosoftWord.exe |
El dominio resolvía a la dirección IP 45.87.246.40, perteneciente al ASN 212165, que el grupo había utilizado en campañas sobre las que nuestro equipo ya había informado.
Para alcanzar sus objetivos en las empresas seleccionadas, Head Mare utilizó varios recursos de acceso público, incluidos programas de código abierto, para realizar movimientos laterales y escalada de privilegios mediante el reenvío de los hashes expuestos. Entre las herramientas detectadas en ataques anteriores se encuentran Mimikatz, Secretsdump, WMIExec y SMBExec (las tres últimas del conjunto de herramientas Impacket).
En esta campaña detectamos intentos de explotación de la vulnerabilidad CVE‑2023‑38831 en WinRAR, que se había utilizado como vector de acceso inicial en una campaña sobre la que ya se había informado, y, en otros dos incidentes, observamos intentos de utilizar herramientas relacionadas con Impacket y SMBMap.
El ataque, además de recopilar hashes NTLM, incluía la distribución del malware PhantomCore, parte del arsenal del grupo.
CVE‑2025‑24054/CVE‑2025‑24071
CVE‑2025‑24071 y CVE‑2025‑24054, registradas al principio como vulnerabilidades distintas, pero más adelante consolidadas bajo el identificador CVE‑2025‑24054, describen una vulnerabilidad de filtración de hashes NTLM que afecta a varias versiones de Windows, entre ellas Windows 11 y Windows Server. La vulnerabilidad se explota, ante todo, mediante archivos diseñados de forma específica, como archivos .library‑ms, que provocan que el sistema inicie solicitudes de autenticación NTLM hacia servidores controlados por el atacante.
El modo de explotación es similar a CVE‑2024‑43451 y requiere poca o ninguna interacción del usuario (por ejemplo, previsualizar un archivo), lo que permite a los atacantes capturar hashes NTLMv2 y obtener acceso no autorizado o escalar privilegios dentro de la red. El escenario de explotación más habitual y extendido de esta vulnerabilidad se observa con archivos .library‑ms dentro de archivos ZIP/RAR, ya que resulta sencillo engañar a los usuarios para que los abran o previsualicen. En la mayoría de los incidentes que observamos, los atacantes utilizaron archivos ZIP como vector de distribución.
Distribución de troyanos en Rusia mediante CVE‑2025‑24054
En Rusia identificamos una campaña que distribuía archivos ZIP maliciosos con el asunto акт_выполненных_работ_апрель (certificado_de_finalización_de_trabajos_abril). Los archivos dentro de los ZIP se hacían pasar por hojas de cálculo .xls, pero en realidad eran archivos .library‑ms que iniciaban de forma automática una conexión con servidores controlados por los atacantes. Los archivos maliciosos tenían incrustada la misma dirección IP de servidor: 185.227.82.72.
Cuando se explotaba la vulnerabilidad, el archivo se conectaba de forma automática a ese servidor, que también alojaba versiones del troyano AveMaria (conocido también como Warzone) para su distribución. AveMaria es un troyano de acceso remoto (RAT) que otorga a los atacantes control remoto para ejecutar comandos, exfiltrar archivos, registrar pulsaciones de teclado y mantener la persistencia.
CVE‑2025‑33073
CVE‑2025‑33073 es una vulnerabilidad de reflexión NTLM de alta gravedad en el control de acceso del cliente SMB de Windows. Un atacante autenticado dentro de la red puede manipular la autenticación SMB, en especial mediante relay local, para forzar que el sistema de la víctima se autentique contra sí mismo como SYSTEM. Esto permite al atacante escalar privilegios y ejecutar código con el nivel más alto de permisos.
La vulnerabilidad se basa en un defecto en la forma en que Windows determina si una conexión es local o remota. Al crear un nombre de host DNS específico que se superpone de forma parcial con el nombre de la máquina, el atacante puede engañar al sistema para que interprete la solicitud de autenticación como si procediera de ese mismo host. Cuando esto ocurre, Windows cambia a un “modo de autenticación local”, que omite el intercambio habitual de desafío-respuesta NTLM e inyecta el token del usuario directo en el subsistema de seguridad del host. Si el atacante ha obligado a la víctima a conectarse al nombre de host manipulado, el token proporcionado es, en la práctica, el de la propia máquina, lo que le otorga acceso con privilegios en el propio host.
Este comportamiento surge porque el protocolo NTLM establece una marca especial y un ID de contexto cuando asume que el cliente y el servidor son la misma entidad. La manipulación del atacante provoca que el sistema operativo trate una solicitud externa como interna, por lo que el token inyectado se maneja como si fuera de confianza. Esta autorreflexión da pie a que el adversario actúe con privilegios de SYSTEM en la máquina objetivo.
Actividad sospechosa en Uzbekistán que involucra CVE‑2025‑33073
Detectamos actividad sospechosa que explota esta vulnerabilidad en un objetivo del sector financiero en Uzbekistán.
Obtuvimos un volcado de tráfico relacionado con esta actividad e identificamos varias cadenas dentro del mismo que corresponden a fragmentos asociados con la autenticación NTLM sobre SMB. Esto incluía negociaciones de autenticación con dialectos SMB, mensajes NTLMSSP, nombres de host y dominios.
En particular, destacan los siguientes indicadores:
- El nombre de host localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA, un nombre manipulado utilizado para engañar a Windows y hacer que trate la autenticación como local.
- La presencia del recurso compartido IPC$, habitual en ataques de NTLM relay/reflection, ya que permite al atacante iniciar la autenticación y, luego, realizar acciones reutilizando esa sesión autenticada.
El incidente comenzaba con la explotación de la vulnerabilidad de reflexión NTLM. El atacante utilizaba un registro DNS manipulado para forzar que el host se autenticara con sí mismo y así obtener un token de SYSTEM. Después, verificaba si contaba con privilegios suficientes para ejecutar código mediante archivos por lotes (batch) que lanzaban comandos sencillos como whoami:
|
1 |
%COMSPEC% /Q /c echo whoami ^> %SYSTEMROOT%\Temp\__output > %TEMP%\execute.bat & %COMSPEC% /Q /c %TEMP%\execute.bat & del %TEMP%\execute.bat |
A continuación, se establecía persistencia mediante la creación de una entrada de servicio sospechosa en el registro, en la ruta:
|
1 |
reg:\\REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\YlHXQbXO |
Habiendo obtenido los privilegios de SYSTEM, el atacante intentaba varios métodos para volcar la memoria de LSASS (Local Security Authority Subsystem Service):
- Usando rundll32.exe:
1C:\Windows\system32\cmd.exe /Q /c CMD.exe /Q /c for /f "tokens=1,2 delims= " ^%A in ('"tasklist /fi "Imagename eq lsass.exe" | find "lsass""') do rundll32.exe C:\windows\System32\comsvcs.dll, #+0000^24 ^%B \Windows\Temp\vdpk2Y.sav full
El comando localiza el proceso lsass.exe, que almacena credenciales en memoria, obtiene su PID e invoca una función interna de comsvcs.dll para volcar la memoria de LSASS y guardarla. Esta técnica se utiliza en etapas posteriores a la explotación (por ejemplo, con Mimikatz u otras herramientas de “living off the land”).
- Cargando una DLL temporal (BDjnNmiX.dll):
1C:\Windows\system32\cmd.exe /Q /c cMd.exE /Q /c for /f "tokens=1,2 delims= " ^%A in ('"tAsKLISt /fi "Imagename eq lSAss.ex*" | find "lsass""') do rundll32.exe C:\Windows\Temp\BDjnNmiX.dll #+0000^24 ^%B \Windows\Temp\sFp3bL291.tar.log full
El comando intenta volcar de nuevo la memoria de LSASS, pero esta vez mediante una DLL personalizada.
- Ejecutando un script de PowerShell codificado en Base64:
El script utiliza la funcion MiniDumpWriteDump que realiza un volcado de un determinado proceso que ejecuta en memoria (en este caso LSASS) al disco, de forma similar a la ejecución de procdump.exe.
Varios minutos después, el atacante intentó realizar movimiento lateral escribiendo en el recurso compartido administrativo de otro host, pero el intento falló. No observamos más actividad posterior.
Protección y recomendaciones
Deshabilitar o limitar NTLM
Mientras NTLM continúe habilitado, los atacantes podrán explotar vulnerabilidades en estos métodos de autenticación heredados. Deshabilitar NTLM o, como mínimo, limitar su uso a sistemas específicos y críticos reduce los puntos vulnerables. Este cambio debe acompañarse de una auditoría estricta para identificar todos los sistemas y aplicaciones que aún dependen de NTLM, a fin de garantizar una transición segura y sin interrupciones.
Implementar el firmado de mensajes
NTLM funciona como capa de autenticación sobre protocolos de aplicación como SMB, LDAP y HTTP, entre otros. Muchos de estos protocolos permiten habilitar firmado (signing) en las comunicaciones. Una de las formas más eficaces de mitigar los ataques de relay NTLM consiste en habilitar el firmado en SMB y LDAP. Estas funciones de seguridad garantizan que todos los mensajes entre cliente y servidor sean firmados, lo que impide que los atacantes manipulen o retransmitan el tráfico de autenticación. Sin firmado, los atacantes pueden interceptar y reutilizar credenciales NTLM para obtener acceso no autorizado a los recursos de la red.
Habilitar Extended Protection for Authentication (EPA)
EPA vincula la autenticación NTLM con la sesión TLS o SSL subyacente, y asegura que las credenciales capturadas no se puedan reutilizar en contextos no autorizados. Esta validación adicional puede aplicarse a servicios como servidores web y LDAP, lo que complica bastante la ejecución de ataques de relay NTLM.
Supervisar y auditar el tráfico y los registros de autenticación NTLM
La revisión periódica de los registros de autenticación NTLM ayuda a identificar patrones anómalos, como direcciones IP de origen inusuales o un número elevado de intentos de autenticación fallidos, que pueden indicar ataques en curso. El uso de herramientas SIEM y de monitoreo de red para rastrear tráfico NTLM sospechoso mejora la detección temprana de amenazas y permite responder con mayor rapidez.
Conclusiones
En 2025, NTLM sigue enraizado en los entornos Windows y continúa ofreciendo a los cibercriminales oportunidades para explotar debilidades conocidas desde hace años. Aunque Microsoft anunció planes para retirarlo, la presencia generalizada del protocolo en sistemas heredados y redes empresariales lo mantiene vigente y expuesto a riesgos. Los actores de amenazas aprovechan fallas recién descubiertas para perfeccionar ataques basados en reenvío de credenciales, escalar privilegios y desplazarse de forma lateral dentro de las redes, lo que demuestra que NTLM sigue representando un riesgo de seguridad importante.
El aumento de incidentes que se enfocan en NTLM observado a lo largo de 2025 refleja los crecientes riesgos que supone depender de mecanismos de autenticación obsoletos. Para mitigar estas amenazas, las organizaciones deben acelerar los esfuerzos de descontinuación, aplicar parches de forma regular y adoptar marcos de protección de identidad más robustos. De lo contrario, NTLM continuará siendo un punto de entrada recurrente y de fácil explotación para los atacantes.




Vieja tecnología, nuevas amenazas: explotación de NTLM en 2025