LAUNDRY BEAR : espionnage russe zero-click sur Zimbra via CVE-2025-66376

Rapport CTI technique du 24 juillet 2026

Résumé exécutif

Le 23 juillet 2026, CISA, la NSA, le FBI et des partenaires internationaux ont publié l'advisory conjointe AA26-204A sur une campagne d'espionnage russe visant Zimbra Collaboration Suite. Le groupe, connu sous les noms LAUNDRY BEAR, Void Blizzard, CL-STA-1114 et TA488, exploite CVE-2025-66376, une XSS stockée dans l'interface Classic UI de Zimbra, depuis au moins juillet 2025. La particularité de cette campagne est qu'elle ne nécessite aucune action de la victime : l'exécution du payload se déclenche au simple affichage de l'email dans une session webmail vulnérable. Aucune formation à la vigilance ne protège contre ce vecteur, puisque la victime n'a littéralement rien à cliquer.

Le groupe est attribué à la Russie par trois sources indépendantes convergentes : les services de renseignement néerlandais AIVD et MIVD (mai 2025, après une intrusion chez la police nationale néerlandaise en septembre 2024), Microsoft Threat Intelligence (mai 2025) et Unit 42 de Palo Alto Networks (juillet 2026). Un ressortissant russe, ancien employé du FSB, a été inculpé aux États-Unis en juin 2026 et attend son procès à Boston après son arrestation en Thaïlande. Le ciblage vise des gouvernements, la défense, les transports et la finance dans les pays de l'OTAN, en Ukraine, dans les pays de la CEI et en Afrique, avec une priorité de collecte alignée sur le soutien militaire occidental à l'Ukraine.

Chronologie

Fiche vulnérabilité (format fiche CTI)

CVE-2025-66376 | CVSS 7.2 | Zimbra Collaboration Suite, interface Classic UI

Cross-site scripting stocké (XSS) résultant d'une sanitisation insuffisante des directives CSS @import dans le contenu HTML des emails. Un email contient un élément SVG invisible encapsulant un script encodé en Base64. Au rendu de l'email dans une session Zimbra Classic UI vulnérable, le SVG se décode et injecte le payload JavaScript directement dans le contexte du navigateur de la victime, sans aucune interaction requise.

Conditions d'exploitation : la victime doit simplement ouvrir ou prévisualiser l'email dans une interface Zimbra Classic UI non corrigée. Aucun clic sur un lien, aucune ouverture de pièce jointe, aucune saisie d'identifiants. C'est un exploit zero-click au sens strict : la surface d'attaque est le moteur de rendu HTML/CSS du client, pas le jugement de l'utilisateur.

PoC disponible : aucun exploit public autonome recensé à ce jour. La chaîne technique est documentée en détail par Unit 42 et CISA à partir de l'analyse de campagnes réelles, pas d'une divulgation coordonnée avec PoC.

Patch/mitigation : corrigée dans ZCS 10.0.18 et 10.1.13 (6 novembre 2025). Toute instance antérieure à ces versions doit être considérée comme potentiellement compromise pour toute période postérieure à juillet 2025. Pour les organisations ne pouvant pas patcher immédiatement, CISA recommande de faire basculer les utilisateurs vers un client mail alternatif plutôt que l'interface webmail Classic UI de Zimbra.

Diagramme de la chaîne d'attaque

Schéma construit à partir des rapports Unit 42 (CL-STA-1114) et de l'advisory CISA AA26-204A.

Analyse technique

Étape 1 : livraison et déclenchement zero-click

L'email d'appât est construit autour de titres d'actualité pour paraître crédible à l'affichage dans la liste des messages, avant même l'ouverture. Le corps HTML contient un élément SVG invisible portant un script encodé en Base64 et chiffré en XOR, combiné à des directives CSS @import qui servent de vecteur d'injection. Le rendu de l'email par le moteur Zimbra Classic UI suffit à déclencher le décodage et l'exécution du script. Ce détail change complètement le calcul défensif : la sensibilisation des utilisateurs, généralement la première ligne de défense contre le phishing, n'a ici aucune prise puisque l'utilisateur ne prend aucune décision exploitable par un attaquant.

Étape 2 : exécution du payload et collecte

Le payload, documenté sous le nom Ulej dans les analyses de campagne, s'exécute dans le contexte authentifié de la session webmail de la victime. Il interroge l'API SOAP de Zimbra pour collecter systématiquement les emails, jour par jour, sur une fenêtre de 90 jours, en excluant les messages classés indésirables. Il tente également d'énumérer la liste d'adresses globale de l'organisation, fournissant à l'attaquant un annuaire des comptes internes utile pour cibler la suite de la campagne.

Étape 3 : vol d'identifiants et de facteurs d'authentification

Au-delà des emails, le payload cible spécifiquement les éléments qui permettent de survivre à une réponse à incident standard. Il exfiltre les jetons CSRF, l'adresse email et le mot de passe de la victime, et surtout les codes de secours de l'authentification à deux facteurs. Ces codes de secours sont conçus pour fonctionner comme substitut au second facteur habituel : un attaquant qui les détient peut s'authentifier même après une réinitialisation du mot de passe. C'est pour cette raison qu'une réponse à incident qui se limite à réinitialiser les mots de passe, sans révoquer et régénérer les codes de secours 2FA, laisse l'attaquant en possession d'un accès valide.

Le payload tente en parallèle d'activer IMAP via la préférence zimbraPrefImapEnabled et de créer un mot de passe applicatif nommé « ZimbraWeb ». Certaines configurations IMAP de Zimbra ne supportent pas les flux 2FA classiques, ce qui fait du mot de passe applicatif un mécanisme de contournement durable, indépendant de la session web compromise. Une technique additionnelle observée consiste à injecter des champs de formulaire cachés dans la session du navigateur pour capter les identifiants proposés par l'autocomplétion du gestionnaire de mots de passe intégré.

Étape 4 : exfiltration et infrastructure

Les données collectées sont envoyées vers une infrastructure de collecte que les analyses désignent sous le nom Flowerbed, une plateforme conteneurisée en Python associant des services de type Catcher, Certbot, Nginx et Gardener. Les transferts volumineux, comme le contenu des emails et les pièces jointes, passent en HTTPS avec des certificats Let's Encrypt valides. Les informations plus courtes comme les identifiants, les codes de secours ou les mots de passe applicatifs sont encodées et exfiltrées par requêtes DNS, un canal souvent moins surveillé que le trafic HTTPS sortant.

Unit 42 documente au moins neuf adresses IP et neuf domaines utilisés pour cette infrastructure de commande et contrôle, avec une durée de vie moyenne de 35,4 jours avant rotation. Cette rotation régulière limite l'efficacité des listes de blocage statiques et complique la reconstitution complète de l'opération par les défenseurs. Le code du payload JavaScript lui-même a en revanche très peu changé sur toute la durée de la campagne, signe d'un acteur qui a trouvé une formule d'exploitation qui fonctionne et n'a pas eu besoin de la retravailler.

Indicateurs de compromission

Les trois domaines listés sont ceux publiquement cités dans les reprises presse du rapport Unit 42. La liste complète des neuf IP et neuf domaines est publiée dans le rapport CL-STA-1114 d'Unit 42 et dans l'advisory CISA AA26-204A. Toute correspondance dans des logs historiques doit être traitée comme un indicateur probable d'exfiltration de données, pas seulement comme une tentative de connexion.

MITRE ATT&CK

Aucune cartographie officielle complète n'a été reprise dans les sources consultées pour ce rapport. Le tableau suivant est une lecture technique construite à partir des éléments confirmés dans les advisories, pas une attribution vendeur.

Remédiation : checklist opérationnelle

1. Vérifier la version installée de Zimbra Collaboration Suite dans la console d'administration. Toute version antérieure à 10.0.18 ou 10.1.13 doit être patchée en urgence.
2. Traiter toute instance non patchée comme potentiellement compromise pour l'ensemble de la période depuis juillet 2025, pas seulement depuis la découverte.
3. Si le patch ne peut pas être appliqué immédiatement, faire basculer les utilisateurs vers un client mail alternatif plutôt que l'interface webmail Classic UI.
4. Révoquer et régénérer les codes de secours 2FA de tous les comptes potentiellement exposés, pas uniquement réinitialiser les mots de passe.
5. Invalider toutes les sessions actives associées à ces comptes.
6. Vérifier la présence de préférences IMAP activées de façon inattendue (zimbraPrefImapEnabled) et de mots de passe applicatifs suspects, en particulier ceux nommés « ZimbraWeb ».
7. Confronter les journaux réseau historiques aux domaines C2 connus (voir tableau IOC) sur toute la période depuis juillet 2025.
8. Pour les comptes affectés dans les secteurs gouvernement ou défense, considérer que les emails des 90 jours précédant la découverte ont pu être lus par l'adversaire, et réévaluer en conséquence la sécurité opérationnelle des sujets traités durant cette fenêtre.

Sources

• Russian State-Supported Cyber Actors Conduct Phishing Campaign Targeting Users of Zimbra Collaboration Suite — CISA AA26-204A
• Zero-Click Zimbra Flaw Fuels Active Russian Espionage Against NATO Agencies — Tech Times
• Russian LAUNDRY BEAR Hackers Exploit Zimbra Zero-Day to Steal 90 Days of Emails — GBHackers
• New Russia-affiliated actor Void Blizzard targets critical sectors for espionage — Microsoft Threat Intelligence
• Russian state-supported cyber actors conduct phishing campaign targeting users of Zimbra Collaboration Suite — cyber.gov.au