Vulnerabilidad sin parche expone NTLMv2 a enlaces manipulados por manejadores de URI

Investigadores en ciberseguridad han descrito una vulnerabilidad sin parche que permite a un atacante provocar la filtración del hash NTLMv2 de un usuario al inducir la apertura de enlaces manipulados en el navegador. Aunque la mecánica recuerda al incidente resuelto en abril de 2026 con el manejador de URI del Snipping Tool (ms-screensketch), la nueva técnica aprovecha el manejador search: con parámetros tipo crumb=location: para forzar al sistema a conectar contra un recurso controlado por el atacante y así capturar el Net-NTLMv2 que el equipo intenta enviar para autenticarse.

La raíz del problema es la misma clase de fallo: un manejador de protocolo que acepta parámetros suministrados por el usuario sin validarlos y que, al procesarlos, provoca una conexión saliente hacia rutas UNC. Esa conexión a un servidor SMB malicioso desencadena el protocolo NTLM y expone el hash, que un atacante puede usar para relé o para intentar autenticarse dentro de una red comprometida. Casos anteriores ya habían mostrado cómo parámetros como filePath o crumb podían explotarse para el mismo fin; empresas como Varonis han documentado usos de crumb en 2024, y proveedores como Huntress han publicado análisis sobre las derivaciones recientes.

La decisión de Microsoft de no publicar un parche para este hallazgo bajo el argumento de que no alcanzó su umbral de gravedad para servicing deja a las organizaciones frente a un riesgo operativo concreto: en ausencia de un arreglo oficial, los vectores siguen siendo explotables por actores que consigan atraer a usuarios a enlaces maliciosos incrustados en correo o páginas web. Esto hace especialmente relevante la protección en la periferia de la red y las políticas de control de protocolo y puerto en estaciones de trabajo.

En términos de impacto, la exposición del Net-NTLMv2 es peligrosa porque el hash puede servir como base para ataques de relé y movimientos laterales, y porque muchos entornos corporativos siguen permitiendo o tolerando NTLM por compatibilidad con software legado. Una sola cuenta con privilegios elevados cuya credencial parcial se filtre puede facilitar escalada y persistencia en una red, con consecuencias que incluyen exfiltración de datos, despliegue de malware o compromiso de servicios internos.

Como contramedidas inmediatas prácticas y viables, es aconsejable bloquear el tráfico SMB saliente (TCP/445 y TCP/139) en equipos que no necesiten comunicarse con servidores internos por esos puertos desde redes públicas o subredes inseguras. Complementariamente, forzar la firma SMB y habilitar las políticas de protección extendida de autenticación reduce la posibilidad de que un hash capturado sea reutilizado con éxito en su contra. Donde sea factible, las organizaciones deberían planificar la eliminación gradual de NTLM en favor de Kerberos y otras autenticaciones más seguras.

Desde la capa de detección y respuesta, hay que monitorear intentos inusuales de autenticación NTLM hacia destinos externos, revisar registros de conexiones SMB y desplegar reglas EDR que alerten sobre procesos que lancen manejadores de URI con parámetros externos. La concienciación del personal sigue siendo crítica: técnicas de ingeniería social que inducen al clic siguen siendo el vector preferido, por lo que la formación y el filtrado de correo con sandboxing ayudan a reducir la probabilidad de explotación.

En el plano estratégico, este incidente recuerda dos lecciones: primero, que los manejadores de protocolos locales pueden convertirse en puertas de salida si aceptan entradas no validadas; segundo, que las decisiones de los proveedores sobre qué parchear pueden dejar huecos que requieren contramedidas a nivel de configuración y arquitectura por parte de los responsables de seguridad. Implementar segmentación de red, restricciones de egress y reglas de firewall por host son medidas que mitigarán la exposición mientras se espera un parche formal.

Quienes quieran profundizar pueden leer análisis y publicaciones técnicas de los equipos que han investigado variantes de este ataque en blogs especializados y documentación oficial sobre NTLM y SMB. Recursos útiles para contextualizar y planificar mitigaciones incluyen las entradas de fabricantes y de la comunidad sobre NTLM y manejo de SMB, como la documentación técnica de Microsoft sobre NTLM y las publicaciones de empresas de seguridad que han documentado explotaciones con parámetros en manejadores de URI: https://learn.microsoft.com/en-us/windows-server/security/ntlm/ y https://www.varonis.com/blog, además de los informes y blogs de investigación de sitios especializados como https://www.huntress.com/blog.

Finalmente, mi recomendación para responsables de TI y seguridad es priorizar controles que no dependen de un parche del proveedor: bloquear SMB saliente innecesario, reforzar la firma de SMB, planificar la desactivación de NTLM y mejorar la monitorización de autenticaciones. Estas medidas reducen la ventana de oportunidad de los atacantes y elevan el coste de explotación incluso si la vulnerabilidad sigue sin corregirse por el fabricante.