Trois ans. C'est le temps qu'il a fallu aux groupes APT les plus organisés du monde pour pivoter massivement vers une nouvelle cible de prédilection : vos équipements réseau périmètraux. VPN, firewalls, sandbox, contrôleurs d'accès — ces boîtiers noirs qui gardent la porte de vos systèmes d'information sont devenus l'angle d'attaque le plus rentable du moment. Ce n'est pas une coïncidence. C'est une stratégie documentée, répétée, et qui continue de faire des ravages parce que la majorité des organisations n'ont pas encore adapté leur posture défensive à cette réalité.

2024-2026 : trois ans de carnage sur les équipements réseau

Commençons par les faits. Depuis 2024, les appliances réseau concentrent une proportion croissante des CVE critiques exploitées in the wild. Ce n'est pas une impression — c'est documenté dans les catalogues KEV (Known Exploited Vulnerabilities) de la CISA, dans les rapports d'incidents des principaux acteurs de la réponse à incident (Mandiant, CrowdStrike, Rapid7), et dans les advisories des vendors eux-mêmes.

Tour d'horizon des incidents marquants depuis 2024 :

  • Ivanti Connect Secure (ex-Pulse Secure) : série de zero-days critiques en 2024 et 2025, exploitation par au moins cinq groupes APT distincts dont des acteurs liés à la Chine et à l'Iran, compromission documentée de milliers d'organisations dans le monde — y compris des agences gouvernementales américaines
  • Palo Alto Networks PAN-OS : CVE-2024-3400 (CVSS 10.0), zero-day exploité avant la publication du patch, command injection sans authentification donnant accès root à l'appliance ; suivi d'autres CVE critiques en 2025 sur GlobalProtect et le portail d'administration
  • Fortinet FortiOS/FortiGate : série de vulnérabilités SSL VPN exploitées depuis 2023, notamment CVE-2023-27997 (CVSS 9.8) et plusieurs failles ultérieures avec exploitation documentée par des groupes étatiques ; et en juillet 2026, double CVSS 9.8 dans FortiSandbox (CVE-2026-25089 et CVE-2026-26083, tous deux sous exploitation active CISA KEV)
  • Cisco ASA/FTD : multiples CVE critiques en 2024 sur les interfaces VPN, exploitation documentée par des groupes étatiques ciblant des infrastructures critiques
  • Juniper Networks : CVE-2026-21902 (CVSS 9.8), RCE root sur les routeurs PTX sous Junos Evolved, publiée en 2026
  • SonicWall SMA 1000 : CVE-2026-15409 (CVSS 10.0) et CVE-2026-15410, deux zero-days exploités depuis le 22 juin 2026 par l'acteur UTA0533, avec vol de credentials VPN et de graines TOTP — publiés le 14 juillet 2026

Ce n'est qu'un échantillon représentatif. Chaque trimestre depuis 2024, au moins un équipement réseau majeur a fait l'objet d'une exploitation zero-day ou critique à grande échelle. En 2025, les données Rapid7 indiquaient que les équipements réseau représentaient environ 30% des vecteurs d'intrusion initiale documentés dans les incidents répondus — une proportion largement supérieure à leur poids dans le parc de systèmes exposés sur Internet.

La question n'est plus "est-ce que mon VPN est une cible ?". La question est : "quand la prochaine CVE critique de mon équipement réseau sera-t-elle exploitée, et serai-je prêt ?"

Pourquoi les APT ciblent ces équipements en priorité

La réponse tient en trois mots : accès, confiance, invisibilité. Ces trois propriétés font des appliances réseau des cibles idéales que les APT ont appris à exploiter systématiquement.

L'accès direct. Un équipement VPN ou firewall périmétral est, par définition, exposé sur Internet et connecté au réseau interne. Il n'y a aucune couche défensive intermédiaire entre l'attaquant et l'appliance — c'est précisément son rôle de jouer ce rôle de frontière. Compromettre un VPN enterprise, c'est obtenir un accès direct au réseau interne sans traverser les défenses habituelles : pas d'IDS en amont, pas de proxy Web, pas de WAF applicatif, pas d'EDR. L'appliance est la porte. Les APT ont découvert qu'il est souvent plus simple d'avoir une copie de la clé que d'essayer d'escalader les murs. C'est une logique économique pure.

La confiance élevée dans l'architecture. Dans les architectures réseau, les équipements périmètraux bénéficient d'un statut particulier. Les règles de firewall sont typiquement configurées pour laisser passer leur trafic sans inspection supplémentaire. Les logs de ces équipements ne sont pas toujours corrélés dans les SIEM — ou, quand ils le sont, les analystes SOC ont tendance à les considérer comme du bruit de fond opérationnel. Une session VPN authentifiée depuis un équipement SonicWall ou Fortinet ne génère presque jamais d'alerte, même si les credentials utilisés ont été volés. Cette confiance implicite est une aubaine pour un attaquant : une fois le VPN compromis, le mouvement latéral passe sous le radar des systèmes de détection comportementale (UEBA) configurés pour les connexions VPN légitimes.

L'invisibilité structurelle. C'est peut-être l'avantage le plus sous-estimé. Ces appliances tournent sur des systèmes embarqués propriétaires — souvent une base Linux ou BSD fortement modifiée avec un firmware propriétaire. Les agents EDR (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) ne s'y installent pas. Les outils de monitoring système standard (Velociraptor, KAPE, osquery) ne les couvrent pas. Les outils forensics classiques n'y fonctionnent pas. Un attaquant qui installe un implant sur une appliance VPN peut y demeurer des mois, voire des années, sans être détecté — comme l'ont démontré plusieurs incidents impliquant des groupes APT étatiques sur des équipements Juniper, Cisco et Fortinet entre 2023 et 2025, où des backdoors ont été découverts rétrospectivement après des investigations approfondies.

À ces trois avantages s'ajoute un quatrième facteur accélérateur : la compression du délai d'exploitation. Le temps moyen entre la publication d'une CVE critique sur un équipement réseau et la première exploitation in the wild s'effondre. En 2022, ce délai moyen était de 28 jours selon les données Rapid7. En 2024, il était tombé sous 5 jours pour les CVE très médiatisées. En 2026, avec l'accélération de l'usage d'outils d'analyse automatisée par les acteurs offensifs, des exploits fonctionnels peuvent être développés en quelques heures après la publication d'un advisory bien documenté. Le cas SonicWall CVE-2026-15409 inverse même le paradigme : exploitation 22 jours avant la publication de l'advisory.

Le problème structurel que l'industrie évite de nommer

Il y a un éléphant dans la pièce que peu d'acteurs de l'industrie de la cybersécurité veulent nommer clairement : les équipements réseau des grands vendors sont, en moyenne, développés avec des pratiques de sécurité inférieures à celles des éditeurs de logiciels applicatifs les plus matures.

Plusieurs raisons structurelles expliquent cet écart. Premièrement, ces appliances tournent souvent sur des bases logicielles très anciennes, avec des couches applicatives qui n'ont pas été revues en profondeur depuis des années. La pression du time-to-market est énorme dans ce secteur dominé par quelques acteurs en compétition agressive, et les tests de sécurité approfondis — fuzzing systématique, revue de code approfondie, SAST/DAST, bug bounty — sont rarement appliqués avec la même rigueur que dans des éditeurs software-first.

Deuxièmement, la surface d'attaque de ces équipements est vaste et mal documentée publiquement : des centaines d'endpoints API internes, des mécanismes de mise à jour propriétaires, des services de debug souvent laissés actifs par défaut, des interfaces de gestion accessibles sur des ports non standards que peu d'administrateurs pensent à surveiller.

Troisièmement, et c'est peut-être le plus structurel, il y a une asymétrie d'information fondamentale : les vendors connaissent la qualité réelle de leur code, leurs clients ne la connaissent pas. En l'absence d'obligations légales de divulgation des pratiques de développement sécurisé (comme le préconise la directive NIS2 pour les systèmes critiques), les entreprises font confiance à la marque et au certificat Common Criteria ou CSPN — qui ne garantissent pas l'absence de vulnérabilités exploitables, seulement le respect d'un processus de développement à un instant T.

Le résultat concret : en 2026, des vendors avec des milliards de dollars de revenus annuels livrent encore des vulnérabilités de type "OS command injection sans authentification" (CVE-2026-25089, FortiSandbox) ou "SSRF sans authentification avec tunnel websocket vers localhost" (CVE-2026-15409, SonicWall SMA 1000). Ces classes de vulnérabilités sont documentées dans l'OWASP Top 10 depuis 2010. Les recommandations pour les éviter sont accessibles, connues, et gratuites. Leur présence dans des produits de sécurité vendus à prix premium en 2026 n'est pas acceptable — mais elle est réelle, et vos équipes doivent en tenir compte dans leur stratégie de gestion des risques.

Ce que votre SOC ne voit pas sur ces équipements

Au-delà du problème des vulnérabilités, il y a un deuxième problème tout aussi critique : le monitoring des appliances réseau est structurellement lacunaire dans la plupart des SOC, même les plus bien équipés.

Les logs exportés par les équipements réseau vers votre SIEM ou votre syslog sont généralement les logs de niveau applicatif : connexions VPN authentifiées, sessions firewall, alertes IDS/IPS. Ces logs sont les journaux de l'activité "normale" — la route principale. Ce qu'ils ne couvrent généralement pas :

  • Les accès à l'interface d'administration web (loggés en local sur l'appliance, rarement exportés vers le SIEM)
  • Les processus système lancés sur l'OS embarqué (inaccessibles sauf accès shell direct)
  • Les connexions réseau initiées par l'appliance elle-même (à distinguer du trafic qu'elle route)
  • Les modifications de fichiers système ou de configuration au niveau OS (invisible sans agent)
  • Les appels système suspects : fork de processus inhabituels, exécution de binaires non standards

En pratique, si un attaquant exploite CVE-2026-25089 sur votre FortiSandbox et installe un implant, vous ne verrez probablement rien dans votre SIEM. L'appliance continuera à fonctionner normalement — analysant des malwares, générant des rapports sandbox, remontant des alertes — pendant que l'attaquant utilise silencieusement le foothold pour explorer votre réseau interne et préparer la suite de son opération.

Cet angle mort est fondamental. Il signifie que même un SOC 24/7 avec des analystes compétents peut passer à côté d'une compromission d'appliance réseau pendant des semaines ou des mois. La détection doit s'appuyer sur des signaux indirects : connexions réseau inattendues depuis l'IP de gestion de l'appliance vers des destinations externes, trafic DNS anormal généré par l'appliance, volumes de trafic sortant inhabituels aux heures creuses, requêtes vers des nœuds RPC blockchain. Ces signaux existent, mais ils demandent une démarche de threat hunting proactive — pas une surveillance réactive des alertes.

Le pattern d'exploitation type : de la vulnérabilité à la persistance en 48 heures

Les incidents documentés depuis 2024 permettent de dessiner un pattern d'exploitation qui se reproduit avec une régularité troublante sur les équipements réseau — qu'il s'agisse d'Ivanti, de Palo Alto, de Fortinet ou de SonicWall. Voici la séquence reconstructuée à partir des rapports d'incidents publics.

J+0, heure 0 — Exploitation initiale. L'attaquant scanne ou cible directement l'appliance exposée sur Internet, typiquement identifiée via Shodan ou FOFA sur le banner HTTP de l'interface de gestion. Il exploite la CVE critique (command injection, SSRF, auth bypass) pour obtenir l'exécution de code. L'opération dure quelques secondes à quelques minutes. Aucune alerte ne s'affiche dans le SIEM. L'appliance continue à router le trafic normalement.

J+0 à J+1 — Reconnaissance et vol de credentials. Depuis le shell obtenu, l'attaquant explore l'appliance : extraction de la base de credentials VPN (couples login/hash ou mots de passe selon la configuration de stockage), récupération des sessions actives et des cookies d'authentification, extraction des clés de chiffrement si accessibles. Dans le cas SonicWall CVE-2026-15409, l'acteur UTA0533 extrait systématiquement les graines TOTP — garantissant un accès MFA valide à long terme même après rotation des mots de passe.

J+1 à J+2 — Installation de la persistance. L'attaquant installe un implant sur l'appliance : backdoor dans les scripts de démarrage, modification de binaires système, mécanisme de reverse shell déguisé en trafic légitime. Les APT les plus sophistiqués ont développé des implants spécifiques pour certains modèles d'appliances, capables de survivre aux mises à jour de firmware — un niveau de sophistication qui témoigne d'un investissement long-terme dans la recherche offensive sur ces cibles.

J+2 et au-delà — Mouvement latéral discret. Avec des credentials VPN légitimes, une persistance sur l'appliance, et parfois un accès MFA valide via les graines TOTP volées, l'attaquant commence à se déplacer dans le réseau interne en passant pour un utilisateur autorisé. Il respecte les protocoles légitimes, utilise les tunnels VPN existants, adapte ses horaires aux plages de travail normales pour minimiser les anomalies comportementales. C'est à ce stade que la durée de présence non détectée peut s'allonger considérablement.

La réponse défensive réaliste : ce qui marche vraiment

Face à ce tableau, voici ce que je recommande concrètement aux équipes IT et sécurité, par ordre de priorité et d'efficacité prouvée sur le terrain.

1. Patcher dans les 24-72h sur les CVE critiques d'équipements périmètraux exposés. Je sais que ça semble basique. Mais dans les incidents que j'observe en audit, la grande majorité des compromissions concernent des équipements non patchés depuis des semaines ou des mois après la publication d'une CVE critique. Le délai moyen de patch en entreprise reste trop long. Une CVE CVSS 9+ sur un équipement périmétral exposé sur Internet mérite un patch en 24-72h maximum — pas dans la prochaine fenêtre de maintenance mensuelle. Cela exige un processus de gestion des vulnérabilités distinct pour les équipements périmètraux, avec des SLA stricts et une astreinte dédiée si nécessaire.

2. Segmenter les interfaces de gestion en OOB. L'interface d'administration de votre VPN, firewall ou sandbox ne doit jamais être accessible depuis Internet — idéalement jamais depuis le réseau de production non plus. Elle doit être sur un réseau de gestion hors-bande (Out-of-Band Management), accessible uniquement depuis un bastion dédié avec authentification forte. Si CVE-2026-25089 dans FortiSandbox n'est exploitable que via l'interface web, un FortiSandbox dont cette interface web n'est pas accessible depuis Internet est déjà significativement moins vulnérable à une exploitation externe. Cette segmentation est un quick-win majeur, souvent sous-exploité.

3. Collecter les bons logs, pas seulement les logs de trafic. Configurer vos appliances pour exporter TOUS leurs logs disponibles vers votre SIEM : logs d'accès à l'interface d'administration (souvent en local seulement par défaut — forcer l'export), logs système si disponibles via syslog au niveau OS, logs de modification de configuration. Créer des règles de détection sur les accès anormaux à l'interface d'admin, les modifications de configuration inattendues en dehors des fenêtres de maintenance, et les connexions réseau initiées par l'appliance elle-même vers des destinations externes non connues.

4. Inventorier et surveiller votre surface d'exposition externe. Savoir exactement ce que vos appliances exposent sur Internet. Utiliser un outil de scan externe (un scanner périodique de votre propre périmètre, ou des services comme Shodan Monitor) pour vérifier régulièrement ce qui est visible — parfois des interfaces de gestion sont exposées accidentellement lors de reconfigurations. Cet inventaire doit être mis à jour en temps réel et toute nouvelle exposition doit déclencher une alerte immédiate.

5. Intégrer les appliances réseau dans votre programme de threat hunting. Définir une routine de vérification proactive mensuelle minimum : intégrité des fichiers critiques de l'OS embarqué (via hachage de référence établi juste après installation d'un firmware sain), processus actifs inhabituels (certains équipements permettent l'accès shell de diagnostic), connexions réseau établies par l'appliance elle-même vers des IP externes non reconnues. Ces vérifications doivent être planifiées et documentées — pas seulement réalisées après un incident.

6. Préparer un plan de réponse spécifique "appliance compromise". Que faites-vous concrètement si votre appliance VPN est compromise demain matin ? Avez-vous un processus documenté pour révoquer toutes les sessions, renouveler les credentials de l'ensemble des utilisateurs, et remettre l'appliance en état de fonctionnement sain ? Le cas SonicWall CVE-2026-15409 illustre bien la complexité : changer les mots de passe seul est insuffisant si les graines TOTP ont été volées. Un plan de réponse generique "changement de mots de passe" ne couvre pas ce scénario.

Mon avis d'expert

Ce que j'observe dans les audits et missions de réponse à incident confirme une tendance de fond depuis 2024 : les organisations qui gèrent bien leurs appliances réseau sont celles qui les traitent comme des systèmes critiques à part entière — avec un processus de patch rigoureux sous 72h, une segmentation réseau sérieuse des interfaces de gestion, un monitoring spécifique, et un plan de réponse documenté. Pas comme des boîtiers qu'on achète, qu'on installe, et qu'on oublie pendant trois ans. La pression commerciale des vendors pour vendre du matériel sans investir suffisamment dans la sécurité du code embarqué est un problème systémique qui ne se résoudra pas avant plusieurs années. En attendant, la charge de la défense revient aux équipes IT et sécurité. Et la bonne nouvelle, c'est que les mesures de base — patcher vite, segmenter les interfaces, collecter les bons logs, pratiquer le threat hunting — sont très efficaces si elles sont appliquées avec rigueur et constance.

Conclusion

Les vulnérabilités FortiSandbox et SonicWall de juillet 2026 ne sont pas des accidents isolés. Elles sont des symptômes d'un problème structurel documenté depuis 2024 : les appliances réseau sont développées avec des pratiques de sécurité insuffisantes, déployées dans des positions architecturales de confiance élevée, monitorées avec des outils inadaptés à leur nature propriétaire, et patchées avec des délais trop longs. Les APT l'ont compris avant beaucoup d'équipes défensives — et ils en profitent. Les recommandations pour rattraper ce retard existent, elles ne sont pas coûteuses, elles ne nécessitent pas de nouveau produit à acheter. Ce qui manque, c'est la priorité et la rigueur d'exécution. Ce billet est une invitation à les mettre dans l'agenda de la semaine qui vient.

Besoin d'un regard expert sur votre sécurité ?

Discutons de votre contexte spécifique — audit périmètre, plan de remédiation, ou préparation à la réponse à incident.

Prendre contact