Deux violations, une cause racine : ce que Zimbra et la Bank of Baroda révèlent sur l’e-mail en tant que surface d’attaque

Un groupe de hackers lié à l’État russe et un intrus non identifié qui s’est introduit dans la boîte mail d’un employé d’une banque indienne n’ont eu besoin de rien d’exotique pour réussir. Il leur a suffi d’un compte email. La même semaine, fin juillet 2026, deux incidents distincts à l’opposé du globe ont confirmé un constat gênant : l’email reste la porte d’entrée la plus facile dans une entreprise, et la plupart des organisations la laissent encore grande ouverte.

Le 23 juillet, CISA et ses partenaires internationaux ont publié l’avis AA26-204A, détaillant une campagne menée par un groupe identifié sous le nom de LAUNDRY BEAR (également connu sous Void Blizzard, CL-STA-1114 et TA488) exploitant une faille de cross-site scripting dans la messagerie web Zimbra Collaboration Suite, CVE-2025-66376, depuis au moins juillet 2025. L’éditeur de sécurité AttackIQ a publié sa propre analyse de l’avis le 27 juillet. Au même moment, la banque publique indienne Bank of Baroda a confirmé enquêter sur une fuite de données qui, selon des chercheurs, aurait pour origine la compromission de la boîte mail d’un seul employé. Continents différents, attaquants différents, ampleur différente. Même vecteur.

Aucun de ces incidents n’a touché un environnement gouverné par Kiteworks. Les victimes de Zimbra utilisaient la messagerie web native de Zimbra ; l’exposition de Bank of Baroda provient d’un email d’entreprise classique. Mais ces deux cas illustrent le même type de risque que vise à réduire une plateforme gouvernée de messagerie sécurisée et d’accès au contenu : du contenu contrôlé par l’attaquant exécuté dans la messagerie, et une seule boîte mail servant de passerelle non protégée vers des mois de correspondances, d’identifiants et de fichiers sensibles. Ce qui suit distingue les faits avérés des affirmations des attaquants dans les deux cas, puis examine en quoi une approche Kiteworks de l’échange sécurisé de données change réellement la donne, et où elle ne le fait pas.

Résumé des points clés

1. Une seule CVE dans la messagerie web Zimbra a ouvert une fenêtre d’espionnage de 12 mois. L’avis AA26-204A de la CISA relie la CVE-2025-66376 à un acteur lié à l’État russe qui collecte des emails, identifiants et tokens MFA auprès de cibles gouvernementales et commerciales depuis au moins juillet 2025.
2. Bank of Baroda attribue sa fuite à une boîte mail d’employé compromise. La banque affirme que ses systèmes bancaires centraux n’ont pas été accédés, mais des chercheurs rapportent des jeux de données divulgués représentant potentiellement des centaines de gigaoctets de dossiers de prêts, rapports d’audit et communications internes, des chiffres provenant des attaquants et non confirmés par la banque.
3. L’email est un dépôt de données, pas seulement un outil de messagerie, et les attaquants le savent. L’exploit Zimbra aurait permis d’extraire 90 jours d’historique de messages en une fois ; la boîte mail de Baroda contenait apparemment des évaluations de prêts et des audits internes qui n’avaient aucune raison d’y rester sans protection.
4. L’application automatique de règles à chaque message comble une faille dont aucune des deux victimes ne disposait. La passerelle de protection des e-mails Kiteworks applique le chiffrement, le routage, la mise en quarantaine et le rejet à chaque message entrant et sortant selon le contenu et la classification des données, puis journalise l’action, des fonctions qui auraient pu s’appliquer si ces organisations avaient routé leurs emails via cette solution plutôt que via la messagerie web native.
5. Les plateformes gouvernées ne rendent pas la messagerie web invulnérable, et cet article ne prétend pas le contraire. Kiteworks n’était impliqué dans aucun des deux incidents, et ces nuances sont importantes : EPG ne peut pas corriger le code source d’un fournisseur de messagerie web, et son efficacité dépend de la configuration des règles et politiques de conservation par l’organisation.

Dans l’avis AA26-204A de la CISA : la campagne Zimbra

L’avis de la CISA, publié conjointement avec des agences partenaires internationales, décrit une opération d’espionnage soutenue visant de nombreux secteurs : la base industrielle de défense (DIB), les administrations fédérales et locales, l’éducation, l’énergie, les forces de l’ordre, les médias, les ONG et les entreprises technologiques dans les pays occidentaux. L’acteur en question, suivi sous plusieurs noms dont LAUNDRY BEAR, Void Blizzard, CL-STA-1114 et TA488, serait actif depuis au moins juillet 2025.

Le mécanisme exploité est une vulnérabilité de cross-site scripting dans l’interface webmail de Zimbra Collaboration Suite, référencée CVE-2025-66376, due à une insuffisance de filtrage des directives CSS @import dans le contenu des emails. Les failles de type cross-site scripting permettent à un attaquant de faire exécuter son propre code dans la session d’une application web légitime, ici le client webmail. Une fois déclenché, selon la CISA, l’exploit permettait de collecter les 90 derniers jours d’emails de la victime, les adresses et mots de passe stockés, l’annuaire interne de l’organisation, les tokens d’authentification à deux facteurs et tout nouveau mot de passe d’application généré. Les données volées étaient ensuite transférées vers une infrastructure de backend que l’acteur appelle en interne « Flowerbed ». Zimbra a publié un correctif dans les versions ZCS 10.0.18 et 10.1.13 en novembre 2025, ce qui signifie que toute organisation encore exposée à cette campagne dispose d’un correctif depuis plusieurs mois.

Ce qui rend cet avis notable, c’est l’ampleur de ce qu’une seule faille dans une plateforme webmail peut permettre. Il ne s’agit pas d’un seul message ou d’une pièce jointe. Ce sont trois mois de correspondance, les identifiants qui la protègent, et les tokens MFA censés empêcher l’exploitation de mots de passe volés. La réponse d’AttackIQ, un exercice d’émulation d’adversaire conçu pour aider les défenseurs à tester si leurs systèmes de détection repèrent ce type de comportement, est une démarche pertinente et utile. Mais il s’agit d’un exercice de détection, pas de prévention ; émuler l’attaque permet de savoir si on la détecterait, pas si l’application webmail aurait exécuté le contenu malveillant à l’origine. Une plateforme SIEM configurée avec des alertes comportementales pour le schéma d’exfiltration « Flowerbed » — volume de données sortant anormal, activité inhabituelle sur les tokens de session, authentifications hors zone géographique — transforme l’exercice ponctuel d’AttackIQ en une capacité de surveillance continue.

Bank of Baroda : ce qui est confirmé et ce qui reste une allégation

Le second incident est moins détaillé publiquement mais illustre encore mieux à quelle vitesse la compromission d’une seule boîte mail peut dégénérer. Le chercheur en sécurité Srikanth Lakshmanan a d’abord identifié un jeu de données lié à Bank of Baroda circulant sur le dark web. Reuters a ensuite rapporté des métadonnées suggérant que le volume dépassait 700 Go, tandis que d’autres médias évoquent près d’1 To. Ces chiffres proviennent des analyses du chercheur ou de l’attaquant, pas de la banque elle-même, et cette distinction est cruciale pour évaluer l’ampleur réelle de l’exposition.

Les données divulguées incluraient des documents d’identité de clients, des dossiers de prêts et d’évaluation, des rapports d’audit interne, des documents d’agence et des communications internes. Certains rapports vont plus loin, évoquant la fuite de numéros Aadhaar et de données NetBanking, mais Bank of Baroda n’a pas confirmé ces éléments précis, il faut donc les considérer comme non vérifiés.

Ce que la banque a confirmé est plus limité et plus révélateur : la fuite provient d’un compte email d’employé compromis, et la banque affirme que ses systèmes bancaires centraux n’ont pas été accédés et restent sécurisés. Aucun groupe de hackers n’a revendiqué l’attaque, bien que certains chercheurs l’attribuent à un acteur nommé TripleX. Bank of Baroda indique avoir lancé une enquête judiciaire et coopérer avec les autorités. Tant que l’enquête n’est pas terminée, le volume et le contenu exacts de la fuite doivent être considérés comme provisoires. La propriété intellectuelle et les dossiers clients accessibles via une seule boîte mail illustrent pourquoi les institutions financières soumises au RGPD ou à des obligations sectorielles de protection des données ne peuvent pas considérer les comptes email individuels comme hors du périmètre de leur environnement gouverné.

En retirant les chiffres incertains, un fait demeure : une seule boîte mail d’employé contenait ou donnait accès à des dossiers de prêts, rapports d’audit et communications internes qu’une banque ne souhaite pas voir circuler publiquement. Il ne s’agit pas d’une chaîne d’exploit technique sophistiquée comme la CVE de Zimbra. C’est un schéma bien plus courant et sans doute plus dangereux : du contenu métier sensible stocké ou accessible dans la boîte mail d’un individu, protégé uniquement par les contrôles d’accès de ce compte.

Pourquoi l’email reste le vecteur d’attaque privilégié

Les équipes de sécurité investissent depuis vingt ans dans la sensibilisation au phishing, l’antivirus et l’authentification multifactorielle, mais l’email reste le point d’entrée initial dans de nombreux incidents médiatisés. Les cas Zimbra et Bank of Baroda montrent pourquoi le problème persiste : l’email n’est pas un simple point de contrôle, c’est un véritable dépôt de contenu, avec des défenses périphériques faibles au regard de ce qu’il contient.

Prenez une boîte mail après un ou deux ans d’activité normale. Contrats. Évaluations de prêts. Résultats d’audit. Dossiers clients transférés en pièce jointe faute de partage réseau pratique. Liens de réinitialisation de mot de passe. Codes de secours MFA envoyés « juste cette fois ». Aucun de ces contenus n’était censé rester dans l’email, mais il s’y accumule car l’email est la voie la plus simple pour échanger des informations. Les attaquants l’ont mieux compris que la plupart des défenseurs, d’où l’impact d’une faille webmail ou d’un identifiant volé : des mois de données sensibles récupérés d’un coup. Une fuite avérée via une boîte mail compromise — où des mois de contenu sensible se sont accumulés sans politique de conservation gouvernée — crée un périmètre de notification impossible à délimiter avant d’avoir reconstitué tout l’historique d’accès.

L’avis Zimbra ajoute une dimension : l’application webmail elle-même devient la surface d’attaque, pas seulement l’utilisateur qui lit les messages. Une faille de cross-site scripting ne nécessite pas que l’utilisateur clique sur un lien malveillant au sens classique du phishing. Elle exploite la confiance du navigateur dans le code de la plateforme webmail. Cela déplace une partie de la défense de la formation des utilisateurs vers la manière dont la plateforme email filtre, isole et audite le contenu, tant à l’enregistrement qu’au transit.

En quoi une approche gouvernée de la messagerie sécurisée change l’exposition

Ni les victimes de Zimbra ni Bank of Baroda n’utilisaient un environnement Kiteworks Secure Email, il serait donc inexact d’affirmer que Kiteworks aurait empêché ces incidents. Ce qu’on peut affirmer, c’est que les mécanismes décrits dans les deux avis — du contenu injecté par l’attaquant exécuté dans la messagerie web, et une boîte mail compromise servant de canal à des fichiers sensibles — relèvent précisément du champ que la messagerie sécurisée gouvernée et l’architecture Zero Trust visent à restreindre.

La Passerelle de protection des e-mails Kiteworks (EPG) s’appuie sur un moteur de politique de données qui applique automatiquement le chiffrement, le routage, la mise en quarantaine et le rejet à chaque message entrant et sortant, selon le contenu, l’expéditeur, le destinataire et les labels de classification, sans action requise de l’utilisateur. Elle analyse aussi les messages entrants et oriente les données sensibles, comme les CUI d’un sous-traitant défense, hors de la boîte mail standard vers un circuit conforme, chaque décision étant tracée dans un journal d’audit unifié et immuable. Dans le scénario Zimbra, cette couche de politique s’intercale devant le flux mail, et non dans le moteur de rendu du client webmail, ce qui réduit l’exposition à une classe d’attaques reposant sur l’exécution de contenus non fiables par l’application webmail. Dans le cas Bank of Baroda, la fonction pertinente consiste à traiter les fichiers sensibles, évaluations de prêts, rapports d’audit, dossiers clients, comme du contenu gouverné, routé et journalisé par politique, et non comme des pièces jointes ad hoc stockées où la boîte mail de l’employé le décide. Les politiques de minimisation des données appliquées à la passerelle email — purge automatique des pièces jointes et contenus sensibles dépassant la durée de conservation — limitent le volume de données récupérables par un attaquant en cas de compromission, réduisant ainsi directement le périmètre d’impact illustré par ces deux incidents.

Ces limites sont essentielles, car exagérer les capacités d’un éditeur après une fuite est une mauvaise habitude courante dans le marketing de la cybersécurité. EPG ne corrige pas le code source d’un fournisseur tiers de messagerie web, et ne peut pas éliminer toutes les vulnérabilités applicatives d’une plateforme en amont. Son efficacité dépend fortement de la configuration des politiques, labels de classification et règles de conservation par l’organisation ; une passerelle mal configurée ne fournit qu’une fraction de la protection possible. L’approche honnête, c’est une exposition réduite et un périmètre d’impact plus restreint, pas l’immunité. Même logique pour le cas Baroda : établir un lien direct entre « boîte mail d’employé compromise » et « messagerie sécurisée gouvernée comble la faille » est une inférence raisonnable à partir des éléments divulgués, mais pas la confirmation d’une chaîne d’exploit technique précise, car la banque n’en a pas publié.

Construire une posture Zero Trust autour du contenu email

La leçon pratique de ces deux incidents : il faut traiter l’email comme un système de gestion de contenu, avec la même rigueur qu’un serveur de fichiers ou une base de données, et non comme un simple outil de communication transportant des pièces jointes.

Il faut analyser avant la livraison, pas après la découverte d’une compromission. L’exploit Zimbra s’exécutait dans la session webmail elle-même, donc une couche d’analyse placée avant la remise du message, plutôt que de s’en remettre uniquement au cycle de correctifs du fournisseur, réduit la fenêtre pendant laquelle du contenu malveillant peut s’exécuter.

Les fichiers sensibles ne doivent pas non plus rester durablement dans les boîtes mail individuelles. Les évaluations de prêts, rapports d’audit et documents d’agence de Bank of Baroda étaient stockés ou accessibles via la boîte mail d’un seul employé. La classification des données et le partage sécurisé de fichiers offrent à ces contenus leur propre périmètre d’accès, indépendant des identifiants d’un individu. Un cadre de gouvernance des données interdisant explicitement le stockage long terme de documents métier sensibles dans les boîtes mail individuelles — et routant ces documents via un environnement de partage sécurisé gouverné avec des contrôles d’accès par fichier — élimine le schéma d’accumulation qui a transformé ces deux incidents d’un simple vol d’identifiants en une fuite massive de contenu.

Les tokens MFA et mots de passe d’application doivent bénéficier du même traitement que les contenus sensibles en transit, et pas seulement comme artefacts d’authentification. La campagne Zimbra ciblait précisément les nouveaux mots de passe d’application transitant par email. Les défenseurs doivent donc réfléchir à la façon dont ces tokens sont délivrés et stockés, pas seulement à leur génération.

Enfin, il faut intégrer la traçabilité à chaque point où du contenu sensible transite par email. Lorsqu’un incident survient, la chronologie forensique doit déjà exister, et non être reconstituée à partir de fragments de logs. L’enquête en cours chez Bank of Baroda, et l’ampleur de la fuite encore incertaine, montrent combien la réponse à incident est compliquée sans cette visibilité dès le départ. Un plan de réponse à incident documenté, incluant un runbook spécifique pour le scénario « boîte mail d’employé compromise avec accumulation de contenu sensible » — couvrant la révocation immédiate des accès, l’extraction des logs d’audit, l’évaluation du périmètre et la séquence de notification réglementaire — transforme ce schéma en une réponse maîtrisée et rapide, au lieu d’une improvisation post-incident.

Rien de tout cela n’est exotique. C’est l’application opérationnelle du Zero Trust appliqué aux données : vérifier chaque contenu transitant par email, qu’il provienne de l’interne ou de l’externe, et ne jamais supposer qu’une boîte mail est sûre simplement parce qu’elle appartient à un employé de confiance.

Exposition réglementaire et sectorielle au-delà de ces deux incidents

Les secteurs cités dans l’avis de la CISA — défense, gouvernement, énergie, forces de l’ordre, éducation — sont aussi parmi les plus réglementés sur la gestion du contenu sensible. Les organisations soumises à la conformité CMMC ou manipulant des CUI font face à des obligations précises sur la circulation de ces informations contrôlées, obligations que la vulnérabilité d’une plateforme webmail aux attaques par exécution de contenu rend plus difficiles à respecter. Les institutions financières comme Bank of Baroda ont leurs propres exigences réglementaires en matière de protection des données et de notification de fuite, et la compromission d’une boîte mail exposant des dossiers de prêts et d’audit soulève exactement les questions que les régulateurs posent après coup : quels contrôles d’accès existaient, qu’est-ce qui a été journalisé, et à quelle vitesse l’exposition a-t-elle été identifiée. Les programmes de gestion des risques supply chain des organisations des secteurs visés devraient évaluer explicitement si un fournisseur ou partenaire échange des CUI ou des données financières réglementées via des canaux email non gouvernés — la même classe de vulnérabilité exploitée par LAUNDRY BEAR concerne aussi la supply chain étendue d’un donneur d’ordre ou d’une institution financière.

Aucun de ces avis n’est d’abord une histoire de conformité. Ce sont des échecs opérationnels de sécurité, et les conséquences réglementaires suivront probablement à la clôture des enquêtes. Mais ils rappellent que les cadres réglementaires supposent de plus en plus que les organisations sachent répondre à des questions simples sur le contenu véhiculé par email : qu’est-ce qui est sorti de l’organisation, quand, et sous quel accès. Une plateforme conçue autour de la conformité réglementaire et de l’échange gouverné de contenu existe pour rendre ces réponses accessibles à la demande, et non à reconstituer après coup. Le tableau de bord RSSI offre la visibilité en temps réel sur tous les canaux d’échange email et contenu, rendant cette capacité opérationnelle et non théorique.

Pour en savoir plus sur la réduction de l’exposition liée à l’email grâce à l’analyse gouvernée, au contrôle d’accès et à la traçabilité, réservez votre démo sans attendre.

Ressources complémentaires

• Article de blog Protégez vos contenus sensibles grâce à la sécurité email
• Article de blog Brief Comment optimiser la gouvernance, la conformité et la protection des contenus email
• Brief Étendez la visibilité et automatisez la protection de tous les emails sensibles
• Brief Améliorez Kiteworks Secure Email avec la passerelle de protection des e-mails (EPG)