Una campaña acelerada está aprovechando el fallo CVE-2026-59310 en el servidor Syslog de VMware vCenter. Este error crítico de salto de directorio (path traversal) permite a los atacantes ejecutar comandos como root sin necesidad de iniciar sesión, otorgándoles el control total de la infraestructura virtual. La explotación se extendió rápidamente tras la divulgación, habiéndose identificado ya 361 direcciones IP afectadas.

Una campaña que se mueve rápidamente está convirtiendo un fallo de VMware vCenter en una ruta para obtener el control total de la infraestructura virtual.

Los atacantes están abusando de CVE-2026-59310, un error crítico de salto de directorio (path traversal) en el Servidor Syslog, para ejecutar comandos como root sin necesidad de un inicio de sesión normal.

La actividad pasó de la divulgación a la explotación generalizada en cuestión de días. QUIRSO mapeó 361 direcciones IP afectadas en 47 países, estando los entornos de tecnología, investigación, educación y telecomunicaciones entre los sectores expuestos.

La escala ilustra por qué los sistemas de gestión de vCenter son objetivos tan atractivos.

QUIRSO GmbH indicó en un informe que investigó una intrusión donde el compromiso progresó desde una probable ejecución de código no autenticada hasta el acceso persistente, creación de cuentas, control de ESXi y ransomware.

Sus investigadores estiman, con una confianza moderada, que un actor de habla china está detrás de la campaña CVE-2026-59310, aunque no lo vinculan con un grupo específico.

La primera conexión de víctima observada ocurrió el 3 de agosto, cinco días después del aviso del proveedor. Para el 5 de agosto, ya habían aparecido 343 de las 361 direcciones IP de víctimas observadas finalmente.

Este cronograma comprimido sigue el aumento de escaneos reportados después de que surgieron estos fallos críticos de seguridad de VMware, y deja poco margen para que los defensores traten los sistemas de gestión orientados a Internet como servidores rutinarios.

El fallo de Syslog abre el acceso root

La intrusión inicial estuvo ligada a archivos cron malformados que aparecieron bajo /etc/cron.d, incluyendo un nombre que hacía referencia al CVE y al servicio Syslog.

No hubo eventos de autenticación coincidentes, mientras que los comandos se ejecutaron como root. Esto respalda fuertemente el hallazgo de que los atacantes utilizaron el salto de directorio de Syslog para escribir contenido en una ubicación donde cron lo ejecutaría.

La técnica convierte un dispositivo de gestión en un punto de lanzamiento. Las tareas programadas descargaban herramientas, ejecutaban comandos de shell y utilizaban carpetas temporales para el almacenamiento intermedio.

En la cadena de ataque más amplia, este acceso root también permitió una shell web y derechos de administrador sin contraseña para una cuenta de servicio legítima. El riesgo es coherente con la forma en que la vulnerabilidad Syslog de vCenter permite la ejecución remota sin requerir acceso previo.

El actor creó entonces varias capas de acceso de retorno. Un servicio del sistema reiniciaba una puerta trasera, mientras que tareas falsas con nombres similares a los de VMware habilitaban repetidamente SSH y colocaban una clave del atacante en las claves autorizadas de root.

La misma campaña instaló una shell web, creó cuentas de administrador de vSphere y recuperó credenciales del servicio de directorio local.

Los investigadores también observaron una utilidad de tunelización inversa basada en SSH que hace que el host comprometido inicie una conexión saliente hacia el operador.

Esto puede evadir los controles diseñados principalmente para bloquear el acceso entrante no solicitado. Su presencia no autorizada, junto con la actividad recurrente de cron o el egreso inesperado de vCenter, justifica una investigación en lugar de descartarlo como una herramienta de administrador.

El cifrado de ESXi aumenta el impacto

Después del descubrimiento del inventario, los atacantes crearon cuentas de administrador local en los hosts ESXi y copiaron un ejecutable de ransomware, además de scripts, a través del explorador de datastores de vSphere.

El script de apoyo detuvo la ejecución de las máquinas virtuales, lanzó el cifrador contra los volúmenes VMFS y eliminó el agente de alta disponibilidad de VMware. Esa secuencia puede convertir el compromiso de un vCenter en un incidente de disponibilidad generalizado.

La carga útil utilizó un cifrador derivado de Babuk y cambió los datos afectados a una extensión nueva y distinta. Los archivos VMDK grandes solo se cifraron parcialmente, centrándose en los primeros 512 MB, pero esto puede hacer que las máquinas virtuales sean inutilizables.

El uso de esta familia de ransomware por sí solo no es una atribución fiable, una distinción útil entre otros ataques de ransomware a ESXi que también afectan al almacenamiento de discos virtuales compartidos.

Tú, como defensor, deberías aplicar las actualizaciones pertinentes de vCenter inmediatamente porque no existe ninguna alternativa que sustituya al parcheado.

También deberías eliminar el acceso público directo a las interfaces de gestión, restringir la administración a redes aprobadas, revisar las cuentas nuevas y los cambios en sudoers, y examinar los directorios de cron, servicios y aplicaciones web en busca de los signos enumerados.

Esto es especialmente urgente mientras los atacantes escanean los sistemas VMware vCenter tras la divulgación.

Los cazadores de amenazas deberían escanear los dispositivos vCenter en busca de herramientas de acceso remoto y puertas traseras no autorizadas utilizando el contenido YARA disponible, y luego correlacionar cualquier coincidencia con conexiones salientes inesperadas y la creación de archivos o tareas.

Las organizaciones que encuentren estos rastros deben tratar el dispositivo y el entorno ESXi alcanzable como potencialmente comprometidos, preservar los registros antes de la limpieza, rotar las credenciales expuestas e iniciar la respuesta ante incidentes.

Fuentes:
https://cybersecuritynews.com/vmware-syslog-path-traversal/