Una vulnerabilidad en Zimbra Collaboration Suite está siendo utilizada para comprometer servidores de correo expuestos a Internet sin necesidad de conocer ninguna contraseña ni conseguir que la víctima abra un archivo o pulse sobre un enlace. Microsoft Threat Intelligence ha documentado ataques que explotan el fallo CVE-2026-73570 para instalar puertas traseras, elevar privilegios y acceder a información almacenada en los sistemas afectados.
El problema reside en el sistema de notificaciones SNMP de Zimbra. Para que un servidor sea vulnerable debe tener instalado el paquete opcional zimbra-snmp y las notificaciones SNMP activadas. En esas condiciones, un atacante puede enviar una solicitud SMTP especialmente preparada e introducir comandos que terminan ejecutándose con los privilegios de la cuenta de servicio de Zimbra.
La característica que eleva especialmente el riesgo es que el ataque no requiere autenticación ni interacción del usuario. No es necesario engañar a un empleado para que abra un adjunto: basta con alcanzar el servidor vulnerable desde Internet y enviar el contenido preparado para explotar el fallo.
De un correo malicioso al control persistente del servidor
Microsoft ha reconstruido una cadena de ataque considerablemente más compleja que una simple explotación inicial.
Una vez conseguida la ejecución de comandos, los atacantes observados desplegaron diferentes web shells JSP en los servidores. Estas puertas traseras les permitían conservar una vía de acceso mediante HTTP y continuar ejecutando instrucciones posteriormente.
Los operadores también utilizaron herramientas habituales de Linux como wget y curl para descargar y ejecutar nuevos componentes, además de establecer reverse shells que proporcionaban sesiones interactivas sobre las máquinas comprometidas. Microsoft observó asimismo mecanismos basados en cron, systemd y ejecución directamente desde memoria.
El siguiente paso consistía en conocer la infraestructura. Los atacantes utilizaban herramientas propias de Zimbra para identificar los servidores de buzones y los nodos MTA del entorno y comprobar si existían relaciones de confianza que pudieran facilitar el movimiento hacia otros sistemas.
En algunos casos consiguieron además elevar sus privilegios hasta obtener acceso root. Microsoft documentó una técnica que abusaba de componentes legítimos de Zimbra y de la configuración PAM y sudo. Tras conseguir privilegios elevados, los atacantes llegaron a crear una entrada que proporcionaba a la cuenta de Zimbra acceso mediante sudo sin contraseña.
Credenciales, correos y secretos de autenticación entre los objetivos
El acceso al servidor no era el punto final. La investigación muestra que los atacantes buscaban información especialmente sensible almacenada dentro de la infraestructura de correo.
En lugar de limitarse a recopilar contraseñas individuales, atacaron credenciales de servicios y secretos de autenticación centralizados de Zimbra, incluidos datos asociados a LDAP, MySQL, Postfix y otros componentes.
También obtuvieron material como zimbraPreAuthKey y zimbraAuthTokenKey. Este último resulta especialmente sensible porque interviene en la firma de los tokens de sesión de los usuarios. Microsoft explica que disponer de este material puede permitir generar tokens para cuentas sin necesitar directamente sus credenciales.
La investigación encontró además malware desarrollado específicamente para entornos Zimbra capaz de extraer credenciales de configuración, información de buzones, metadatos, dispositivos móviles asociados y otros datos almacenados en las bases de datos.
Microsoft observó incluso cómo, en uno de los servidores comprometidos, los atacantes comprimieron copias de seguridad de buzones y utilizaron AzCopy para intentar transferir el archivo a Azure Blob Storage. Sin embargo, las evidencias disponibles no permiten confirmar que esa transferencia llegara a completarse.
Los ataques comenzaron antes de hacerse pública la vulnerabilidad
La cronología añade otro elemento relevante. Zimbra publicó el 20 de julio de 2026 la versión 10.1.20, que incluía la corrección del problema. La vulnerabilidad CVE-2026-73570 no fue divulgada públicamente hasta el 13 de agosto.
Microsoft detectó actividad contra el mismo vector de inyección durante ese intervalo. Entre el 28 de julio y el 7 de agosto observó herramientas realizando pruebas sobre el punto vulnerable, antes de que la existencia de CVE-2026-73570 fuera conocida públicamente.
Los operadores utilizaban inicialmente pequeñas comprobaciones mediante HTTP, DNS e ICMP para verificar si podían ejecutar comandos en los servidores sin necesidad de desplegar inmediatamente el resto de sus herramientas.
Microsoft señala que los ataques investigados afectaron a organizaciones de más de una región y sector, por lo que la explotación observada no estuvo limitada a una única industria o zona geográfica.
