La vulnerabilidad de Windows que roba credenciales sin interacción y ya se está explotando en el mundo real

Microsoft actualizó esta semana su advertencia sobre una falla de seguridad en Windows Shell —CVE-2026-32202— y confirmó que ya se está explotando en el mundo real. Aunque la puntuación CVSS oficial es moderada, la importancia práctica de este fallo radica en su papel dentro de una cadena de explotación y en la facilidad con la que puede convertir archivos aparentemente inofensivos en vectores de robo de credenciales sin interacción del usuario.

En términos técnicos, la vulnerabilidad es una fallida verificación de confianza al resolver rutas UNC, lo que permite que un acceso automático a un recurso remoto (por ejemplo, un archivo .cpl cargado por el mecanismo de Windows Shell a través de un acceso SMB) desencadene una conexión SMB saliente desde la máquina víctima hacia un servidor controlado por el atacante. Esa conexión provoca un intercambio NTLM que puede filtrar el hash Net-NTLMv2 del usuario, explotable después mediante relays o ataques offline. En la práctica esta dinámica reapareció después de un parche parcial aplicado previamente a CVE-2026-21510, y según investigadores vincula la campaña con el grupo APT28 (Fancy Bear).

El patrón de abuso que describen los descubridores combina archivos LNK (accesos directos) que activan la resolución de nombres en el espacio de nombres de Shell y, a su vez, la carga de una DLL/CPL desde un recurso UNC remoto. La gran amenaza no fue tanto el correr código remoto directo, sino el robo de credenciales que facilita movimiento lateral y ataques posteriores. Esto explica por qué actores con capacidades y objetivos concretos, como APT28, han incorporado estas técnicas en campañas dirigidas a objetivos en Ucrania y la Unión Europea.

Para organizaciones y administradores, las implicaciones operativas son claras: parchear es condición necesaria pero no suficiente. Microsoft ya corrigió el fallo en el parche mensual más reciente, por lo que la primera acción obligatoria es aplicar las actualizaciones de seguridad en todos los endpoints y servidores afectados. Además, conviene validar que los parches se desplegaron correctamente y revisar los indicadores de vulnerabilidad en su inventario de parches. Puede consultar la guía de seguridad de Microsoft para este CVE y actualizaciones relacionadas en la página oficial de Microsoft Security Response Center: Microsoft Security Response Center.

Más allá del parche, existen medidas defensivas que reducen tanto la probabilidad como el impacto de este tipo de abuso. Entre las más efectivas están la restricción del tráfico SMB saliente hacia Internet (bloquear TCP/445 desde estaciones de trabajo y servidores que no necesiten comunicarse externamente), la habilitación y exigencia de SMB signing donde aplique, la configuración de políticas de grupo que impidan la resolución automática de rutas UNC desde entornos inseguros y la desactivación de servicios innecesarios que puedan resolver recursos remotos. También es recomendable aumentar el uso de autenticación fuerte y multifactor para mitigar el valor de hashes eventualmente capturados.

En materia de detección, los equipos de seguridad deben prestar atención a eventos de autenticación NTLM inesperados hacia dominios externos, intentos de resolución UNC hacia hosts fuera de la red y ejecución vinculada a cargas CPL o accesos directos LNK. Los productos EDR/MDR deberían bloquear o alertar sobre la carga dinámica de DLLs desde orígenes remotos y sobre patrones de actividad típicos de relays NTLM. Los proveedores y equipos internos han empezado a publicar análisis técnicos; para entender la investigación original y su contexto técnico, puede consultarse el análisis y blog de investigación de la industria en el sitio de Akamai: Akamai Security Blog.

Finalmente, esta serie de fallos subraya una lección recurrente: las mitigaciones parciales pueden dejar vectores residuales que actores sofisticados encadenan con otras vulnerabilidades. La defensa moderna exige parches completos, segmentación de red, endurecimiento de protocolos de autenticación y monitoreo continuo. Audite sus controles de salida SMB, valide la configuración de SmartScreen y otras protecciones de origen, y trate los hashes NTLM como credenciales de alto riesgo: asuma que, si se exponen, requerirán rotación y medidas compensatorias inmediatas.