Microsoft Threat Intelligence a détecté l’exploitation d’une vulnérabilité CVE-2026-73570 dans le chemin des notifications SNMP de Zimbra Collaboration Suite. La vulnérabilité permet l’exécution à distance de commandes système sans authentification ni interaction de l’utilisateur, lorsque le paquet optionnel zimbra-snmp est installé et que les notifications SNMP sont activées sur un serveur Zimbra exposé à Internet.
Microsoft affirme que l’exploitation commence par un message SMTP spécialement conçu, dans lequel une valeur contrôlée par l’attaquant peut parvenir au traitement des notifications SNMP, puis être intégrée à un appel shell associé à la surveillance de l’état du service. L’attaquant peut ainsi exécuter des commandes avec les privilèges du compte de service zimbra.
Une exploitation commencée avant la divulgation publique
Zimbra a publié le correctif dans la version 10.1.20 le 20 juillet 2026, tandis que la vulnérabilité a été divulguée publiquement le 13 août. Entre le 28 juillet et le 7 août, Microsoft a détecté des outils d’analyse et de test externes qui vérifiaient la possibilité d’exécuter des commandes via le même chemin, avant la divulgation publique de la vulnérabilité.
Les tests utilisaient des requêtes HTTP, des requêtes DNS et ICMP, ainsi que des commandes telles que curl, wget, ping, nslookup et id afin de démontrer l’exécution de commandes et l’accès externe au serveur, sans toujours devoir télécharger une charge utile complète.
De l’exécution de commandes au contrôle du serveur
Après l’accès initial, les attaquants ont implanté des portes dérobées au format JSP dans les chemins des applications Zimbra, créé des sessions shell inversées et exécuté des processus en arrière-plan. Microsoft a également détecté l’utilisation de cron, de systemd et de memfd_create pour maintenir l’exécution ou lancer une charge utile depuis la mémoire.
Dans une chaîne d’attaque, des composants autorisés à utiliser sudo ainsi qu’un chemin associé à PAM ont été exploités pour élever les privilèges du compte zimbra jusqu’à root. Les attaquants ont également installé un service systemd nommé zimlog.service, dont le nom imite un composant légitime de Zimbra, afin de lancer la charge utile au démarrage du système.
L’activité ne s’est pas limitée au premier serveur. L’identité SSH présente dans Zimbra et le programme rsync ont été utilisés pour transférer des fichiers et des portes dérobées vers d’autres nœuds au sein du cluster de messagerie, ce qui a étendu la portée de l’accès et réduit la dépendance à un point de compromission unique.
Ciblage des données d’authentification et de messagerie
Les attaquants ont collecté des valeurs provenant des paramètres locaux de Zimbra, notamment les identifiants des services LDAP, MySQL, Postfix, Amavis et de la réplication. Ils ont également ciblé des clés telles que zimbraPreAuthKey, zimbraAuthTokenKey et zimbraTwoFactorAuthSecret.
L’analyse de Microsoft indique que certains outils ont tenté de lire les bases de données de messagerie, les données des appareils et les paramètres d’absence du bureau, ainsi que les certificats, les clés privées et les fichiers de configuration de Postfix. Lors d’un incident, des sauvegardes récentes de boîtes aux lettres ont été rassemblées dans une archive, puis AzCopy a été utilisé pour tenter de les transférer vers un stockage Azure Blob. Les éléments disponibles ne confirment pas que le transfert a été mené à bien.
Que doivent faire les opérateurs ?
La recommandation principale consiste à mettre à niveau tous les serveurs Zimbra vers la version 10.1.20 ou une version ultérieure. Si l’application du correctif est impossible immédiatement, Microsoft recommande de supprimer le paquet optionnel zimbra-snmp, de désactiver les notifications SNMP et de limiter l’accès à SNMP et SMTP aux seuls hôtes de confiance.
Les alertes de shell inversé sur des serveurs de messagerie exposés à Internet doivent également être traitées comme des incidents hautement prioritaires, sans se contenter de rechercher les noms de logiciels malveillants connus ; certains des résultats les plus graves comprenaient l’utilisation d’un shell interactif standard sans famille de logiciels malveillants précise. Les mesures de réponse comprennent la rotation des secrets Zimbra et des clés d’authentification, l’examen des services systemd ainsi que des modules PAM et sudo, et la recherche de fichiers JSP inattendus et de traces de servlets générées sur tous les nœuds de messagerie.
Cette enquête montre que le risque pratique ne se limite pas à l’exécution d’une commande isolée. Une seule vulnérabilité sur un serveur de messagerie exposé peut devenir un point de départ pour collecter des secrets, implanter des moyens d’accès persistants, se déplacer au sein du cluster et tenter d’exfiltrer des données de messagerie. À l’inverse, des indicateurs tels que la création d’une archive ou l’exécution d’un outil de transfert vers le cloud ne prouvent pas à eux seuls la réussite du vol de données ; il faut mettre en corrélation les journaux des processus, des fichiers et des communications afin de déterminer ce qui s’est réellement produit.