Resumen
CVE-2025-50154 es una vulnerabilidad del Explorador de archivos de Windows que puede exponer información confidencial de autenticación a través de la red. Microsoft clasifica el problema como suplantación de identidad, y la vulnerabilidad subyacente se corresponde con el CWE-200 (Exposición de información confidencial).
En las configuraciones afectadas, el Explorador de Windows puede iniciar una autenticación de red mientras procesa metadatos relacionados con accesos directos. Si el destino remoto al que se hace referencia está bajo el control de un atacante, este podría capturar datos de desafío-respuesta NTLM. Esto, dependiendo de los controles de seguridad de la organización, podría dar lugar a abusos posteriores, como el reenvío NTLM o la adivinación de contraseñas sin conexión.
En este blog, analizamos la vulnerabilidad CVE-2025-50154 a partir de la investigación llevada a cabo por estudiantes de posgrado que participan en el Programa de Becas OPSWAT , y ofrecemos recomendaciones prácticas para mitigar el riesgo de autenticación NTLM forzada.
Repercusiones y riesgos
La vulnerabilidad CVE-2025-50154 se dio a conocer el 12 de agosto de 2025 y afecta a varias versiones compatibles de Windows para clientes y servidores ( Server de Windows 10/11 y Windows Server ) anteriores a las versiones corregidas. La vulnerabilidad tiene una puntuación CVSS v3.1 de 6,5 (media).
La principal consecuencia en materia de seguridad es la exposición de credenciales: un atacante podría obtener datos de desafío-respuesta NTLM al hacer que el Explorador se autentique en un dispositivo controlado por él. Dependiendo del entorno, esto podría utilizarse para:
• Retransmisión NTLM (suplantación de identidad): autenticarse en otros servicios haciéndose pasar por la víctima cuando las protecciones contra la retransmisión no existen o están mal configuradas.
• Adivinación o descifrado de contraseñas sin conexión: intento de recuperar contraseñas débiles a partir de material de desafío-respuesta capturado.
La viabilidad depende en gran medida de los controles de la empresa, como la firma SMB, las restricciones NTLM, la segmentación de la red y el refuerzo de la seguridad del lado del servicio.
Escenario de ataque
CVE-2025-50154 es una vulnerabilidad de autenticación forzada. Cuando el Explorador de Windows procesa un acceso directo que hace referencia a una ubicación SMB/UNC remota, puede iniciar una conexión SMB durante la visualización normal o la validación de la ruta. Como consecuencia, el punto final remoto puede recibir datos del intercambio de autenticación NTLM generados durante el establecimiento de la sesión.
Un escenario de ataque típico es el siguiente:
- Preparación del ataque: el atacante controla un servidor SMB y prepara un recurso compartido al que hace referencia el acceso directo.
- Colocación de accesos directos: se introduce en el entorno de la víctima, a través de canales habituales (por ejemplo, archivos adjuntos de phishing, carpetas sincronizadas, repositorios de archivos compartidos o un punto de acceso ya existente), un archivo .lnk que apunta a una ruta SMB controlada por el atacante.
- Acceso activado por el Explorador: cuando la víctima navega por un directorio que contiene el acceso directo, el Explorador de Windows analiza los metadatos del acceso directo y puede intentar resolver el destino remoto como parte del procesamiento habitual de la interfaz de usuario.
- Autenticación implícita: durante el establecimiento de la sesión SMB, Windows se autentica en el contexto del usuario (a menudo mediante NTLM). No es necesario que la víctima ejecute el destino del acceso directo para que se produzca el intercambio de autenticación.
- Resultados tras la captura (dependientes del entorno): en función de los controles del entorno, el material NTLM capturado puede utilizarse para la retransmisión NTLM o para descifrar contraseñas sin conexión. La viabilidad práctica depende de factores como la firma SMB, las restricciones NTLM y la segmentación de la red.
Antecedentes técnicos
El Explorador de Windows y la representación de accesos directos
El Explorador de Windows (explorer.exe) es el proceso del shell de Windows que enumera el contenido de los directorios y muestra la interfaz de usuario del Explorador de archivos, invocando componentes del shell (por ejemplo, controladores de iconos, superposiciones y miniaturas) para obtener y mostrar iconos, superposiciones y miniaturas.
Un acceso directo de Windows (.lnk) no es un simple puntero de texto, sino un formato de metadatos estructurado que puede almacenar una ruta de destino (ruta local o ruta UNC/SMB), argumentos opcionales y un directorio de trabajo, así como una referencia de icono independiente. Durante la navegación normal por las carpetas, el Explorador analiza los metadatos del acceso directo para mostrarlo en la interfaz de usuario (por ejemplo, resolviendo el icono y validando el destino). Dependiendo del destino al que se hace referencia y de los metadatos relacionados, este procesamiento puede hacer que el Explorador intente acceder a la red como parte de la representación rutinaria o la verificación de la ruta.
Autenticación NTLM a través de SMB
En el uso compartido de archivos de Windows, la autenticación SMB suele dar prioridad a Kerberos en entornos de dominio, pero NTLM puede seguir utilizándose cuando Kerberos no está disponible o no se ha seleccionado. NTLM es un protocolo de desafío-respuesta: el cliente anuncia primero sus capacidades, el servidor devuelve un desafío (nonce) y el cliente responde con un mensaje de autenticación derivado del desafío y del secreto del usuario, sin enviar la contraseña en texto plano.
Variantes de NTLM y estado de seguridad (NTLMv1 frente a NTLMv2)
NTLM tiene varias variantes. Los entornos modernos de Windows suelen utilizar NTLMv2 y deben evitar, en la medida de lo posible, los protocolos heredados LM/NTLMv1.
El protocolo NTLMv1 llegó a considerarse inseguro por varias razones fundamentales (cifrado débil, claves de baja entropía, vulnerabilidad a los ataques de retransmisión, riesgo de descifrado fuera de línea, etc.).
Para mejorar esto, Microsoft introdujo NTLMv2, que refuerza el cálculo de la respuesta. En la práctica, NTLMv2 sustituye la antigua construcción de respuestas de tipo DES por un esquema basado en HMAC-MD5 e incorpora información contextual adicional en la respuesta, lo que lo hace considerablemente más robusto que NTLMv1 frente a varias clases de técnicas de recuperación fuera de línea.
Aun con NTLMv2, las organizaciones deben seguir considerando NTLM como un protocolo de autenticación de mayor riesgo en comparación con Kerberos y aplicar controles de defensa en profundidad (por ejemplo, la firma SMB y la segmentación) para reducir el alcance de los incidentes en casos de autenticación forzada.
Por qué NTLM sigue siendo un objetivo frecuente
Aunque NTLM es un protocolo de desafío-respuesta, sigue resultando atractivo para los atacantes porque el intercambio de autenticación se puede utilizar directamente en condiciones de red hostiles. Durante el establecimiento de la sesión SMB, el punto final remoto recibe los metadatos de autenticación y los valores de desafío-respuesta necesarios para autenticar al cliente. Si un adversario puede controlar el punto final de destino (por ejemplo, un servidor SMB controlado por el atacante) o puede interceptar o interrumpir la conexión en tránsito, puede capturar el material del intercambio NTLM e intentar abusos posteriores, como el relé NTLM o la adivinación de contraseñas fuera de línea, dependiendo de las protecciones del entorno.
Windows también integra NTLM en su sistema de inicio de sesión único (SSO). El material de credenciales derivado del secreto del usuario es gestionado por LSASS y puede utilizarse para autenticarse en recursos de red (por ejemplo, recursos compartidos SMB) sin solicitar repetidamente la intervención del usuario. Si bien esto mejora la usabilidad, amplía la superficie de ataque para escenarios de autenticación forzada: cuando un acceso directo .lnk hace referencia a una ruta SMB remota, el Explorador de Windows puede iniciar una conexión SMB durante el procesamiento rutinario del acceso directo y negociar automáticamente la autenticación.
En el contexto de CVE-2025-50154, esto significa que los datos del intercambio de autenticación NTLM pueden enviarse a un punto final SMB controlado por el atacante sin que la víctima ejecute el objetivo en cuestión, lo que crea una vía de exposición silenciosa de credenciales durante la navegación normal por las carpetas.
Análisis técnico
Representación del icono del Explorador y procesamiento de accesos directos
Cuando se abre una carpeta en el Explorador de archivos, el Explorador enumera el contenido del directorio y determina el tipo de cada elemento basándose en su asociación de archivos registrada (que suele venir determinada por la extensión del archivo). A continuación, Windows utiliza el registro de la clase de shell correspondiente (por ejemplo, a través de las asignaciones CLSID/ProgID asociadas en el Registro) para localizar el controlador de shell adecuado, que suele ser un componente COM encargado de la extracción y la representación del icono. El Explorador invoca las interfaces pertinentes para recuperar y mostrar el icono.
En el caso de los archivos .lnk (enlaces de Shell), el Explorador no suele mostrar un icono de acceso directo genérico de forma predeterminada. En su lugar, analiza los metadatos del acceso directo, intenta resolver el destino al que hace referencia (y la información relacionada con el icono) y, a continuación, muestra el icono asociado a ese destino resuelto.
Cuando el Explorador procesa un archivo .lnk, determina el icono llamando a CShellLink::GetIconLocation, que identifica de dónde debe cargarse el icono (por ejemplo, el binario de destino, una ruta de icono explícita o un icono predeterminado del sistema). Como parte de este flujo, el Explorador inicializa la extracción del icono (_InitExtractIcon) y, a continuación, ejecuta la lógica de resolución principal (_GetExtractIcon), que evalúa la fuente del icono (mediante _CheckExtractLocation).
• Si el acceso directo especifica una ubicación local para el icono (por ejemplo, un archivo ejecutable o una DLL en el disco), el Explorador carga el icono directamente desde ese recurso.
• Si la ubicación del icono es una URL remota, el Explorador puede descargar el icono a su caché local (por ejemplo, mediante URLDownloadToCacheFileW) y, a continuación, cargarlo desde la copia almacenada en la caché.
• Si no hay ninguna fuente de iconos válida disponible, el Explorador recurre a un icono predeterminado proporcionado por el controlador del sistema.
Una vez resueltos los metadatos relacionados con los iconos, el Explorador pasa a la función CShellLink::Extract, que gestiona el destino del acceso directo y completa el proceso de extracción. Como parte de este proceso, el Explorador invoca a CShellLink::_ShortNetTimeout para aplicar tiempos de espera de red más cortos cuando el acceso directo hace referencia a una ubicación remota, lo que reduce los retrasos en la interfaz de usuario si el destino de red es lento o inaccesible.
Cuando el destino se identifica como una ruta de red (UNC), el Explorador lleva a cabo la validación del destino de forma asíncrona. Genera un subproceso de trabajo que ejecuta CShellLink::_VerifyPathThreadProc, el cual comprueba si el destino al que se hace referencia existe.
En esta rutina, Explorer llama a la función PathFileExistsAndAttributesW para comprobar si el destino existe y obtener sus atributos básicos (por ejemplo, si se trata de un archivo o de un directorio), lo que a su vez requiere un intento de acceso a la red en el caso de destinos SMB/UNC.
Causa principal de la vulnerabilidad
En el proceso de renderizado de accesos directos descrito anteriormente, hay dos operaciones de salida que son relevantes:
• Recuperación de iconos mediante URLDownloadToCacheFileW (cuando la fuente del icono del acceso directo es una URL remota).
• Validación del destino mediante PathFileExistsAndAttributesW (cuando el destino del acceso directo es una ruta UNC/SMB).
Para validar el comportamiento de URLDownloadToCacheFileW, hemos probado la API una prueba mínima e independiente.
La actividad de red consistió en una solicitud HTTP convencional y, según nuestras observaciones, no reveló información sobre credenciales relevante para esta vulnerabilidad.
El comportamiento más significativo se produce con PathFileExistsAndAttributesW cuando la ruta evaluada es un destino UNC/SMB. Durante la depuración, observamos que esta comprobación puede iniciar la configuración de una sesión SMB y negociar la autenticación en el contexto del usuario actual.
Dado que el Explorador puede activar esta validación automáticamente al procesar un archivo .lnk, un punto de conexión SMB controlado por un atacante puede recibir datos del intercambio de autenticación NTLM sin que la víctima ejecute el archivo al que se hace referencia, lo que crea una vía de exposición silenciosa de credenciales durante la navegación habitual por las carpetas.
Prueba de concepto
En un laboratorio aislado, los participantes en nuestro programa de becas OPSWAT validaron la vulnerabilidad CVE-2025-50154 utilizando un acceso directo (.lnk) que apuntaba a una ruta SMB/UNC remota. En un sistema Windows vulnerable, el mero hecho de explorar la carpeta en el Explorador de Windows activaba una conexión SMB durante el procesamiento normal del acceso directo, lo que provocaba que se enviara información de intercambio de autenticación NTLM al terminal remoto, sin que la víctima ejecutara el destino del acceso directo.
Remediación
Las organizaciones deben asegurarse de que sus sistemas operativos y aplicaciones reciban parches periódicamente y se mantengan actualizados para mitigar las vulnerabilidades conocidas. Esto incluye aplicar todas las actualizaciones de seguridad pertinentes de Microsoft y verificar que todos los dispositivos finales ejecuten las versiones más recientes y corregidas de Windows. Paralelamente, las organizaciones deben reducir su superficie de ataque restringiendo el acceso SMB saliente cuando sea necesario y reforzando los controles de seguridad de NTLM/SMB de acuerdo con su entorno.
MetaDefender respalda estas iniciativas y ayuda a ponerlas en práctica a gran escala, al ofrecer una visibilidad clara de la exposición y el estado de las actualizaciones. Gracias a sus sólidas funciones de gestión de vulnerabilidades y parches, compatibles con más de 1.100 aplicaciones, MetaDefender Endpoint identificaEndpoint los dispositivos que ejecutan versiones de Windows sin parches o desactualizadas, así como aplicaciones de terceros, y ofrece las soluciones recomendadas.
Además, a través de su consola de gestión en My OPSWAT Central Management, los administradores obtienen una visión centralizada y unificada del estado de la seguridad de los terminales, la exposición a vulnerabilidades y la gestión de parches, todo ello dentro de una única plataforma para definir y aplicar políticas de seguridad en toda la organización. Los administradores también pueden crear e implementar scripts personalizados en los endpoints queEndpoint MetaDefender Endpoint para automatizar las acciones de refuerzo de seguridad relacionadas con el acceso SMB y el uso de NTLM. Este enfoque agiliza la aplicación de la seguridad al tiempo que proporciona información clara sobre los resultados de la ejecución, lo que permite a los administradores identificar rápidamente los endpoints que puedan requerir una investigación más profunda o una intervención manual.
MetaDefender Endpoint los equipos de seguridad y de TI priorizar las implementaciones, acelerar la corrección de incidencias, supervisar de forma continua el estado de seguridad de la organización y, en última instancia, reducir la exposición a vulnerabilidades y exposiciones comunes (CVE), como la CVE-2025-50154 y otras amenazas similares que afectan a los dispositivos finales.
