VPN, pare-feux, ADC : pourquoi les équipements réseau périmètre sont devenus la cible n°1 des APT

Fortinet, Citrix, Ivanti, Palo Alto, WatchGuard, SonicWall, F5 — ces noms reviennent en boucle dans les rapports d'incidents majeurs depuis 2023. Ce n'est pas une coïncidence. Les équipements réseau périmètre sont devenus le vecteur d'intrusion initial le plus utilisé par les APT dans le monde entier. Et la plupart des organisations n'ont pas encore adapté leur doctrine de sécurité à cette réalité.

Le constat : les APT ont changé de méthode d'entrée

Pendant des années, le vecteur d'attaque initial dominant dans les compromissions sophistiquées était le spear phishing — un e-mail ciblé qui convainquait un employé de cliquer sur un lien ou d'ouvrir une pièce jointe. C'est encore une méthode courante, mais quelque chose a changé structurellement depuis 2022-2023.

Les groupes APT — qu'ils soient étatiques comme Volt Typhoon, Salt Typhoon, Sandworm, ou APT40, ou qu'ils soient à motivation financière comme Lockbit, Akira, ou Play — ont massivement pivoté vers l'exploitation directe d'équipements réseau périmètre exposés sur Internet. La raison est simple : c'est plus efficace, plus furtif, et permet un accès initial sans dépendre d'une action humaine.

Les chiffres parlent d'eux-mêmes. Selon le rapport Mandiant M-Trends 2025, les équipements réseau (VPN, firewalls, load balancers, gateways) ont représenté 32 % des vecteurs d'accès initial dans les incidents investigués — contre 22 % en 2023 et 14 % en 2021. Le phishing représente encore 31 % mais décline. Pour la première fois, les équipements périmètre dépassent l'humain comme point d'entrée privilégié dans les attaques avancées.

Cisa a publié en 2025 une liste de 15 CVE les plus exploitées dans les compromissions de systèmes gouvernementaux américains. Parmi elles, 9 concernaient des équipements réseau : 4 Fortinet, 2 Ivanti, 1 Citrix, 1 F5 et 1 Palo Alto. Cette concentration est frappante et reflète une tendance mondiale observable dans les données de Shodan, Greynoise et les rapports d'incidents traités par les CERTs nationaux.

Le catalogue des compromissions 2024-2026 : un palmarès alarmant

Pour mesurer l'ampleur du phénomène, il faut regarder les incidents concrets survenus sur les 24 derniers mois. Ce panorama n'est pas exhaustif, mais il illustre l'étendue du problème.

Fortinet FortiGate (2024-2026) : La CISA a alerté en janvier 2024 sur l'exploitation de CVE-2022-42475 (CVSS 9.3) par des acteurs étatiques qui avaient maintenu des accès persistants même après les correctifs, en utilisant des webshells "SymLink" survivant aux mises à jour. En 2025, l'opération FortiBleed (CVE-2025-47575, CVSS 9.8) a exposé les configurations de 86 644 pare-feux FortiGate. En octobre 2026, le FortiMail zero-day CVE-2026-104286 (CVSS 9.8) faisait l'objet d'une exploitation active sans patch disponible. Fortinet est devenu le fournisseur le plus ciblé par les APT en termes de volume d'incidents documentés.

Ivanti Connect Secure et Policy Secure (2024-2026) : CVE-2023-46805 et CVE-2024-21887, deux zero-days Ivanti exploités en chaîne dès janvier 2024, ont conduit à des compromissions massives chez des organisations gouvernementales, de défense et de santé dans le monde entier. Mandiant et CISA avaient estimé que des milliers d'organisations avaient été touchées. En 2026, CVE-2026-10523 (CVSS 9.9, bypass d'authentification administrateur) a démontré que le problème structural d'Ivanti n'était pas résolu. Le pattern est identique à chaque fois : faille préauthentification permettant l'exécution de commandes ou l'accès à la configuration.

Citrix NetScaler ADC et Gateway (2023-2026) : "Citrix Bleed" (CVE-2023-4966, CVSS 9.4) en 2023 avait permis à des ransomwares comme LockBit de compromettre des milliers d'organisations en exfiltrant des tokens de session valides. En 2026, le cycle recommence avec CVE-2026-88771 et CVE-2026-88772, deux RCE CVSS 9,5 exploitées en zero-day avant même la divulgation de Citrix. La répétitivité des incidents sur cette famille de produits interroge sur la qualité du cycle de développement sécurisé (SDL) chez Citrix.

Palo Alto Networks PAN-OS (2024) : CVE-2024-3400 (CVSS 10.0) en avril 2024, une injection de commande dans GlobalProtect Gateway exploitée à grande échelle par le groupe UTA0218 selon Volexity. Palo Alto a réagi rapidement mais les données CISA indiquaient que plusieurs centaines d'équipements avaient été compromis avant le patch.

WatchGuard (2026) : CVE-2026-13043 (accès mémoire kernel sans authentification) a conduit à l'insertion de backdoors dans plusieurs centaines d'appliances Firebox dans des organisations industrielles et de santé européennes et américaines.

Ce qui frappe dans ce catalogue, c'est la présence de tous les grands noms du marché réseau. Il n'y a pas de fournisseur "safe" — il y a des fournisseurs avec des délais de détection et de correction plus ou moins bons, et des organisations avec des processus de patch plus ou moins rapides.

Pourquoi ces équipements sont-ils si vulnérables — et si précieux pour les attaquants ?

La question mérite une analyse technique honnête. Ces équipements ne sont pas vulnérables parce que leurs fabricants sont incompétents. Ils sont vulnérables pour des raisons structurelles qui sont difficiles à résoudre rapidement.

1. Une surface d'attaque exposée par construction. Un firewall, un VPN gateway ou un ADC doit par définition être accessible depuis Internet. Il ne peut pas être caché derrière d'autres protections — c'est lui la protection. Cela signifie que toute vulnérabilité dans son code d'exposition Internet est directement atteignable par n'importe quel acteur dans le monde. À l'inverse, une vulnérabilité dans un serveur interne nécessite un accès initial préalable pour être exploitée.

2. Des systèmes hétérogènes accumulant des couches de code legacy. NetScaler existe depuis 1999. FortiOS depuis 2002. Ces systèmes ont accumulé 20 à 25 ans de code C et C++, souvent avec des composants tiers datant d'une époque où la sécurité n'était pas la priorité. Les vulnérabilités de type buffer overflow et memory corruption — responsables de la majorité des RCE critiques — sont caractéristiques de cet héritage de code non géré (unsafe languages). Réécrire ces systèmes en Rust ou en Go prendrait des années et des centaines de millions de dollars.

3. Une complexité fonctionnelle extrême. Un ADC moderne gère simultanément : terminaison TLS/SSL, authentification SAML/OAuth/RADIUS/LDAP, proxification HTTP/2 et HTTP/3, inspection de contenu applicatif, équilibrage de charge, compression, mise en cache. Chaque fonctionnalité est une surface d'attaque. La combinaison de ces fonctionnalités crée des interactions complexes que les tests de sécurité standards ne couvrent pas exhaustivement. CVE-2026-107406 dans le composant SAML de NetScaler est un exemple parfait : une fonctionnalité d'authentification ajoutée pour répondre aux besoins des grandes entreprises, qui introduit un vecteur d'attaque non anticipé.

4. Des cycles de mise à jour lents côté clients. Contrairement aux applications web modernes où un déploiement peut se faire en minutes, patcher un équipement réseau critique peut nécessiter une fenêtre de maintenance planifiée plusieurs jours ou semaines à l'avance, une validation de compatibilité, et parfois un redémarrage entraînant une interruption de service. Cette friction opérationnelle crée des fenêtres d'exposition prolongées. Lors de l'incident Ivanti de janvier 2024, plusieurs organisations gouvernementales américaines patchées avaient découvert pendant l'analyse forensique que leur équipement avait été compromis dans les 72 heures suivant la divulgation, avant même que leur processus de patch interne soit déclenché.

5. La valeur stratégique de l'accès obtenu. Compromettre un équipement réseau périmètre donne accès à l'ensemble du trafic transitant par lui — incluant les tokens d'authentification, les sessions VPN actives, les credentials en transit. C'est structurellement différent de compromettre un poste de travail ou même un serveur applicatif. Un firewall ou un ADC compromis permet potentiellement d'intercepter le trafic de toute l'organisation sans déclencher d'alertes sur les systèmes de détection orientés endpoint ou réseau interne.

La réponse des constructeurs : en retard et insuffisante

Je vais être direct : la qualité du cycle de développement sécurisé (SDL) de plusieurs grands constructeurs réseau est insuffisante pour le niveau de menace actuel. Ce n'est pas une opinion gratuite — c'est une conclusion que l'on peut tirer de l'analyse des patterns de vulnérabilités observés.

Quand Fortinet corrige un buffer overflow dans FortiOS et qu'un chercheur trouve 3 variantes du même bug dans le même composant 6 mois plus tard, cela indique un problème systémique de code review et de fuzzing, pas un incident isolé. Quand Citrix corrige "Citrix Bleed" en 2023 et que des RCE critiques dans des composants similaires réapparaissent en 2026, la question du SDL se pose légitimement.

Les constructeurs qui progressent en matière de sécurité adoptent des approches mesurables : revues de code assistées par outils d'analyse statique sur l'ensemble du codebase (pas seulement les nouvelles fonctionnalités), programmes de fuzzing continus sur toutes les interfaces d'entrée réseau, adoption progressive de langages memory-safe pour les nouveaux composants, et surtout, des programmes de bug bounty avec des récompenses significatives pour les vulnérabilités critiques. Palo Alto, par exemple, a renforcé son SDL après l'incident de 2024 et a publié un rapport de transparence documentant ses améliorations — une démarche exemplaire que les autres devraient suivre.

Par ailleurs, la communication autour des incidents laisse souvent à désirer. Citrix avait initialement minimisé l'impact de "Citrix Bleed" avant que les investigations tierces ne révèlent l'ampleur réelle. Ivanti a mis plusieurs semaines à fournir des indicateurs de compromission précis pour les failles de 2024. Cette opacité initiale ralentit la réponse des organisations affectées et aggrave les dommages.

Ce que ça change concrètement pour les RSSI

Cette tendance de fond impose de revoir plusieurs doctrines établies en matière de sécurité périmètre.

Doctrine 1 : le périmètre réseau est une ligne de défense, pas un actif à sécuriser. Pendant longtemps, les équipements réseau étaient considérés comme des outils de sécurité, pas comme des cibles de sécurité. Cette vision est obsolète. Vos firewalls, VPN gateways et ADC doivent faire l'objet du même niveau de surveillance, de gestion des vulnérabilités et de réponse aux incidents que vos serveurs et endpoints. Ils doivent être inclus dans vos scans de vulnérabilités, dans vos périmètres de pentest, et dans vos runbooks de réponse aux incidents.

Doctrine 2 : patcher sous 30 jours est suffisant. Pour les équipements périmètre critiques, exposés sur Internet, ce délai est inacceptable quand il s'agit d'une RCE préauthentification activement exploitée en zero-day. CVE-2026-88771 était exploitée avant la divulgation. À la date de divulgation, votre fenêtre de patch est déjà potentiellement dépassée. Les organisations les plus matures adoptent maintenant une doctrine de patch d'urgence sous 24-48 heures pour les RCE et bypass d'authentification critiques sur les équipements périmètre exposés Internet.

Doctrine 3 : la segmentation réseau protège même si le périmètre tombe. C'est théoriquement vrai, mais les incidents récents montrent que des APT qui compromettent un équipement périmètre restent souvent dormants pendant des semaines ou des mois avant de se déplacer latéralement, pour une raison simple : ils collectent d'abord les credentials transitant par l'équipement compromis (VPN, SAML tokens, sessions authentifiées) pour se déplacer ensuite avec des identités légitimes qui échappent à la détection par segmentation.

Actions concrètes à prendre dès maintenant :

• Inventorier tous vos équipements réseau périmètre et leurs versions firmware, et les intégrer dans votre processus de veille CVE avec une priorité haute
• Mettre en place une détection spécifique aux équipements réseau dans votre SIEM : anomalies d'accès aux interfaces de management, connexions sortantes depuis les équipements eux-mêmes, changements de configuration non planifiés
• Restreindre l'accès aux interfaces de management à un réseau d'administration dédié, jamais exposé sur Internet
• Tester régulièrement l'intégrité de vos équipements via les outils de vérification fournis par les constructeurs
• Inclure vos équipements réseau dans le périmètre de vos exercices de réponse aux incidents — savoir quoi faire quand un FortiGate ou un NetScaler est compromis, et le savoir à l'avance

Le marché va-t-il s'autoréguler ?

Une question que je me pose souvent avec mes clients : le marché va-t-il créer des incitations suffisantes pour que les constructeurs réseau améliorent structurellement la sécurité de leurs produits ?

Les signaux sont mitigés. D'un côté, plusieurs acheteurs gouvernementaux américains et européens commencent à inclure des critères de maturité en sécurité dans leurs appels d'offres — délais de correction des CVE critiques, transparence sur les incidents, certification de produits. CISA a publié en 2024 son programme "Secure by Design" qui presse les constructeurs à réduire les classes entières de vulnérabilités (memory safety notamment). Ces initiatives vont dans le bon sens.

De l'autre côté, dans le secteur privé, le prix reste souvent le critère dominant, et la "dette sécurité" accumulée dans des produits n'est pas visible dans un catalogue. Un client peut acheter un FortiGate ou un NetScaler en comparant les fonctionnalités et le TCO, sans avoir de visibilité sur le nombre de CVE critiques publiées sur ce produit au cours des 3 dernières années. Un "score de sécurité constructeur" standardisé et public serait une innovation utile — des initiatives comme celles de CISA sur les KEV (Known Exploited Vulnerabilities) vont dans ce sens indirectement.

En attendant une hypothétique régulation ou autorégulation du marché, la réalité opérationnelle est que les RSSI doivent gérer le risque avec les outils disponibles : patch rapide, monitoring des équipements réseau comme des actifs à risque, et vérification d'intégrité systématique.

Conclusion

La prochaine grande compromission dans votre secteur passera probablement par un équipement réseau périmètre — qu'il s'agisse d'un Citrix NetScaler, d'un FortiGate, d'un Ivanti Connect Secure ou d'un équipement concurrent. La question n'est pas si cela arrivera, c'est quand et si votre organisation sera prête à le détecter rapidement et à le contenir.

Les organisations qui s'en sortent le mieux ne sont pas nécessairement celles qui ont les meilleurs équipements — ce sont celles qui ont adapté leurs processus à la réalité de la menace actuelle : patch d'urgence sous 48h pour les RCE critiques, monitoring des équipements réseau dans le SIEM, vérifications d'intégrité post-patch, et exercices de réponse aux incidents incluant le scénario "équipement périmètre compromis".