Un actor de amenazas de origen chino ha sido vinculado a una campaña de spear-phishing que explota vulnerabilidades de seguridad recientemente parcheadas en Google Chrome y Microsoft Windows para distribuir un backdoor malicioso en JavaScript denominado GRIMWEDGE.
Volexity, que rastrea a este grupo como UTA0560, informó que la actividad se dirigió a múltiples organizaciones no gubernamentales (ONG) el 1 de septiembre de 2026.
Los correos electrónicos contenían un mensaje que animaba a los usuarios a hacer clic en un enlace que llevaba al sitio web de una universidad estadounidense. Estos enlaces abusaban de una vulnerabilidad de cross-site scripting reflejado (XSS) en el sitio web, redirigiendo a los destinatarios a infraestructura controlada por el actor de amenazas que alojaba una cadena de explotación de múltiples etapas.
La cadena de explotación, como ya destacó Proofpoint, involucra tres fallos distintos: dos en Chrome y uno en Windows Advanced Local Procedure Call (ALPC). Primero aprovecha CVE-2026-85046 para obtener lectura/escritura arbitraria dentro del sandbox de V8, luego escapa del sandbox del navegador mediante CVE-2026-87491 y finalmente emplea CVE-2026-85880 para inyectar código en el proceso de Chrome y lograr ejecución de código arbitrario.
Se ha observado que UTA0560 recurre a este método de ataque para desplegar GRIMWEDGE, que facilita capacidades de reconocimiento del host, gestión de archivos y procesos, ejecución de comandos y entrega de cargas útiles. Todo comienza con un correo de spear-phishing que persuade a la víctima para que haga clic en un enlace incrustado que apunta a un sitio web legítimo susceptible a una vulnerabilidad XSS reflejado.
Se dice que el actor de amenazas aprovechó este fallo para activar la cadena de explotación de día cero, también llamada BlueMoon, para entregar el malware, mientras filtraba los sistemas que no usaban Chrome en Windows para visitar la URL. La página de explotación final incorpora tres cargas útiles binarias como cadenas codificadas en Base64 dentro de JavaScript:
- p1, shellcode que carga reflexivamente una DLL para realizar reconocimiento y fingerprinting del host
- p2, shellcode que carga reflexivamente una DLL para facilitar la escalada de privilegios del kernel de Windows
- pp, shellcode para realizar inyección en el proceso del navegador y descarga de carga útil
En el caso de UTA0560, la carga útil de siguiente etapa es un ejecutable llamado "msgbox.exe", que actúa como loader responsable de extraer de sí mismo un binario legítimo de Windows y una DLL maliciosa ("wsc.dll") para iniciar una cadena de sideloading de DLL. La DLL, por su parte, contacta al mismo servidor para obtener un archivo de texto que lleva el nombre del hostname del dispositivo obtenido durante la fase de perfilado.
El archivo de texto es un instalador MSI diseñado para ejecutar un backdoor JavaScript ofuscado contenido en las acciones personalizadas del MSI. Una vez lanzado, GRIMWEDGE entra en un bucle de comandos persistente que consulta a un servidor de comando y control (C2) ("ocr.opusaccel[.]top") para recibir más instrucciones que luego se ejecutan en memoria mediante el comando eval(). Está equipado para interpretar los siguientes comandos:
- Info, para realizar reconocimiento del sistema
- Dir, para obtener un listado de directorio
- Mkdir, para crear un directorio
- Del, para eliminar un archivo
- Tasklist, para enumerar procesos en ejecución
- Taskkill, para terminar un proceso por PID
- Type, para leer un archivo de hasta 5 MB
- Run, para ejecutar un comando en una ventana oculta
- Upload (chunk), para obtener un fragmento codificado en Base64 del servidor C2 y añadirlo a un búfer en memoria
- Upload (commit), para guardar el búfer acumulado en disco como archivo final
El código no tiene persistencia incorporada, movimiento lateral ni mecanismo de exfiltración más allá de los comandos de lectura de archivos y carga. El backdoor proporciona un punto de apoyo inicial en un host comprometido suficiente para que UTA0560 examine el host, recupere archivos de interés y despliegue herramientas adicionales mediante los comandos Run y Upload.
Volexity también observó a un segundo actor de amenazas vinculado a China conocido como JungleBamboo (alias APT31) utilizando la misma cadena de explotación aproximadamente al mismo tiempo para desplegar un loader llamado SUPERSTOMP, que luego instala LONGTALE, una extensión de Chrome para robo de credenciales también conocida como GemStone, desde un servidor remoto. Se disfraza como una extensión de Google Gemini para Chrome (ID: ckiknalbeplpcpofpnabcnhjcegckfei) para evadir la detección, mientras soporta las siguientes características:
- Registro de teclas y captura de formularios
- Robo de cookies y sesiones
- Captura de pantalla monitorizando el contenido de la página en busca de palabras clave proporcionadas por un servidor C2
- Exfiltración masiva de pulsaciones de teclas, cookies, datos de almacenamiento, historial de navegación y metadatos de sesión al servidor C2 en intervalos de aproximadamente 30 segundos
- Control y comando remotos
LONGTALE carece incluso de un comando básico de ejecución remota de código que permitiría al actor de amenazas realizar actividades adicionales de post-explotación en dispositivos comprometidos. Es posible que el actor de amenazas considerara esta característica innecesaria, ya que las extensas capacidades de robo de información que ofrece LONGTALE eran suficientes para lograr los objetivos de robo de credenciales y vigilancia de JungleBamboo.
El uso casi simultáneo de la misma cadena Chrome-Windows por múltiples actores de amenazas en China ha planteado la posibilidad de que haya sido vendida o puesta a disposición por el desarrollador del exploit después de posiblemente realizar ingeniería inversa de los cambios en el código fuente de Chromium.
Lo notable aquí es la brecha de parches: si bien las correcciones para los dos fallos de Chrome se enviaron al código base de Chromium de código abierto, no se habían incorporado a una versión estable de Google Chrome. En otras palabras, los parches upstream crearon un caso inusual de dos errores N-day que se abordaron en Chromium, pero no en Chrome. Esto, a su vez, los convirtió en días cero contra Chrome.
Dado que Chrome dependía de un ciclo de lanzamiento de cuatro semanas para versiones principales hasta la semana pasada (ahora es cada dos semanas), es posible que los atacantes intentaran moverse rápidamente antes de que se cerrara la ventana de explotación y llegaran los parches oficiales de Google.
Las vulnerabilidades de brecha de parches presentan un riesgo aún mayor, ya que crean una ventana de tiempo adicional para que los actores de amenazas realicen campañas de explotación […] a medida que los modelos de lenguaje grandes se vuelven más populares y efectivos para la investigación rápida de vulnerabilidades y el desarrollo de exploits.
Deja una respuesta