Mastodon Mastodon Mastodon Mastodon

Campaña masiva contra VMware vCenter explota CVE-2026-59310

Foto del autor

CyberSecureFox Editorial Team

Publicado:

La vulnerabilidad crítica de directory traversal CVE-2026-59310 (CVSS 9.8) en Broadcom VMware vCenter Server está siendo explotada activamente en el marco de una campaña a gran escala que, según la empresa alemana QUIRSO, ha afectado a 361 direcciones IP únicas de víctimas en 47 países. La vulnerabilidad permite ejecutar código arbitrario con privilegios de root en vCenter Server Appliance sin autenticación previa. Broadcom publicó un parche el 29 de julio de 2026; sin embargo, la explotación comenzó apenas cinco días después de la divulgación pública. Todas las organizaciones que utilicen VMware vCenter deben aplicar el parche de inmediato y revisar sus sistemas en busca de indicios de compromiso.

Detalles técnicos de las vulnerabilidades

Según los datos de NVD, CVE-2026-59310 es una vulnerabilidad de directory traversal en VMware vCenter Server. Su explotación otorga al atacante ejecución inmediata de código en el contexto de root en vCenter Server Appliance, sin necesidad de comprometer previamente una cuenta sin privilegios ni realizar una escalada posterior de privilegios. Todos los comandos registrados a través del demonio cron ya se ejecutaban con permisos de superusuario.

Paralelamente, en uno de los sistemas comprometidos se observó también la explotación de CVE-2026-59309, una vulnerabilidad de bypass de autenticación en vCenter, respecto de la cual igualmente se detecta un escaneo activo. Los rastros de explotación de CVE-2026-59309 datan del 1 de agosto de 2026 e incluyen la creación de una cuenta administrativa sin que se registraran eventos de inicio de sesión para la cuenta legítima. Al mismo tiempo, según QUIRSO, la actividad relacionada con ambas vulnerabilidades en un mismo sistema no se solapó: la cuenta «vcenter_admin» creada mediante CVE-2026-59309 no se utilizó en las fases posteriores del ataque.

Los productos afectados incluyen VMware vCenter Server, vCenter Server Appliance, VMware Cloud Foundation (incluida la versión 9.0) y hosts ESXi.

Mecanismo de ataque y herramientas

Según la investigación de QUIRSO, la cadena de explotación de CVE-2026-59310 comenzaba abusando del mecanismo de syslog remoto en vCenter Server Appliance para colocar archivos en el directorio /etc/cron.d, una ubicación privilegiada para la ejecución automática. El primer artefacto observado fue un archivo de cron mal formado, zz-poc59310-syslog.log, cuyo nombre hace referencia directa al identificador de la CVE e indica su origen en un proof-of-concept público.

Posteriormente, mediante los comandos curl o wget se descargaba el backdoor linuxFile (también conocido como systemlog o linux_x86). Este implante proporciona ejecución remota de comandos a través de un canal WebSocket: se conecta al servidor de mando y control, recibe instrucciones, las ejecuta mediante /bin/sh y devuelve los resultados. La dirección del servidor C2 está ofuscada mediante XOR y se decodifica en tiempo de ejecución. Pese al uso de transporte sin cifrar ws://, las comunicaciones se protegen con criptografía propia a nivel de aplicación. El implante soporta la reconexión automática y la persistencia mediante systemd y cron.

Persistencia y movimiento lateral

Los atacantes creaban tres tareas cron que se hacían pasar por servicios legítimos de VMware:

  • vmware-vpxd-stats-*: adición de la clave SSH del atacante al archivo authorized_keys para acceso remoto
  • vmware-perf-collect-*: implantación del web shell JSP vmware-perf-update.jsp
  • vmware-perf-sync-*: implantación del mismo web shell y ejecución de un script codificado en Base64 para el robo de credenciales y la creación de la cuenta «adminuser» con inclusión en el grupo vSphere SSO Administrators

Para el robo de credenciales se utilizó el script /tmp/.vmware-perf-upd.sh, que extraía las contraseñas de vmdir mediante una consulta al registro HKEY_THIS_MACHINE\services\vmdir o, en caso de fallo, a través del módulo de Python vmafd con las llamadas GetMachineName(), GetMachinePassword() y GetDomainName(). Las credenciales sustraídas se empleaban para realizar modificaciones privilegiadas en el directorio, incluida la adición de cuentas al grupo de administradores.

Además se creaba el archivo /etc/sudoers.d/vmware-perf, que otorgaba a la cuenta de servicio perfcharts acceso sudo ilimitado y sin contraseña a root. En los hosts ESXi se creaban cuentas locales (por ejemplo, «adminuser»), que posteriormente se utilizaban para desplegar el cifrador.

Fase final: el cifrador como cortina de humo

El ataque culminaba con el despliegue en los hosts ESXi de un cifrador con la extensión .babyk, característica de una familia derivada de Babuk. Sin embargo, según la valoración de QUIRSO, el despliegue del cifrador, presumiblemente, no era el objetivo principal de la campaña. Los investigadores lo consideran una cortina de humo destinada a distraer a los defensores y destruir los registros de ESXi mediante cifrado, privando así a los analistas de telemetría para la investigación. El análisis de QUIRSO se limitó a un único sistema comprometido, por lo que se desconoce el alcance del despliegue del cifrador en otras víctimas.

Contexto de la amenaza y atribución

QUIRSO estima con una moderada grado de confianza que la campaña está siendo llevada a cabo por un actor de habla china, que presumiblemente opera en el huso horario UTC+08:00. Esta evaluación se basa en un conjunto de indicios indirectos: artefactos en chino en los scripts, reutilización de materiales procedentes de publicaciones de seguridad chinas, uso de herramientas de gestión en chino, victimología que excluye a la China continental y patrones de actividad compatibles con un horario laboral en UTC+08:00. Cabe subrayar que esta atribución no ha sido confirmada por fuentes independientes y se apoya en la investigación de una sola empresa.

Distribución geográfica de las víctimas: Alemania (55), Estados Unidos (41), Turquía (38), Irán (26), Francia (25); el resto se reparte entre 42 países. Un error operacional de los atacantes fue que el servidor 5.34.176.100:5244 exponía un conjunto de herramientas de reverse SSH a través de un listado abierto de directorios de AList.

Indicadores de compromiso

A partir de los datos del estudio se han identificado los siguientes IOC:

  • Direcciones IP: 146.59.252[.]178, 5.34.177[.]38, 185.144.28[.]120, 192.255.141[.]13, 5.34.176[.]100
  • Dominio: intel.se9ly9upbhay[.]shop
  • Dirección C2: ws://intel.se9ly9upbhay[.]shop:8080/ws
  • Puertos: 9861, 3232, 8080, 5244
  • Artefactos en disco:zz-poc59310-syslog.log en /etc/cron.d, vmware-perf-update.jsp, /tmp/.vmware-perf-upd.sh, /etc/sudoers.d/vmware-perf
  • Cuentas: vcenter_admin, adminuser, vcadmin
  • User-Agent: GoodMoodle-VCFleet/1.0

Recomendaciones de respuesta

  1. Instale de inmediato el parche para CVE-2026-59310 y CVE-2026-59309, publicado por Broadcom el 29 de julio de 2026. Si no es posible actualizar en las próximas horas, aísle vCenter de Internet.
  2. Revise la presencia de IOC: escanee /etc/cron.d en busca de archivos atípicos y compruebe la existencia de las cuentas vcenter_admin, adminuser y vcadmin en vSphere SSO y localmente en los hosts ESXi.
  3. Auditoría de sudoers: revise /etc/sudoers.d/ para detectar el archivo vmware-perf u otras configuraciones no legítimas.
  4. Revise authorized_keys: asegúrese de que no haya claves SSH ajenas en los archivos de autorización del vCenter Server Appliance.
  5. Revise los servicios systemd: busque unidades atípicas asociadas a binarios systemlog o linux_x86.
  6. Bloquee los IOC de red en el perímetro: direcciones IP y dominio de la lista anterior.
  7. Rotación de credenciales: cambie las contraseñas de todas las cuentas administrativas de vCenter y vmdir, especialmente si el sistema estuvo accesible desde Internet después del 29 de julio de 2026.

La ventana de cinco días entre la divulgación pública de CVE-2026-59310 y el inicio de la explotación masiva confirma que las vulnerabilidades críticas en componentes de infraestructura de virtualización requieren un parcheo de emergencia en cuestión de horas, no de días. Las organizaciones que utilicen VMware vCenter con acceso desde Internet deberían partir de la hipótesis de una posible intrusión y llevar a cabo una auditoría completa basándose en los indicadores anteriores, sin limitarse a instalar la actualización.


CyberSecureFox Editorial Team

El equipo editorial de CyberSecureFox cubre noticias de ciberseguridad, vulnerabilidades, campañas de malware, actividad de ransomware, AI security, cloud security y security advisories de proveedores. Los materiales se preparan a partir de official advisories, datos de CVE/NVD, alertas de CISA, publicaciones de proveedores e informes públicos de investigadores. Los artículos se revisan antes de su publicación y se actualizan cuando aparece nueva información.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.