CVE-2026-32202: la vulnerabilidad zero-click de Windows Shell que APT28 ya está explotando

Microsoft publicó esta semana un aviso fuera de ciclo (out-of-band advisory) confirmando la explotación activa de CVE-2026-32202, una vulnerabilidad de severidad crítica en Windows Shell que permite la fuga de credenciales NTLMv2 sin interacción del usuario. La pieza incómoda del aviso no es solo el vector —archivos .LNK maliciosos capaces de evadir Microsoft Defender SmartScreen— sino la genealogía: la falla nace de un parche incompleto liberado meses antes para CVE-2026-21510, y está siendo encadenada en operaciones atribuidas con alta confianza a APT28 (Fancy Bear / Forest Blizzard / GRU Unit 26165).

Para los equipos de seguridad ofensiva y defensiva, este caso vuelve a poner sobre la mesa tres viejos conocidos que el ecosistema Windows arrastra desde hace una década: la superficie de ataque del Shell al renderizar metadatos de archivos, la fragilidad histórica de NTLM como protocolo de autenticación, y el riesgo de los parches sintomáticos que cierran la PoC pública pero dejan abierta la causa raíz.

Este artículo desglosa la cadena técnica, el contexto de threat intel y un plan de mitigación detallado que va más allá del "apliquen el parche".

Resumen ejecutivo

• CVE: CVE-2026-32202 (Windows Shell — Authentication Bypass / Credential Disclosure).

• Predecesora: CVE-2026-21510, parchada parcialmente. La nueva CVE es una variante que sortea la corrección original.

• Vector: archivo .LNK malicioso entregado por correo, almacenamiento extraíble, recurso compartido o descarga web.

• Interacción requerida: ninguna. Basta con que el archivo sea renderizado por el Shell (Explorador de Windows, panel de previsualización, indexado de carpetas, montaje de un USB).

• Impacto: fuga del hash Net-NTLMv2 del usuario hacia un servidor SMB controlado por el atacante, con potencial de relay a servicios internos y crackeo offline.

• Bypass: evade Microsoft Defender SmartScreen y la marca de procedencia (Mark-of-the-Web, MOTW).

• Atribución: campañas observadas vinculadas a APT28 (Fancy Bear), enfocadas en gobierno, defensa y proveedores de infraestructura crítica en Europa y Norteamérica.

• Acción inmediata: aplicar la actualización de seguridad fuera de ciclo; bloquear SMB saliente (puertos 445/139) en el perímetro y de hosts a Internet; endurecer NTLM.

El parche incompleto: cómo CVE-2026-21510 se convirtió en CVE-2026-32202

CVE-2026-21510 se publicó originalmente como una vulnerabilidad de divulgación de información en el procesamiento de archivos .LNK por parte de Windows Shell. La PoC pública obligaba al sistema a resolver una ruta UNC remota (\\atacante\share\icon.ico) cuando el Shell intentaba renderizar el ícono del acceso directo, lo que disparaba una autenticación SMB automática y filtraba el hash NTLM del usuario.

El parche original cerró el camino exacto de la PoC: validó que las rutas UNC contenidas en ciertos campos del LNK no fueran resueltas durante el render del ícono cuando el archivo portaba MOTW, y reforzó la verificación de SmartScreen sobre el origen del archivo.

CVE-2026-32202 es, en términos prácticos, la misma clase de bug por otro camino. Investigadores externos —y, según el aviso, actores ofensivos antes que ellos— identificaron que el Shell sigue resolviendo rutas remotas en otros campos del formato LNK (notablemente el bloque EnvironmentVariableDataBlock y la cadena de búsqueda de íconos extendida), y que ciertos crafted overlays en el archivo provocan que el motor de SmartScreen omita la evaluación reputacional al considerar al archivo "ya inspeccionado".

Es el patrón clásico de los parches sintomáticos: se cierra el caso de prueba, no el invariante violado. Quien quiera profundizar en este modo de fallar encontrará paralelos directos con la familia de bypass de SmartScreen (CVE-2024-21412, CVE-2024-29988) y con los abusos históricos del formato LNK (MS10-046 / Stuxnet, ZDI-CAN-23100). El árbol genealógico es largo y el patrón se repite.

Anatomía de la cadena de ataque

La cadena observada en los incidentes recientes encaja en cuatro pasos. Ninguno requiere un clic del usuario más allá de abrir la carpeta —o, en el peor caso, conectar un USB que el sistema indexe automáticamente.

1. Entrega del LNK

El archivo se entrega por uno de los canales habituales de APT28: adjunto en correo de spearphishing, ZIP/ISO/IMG montable que oculta la marca MOTW al extraer su contenido, o repositorio compartido (SharePoint, file servers internos vía pivote previo). En operaciones recientes se observó también la entrega vía drive-by sobre páginas comprometidas, donde el archivo se descarga junto con un señuelo legítimo.

El LNK luce inofensivo. Tiene un nombre verosímil (Reporte_Q1_2026.pdf.lnk con doble extensión oculta, Resume.lnk, Agenda_OTAN.lnk) y un ícono que imita al de un PDF o un documento de Word.

2. Renderizado por Windows Shell — el momento "zero-click"

Aquí está la parte interesante. Windows Shell, al mostrar un archivo en el Explorador, en el panel de previsualización, durante la indexación del Search Index Service o cuando el sistema construye miniaturas, resuelve activamente los metadatos del LNK para pintar su ícono. Si esos metadatos apuntan a una ruta UNC remota, el sistema intenta abrirla.

No hay doble clic. Basta con que la carpeta donde reside el archivo sea visualizada o que el archivo sea tocado por cualquier proceso del Shell. En los entornos donde Outlook guarda adjuntos descargados en una carpeta indexada, o donde los usuarios trabajan con un panel de previsualización activo, el ataque dispara solo.

3. Bypass de SmartScreen y MOTW

En este punto, la defensa esperada sería que SmartScreen evaluara la reputación del archivo y MOTW marcara cualquier ejecución posterior con la procedencia "Internet". CVE-2026-32202 abusa de la lógica que distingue resolución de íconos de ejecución de contenido: el Shell trata la resolución UNC como una operación de render, no como una ejecución, y por lo tanto omite la evaluación de SmartScreen sobre la conexión saliente. La marca MOTW, presente en el archivo, no se propaga al socket SMB.

El resultado neto: el sistema abre una conexión SMB hacia un host arbitrario controlado por el atacante sin que ninguna capa reputacional intervenga.

4. Coerción de autenticación y captura del hash NTLMv2

La conexión SMB saliente arrastra automáticamente el contexto del usuario actual. El cliente SMB de Windows negocia autenticación con el servidor remoto y, salvo configuración explícita, ofrece Net-NTLMv2 como mecanismo. El servidor controlado por el atacante (típicamente Responder, Inveigh o impacket-ntlmrelayx en modo capture) registra el NTLMSSP_AUTH y obtiene el hash desafío-respuesta del usuario.

A partir de ahí el atacante tiene dos rutas:

Crackeo offline. El hash Net-NTLMv2 puede ser sometido a un ataque de diccionario o fuerza bruta con hashcat -m 5600. La calidad de la contraseña del usuario determina la dificultad. En entornos donde aún se usan contraseñas humanas con políticas laxas, el time-to-crack se mide en horas, no en semanas.

NTLM relay. El hash puede ser reenviado en tiempo real contra otros servicios del entorno que acepten NTLM (LDAP, LDAPS, HTTP/EWS, SMB sobre hosts sin firma obligatoria, ADCS/PKI con plantillas vulnerables). Si el usuario coercionado tiene privilegios elevados —o si el relay golpea ADCS para emitir un certificado a su nombre—, el atacante salta de "tengo un hash" a "tengo persistencia en el dominio" en minutos. El playbook de ataques tipo PetitPotam + ADCS ESC8 lleva años documentado y sigue siendo brutalmente efectivo.

¿Por qué APT28 y por qué ahora?

La atribución pública apunta a APT28 (también rastreado como Fancy Bear, Forest Blizzard, Sofacy, Strontium, GRU Unit 26165). El grupo, vinculado a la inteligencia militar rusa, tiene un historial documentado de explotar bugs de coerción de credenciales y de invertir tiempo en cadenas zero-click contra blancos diplomáticos, militares y de infraestructura crítica. Los TTP coinciden:

• Uso de archivos .LNK como dropper inicial: visto en campañas previas (HeadLace, JaguarTooth).

• Robo de hashes NTLM como objetivo táctico —no estratégico— para escalar lateralmente: documentado en operaciones contra OTAN y energía europea.

• Preferencia por explotar variantes de bugs ya parchados, donde la madurez del parcheo organizacional es desigual.

Lo "novedoso" del caso, más que la técnica, es la velocidad: el aviso de Microsoft documenta explotación in-the-wild antes de que existiera PoC pública para CVE-2026-32202. Esto sugiere que el grupo descubrió el bypass del parche por su cuenta o lo adquirió en un mercado cerrado, y lo desplegó con una ventana de oportunidad calculada.

Para contexto evenhanded: la atribución a un actor estatal específico siempre debe leerse con prudencia. Los indicadores técnicos (infraestructura, tradecraft, sobreposición con campañas previas) son consistentes con APT28, pero la atribución absoluta requiere acceso a inteligencia que ni Microsoft ni los proveedores de threat intel publican íntegramente. El consejo operativo no cambia con la atribución; el riesgo es real independientemente de quién esté detrás.

Detección: qué buscar en su telemetría

Mientras el parche se distribuye y se valida, los equipos de detección pueden aprovechar varias señales. La buena noticia es que la cadena deja huella tanto en endpoint como en red.

En endpoint (EDR / Sysmon):

• Eventos Sysmon EventID 3 (Network Connect) con DestinationPort=445 y DestinationIp fuera del espacio RFC1918 o fuera del set de file servers conocidos. SMB saliente a Internet es, casi por definición, anómalo.

• Eventos Sysmon EventID 7 (Image Loaded) con explorer.exe cargando windows.storage.dll o shell32.dll justo antes del Network Connect, en ventana corta (< 2s), sin que el usuario haya iniciado un proceso hijo.

• Creación de archivos .lnk en rutas como Downloads, Desktop, Temp, OneDrive\\...\\Recibido, especialmente con MOTW (Zone.Identifier:$DATA = ZoneId=3).

• Acceso al archivo LNK por parte de procesos no esperados: SearchIndexer.exe, dllhost.exe (con CLSID de thumbnail provider), explorer.exe en sesión de un usuario que no abrió nada.

En red (NDR / firewall logs / Zeek):

• Tráfico SMB saliente (tcp/445, tcp/139) hacia hosts externos. Si su política ya bloquea esto en el perímetro, los intentos de conexión siguen siendo señal de oro.

• Resoluciones DNS hacia dominios recién registrados o con TTL muy bajo, seguidas inmediatamente por intentos SMB. APT28 suele usar dominios typosquatting de proveedores legítimos (CDN, almacenamiento cloud).

• Sesiones SMB con NTLMSSP_NEGOTIATE seguidas de NTLMSSP_AUTH y cierre inmediato sin operaciones SMB2 reales: firma clara de servidor capture-only.

A nivel de Windows Event Log:

• Security 4624/4625 con LogonType=3 (Network) y AuthenticationPackage=NTLM cuando NTLMv2 ya no debería ser el mecanismo primario en su entorno.

• Microsoft-Windows-NTLM/Operational 8001/8002/8003 para detectar uso saliente de NTLM (requiere auditoría NTLM habilitada).

Ofrezco una regla rápida que ha funcionado bien como detección compensatoria mientras el parche llega: cualquier proceso explorer.exe o searchindexer.exe que abra un socket TCP/445 hacia una IP que no esté en una allowlist de file servers internos, en cualquier endpoint del parque, es un caso digno de investigación inmediata.

Mitigación detallada

El parche es la respuesta correcta, pero rara vez es la respuesta única ni la primera disponible. Lo que sigue es un plan en capas, ordenado de mayor a menor impacto y con la lógica de defensa en profundidad: si una capa falla, otra detiene la cadena.

1. Aplicar el parche fuera de ciclo

Microsoft liberó actualizaciones para las ramas soportadas (Windows 11 23H2/24H2, Windows 10 22H2 ESU, Windows Server 2019/2022/2025). La actualización debe probarse en un anillo controlado —especialmente porque toca componentes de Shell que pueden afectar a software de terceros que hookea el Explorador— y luego desplegarse a producción dentro de las 72 horas posteriores. Para sistemas legacy fuera de soporte, no hay parche; las mitigaciones de las siguientes secciones se vuelven obligatorias, no opcionales.

2. Bloquear SMB saliente en el perímetro

Esta es, lejos, la mitigación de mayor relación costo/beneficio. Si su organización no tiene un caso de uso documentado para que estaciones de trabajo o servidores hablen SMB hacia Internet, bloquee tcp/445 y tcp/139 saliente:

• En el firewall perimetral para todos los segmentos cliente.

• En el firewall de Windows vía GPO (Windows Defender Firewall with Advanced Security → regla outbound bloqueando tcp/445 con destino Internet/Public).

• En proxies y DNS firewalls, alertar (y bloquear si la política lo permite) sobre resoluciones de hostnames que terminen siendo destinos SMB.

Esta sola medida neutraliza el impacto de la vulnerabilidad incluso si el endpoint no está parchado: el hash nunca sale del perímetro.

3. Endurecer NTLM y favorecer Kerberos

NTLM debería estar en vías de extinción en cualquier entorno moderno. Los pasos:

• Habilitar SMB Signing obligatorio en clientes y servidores (RequireSecuritySignature = 1) para impedir el relay sobre SMB.

• Configurar EPA (Extended Protection for Authentication) en LDAP, ADCS Web Enrollment, Exchange y cualquier servicio HTTP que aún acepte NTLM.

• Aplicar la GPO Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers en modo Audit primero, luego Deny all para hosts que no necesiten NTLM saliente.

• Si su entorno está listo, habilitar las nuevas capacidades de Windows 11 24H2+ que permiten deshabilitar NTLM en el cliente para autenticación saliente, manteniendo Kerberos como mecanismo único.

• En ADCS, deshabilitar las plantillas vulnerables a ESC1/ESC8 (auditar con Certify/Certipy), forzar HTTPS con EPA en los endpoints de inscripción y, donde sea viable, retirar el rol de Web Enrollment.

4. Romper la cadena en el Shell

Hay varias palancas que reducen la superficie del Shell antes de que el bug se dispare:

• Deshabilitar el panel de previsualización y la resolución automática de íconos LNK vía GPO en perfiles de alto riesgo (ejecutivos, finanzas, equipos con acceso a fuentes externas frecuentes).

• Bloquear archivos .lnk en correo a nivel de gateway (Exchange Online, gateways de terceros). En operaciones recientes APT28 los entregó dentro de ZIPs e ISOs; bloquear ISO/IMG/VHD adjuntos en Exchange Transport Rules elimina otra ruta común.

• Deshabilitar el montaje automático de ISO/IMG en estaciones de trabajo (HKLM\Software\Classes\Windows.IsoFile\shell\mount con permisos restrictivos), ya que es uno de los trucos preferidos para evadir MOTW.

• AppLocker / WDAC con regla que bloquee la ejecución de .lnk desde ubicaciones no confiables (%TEMP%, %USERPROFILE%\Downloads, raíces de USB). Esto no detiene la coerción de NTLM por render, pero corta la siguiente fase si el LNK lleva además un payload ejecutable.

5. Reforzar EDR y reglas de detección

Sumar reglas específicas mientras el parche se valida:

• Alertar sobre cualquier outbound SMB desde estaciones de trabajo.

• Alertar sobre Network Connect originado por explorer.exe, searchindexer.exe, dllhost.exe, runtimebroker.exe cuyo destino sea tcp/445.

• Cazar archivos .lnk con campos UNC que apunten a IPs externas (script PowerShell sencillo + parsing del formato MS-SHLLINK).

• Activar ASR rules de Microsoft Defender, en particular Block credential stealing from the Windows local security authority subsystem y Block all Office applications from creating child processes.

6. Hacer el incidente caro al atacante

Aun si el hash sale, hay capas que limitan su utilidad:

• Política de contraseñas robusta para que el crackeo offline no sea trivial: passphrases largas, banned-password lists alineadas con HIBP, MFA en todo lo que NTLM no proteja.

• Cuentas privilegiadas en silos de Tier 0 sin sesión interactiva en estaciones de usuario: si un admin de dominio nunca toca un endpoint de oficina, su hash no se filtra por este vector.

• gMSA/dMSA para servicios que históricamente corrían con cuentas privilegiadas y contraseñas estáticas.

• Tickets PRT y credenciales en cache auditados; rotación inmediata si hay sospecha de exposición.

Plan de respuesta en 72 horas

Para los equipos que tengan que justificar acciones concretas a su CISO esta semana, una secuencia razonable es:

Primero, en las primeras 24 horas, validar el bloqueo de SMB saliente en el perímetro y desplegar la regla de detección compensatoria sobre explorer.exe → tcp/445. Inventariar versiones de Windows en el parque y priorizar el anillo de pruebas del parche.

Segundo, entre las 24 y 48 horas, iniciar el despliegue del parche al primer anillo (TI, seguridad, sistemas no críticos), revisar logs de los últimos 30 días buscando los IoCs descritos arriba, y comunicar a usuarios de alto riesgo el estado de la amenaza sin entrar en detalle técnico (foco: no ejecutar adjuntos, reportar comportamiento anómalo).

Tercero, entre las 48 y 72 horas, completar el despliegue a producción, activar las GPO de NTLM saliente en modo auditoría, validar la cobertura de detección con un purple team corto que reproduzca la cadena en laboratorio (un Responder en la red de pruebas y un LNK forjado bastan), y dejar documentadas las brechas de hardening que esta CVE expuso para el siguiente ciclo de mejora.

Lecciones que se repiten

CVE-2026-32202 no es, en sí, una sorpresa técnica. Es la nueva temporada de una serie que el ecosistema Windows lleva produciendo desde hace quince años: archivos LNK como vector silencioso, NTLM filtrándose por defecto, parches que cierran la PoC pero no la causa raíz. Lo que sí debería sorprender —y mover decisiones— es seguir encontrando entornos donde SMB saliente a Internet está permitido o donde NTLM aún es el mecanismo de autenticación por defecto.

La pregunta útil para el lector no es "¿estamos parchados?". Es "¿cuántas capas tendrían que fallar para que un hash de un usuario nuestro termine en un servidor de un actor extranjero?". Si la respuesta es "una", el parche es urgente y todo lo demás también. Si la respuesta es "tres o cuatro", se está haciendo defensa en profundidad bien.

El parche llegará y se aplicará. La causa raíz —un Shell que resuelve rutas remotas para pintar íconos y un protocolo de autenticación que regala credenciales con cualquier conexión saliente— seguirá ahí, esperando la siguiente variante. Diseñar la red asumiendo que va a fallar es lo único que envejece bien.