El equipo de investigación de seguridad de Microsoft ha descubierto que actores de amenazas han aprovechado una vulnerabilidad en Zimbra Collaboration Suite (ZCS) para desplegar web shells y acceder a datos de buzones. La falla, identificada como CVE-2026-73570, tiene una puntuación CVSS de 8.9 y consiste en una inyección de comandos del sistema operativo sin autenticación que puede conducir a ejecución remota de código cuando las notificaciones SNMP están habilitadas y el paquete opcional zimbra-snmp está instalado.
La explotación de CVE-2026-73570 puede desencadenarse mediante una solicitud SMTP especialmente diseñada contra servidores Zimbra expuestos, sin requerir autenticación ni interacción del usuario. Zimbra parcheó la vulnerabilidad en julio de 2026 con la versión 10.1.20.
Tras una explotación exitosa, la actividad observada incluyó el despliegue de web shells JSP y shells inversos, escalada de privilegios, herramientas de acceso remoto persistentes y ejecución en memoria. Los actores también accedieron al correo y recopilaron datos de autenticación y de buzones, con creación de archivos y transferencia posterior.
Microsoft indicó que observó organizaciones afectadas en más de una región e industria, aunque no todos los hosts mostraron todas las etapas de la cadena de ataque. Actualmente se desconoce quién está detrás de los ataques.
Los detalles de la explotación activa de CVE-2026-73570 fueron destacados por primera vez por el Equipo de Respuesta a Incidentes de Ciberseguridad de Polonia (CERT Polska) en agosto de 2026, que instó 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 directorios temporales y en los directorios 'webapps' de Zimbra.
Más tarde ese mes, la Agencia de Ciberseguridad y Seguridad de Infraestructuras de EE. UU. (CISA) añadió oficialmente la falla a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV), obligando a las agencias federales a aplicar las correcciones antes del 24 de agosto de 2026.
Según los 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ó Zimbra versión 10.1.20, y el 13 de agosto de 2026, cuando se divulgó públicamente la falla.
Específicamente, entre el 28 de julio y el 7 de agosto de 2026, se encontraron dos herramientas de escaneo fuera de banda distintas sondeando la ruta de inyección para validar la ejecución de comandos sin entregar una carga útil de seguimiento.
Los atacantes luego abusaron de esta vía de acceso inicial para ejecutar comandos como la cuenta de servicio 'zimbra' y desplegar múltiples web shells JSP en las rutas de las aplicaciones Jetty y mailboxd para redundancia, así como descargar y ejecutar cargas maliciosas directamente a través de wget o curl, y establecer shells inversos interactivos.
Otras cadenas de ejecución utilizaron cron, systemd o memfd_create para mantener una ejecución recurrente o en memoria. 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 verificaciones básicas de permisos.
Algunos de los pasos posteriores realizados por el actor de amenazas se enumeran a continuación:
- Mapear el despliegue de Zimbra usando zmprov para identificar nodos de buzón y MTA para el descubrimiento del entorno.
- Verificar la presencia de la identidad SSH de Zimbra para facilitar el movimiento entre hosts Zimbra.
- Utilizar una técnica de escalada de privilegios que otorga a la cuenta de servicio 'zimbra' acceso sudo sin restricciones 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.
- Atacar los secretos de autenticación y servicios centralizados de Zimbra mediante el comando 'zmlocalconfig -s' en el servidor en lugar de ir tras contraseñas de buzones individuales. Las credenciales recuperadas se utilizan luego para consultas LDAP autenticadas y 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 un shell inverso cifrado con OpenSSL hacia infraestructura controlada por el atacante para ejecutar comandos, recuperar cargas útiles y exfiltrar la salida de comandos.
En al menos una campaña, se descubrió que los atacantes utilizaron un descargador de shell ligero para un binario Go llamado Zimdown2, que luego actúa como instalador del agente de acceso remoto Zimclient2. Zimclient2 ofrece acceso interactivo a shells, operaciones de archivos bidireccionales y proxy SOCKS5.
Soportaba transportes WebSocket, TLS y TCP crudo, proporcionando acceso remoto resistente y posible pivote de red a través de servidores Zimbra comprometidos. La evidencia identificó varios mecanismos de persistencia asociados con la carga útil, incluidos servicios systemd, OpenRC, cron, archivos de inicio de shell, claves autorizadas SSH 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 credenciales de la cuenta de servicio de Zimbra desde '/opt/zimbra/conf/localconfig.xml' y utilizar esos 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 credenciales, certificados, secretos LDAP, reglas de correo y artefactos de configuración. Los archivos recolectados se comprimen en un archivo ZIP para su posterior transferencia a un punto final remoto.
En un servidor Zimbra comprometido, el actor archivó el contenido reciente de la copia de seguridad del buzón en /opt/zimbra/final.tar.gz. Luego descargó AzCopy desde hxxps://aka[.]ms/downloadazcopy-v10-linux y lo invocó con una URL SAS de Azure Blob proporcionada por el operador dirigida 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 completara con éxito.
Para contrarrestar la amenaza, se recomienda a las organizaciones aplicar las actualizaciones de inmediato. Si no es posible parchear, se recomienda desinstalar el paquete zimbra-snmp, deshabilitar las notificaciones SNMP y restringir el acceso SNMP y SMTP solo a hosts de confianza. Otras medidas de protección incluyen rotar los secretos de autenticación de Zimbra y escanear el servidor en busca de persistencia redundante de web shells.
Deja una respuesta