Un correctif ferme la brèche mais ne dit rien des jours qui ont précédé
Quand une faille est attaquée avant qu’un correctif existe, installer le correctif vous indique que la brèche est fermée. Il ne vous dit pas si quelqu’un est déjà passé par là.
Illustration conceptuelle des 47 jours écoulés entre la première attaque et la divulgation dans le cas BeyondTrust. Un correctif ferme la faille mais ne montre pas si l’équipement est sain.
Un équipement de bordure est un système placé à la frontière de votre réseau et exposé à Internet. Les passerelles VPN, les outils d’assistance à distance, les passerelles de messagerie, les pare-feu et les répartiteurs de charge sont tous des équipements de bordure. Ils sont joignables depuis l’extérieur, ils disposent d’accès étendus, et beaucoup d’équipes ne voient pas grand-chose de ce qui s’y passe.
On appelle zero-day une faille que les attaquants exploitent avant que l’éditeur ait publié un correctif. Cet article s’appuie sur deux cas récents pour montrer ce qu’un correctif règle et ce qu’il ne règle pas. Il se termine par une méthode applicable à tout équipement de bordure exploité, et par une règle pour décider quand reconstruire plutôt que faire confiance.
Pourquoi les équipements de bordure attirent les attaquants
Un équipement de bordure est une bonne cible, pour trois raisons simples. Il est exposé à Internet par conception. Il détient souvent des identifiants stockés ou occupe une position de confiance dans votre réseau. Et il fonctionne généralement sous un système d’exploitation verrouillé, si bien que vous ne pouvez pas facilement y installer vos propres outils de surveillance.
Ce dernier point compte plus qu’il n’y paraît. Si vous ne pouvez pas inspecter l’équipement de l’intérieur, les vérifications de l’éditeur et vos journaux deviennent vos seules preuves. Les deux peuvent faillir, comme le montrent les deux cas suivants. Notre article précédent sur ce que signifie une fenêtre d’intrusion de 72 minutes (en anglais) explique pourquoi le temps qui s’écoule avant que vous ne remarquiez quelque chose compte autant.
Cas 1 : Ivanti Connect Secure, où une partie de la chaîne reste ouverte
Ivanti Connect Secure est une passerelle VPN. Le 13 octobre, Ivanti a publié un avis de sécurité concernant CVE-2026-104935, une faille qui permet à un attaquant de contourner l’authentification et d’exécuter des commandes sur l’équipement. La CISA l’a ajoutée le jour même à son catalogue Known Exploited Vulnerabilities. Ce catalogue recense les failles dont la CISA a confirmé l’utilisation dans des attaques réelles, et les agences fédérales doivent les corriger avant une date fixée, le 16 octobre pour celle-ci.
L’entreprise de sécurité Volexity a indiqué que l’attaquant avait commencé à exploiter la faille le 3 octobre contre l’appliance d’un client. Volexity a décrit cette appliance comme à jour de tous ses correctifs : elle exécutait la version 22.8R2.4, le build le plus récent disponible avant le correctif. Il s’agit d’un seul incident ; il montre donc que la faille a été exploitée avant sa divulgation. Il ne dit pas à quelle échelle elle l’a été, et Ivanti indique seulement qu’un nombre limité de clients ont été touchés. Les versions corrigées comprennent 22.8R2.5, 25.1.1.2, 25.1.3.0 et 25.1.3.1, selon le résumé de l’avis publié par Rapid7.
Deux détails font de ce cas une bonne leçon. D’abord, la chaîne d’attaque comporte plusieurs étapes. Volexity a signalé une étape distincte d’élévation de privilèges, qui porte l’accès au niveau root, que le correctif ne couvrait pas au moment de la divulgation. Selon les articles consacrés au rapport, elle n’a pas d’identifiant CVE public. Volexity a indiqué qu’un correctif arriverait dans une prochaine version « dans les semaines à venir ». Pour l’instant, « corrigé » n’est donc vrai qu’en partie.
Ensuite, l’attaque a laissé peu de traces. Volexity n’a trouvé ni porte dérobée ni web shell. Le code d’exploitation et l’étape root se sont exécutés principalement en mémoire, et les données de configuration modifiées ont été restaurées ensuite, si bien que l’Integrity Checker Tool d’Ivanti n’a pas détecté les changements. Ivanti conseille toujours à ses clients d’exécuter cet outil régulièrement. Volexity a aussi constaté que l’attaquant avait supprimé de manière sélective des entrées des journaux de débogage et d’audit de l’appliance, et précise que l’efficacité réelle de ce nettoyage n’est pas entièrement établie. Ivanti indique que peu d’indicateurs de compromission étaient disponibles au moment de la divulgation, et Volexity en a publié quelques-uns, tirés du seul incident sur lequel elle a enquêté.
La leçon est simple. Un numéro de version corrigée vous dit ce que l’équipement exécute aujourd’hui. Il ne peut pas vous dire ce qui s’est passé avant, et un résultat sain fourni par l’outil de vérification de l’éditeur ou par les journaux de l’équipement lui-même ne suffit pas à lui seul.
Alternative textuelle accessible pour cette figure
Les deux failles ont été exploitées avant leur divulgation. La chronologie va du 29 août au 15 octobre 2026 sur une même échelle, avec des graduations au 29 août, au 29 septembre et au 15 octobre.
BeyondTrust Remote Support : l’exploitation a commencé le 29 août, un correctif a été publié le 8 octobre et la faille a été divulguée le 15 octobre. Cela fait 47 jours d’exploitation avant la divulgation.
Ivanti Connect Secure : l’exploitation a commencé le 3 octobre et la faille a été divulguée le 13 octobre, 10 jours plus tard. L’étape d’élévation de privilèges root n’était toujours pas corrigée au moment de la divulgation.
Cas 2 : BeyondTrust Remote Support, où la recherche remonte au mois d’août
BeyondTrust Remote Support permet au personnel d’assistance de prendre le contrôle de l’ordinateur d’autres personnes. Il stocke des identifiants dans un coffre-fort pour que ce personnel puisse se connecter à des systèmes au nom d’un utilisateur, ce qui lui donne beaucoup de valeur aux yeux d’un attaquant. CVE-2026-102764 est une faille de téléversement de fichiers sans authentification : une personne extérieure peut déposer un fichier sur l’équipement sans se connecter. Elle touche les versions jusqu’à 26.2.3.
BeyondTrust indique que la première attaque a eu lieu le 29 août. L’éditeur a publié le correctif le 8 octobre, ses clients SaaS étant corrigés automatiquement, et a divulgué la faille le 15 octobre. Selon notre décompte, cela fait 47 jours entre la première attaque et la divulgation. BeyondTrust dit avoir connaissance de deux clients touchés : là aussi, le nombre de cas connus est faible.
Google attribue cette activité à un groupe qu’il nomme ARMORY CASTLE, anciennement suivi selon lui sous le nom UNC5221, et le décrit comme un acteur d’espionnage présumé lié à la Chine. C’est l’évaluation des éléments par Google, pas une conclusion que nous pouvons confirmer nous-mêmes.
Ce que les attaquants ont fait une fois entrés est la partie la plus instructive. Selon Google, ils ont installé un web shell environ onze minutes après la première requête d’exploitation. Ils ont créé une porte dérobée root, tenté de récupérer des identifiants dans le coffre-fort, ajouté un script de persistance qui survit à un redémarrage, et supprimé les journaux de l’appliance, du serveur web et de l’application. Google affirme qu’une persistance de ce type survit aussi à une réinitialisation de la configuration.
Les recommandations de Google en découlent. Préservez les preuves avant de modifier quoi que ce soit. Si la compromission est confirmée ou si vous ne pouvez pas l’exclure, redéployez à partir d’une image saine et entièrement corrigée, car les clients ne peuvent pas auditer le système de fichiers de l’appliance. Ne renouvelez les identifiants qu’après le correctif ou la reconstruction, car de nouveaux identifiants saisis sur un équipement que l’attaquant contrôle encore sont eux aussi exposés.
Collectez les journaux des systèmes qui entourent l’équipement, comme le pare-feu et le proxy inverse, car les journaux présents sur l’équipement ont pu être supprimés. BeyondTrust fait la même mise en garde : les copies conservées hors de l’appliance sont souvent la seule trace restante.
La leçon : votre fenêtre d’investigation commence à la première date d’exploitation, pas à la date de publication du correctif. Les journaux de l’équipement lui-même sont des preuves fragiles si l’attaquant en a eu le contrôle.
Des cas plus modestes, des leçons plus modestes
Un premier correctif n’est pas toujours complet. AhsayCBS, un serveur de sauvegarde, présentait deux failles que les attaquants ont enchaînées : un contournement de l’authentification et une injection de commandes qui s’exécute en tant que SYSTEM. Help Net Security a rapporté que les correctifs antérieurs étaient incomplets et que les builds corrigés sont v10.3.4.45 et v9.15.2.70. Si vous avez appliqué un build antérieur puis êtes passé à autre chose, vérifiez que vous utilisez bien le build corrigé. Selon les rapports, des attaquants ont implanté des web shells et des mineurs de cryptomonnaie sur des serveurs exposés, et Huntress a documenté ces attaques le 8 octobre.
D’autres failles récentes d’équipements de bordure montrent pourquoi les numéros de build exacts et la rapidité comptent toujours, même sans signe de compromission antérieure. Citrix est un cas récurrent, et notre article sur les zero-days NetScaler de septembre (en anglais) couvre les failles précédentes.
| Produit | Ce qui s’est passé | Ce qu’il faut en retenir |
|---|---|---|
| Citrix NetScaler (CVE-2026-107406) | Une faille critique de dépassement de mémoire dans les configurations SAML, notée 9,5 en CVSS v4 et publiée le 8 octobre. Corrigée dans 14.1-73.46 et 13.1-64.29 ou versions ultérieures. Le bulletin indique comme touchées les versions 14.1-73.37 à 14.1-73.41 et 13.1-64.23 à 13.1-64.28, et ne précise pas si la faille est exploitée. | Un build récent peut encore être touché. Comparez votre build exact avec le bulletin le plus récent. |
| Cisco Secure Email Gateway (CVE-2026-76519) | CVSS 9,8, aucune solution de contournement, exploitée. Corrigée dans AsyncOS 16.5.0-780 sur la branche 16.5. Ajoutée par la CISA à son catalogue le 14 octobre. L’avis de Cisco indique qu’un attaquant disposant d’un accès root peut dissimuler des preuves sur l’équipement : vérifiez donc les journaux du pare-feu et du réseau situés hors de celui-ci, et préservez les données forensiques avant la mise à niveau. Pour une appliance virtuelle compromise, il recommande de déployer une nouvelle VM sur une version corrigée sans importer l’ancienne configuration. | L’éditeur lui-même recommande d’abord les preuves, puis une reconstruction, puis de nouveaux identifiants. |
| Palo Alto PAN-OS (CVE-2026-0322) | CVSS 8,6, « exploitation très limitée » observée, aucune solution de contournement connue. La faille touche l’interface de gestion, et Palo Alto conseille d’en limiter l’accès à des adresses internes de confiance ou à un serveur de rebond (jump box). | Gardez les interfaces de gestion hors d’Internet. |
Une méthode à suivre
Lorsqu’un équipement de bordure que vous gérez est cité dans un avis portant sur une faille exploitée, suivez ces étapes dans l’ordre.
- Corriger ou isoler. Appliquez la version corrigée. Si aucun correctif n’existe encore, restreignez l’accès à l’équipement et appliquez les mesures d’atténuation de l’éditeur.
- Préserver les preuves avant toute modification. Faites un instantané ou une copie du disque et de la mémoire si vous le pouvez. Collectez les journaux du pare-feu, du proxy et de tout serveur de journalisation.
- Trouver la première date d’exploitation. Lisez les rapports de l’éditeur et des chercheurs. Votre fenêtre de recherche va de cette date à aujourd’hui.
- Remonter toute cette fenêtre. Cherchez dans les journaux conservés hors de l’équipement. Recherchez les indicateurs publiés par les chercheurs. Considérez toute interruption dans le transfert des journaux comme un signal d’alerte.
- Décider : faire confiance ou reconstruire. Voir la règle ci-dessous.
- Renouveler les identifiants une fois l’équipement sain. Commencez par les comptes administrateur de l’équipement lui-même. Renouvelez ensuite tout ce qu’il stockait ou servait d’intermédiaire pour transmettre, y compris les secrets d’API, les comptes de service et tout mot de passe qui y a été saisi.
Quand reconstruire et quand faire confiance
Reconstruire chaque équipement après chaque avis n’est pas réaliste. Voici la règle que nous suggérons. Elle relève de notre jugement, s’appuie sur les recommandations de Google concernant BeyondTrust, et n’est pas une norme publiée.
Reconstruisez à partir d’une image saine si la compromission de l’équipement est confirmée. Reconstruisez également si l’exploitation a commencé avant la date à laquelle vous avez appliqué le correctif et que vous ne pouvez pas démontrer que votre équipement n’a pas été atteint. Cette seconde condition compte surtout pour les appliances que vous ne pouvez pas inspecter de l’intérieur.
Vous pouvez raisonnablement faire confiance à l’équipement après correction si trois conditions sont réunies. Il n’était pas exposé à Internet pendant la fenêtre, ou vous disposez de journaux indépendants qui ne montrent aucune activité correspondante. Ni l’éditeur ni les chercheurs ne signalent d’accès qui survive au correctif. Et vous renouvelez les identifiants que l’équipement détenait.
Ce que nous savons, et ce que nous ignorons
| Catégorie | Énoncé |
|---|---|
| Fait | La CISA classe comme exploitées la faille Ivanti (13 octobre) et la faille BeyondTrust (16 octobre). BeyondTrust a confirmé une exploitation depuis le 29 août et a publié un correctif le 8 octobre. |
| Rapport de chercheurs | Selon Volexity, l’attaque contre Ivanti s’est déroulée principalement en mémoire, a échappé à l’outil de vérification d’intégrité et a supprimé des entrées de journaux. Selon Google, les attaquants de BeyondTrust ont supprimé des journaux et installé un mécanisme de persistance. |
| Notre déduction | Toute appliance exposée pendant une fenêtre d’exploitation doit être considérée comme peut-être atteinte jusqu’à preuve du contraire. |
| Inconnu | Si Ivanti a désormais corrigé l’étape d’élévation de privilèges. Le nombre d’organisations touchées au-delà des cas décrits par les éditeurs. |
Jusqu’où approfondir le sujet
Connaître : La plupart des développeurs et des managers n’ont besoin que de l’idée. Un correctif ferme une faille et n’efface pas une intrusion. Demandez à votre équipe de sécurité si les failles exploitées sont vérifiées en remontant jusqu’à la date de la première attaque.
Appliquer : Si vous gérez des VPN, des passerelles, des outils d’assistance à distance ou des serveurs de sauvegarde, vous avez besoin de la méthode ci-dessus. Vous devez savoir lire un avis, trouver la première date d’exploitation, préserver les preuves, vérifier les journaux conservés hors de l’équipement et décider d’une reconstruction.
Maîtriser : Si vous êtes responsable de la réponse aux incidents ou de l’architecture, vous devez aussi concevoir en tenant compte de ce risque. Transférez les journaux de chaque équipement de bordure vers l’extérieur en quasi temps réel. Gardez les interfaces de gestion hors d’Internet. Conservez des images saines et des procédures de restauration testées, pour qu’une reconstruction prenne des heures et non des semaines.
Ce que vous pouvez ignorer pour l’instant
Vous n’avez pas besoin de retenir les noms de logiciels malveillants, les noms de groupes ou les chemins de fichiers cités dans ces rapports. Ils changent à chaque incident, et les indicateurs publiés sont utiles à une équipe de traque des menaces, pas à un lecteur non spécialiste. Ce qui dure, c’est la forme de la réponse.
Une prochaine étape concrète
Choisissez un équipement de bordure que vous gérez et répondez à trois questions. Où vont ses journaux, et sont-ils stockés à un endroit qu’un attaquant présent sur l’équipement ne pourrait pas atteindre ? En combien de temps pourriez-vous le reconstruire à partir d’une image saine ? Quels identifiants détient-il ? Si vous ne pouvez pas répondre aux trois aujourd’hui, cette lacune compte davantage que le prochain correctif.
Pour aller plus loin
- Volexity sur la chaîne de zero-days Ivanti Connect Secure, pour les étapes de l’attaquant, l’altération des journaux et les indicateurs.
- Le billet d’Ivanti sur sa mise à jour de sécurité d’octobre 2026, pour la déclaration de l’éditeur et le lien vers son avis.
- Rapid7 sur Ivanti Connect Secure CVE-2026-104935, pour les versions corrigées et l’inscription au catalogue de la CISA.
- Avis de sécurité BeyondTrust BT26-05 et le billet de blog associé, pour les versions, les dates et le correctif.
- Google Threat Intelligence : ARMORY CASTLE exploits BeyondTrust, pour les étapes de l’intrusion et les recommandations de reconstruction et de renouvellement des identifiants.
- Avis de Cisco sur CVE-2026-76519, pour la vérification de compromission et les étapes de rétablissement.
- Avis de Palo Alto Networks sur CVE-2026-0322, pour les versions corrigées et les mesures d’atténuation partielles.
- Bulletin Citrix CTX697191, pour les builds NetScaler exacts touchés et corrigés.
- Help Net Security sur les ajouts de la CISA, pour les détails sur Ahsay et les dates d’inscription au KEV.
- Le catalogue Known Exploited Vulnerabilities de la CISA, pour le statut actuel et les échéances de chaque faille.
Les faits présentés dans cet article ont été vérifiés les 18 et 19 octobre 2026. Les éditeurs peuvent publier d’autres correctifs et précisions : consultez les sources ci-dessus avant d’agir.