Investigadores atribuyen a un grupo vinculado a China la explotación de fallos críticos en VMware vCenter para ejecutar código arbitrario y saltar la autenticación. El ataque afectó a 361 direcciones IP en 47 países, permitiendo a los atacantes obtener acceso root y crear cuentas administrativas. El objetivo final fue el despliegue de un ransomware derivado de Babuk para cifrar archivos en hosts ESXi.







Investigadores de ciberseguridad han atribuido la explotación de un fallo de seguridad recientemente parcheado en Broadcom VMware vCenter a una amenaza persistente avanzada (APT) presuntamente vinculada a China.

Los ataques implican la explotación de CVE-2026-59310 (puntuación CVSS: 9.8), una vulnerabilidad grave de salto de directorio en el servidor VMware vCenter que podría ser utilizada por un actor malicioso para ejecutar código arbitrario. Broadcom lanzó una corrección para este fallo el 29 de julio de 2026.

La empresa alemana de respuesta a incidentes QUIRSO evaluó con confianza moderada que la campaña de explotación dirigida a CVE-2026-59310 está operada por un actor de amenazas que habla chino, probablemente trabajando en la zona horaria UTC+08:00, que es la predominante en las regiones de habla china.

"Esta evaluación se basa en la convergencia de artefactos en idioma chino en los scripts creados por el atacante, la aparente reutilización de investigaciones de una publicación de seguridad china, el uso operativo repetido de herramientas y software de gestión en chino, una victimología que excluye a China continental y patrones de actividad compatibles con el horario laboral UTC+08:00", afirmaron los investigadores de QUIRSO Maike Orlikowski, Çağatay Yürekli y Denis Szadkowski aquí.

La actividad, que comenzó cinco días naturales después de la divulgación pública del fallo, se estima que ha comprometido 361 direcciones IP de víctimas únicas en 47 países, con la mayoría de las infecciones dispersas en Alemania (55), EE. UU. (41), Turquía (38), Irán (26) y Francia (25).

Explotación de CVE-2026-59309

Se dice que un servidor vCenter Appliance comprometido analizado por QUIRSO fue objetivo tanto de CVE-2026-59310 como de CVE-2026-59309, una omisión de autenticación que también ha sido objeto de esfuerzos de escaneo activo. Las pruebas muestran actividad maliciosa consistente con la explotación de CVE-2026-59309 ya el 1 de agosto de 2026, seguida de la creación de una cuenta administrativa en vCenter.

Dicho esto, no se han observado eventos de inicio de sesión para la cuenta administrativa legítima que se utilizó para crear esta nueva cuenta. La creación de la cuenta se originó desde la dirección IP 146.59.252[.]178 y también implicó el descubrimiento de vSphere a través de la API REST el 3 de agosto utilizando cadenas de User-Agent como "GoodMoodle-VCFleet/1.0", en un intento de disfrazarlo como actividad relacionada con VMware.

Cabe destacar que VCF Fleet es una capacidad de gestión centralizada introducida por Broadcom en VMware Cloud Foundation (VCF) en la versión 9.0 para desplegar, escalar, parchear y operar múltiples instancias de VCF.



QUIRSO señaló que no hay solapamiento entre esta actividad y la cadena de eventos que implica el abuso de CVE-2026-59310 en el mismo sistema comenzando el 3 de agosto, añadiendo que la cuenta de administrador "vcenter_admin" recién creada no se utilizó en las fases posteriores del ataque.

Explotación de CVE-2026-59310

En cuanto a la explotación de CVE-2026-59310, la primera actividad implicó que el demonio cron (también conocido como crond) registrara un archivo cron malformado llamado "zz-poc59310-syslog.log". En el siguiente paso, se ejecuta un comando curl (o alternativamente un comando wget) para recuperar una puerta trasera (backdoor) desde "5.34.177[.]38:9861", ejecutarla y luego eliminar el archivo de registro.

La convención de nomenclatura del archivo de registro es significativa ya que es una referencia directa al identificador CVE y a que se trataba de una prueba de concepto (PoC) ideada después de que los detalles del fallo fueran de conocimiento público.

"El sufijo '-syslog.log' también refleja la convención de nomenclatura de archivos de syslog remoto de vCSA, pero el archivo aparece bajo /etc/cron.d en lugar del directorio de salida de syslog configurado", explicó QUIRSO. "Esto sugiere que el servidor syslog de vCSA fue abusado para colocar archivos en una ubicación de ejecución privilegiada".

El actor de amenazas detrás de la operación también confió extensamente en cron para ejecutar cargas útiles maliciosas, incluyendo la obtención y ejecución de un script de shell ("esxi.sh"). El script de shell sirve entonces como descargador e instalador de persistencia para un binario de SSH inverso ("reverse_ssh") específico de la arquitectura.

Otras tareas de cron relacionadas con la creación de directorios temporales, descarga de ejecutables y cambio de sus permisos hacían referencia a servidores en "192.255.141[.]13:8080" y "5.34.176[.]100:5244". En lo que parece ser un error de seguridad operativa, se descubrió que este último exponía el conjunto de herramientas de binarios SSH inversos a través de un listado de directorios AList.

A continuación, se presenta una breve descripción de algunas de las diversas acciones llevadas a cabo por el actor de amenazas:

* Despliegue de "linuxFile" (también conocido como systemlog o linux_x86), que se conecta a "ws://intel.se9ly9upbhay.shop:8080/ws" y establece persistencia a través de un servicio systemd.
* Configuración de tres tareas cron suplantando servicios legítimos de VMware: vmware-vpxd-stats-* (facilita un canal de acceso remoto basado en SSH), vmware-perf-collect-* (suelta una shell web JSP llamada "vmware-perf-update.jsp"), y vmware-perf-sync-* (suelta la misma shell web y ejecuta un script codificado en Base64 que accede a credenciales y configura una nueva cuenta llamada "adminuser").
* Creación de dos cuentas adicionales: añadiendo "vcadmin" a vSphere mediante un script de Python y creando una cuenta de administrador de vSphere mediante una operación externa de LDAP.
* Creación de un archivo llamado "/etc/sudoers.d/vmware-perf" con una configuración que otorga a la cuenta de servicio "perfcharts" acceso sudo a root sin contraseña y sin interacción.
* Ejecución de scripts de shell como "/tmp/.vmware-perf-upd.sh" para obtener credenciales de vmdir.
* Uso de la API de vSphere para realizar operaciones de descubrimiento y "esxi.sh" para desplegar el cliente reverse_ssh.
* Creación de cuentas locales en los hosts ESXi (por ejemplo, "adminuser") para permitir el cifrado de ransomware.
* Medidas para evadir la detección, reducir la visibilidad forense y mezclarse en el entorno VMware.

El ataque finalmente prepara el camino para el despliegue de un ransomware en hosts ESXi que cifra archivos con la extensión ".babyk", que normalmente se asocia con ransomware derivado de Babuk. No está claro si este era el objetivo final de la campaña, o si la carga útil derivada de Babuk fue "seleccionada oportunistamente o incluso intencionalmente" para confundir los esfuerzos de atribución.

"La explotación de CVE-2026-59310 proporcionó al actor una ejecución de código inmediata y no interactiva en un contexto de root en el dispositivo vCenter Server", afirmaron los investigadores. "Por lo tanto, los comandos posteriores registrados por CROND ya se estaban ejecutando como root, otorgando al actor acceso sin restricciones al VCSA subyacente sin tener que comprometer primero una cuenta local no privilegiada".

Fuente:
THN