Zimbra CVE-2026-73570, explotada antes de hacerse pública
Según Microsoft, los atacantes empezaron a aprovechar una vulnerabilidad de inyección de comandos de gravedad alta en Zimbra Collaboration Suite (ZCS) en las semanas posteriores a la publicación del parche, pero antes de que el fallo se divulgara públicamente.
La vulnerabilidad, identificada como CVE-2026-73570, tiene una puntuación CVSS de 8,9. Afecta a las versiones de ZCS anteriores a la 10.1.20 y permite a atacantes no autenticados ejecutar código de forma remota en servidores de correo vulnerables.
Cómo funciona el fallo
El problema está en la forma en que ZCS gestiona las notificaciones SNMP. SNMP (Simple Network Management Protocol) se usa habitualmente para supervisar y administrar dispositivos y servicios de red. En las versiones afectadas, los datos no fiables que se procesan durante estas notificaciones no se depuran correctamente, lo que abre la puerta a la inyección de comandos del sistema operativo.
La explotación depende de dos condiciones: debe estar instalado el paquete opcional zimbra-snmp y deben estar activadas las notificaciones SNMP. Si se cumplen ambas, un atacante puede activar el fallo enviando peticiones SMTP especialmente manipuladas. SMTP es el protocolo que usan los servidores de correo para enviar y recibir mensajes.
Un ataque con éxito permite al intruso ejecutar código con los privilegios del usuario de Zimbra, sin necesidad de iniciar sesión.
Un desfase entre el parche y la divulgación
Zimbra publicó la corrección el 20 de julio en ZCS 10.1.20. La divulgación pública llegó el 13 de agosto. El 17 de agosto, CERT Polska, el equipo nacional de respuesta a emergencias informáticas de Polonia, advirtió de que el fallo se estaba explotando y publicó indicadores de compromiso (IoC).
Los hallazgos de Microsoft demuestran que los ataques empezaron antes.
"Entre el 28 de julio y el 7 de agosto, después de que hubiera una corrección disponible el 20 de julio pero antes de la divulgación pública del 13 de agosto, Microsoft observó dos herramientas de escaneo fuera de banda distintas sondeando el punto de inyección vulnerable", señaló la compañía.
Este reconocimiento inicial no entregaba ninguna carga útil. Se trataba de comprobaciones ligeras pensadas para confirmar que se podían ejecutar comandos a través de la ruta vulnerable. Esa misma ruta de ejecución se utilizó después en la explotación real.
De las webshells a root
En los ataques posteriores, los intrusos colocaron webshells JSP en directorios de aplicaciones accesibles públicamente. También descargaron y ejecutaron contenido con wget o curl, lanzaron procesos en segundo plano y establecieron shells inversas interactivas.
"Se desplegaron múltiples webshells JSP en las rutas de aplicación de Jetty y mailboxd, incluidas copias adicionales en nodos de buzones vecinos. Esto ofrecía vías de acceso alternativas en distintas configuraciones de Zimbra y reducía la dependencia de una única webshell", explicó Microsoft.
Una vez dentro, los atacantes:
- cartografiaron los clústeres de Zimbra y obtuvieron la huella del entorno
- comprobaron la identidad SSH de Zimbra
- escalaron privilegios hasta root usando herramientas legítimas de Zimbra
- instalaron un mecanismo de persistencia secundario en forma de servicio de systemd llamado zimlog.service
Los atacantes también iban a por credenciales. Microsoft afirma que se centraron en los secretos de autenticación y del servicio centralizado de Zimbra, y que después usaron las credenciales robadas para lanzar consultas LDAP autenticadas que devolvían secretos de gran valor.
La propia identidad SSH de Zimbra sirvió para saltar a otros nodos del clúster. Las conexiones de retorno HTTP y HTTPS confirmaban que los comandos se estaban ejecutando y, finalmente, los atacantes desplegaron "un agente de acceso remoto completo que proporcionaba acceso a una shell interactiva, operaciones de archivos bidireccionales y proxy SOCKS5".
Qué deben hacer los administradores
Se recomienda a las organizaciones que usan ZCS:
- actualizar a la versión 10.1.20 o posterior
- desinstalar el paquete opcional zimbra-snmp si no se necesita
- desactivar la configuración vulnerable de notificaciones SNMP
- restringir el acceso a SNMP y SMTP
- revisar sus entornos en busca de indicios de compromiso
Dado que la explotación empezó antes de la divulgación, puede que aplicar el parche no baste. Los servidores expuestos entre finales de julio y el momento en que se instaló la actualización deberían revisarse en busca de webshells en las rutas de Jetty y mailboxd, servicios de systemd inesperados como zimlog.service y un uso inusual de la identidad SSH de Zimbra entre los nodos del clúster.
Nuestra opinión
Lo más llamativo de este caso es la cronología. Los atacantes ya estaban sondeando la ruta de código vulnerable aproximadamente una semana después de que saliera el parche y mucho antes de cualquier aviso público. Esto apunta a que alguien estudió a fondo la corrección, una práctica conocida a menudo como patch diffing, y dedujo el fallo a partir de los cambios. Para los defensores, es un recordatorio de que publicar un parche discretamente no da mucho margen. El intervalo entre una corrección y su conversión en arma parece estar acortándose, una tendencia que encaja con el aumento general de divulgaciones de vulnerabilidades y una explotación cada vez más rápida que venimos siguiendo.
Las plataformas de correo web y colaboración autoalojadas siguen siendo objetivos atractivos. Están expuestas a internet, gestionan comunicaciones sensibles y almacenan credenciales que pueden abrir mucho más de una red. La actividad posterior a la explotación en este caso, desde las consultas LDAP hasta el movimiento lateral por SSH, demuestra que a los atacantes les interesaba mucho más que un único buzón. Recuerda a los recientes ataques por inyección SQL en Roundcube, otro caso de software de correo arrastrado a campañas activas.
Microsoft no ha atribuido la actividad a ningún grupo concreto y no está claro cuántas organizaciones se han visto afectadas. Habrá que estar atentos a si CERT Polska u otros equipos nacionales comparten más datos sobre las víctimas y a si los IoC vinculan esta campaña con actores conocidos. Mientras tanto, los administradores deberían considerar potencialmente comprometido cualquier servidor Zimbra que siguiera sin parchear a finales de julio hasta que se demuestre lo contrario, y plantearse si de verdad necesitan tener instalados componentes opcionales como zimbra-snmp.