Microsoft Threat Intelligence detectó la explotación de la vulnerabilidad CVE-2026-73570 en la ruta de notificaciones SNMP de Zimbra Collaboration Suite. La vulnerabilidad permite ejecutar comandos del sistema de forma remota sin autenticación ni interacción del usuario, cuando el paquete opcional zimbra-snmp está instalado y las notificaciones SNMP están habilitadas en un servidor Zimbra expuesto a Internet.
Microsoft afirma que la explotación comienza con un mensaje SMTP diseñado específicamente, ya que un valor controlado por el atacante puede llegar al procesamiento de las notificaciones SNMP y después insertarse en una llamada de shell relacionada con la supervisión del estado del servicio. Como resultado, el atacante puede ejecutar comandos con los privilegios de la cuenta de servicio zimbra.
La explotación comenzó antes de la divulgación pública
Zimbra publicó la corrección en la versión 10.1.20 el 20 de julio de 2026, mientras que la vulnerabilidad se divulgó públicamente el 13 de agosto. Entre el 28 de julio y el 7 de agosto, Microsoft observó herramientas de escaneo y pruebas externas que verificaban la posibilidad de ejecutar comandos a través de la misma ruta, antes de la divulgación pública de la vulnerabilidad.
Las pruebas utilizaron solicitudes HTTP, consultas DNS e ICMP, y comandos como curl, wget, ping, nslookup e id para demostrar la ejecución de comandos y el acceso externo al servidor, sin necesidad, en todos los casos, de descargar una carga útil completa.
De la ejecución del comando al control del servidor
Después del acceso inicial, los atacantes implantaron puertas traseras en formato JSP dentro de las rutas de las aplicaciones de Zimbra, crearon sesiones de shell inversas y ejecutaron procesos en segundo plano. Microsoft también observó el uso de cron, systemd y memfd_create para mantener la ejecución o ejecutar una carga útil desde la memoria.
En una de las cadenas de ataque, se abusó de componentes autorizados para utilizar sudo y de una ruta relacionada con PAM para elevar los privilegios de la cuenta zimbra a root. Los atacantes también instalaron un servicio de systemd llamado zimlog.service, un nombre que imita a un componente legítimo de Zimbra, para ejecutar la carga útil durante el arranque del sistema.
La actividad no se detuvo en el primer servidor. Se utilizaron la identidad SSH existente en Zimbra y el programa rsync para transferir archivos y puertas traseras a otros nodos dentro del clúster de correo, lo que amplió el alcance del acceso y redujo la dependencia de un único punto de intrusión.
Objetivo: los datos de autenticación y el correo
Los atacantes recopilaron valores de las configuraciones locales de Zimbra, incluidos datos de autenticación de los servicios LDAP, MySQL, Postfix, Amavis y de replicación. También atacaron claves como zimbraPreAuthKey, zimbraAuthTokenKey y zimbraTwoFactorAuthSecret.
El análisis de Microsoft indica que algunas herramientas intentaron leer bases de datos de correo, datos de dispositivos y configuraciones de fuera de la oficina, además de certificados, claves privadas y archivos de configuración de Postfix. En un incidente, se recopilaron copias de seguridad recientes de buzones en un archivo y después se utilizó AzCopy para intentar transferirlas a un almacenamiento Azure Blob. Las pruebas disponibles no confirman que la transferencia se completara.
¿Qué deberían hacer los operadores?
La recomendación principal es actualizar todos los servidores Zimbra a la versión 10.1.20 o posterior. Si no es posible aplicar el parche de inmediato, Microsoft recomienda eliminar el paquete opcional zimbra-snmp, deshabilitar las notificaciones SNMP y restringir el acceso a SNMP y SMTP únicamente a hosts de confianza.
Las alertas de shell inversa en servidores de correo expuestos a Internet también deberían tratarse como incidentes de alta prioridad, sin limitarse a buscar nombres de malware conocidos; algunos de los hallazgos más graves incluyeron el uso de un shell interactivo normal sin una familia de malware específica. Las medidas de respuesta incluyen rotar los secretos de Zimbra y las claves de autenticación, revisar los servicios de systemd y los módulos de PAM y sudo, y buscar archivos JSP inesperados y rastros de servlets generados en todos los nodos de correo.
Esta investigación demuestra que el riesgo práctico no se limita a la ejecución de un único comando. Una sola vulnerabilidad en un servidor de correo expuesto puede convertirse en un punto de partida para recopilar secretos, implantar mecanismos de acceso persistente, desplazarse dentro del clúster e intentar extraer datos de correo. Al mismo tiempo, indicadores como la creación de un archivo o la ejecución de una herramienta de transferencia en la nube, por sí solos, no demuestran que el robo de datos haya tenido éxito; para determinar qué ocurrió realmente es necesario correlacionar los registros de procesos, archivos y comunicaciones.