Ciberatacantes explotaron una vulnerabilidad de inyección de comandos en Zimbra Collaboration Suite (CVE-2026-73570) para ejecutar código remoto y robar datos de buzones de correo. Los atacantes desplegaron web shells y herramientas de acceso remoto para escalar privilegios y moverse lateralmente por los servidores. Se recomienda actualizar a la versión 10.1.20 o desinstalar el paquete zimbra-snmp para mitigar el riesgo.



Los actores de amenazas han aprovechado un fallo de seguridad ya parcheado en Zimbra Collaboration Suite (ZCS) para desplegar web shells y acceder a los datos de los buzones de correo, según los hallazgos del equipo de Microsoft Security Research.

El ataque explota el CVE-2026-73570 (puntuación CVSS: 8.9), un fallo de inyección de comandos del sistema operativo no autenticado que puede provocar la ejecución remota de código cuando las notificaciones del Protocolo Simple de Gestión de Red (SNMP) están habilitadas y el paquete opcional zimbra-snmp está instalado.

La explotación del CVE-2026-73570 puede activarse mediante una solicitud SMTP especialmente diseñada (es decir, un correo electrónico contra servidores Zimbra expuestos) sin requerir autenticación ni interacción del usuario. La vulnerabilidad fue parcheada por Zimbra en julio de 2026 con el lanzamiento de la versión 10.1.20.

"Tras una explotación exitosa, la actividad observada incluyó el despliegue de web shells JSP y shells inversas, escalada de privilegios, herramientas de acceso remoto persistentes y ejecución respaldada en memoria", afirmó el gigante tecnológico en su blog. "Los actores de amenazas también accedieron al correo electrónico y recopilaron datos de autenticación y de buzones, observándose la creación de archivos y su posterior transferencia".

Microsoft señaló que observó organizaciones afectadas en más de una región e industria, aunque no todos los hosts mostraron cada etapa de la cadena de ataque. Actualmente no se sabe quién está detrás de los ataques.

Los detalles de la explotación activa del CVE-2026-73570 fueron destacados primero por el Equipo de Respuesta a Emergencias Informáticas de Polonia (CERT Polska) en agosto de 2026, instando a los usuarios a revisar el archivo "/var/log/zimbra.log" en busca de reinicios sospechosos del servicio Zimbra y a buscar archivos creados en los directorios temporales y de "webapps" de Zimbra.

Más adelante ese mes, la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) añadió oficialmente el fallo a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV), ordenando que las agencias federales aplicaran las correcciones antes del 24 de agosto de 2026.

Basándose en datos de telemetría, la actividad de ataque documentada por Microsoft se identificó "durante el intervalo" entre el 20 de julio de 2026, cuando se lanzó la versión 10.1.20 de Zimbra, y el 13 de agosto de 2026, cuando el fallo se hizo público.

Específicamente, entre el 28 de julio y el 7 de agosto de 2026, se encontraron dos herramientas de escaneo independientes probando la ruta de inyección para validar la ejecución de comandos sin entregar una carga útil posterior.

Los atacantes abusaron entonces de esta ruta de acceso inicial para ejecutar comandos como la cuenta de servicio "zimbra" y desplegar múltiples web shells JSP a través de las rutas de aplicación Jetty y mailboxd para redundancia, así como descargar y ejecutar cargas útiles maliciosas directamente a través de wget o curl, y establecer shells inversas interactivas.

"Otras cadenas de ejecución utilizaron cron, systemd o memfd_create para mantener una ejecución recurrente o respaldada en memoria", dijo Microsoft. "En algunos casos, los atacantes habilitaron temporalmente el acceso de escritura a un directorio público para desplegar la web shell y luego restauraron los permisos del directorio, limitando la visibilidad del cambio durante las comprobaciones básicas de permisos".

Algunos de los pasos posteriores emprendidos por el actor de amenazas se enumeran a continuación:

* Mapear el despliegue de Zimbra usando zmprov para identificar nodos de buzones y MTA para el descubrimiento del entorno.
* Comprobar la presencia de la identidad SSH de Zimbra para facilitar probablemente el movimiento entre hosts de Zimbra.
* Usar una técnica de escalada de privilegios que otorga a la cuenta de servicio "zimbra" acceso sudo irrestricto y sin contraseña modificando el archivo de configuración "/etc/pam.d/sudo".
* Crear un servicio systemd llamado "zimlog.service" como segundo mecanismo de persistencia que establece la ejecución al arrancar el sistema.
* Apuntar a los secretos de autenticación y servicio centralizados de Zimbra usando el comando "zmlocalconfig -s" en el servidor en lugar de ir tras las contraseñas individuales de los buzones. Las credenciales recuperadas se utilizan luego para consultas LDAP autenticadas para obtener atributos de alto valor, como zimbraPreAuthKey, zimbraAuthTokenKey y zimbraTwoFactorAuthSecret.
* Utilizar la identidad SSH existente de Zimbra en "/opt/zimbra/.ssh/zimbra_identity" para permitir el movimiento lateral a través de otros nodos confiables del clúster. Se utiliza Rsync para transferir web shells JSP y otros scripts auxiliares entre nodos.
* Emplear una shell inversa cifrada con OpenSSL hacia una infraestructura controlada por el atacante para realizar la ejecución de comandos, recuperación de carga útil y exfiltración de la salida de los comandos.

En al menos una campaña, se ha descubierto que los atacantes utilizan un descargador de shell ligero para un binario Go llamado Zimdown2 que luego actúa como instalador para el agente de acceso remoto Zimclient2. Zimclient2 ofrece acceso a shell interactiva, operaciones de archivos bidireccionales y proxy SOCKS5.

"Soportaba transportes WebSocket, TLS y TCP raw, proporcionando un acceso remoto resiliente y un posible pivotaje de red a través de servidores Zimbra comprometidos", dijo Microsoft. "La evidencia identificó varios mecanismos de persistencia asociados con la carga útil, incluyendo servicios systemd, OpenRC, cron, archivos de inicio de shell, claves SSH autorizadas y creación de cuentas locales".

También se asocia con la actividad el despliegue de cargas útiles específicas de Zimbra. Esto incluye un ejecutable basado en Go que intenta extraer las credenciales de la cuenta de servicio de Zimbra de "/opt/zimbra/conf/localconfig.xml", y usar estos valores para construir cadenas de conexión MySQL y LDAP a la instancia MySQL de Zimbra y exportar el contenido de las siguientes tablas de la base de datos:

* mailbox
* mailbox_metadata
* mobile_devices
* out_of_office
* Todas las tablas en el espacio de nombres zimbra.*

El implante también recopila y prepara artefactos de credenciales, certificados, secretos de LDAP, reglas de correo y configuración. Los archivos recolectados se comprimen en un archivo ZIP para su posterior transferencia a un endpoint remoto.

"En un servidor Zimbra comprometido, el actor archivó contenido reciente de respaldo de buzones en /opt/zimbra/final.tar.gz", dijo Microsoft. "El actor luego descargó AzCopy de hxxps://aka[.]ms/downloadazcopy-v10-linux y lo invocó con una URL SAS de Azure Blob proporcionada por el operador apuntando a wsweb03[.]blob[.]core[.]windows[.]net/log/windows.log".

"Esta actividad muestra la recopilación de datos de buzones, la preparación de archivos locales y un intento de exfiltración utilizando herramientas de almacenamiento en la nube; la evidencia disponible no confirma que la transferencia se haya completado con éxito".

Para contrarrestar la amenaza, se aconseja a las organizaciones aplicar las actualizaciones inmediatamente. Si el parcheo no es una opción, se recomienda desinstalar el paquete zimbra-snmp, deshabilitar las notificaciones SNMP y restringir el acceso SNMP y SMTP solo a hosts confiables. Otras salvaguardas incluyen rotar los secretos de autenticación de Zimbra y escanear el servidor en busca de persistencia redundante de web shells.

Fuente:
THN