Análisis técnico de la vulnerabilidad CVE-2026-73570
Microsoft Threat Intelligence ha documentado la explotación de una vulnerabilidad de inyección de comandos del sistema operativo, catalogada como CVE-2026-73570, que afecta específicamente a la suite de colaboración Zimbra. El fallo se localiza en la ruta de notificaciones SNMP (Simple Network Management Protocol), un protocolo estándar utilizado para gestionar y supervisar dispositivos en redes IP. La vulnerabilidad permite que un atacante remoto envíe una solicitud SMTP especialmente diseñada que introduce datos no confiables en el procesamiento de estas notificaciones.
Para que el ataque sea exitoso, el servidor de correo Zimbra debe estar expuesto a internet y tener instalado el paquete opcional zimbra-snmp con las notificaciones SNMP habilitadas. Si se cumplen estas condiciones y la entrada no se sanea correctamente, los comandos embebidos en la solicitud se ejecutan con los privilegios de la cuenta de servicio zimbra. Esta capacidad de ejecución remota de código sin necesidad de autenticación previa convierte al servidor en un objetivo crítico, ya que el atacante no necesita poseer ninguna contraseña ni cuenta válida en el sistema.
Cronología de la detección y respuesta
La remediación de este fallo se hizo efectiva el 20 de julio de 2026 con el lanzamiento de la versión 10.1.20 de Zimbra. Sin embargo, la vulnerabilidad no se hizo pública oficialmente hasta el 13 de agosto de 2026. Durante este intervalo, Microsoft detectó a través de su telemetría que diversos actores de amenazas ya estaban aprovechando la brecha antes de que la comunidad de seguridad tuviera conocimiento general del problema.
Entre el 28 de julio y el 7 de agosto, se observaron actividades de reconocimiento mediante el uso de dos herramientas de escaneo independientes. Estas herramientas probaban el punto de inyección utilizando la ruta de ejecución swatchdog-to-snmptrap. Los atacantes validaron la ejecución de comandos mediante sondas ligeras dirigidas a subdominios únicos en servicios de interacción pública y colaborador, tales como oast.fun, oast.online, dnslog.pp.ua y requestrepo.com, además de infraestructura asociada a bypass.eu.org.
Para confirmar el acceso, los operadores utilizaron comandos estándar de red y sistema como curl, wget, ping, nslookup e id. Las solicitudes HTTP se identificaban mediante el User-Agent específico ZB73570, mientras que las consultas DNS e ICMP empleaban subdominios de respuesta aleatorios. Estas pruebas iniciales no buscaban desplegar una carga maliciosa inmediata, sino verificar que el servidor era vulnerable y que existía acceso externo al directorio raíz web del sistema.
Mecanismos de acceso inicial y despliegue de malware
Una vez confirmada la vulnerabilidad, los atacantes procedieron a la fase de acceso inicial. El proceso comienza cuando un cambio en el estado del servicio activa la monitorización de salud, momento en el cual el componente swatchdog incorpora el valor controlado por el atacante en una invocación de shell de snmptrap. Esto otorga al actor externo la capacidad de ejecutar comandos directos bajo la cuenta de servicio de Zimbra.
En los casos analizados, los atacantes utilizaron este acceso para desplegar web shells de JSP (JavaServer Pages), que son scripts que permiten administrar el servidor a través de un navegador web. Para lograrlo, modificaron los permisos del directorio raíz web, reconstruyeron una carga útil comprimida y codificada a partir de fragmentos previamente almacenados y escribieron el resultado final en directorios de aplicaciones accesibles públicamente. Tras la instalación, eliminaron los fragmentos temporales para reducir la visibilidad del ataque.
Además del despliegue de web shells, se observó el uso de wget y curl para descargar contenido remoto y ejecutarlo directamente en la shell, lanzando procesos en segundo plano y estableciendo reverse shells interactivas. Estas últimas permiten que el servidor comprometido inicie una conexión hacia la máquina del atacante, saltándose a menudo las restricciones de los firewalls entrantes. Para garantizar la persistencia, algunos actores utilizaron cron, systemd o la función memfd_create, que permite la ejecución de código directamente en la memoria, evitando dejar rastros en el disco duro.
Reconocimiento interno y escalada de privilegios
Tras obtener el acceso inicial, los atacantes iniciaron una fase de mapeo del clúster de Zimbra utilizando el comando zmprov. Esta herramienta permitió identificar los nodos de buzones de correo y los nodos de MTA (Mail Transfer Agent), proporcionando una visión completa de los roles de los servidores en el entorno y facilitando la identificación de objetivos prioritarios para el movimiento lateral.
Asimismo, se verificó la existencia de la identidad SSH de Zimbra para determinar si existía una confianza administrativa que permitiera saltar entre diferentes hosts sin necesidad de nuevas credenciales. Para extraer información del entorno, como el número de servidores de buzones, los atacantes utilizaron callbacks basados en DNS que transmitían estos detalles a sus propios servidores de control.
La fase más crítica fue la escalada de privilegios para obtener acceso de root, el nivel más alto de permisos en sistemas Linux. Los atacantes abusaron de los asistentes de servicio autorizados por sudo de Zimbra y de la interacción entre zmmailboxdmgr, su directorio de registros escribible y la configuración de PAM (Pluggable Authentication Modules). El proceso implicó sustituir el registro de zmmailboxd.out por un enlace simbólico hacia la configuración de PAM de sudo.
Al invocar el proceso privilegiado zmmailboxdmgr, el archivo de configuración de PAM pasó a ser propiedad de la cuenta de servicio zimbra, permitiendo que el atacante lo modificara. Insertaron un gancho de sesión pam_exec que ejecutaba un script local, el cual, al ser activado mediante el asistente zmstat-fd, creó una entrada NOPASSWD: ALL en el archivo sudoers. Esto otorgó a la cuenta de zimbra acceso total al sistema sin requerir contraseña. Finalmente, restauraron el contenido original de PAM y borraron los archivos temporales para ocultar la maniobra.
Persistencia y exfiltración de datos
Para asegurar el acceso a largo plazo, se implementó un mecanismo de persistencia mediante la creación de un servicio de systemd denominado zimlog.service. Este nombre fue elegido deliberadamente para mimetizarse con los componentes legítimos de registro de Zimbra. El archivo del servicio fue instalado manualmente en /etc/systemd/system/ y se le modificaron las marcas temporales (timestomping) para que coincidieran con servicios antiguos y legítimos como sshd.service o rsync.service, dificultando su detección mediante análisis forenses básicos.
Con el control total del sistema, los atacantes no se centraron en robar contraseñas individuales de los usuarios, sino en obtener las claves maestras de autenticación y los secretos de los servicios centralizados de Zimbra. Utilizaron el comando zmlocalconfig -s para exponer las credenciales utilizadas por LDAP, MySQL, Postfix, Amavis y los servicios de replicación.
Estas credenciales permitieron realizar consultas autenticadas en el directorio LDAP, facilitando la recolección de datos de buzones y cuentas de autenticación. Microsoft observó actividades de creación de archivos comprimidos y la posterior transferencia de estos datos hacia el exterior. La operación combinó el uso de payloads automatizados con intervenciones manuales directas sobre los servidores comprometidos.
Impacto y alcance de la amenaza
La explotación de la CVE-2026-73570 no se limitó a un sector industrial o área geográfica específica. Microsoft ha confirmado que organizaciones de diversas regiones y sectores fueron blanco de estos ataques, lo que indica que los actores de amenazas realizaron escaneos globales indiscriminados buscando cualquier servidor Zimbra que cumpliera los requisitos técnicos de vulnerabilidad.
El riesgo principal reside en que el servidor de correo es a menudo la puerta de entrada a la red corporativa. El control total de la infraestructura de mensajería permite a los atacantes leer comunicaciones confidenciales, suplantar la identidad de ejecutivos para realizar ataques de phishing interno y utilizar el servidor como base para atacar otros sistemas dentro de la red privada de la organización.
La capacidad de ejecutar comandos sin autenticación elimina la barrera más básica de seguridad, dejando la protección del servidor únicamente dependiente de la actualización del software. Las organizaciones que no aplicaron el parche de la versión 10.1.20 antes de la divulgación pública quedaron expuestas a un flujo de ataques que comenzó semanas antes de que la vulnerabilidad fuera oficialmente reportada, subrayando la peligrosidad de los periodos de ventana entre la disponibilidad de un parche y su implementación real en entornos productivos.
