:quality(90):no_upscale()){kind=logo}
Quatre attaques visant des passerelles en cinq semaines mettent en évidence le manque de coordination entre les attaques et les mesures de riposte
STATUT : Modèle d'exploitation actif GREVEITÉ : 8/10 PUBLIC CIBLE : Responsables de la sécurité au sein des administrations publiques, du secteur de la défense et des infrastructures critiques
12 octobre 2026
·Blog
·Communications sécurisées
:quality(90):no_upscale())
Au cours des cinq dernières semaines, des pirates ont exploité des vulnérabilités critiques dans quatre catégories de passerelles largement déployées, notamment la messagerie électronique, l’accès à distance, l’échange sécurisé de contenu et la connectivité via des protocoles OT. Trois de ces incidents concernaient des vulnérabilités susceptibles de permettre un contrôle au niveau root. Pris dans leur ensemble , ces événements mettent en évidence deux défis distincts en matière de coordination que la planification des interventions distingue rarement : communiquer alors qu’un pirate peut déjà contrôler des canaux de confiance, et communiquer après que ces canaux ont été délibérément isolés pour contenir l’attaque.
Que s'est-il passé ?
Ces vulnérabilités ont engendré deux problèmes de coordination : la communication pendant une attaque en cours et la communication pendant la phase d'isolement destinée à y mettre fin.
Le 21 août, la CISA a ajouté la faille CVE-2026-73570 de Zimbra à son catalogue des vulnérabilités connues pour avoir été exploitées, après que des pirates l'aient exploitée avant sa divulgation publique.1 Fin août, Shadowserver avait recensé 274 instances compromises, les pirates utilisant l'identité SSH de confiance de Zimbra pour se déplacer d'un nœud à l'autre au sein du cluster,2 ce qui illustre le premier problème : la coordination via un canal que l'attaquant contrôle déjà.
Trois semaines plus tard, Citrix a confirmé l'existence de deux vulnérabilités « zero-day », CVE-2026-88771 et CVE-2026-88772, toutes deux notées 9,5, qui faisaient l'objet d'une exploitation active sur les appliances NetScaler ADC et Gateway.3 Mandiant et le Threat Intelligence Group de Google ont attribué cette exploitation à des acteurs soupçonnés d'être liés à des États.4 Ces deux failles permettent d'obtenir un contrôle total au niveau root de l'appareil.5
Fin septembre, un fournisseur de services d'échange sécurisé de contenus a mis hors ligne ses systèmes destinés à la clientèle après avoir reçu des informations indiquant une menace crédible.7 Cette mise hors service préventive a duré environ neuf heures et illustre le type de mesure d’isolement souvent recommandé par les directives de défense lorsque le risque ne peut être immédiatement écarté. Pendant toute la durée de cette mesure, les services de coordination qui fonctionnaient normalement via ces systèmes étaient indisponibles.
Le 2 octobre, Moxa a révélé l'existence de deux vulnérabilités dans ses passerelles de protocole MGate, utilisées dans les secteurs de l'énergie, de l'eau, de l'industrie et des administrations publiques.6 L'une d'entre elles, notée 9,4, permet à un utilisateur disposant d'un accès en lecture seule de corrompre la mémoire d'un appareil, tandis que l'autre ne dispose pas encore de correctif au niveau du micrologiciel. Il s'agit précisément des passerelles que la CISA et les recommandations internationales conseillent aux opérateurs d'isoler dès les premiers signes de compromission. Ces recommandations s'arrêtent à la périphérie du réseau et ne fournissent aucune instruction sur la manière de maintenir la coordination une fois celle-ci fermée.
Dans les quatre cas, les deux mêmes lacunes se répètent. Lorsqu’un attaquant est susceptible de contrôler le canal de confiance, comme dans les cas de Zimbra et de NetScaler, toute coordination via ce canal risque de se faire à la vue de l’attaquant. Dès qu’ une organisation isole un système compromis ou à risque, comme le recommandent les directives relatives aux technologies opérationnelles (OT) pour les équipements de type Moxa, toute coordination qui reposait sur ce système disparaît, à moins qu’un canal distinct n’existe déjà.
Conclusion | Ce que cela signifie | Conséquence opérationnelle | Question ouverte |
Trois des quatre incidents concernaient des vulnérabilités qui conféraient, ou pouvaient permettre d'étendre, un contrôle de niveau root sur l'infrastructure critique des passerelles.7 | Un pirate disposant d'un tel niveau d'accès peut surveiller ou manipuler tout ce qui transite par la passerelle, y compris toute coordination qui en dépend encore. | Utiliser les canaux du système compromis pour coordonner une riposte revient à risquer de le faire sous le regard de l'attaquant qui les contrôle. | Combien d'organisations exploitant une infrastructure de passerelle disposent d'un plan de coordination qui prévoit que la passerelle elle-même puisse être compromise, et non pas simplement indisponible ? |
Une organisation confrontée à une menace crédible a choisi de mettre hors service une infrastructure critique pendant plusieurs heures, ce qui illustre bien comment les procédures défensives standard peuvent créer un vide de coordination. | La stratégie défensive classique, qui consiste à isoler le système suspect, engendre un vide de coordination qui dure exactement aussi longtemps que l'isolement. | Une organisation qui ne dispose que d'un seul canal de coordination perd ce canal dès lors qu'elle prend la mesure de protection adéquate et isole le système sur lequel elle fonctionne. | Combien d'organisations disposent d'un canal de coordination distinct et éprouvé, prêt à l'emploi avant même d'avoir à isoler un système, plutôt que d'en improviser un pendant la fenêtre de maintenance ? |
Les failles de Moxa MGate affectent les passerelles de protocole que la CISA et les recommandations internationales enjoignent déjà aux opérateurs d'infrastructures critiques d'isoler dès les premiers signes de compromission. | Les recommandations en matière d'isolation pour les environnements OT traitent de la périphérie du réseau, mais ne précisent pas comment le personnel doit se coordonner une fois cette périphérie fermée. | Les équipes de terrain, le personnel de la salle de contrôle et les partenaires d'entraide ont besoin d'un plan de coordination qui tienne compte du fait que c'est le réseau OT lui-même qui pourrait être isolé, et pas seulement le réseau informatique. | Les plans actuels d'intervention en cas d'incident OT prévoient-ils un canal de coordination pour la « fenêtre d'isolation », ou seulement pour l'étape d'isolation elle-même ? |
Pourquoi est-ce important ?
Vieille Assomption | Réalité actuelle | Réponse de BlackBerry |
Si une passerelle est compromise, les canaux de communication existants de l'organisation peuvent toujours être utilisés pour coordonner la réponse, car la faille concerne les données et non les canaux. | Deux des quatre failles de sécurité de la passerelle ont permis aux attaquants d'obtenir un contrôle de niveau root, ce qui signifie que le canal existant correspond au système même que l'attaquant contrôle désormais. | BlackBerry® AtHoc® offre un canal de coordination indépendant de l'infrastructure faisant l'objet de l'enquête, ce qui évite que l'intervention ne passe par un système qui pourrait déjà être hostile. |
Mettre hors ligne un système compromis ou à risque constitue en soi une mesure défensive à part entière. | Une mise à l'arrêt préventive récente montre que l'isolation d'un système entraîne également l'isolation de toute coordination qui en dépendait auparavant, et ce pendant toute la durée de cette période d'isolation. | BlackBerry AtHoc est conçu pour fonctionner spécifiquement pendant les périodes d'isolation, offrant ainsi aux équipes un canal de coordination qui ne dépend pas du système en cours d'isolation. |
Les consignes d'isolation du réseau opérationnel (OT), qui préconisent de déconnecter le réseau dès qu'une intrusion est suspectée, constituent à elles seules une réponse complète. | La divulgation concernant Moxa concerne précisément la catégorie de passerelles OT que ces recommandations invitent les opérateurs à isoler, et ces recommandations s’arrêtent à la limite du réseau, sans donner d’instructions sur la manière dont le personnel doit continuer à se coordonner par la suite. | BlackBerry AtHoc et BlackBerry® SecuSUITE® étendent ce même principe de coordination hors bande aux environnements OT ; ainsi, isoler le réseau ne revient pas à isoler les personnes qui en dépendent. |
Mesures recommandées
IMMÉDIAT | Vérifiez l'état des correctifs sur toutes les plateformes concernées de votre environnement, notamment les passerelles de messagerie, l'infrastructure d'accès à distance, les systèmes d'échange sécurisé de contenu et les passerelles de protocole OT. Considérez toute instance non mise à jour et accessible depuis Internet comme une compromission active potentielle. |
IMMÉDIAT | Vérifiez si votre organisation dispose d'un canal de coordination qui reste accessible au cas où votre messagerie électronique ou votre système d'accès à distance serait coupé sans préavis. |
À COURT TERME | Mettre au point et tester explicitement un canal de coordination hors bande pour les deux scénarios suivants : fonctionnement alors qu'un système de confiance est susceptible d'être compromis, et fonctionnement après que ce système a été délibérément isolé. |
À COURT TERME | Étendre la planification de l'isolation et de la coordination aux environnements OT en particulier, étant donné que les recommandations actuelles en matière d'isolation des réseaux OT portent sur la périphérie du réseau, mais pas sur ce qu'il advient de la coordination une fois celle-ci mise en place. |
EN COURS | Considérez la durée pendant laquelle un canal de coordination doit rester opérationnel au cours d'une fenêtre d'isolation (plusieurs heures, voire davantage) comme une hypothèse de planification plutôt que comme un élément secondaire. |
Poste chez BlackBerry
Chacun de ces quatre incidents finit par être résolu soit en corrigeant la vulnérabilité, soit en isolant le système affecté. Aucune de ces deux mesures ne rétablit à elle seule la coordination. Un attaquant disposant d’un accès root sur une passerelle de confiance peut surveiller tout ce qui transite par celle-ci, et un système mis hors ligne pour bloquer cet attaquant entraîne dans sa chute la fonction de coordination. Ces deux scénarios soulignent la même exigence : un canal conçu pour continuer à fonctionner indépendamment du système compromis ou isolé, car le moment où une organisation a le plus besoin de ce canal peut bien être celui où le canal habituel n’est justement pas disponible.
Références :
1. Des pirates exploitent une faille SNMP de Zimbra pour exécuter du code à distance sans authentification (The Hacker News, article sur l'exploitation active de la vulnérabilité CVE-2026-73570, 20 août 2026).
2. Des pirates ont compromis plus de 270 serveurs Zimbra lors d'attaques en cours (BleepingComputer, article sur les compromissions de serveurs Zimbra recensées par Shadowserver, 25 août 2026).
3. Avertissement : deux failles « zero-day » de type RCE non corrigées dans Citrix NetScaler font actuellement l'objet d'une exploitation active (The Hacker News, Citrix confirme l'exploitation de failles « zero-day » dans NetScaler, 27 septembre 2026).
4. Se prémunir contre l'exploitation active des appliances ADC et passerelles Citrix NetScaler (Blog Google Cloud, rédigé par Mandiant, Google Threat Intelligence Group et Mandiant Services ; analyse et conseils de défense concernant l’exploitation active des vulnérabilités CVE-2026-88772 et CVE-2026-88771 de Citrix NetScaler, 29 septembre 2026).
5. Les failles « zero-day » de Citrix NetScaler mettent en évidence un risque récurrent d'accès root (TechTimes, analyse des schémas récurrents de vulnérabilités permettant l'accès root à NetScaler, 30 septembre 2026).
6. Les vulnérabilités de Moxa MGate mettent en danger les passerelles de protocoles industriels (SecurityOnline, couverture et analyse des vulnérabilités CVE-2026-86325 et CVE-2026-86326 de Moxa MGate, y compris les produits concernés, les niveaux de gravité et les recommandations de mitigation. 2 octobre 2026).
7. Kiteworks corrige une faille de sécurité de gravité maximale liée à l'injection de code (BleepingComputer, article du 1er octobre 2026 consacré à la vulnérabilité CVE-2026-54154 affectant Kiteworks Email Protection Gateway (EPG)).
:quality(90):no_upscale())