Depuis 2023, pas un trimestre ne s'écoule sans qu'une appliance VPN ou un pare-feu périphérique fasse l'objet d'une alerte critique exploitée in-the-wild. Ivanti, SonicWall, Palo Alto, Cisco ASA, Fortinet — le palmarès des équipements compromis ressemble à un catalogue des solutions de sécurité périmètre les plus vendues du marché. Ce n'est pas une coïncidence. C'est une stratégie délibérée des acteurs de la menace, et elle fonctionne.

Pourquoi les appliances VPN sont le Graal de l'espion numérique

Comprendre pourquoi les VPN et pare-feux concentrent autant l'attention des APT nécessite de raisonner comme un attaquant. Un concentrateur VPN remplit trois critères qui en font une cible de premier choix : il est exposé directement sur Internet par définition, il dispose de privilèges élevés sur le réseau interne, et il traite les identifiants de l'ensemble des utilisateurs distants en temps réel.

En compromettant une appliance VPN, un attaquant ne gagne pas seulement un point d'accès. Il gagne une position stratégique dans l'architecture réseau — souvent avec une visibilité sur l'ensemble du trafic chiffré qui transite, la capacité d'intercepter des credentials en clair avant chiffrement côté client, et la possibilité de se déplacer latéralement vers des ressources internes sans déclencher les alertes habituelles liées aux connexions externes suspectes. Le trafic VPN légitime est, par nature, peu surveillé une fois à l'intérieur du tunnel — les équipes SOC font confiance aux connexions VPN établies.

Le deuxième attrait est la persistance. Les appliances VPN fonctionnent 24h/24, 365 jours par an. Elles reçoivent des patches beaucoup moins fréquemment que les postes de travail ou les serveurs d'application — souvent parce que les équipes réseau n'ont pas de fenêtre de maintenance facile pour interrompre le service VPN d'une organisation entière. Cette inertie de mise à jour est systématique et elle est connue des attaquants qui l'exploitent délibérément.

Troisièmement, ces équipements fonctionnent généralement sur des systèmes d'exploitation propriétaires ou des Linux embarqués avec peu ou pas de visibilité EDR. Aucun antivirus ne tourne sur une appliance Ivanti ou SonicWall. Les logs, quand ils sont activés, restent souvent sur l'appliance elle-même et peuvent être falsifiés par un attaquant disposant d'un accès root. La capacité de détection d'une intrusion sur ces équipements est structurellement inférieure à celle d'un poste de travail Windows avec un EDR moderne.

Le résultat est prévisible : ces équipements sont devenus le vecteur d'intrusion initiale préféré des groupes APT depuis au moins 2022. Les données issues des rapports M-Trends de Mandiant et des analyses de CrowdStrike montrent que les appliances réseau périmètre représentaient le vecteur d'accès initial numéro un dans les incidents impliquant des acteurs étatiques en 2024-2026, devant le phishing ciblé et l'exploitation de serveurs applicatifs exposés.

Le cas Ivanti : un pattern d'échecs qui se répète depuis 2024

L'histoire d'Ivanti Connect Secure illustre parfaitement le problème structurel de ces équipements. Depuis 2024, ce produit a été touché par une série de vulnérabilités critiques exploitées en production, chacune ayant conduit à des compromissions de grande envergure, avec des victimes dans les secteurs les plus sensibles.

En janvier 2024, CVE-2023-46805 et CVE-2024-21887 ont été massivement exploitées par des acteurs APT liés à la Chine (UNC5325 selon Mandiant, groupe également connu sous d'autres désignations dans les attributions américaines). Ces deux failles permettaient une authentification bypass et une injection de commande. Des milliers d'appliances dans le monde, notamment des agences gouvernementales américaines et européennes, ont été compromises. CISA a émis une directive d'urgence ED 24-01 ordonnant aux agences fédérales américaines de déconnecter leurs appliances Ivanti. La réponse d'Ivanti a été critiquée pour sa lenteur et son manque de transparence initiale sur l'étendue de la compromission.

En mars 2024, CVE-2024-21893 — une autre faille critique dans le même produit — a suivi. L'investigation forensique a révélé que certaines organisations avaient été compromises sans que le patch des failles précédentes ait suffi à éliminer les accès persistants des attaquants. Des webshells et implants en mémoire avaient survécu aux procédures de remédiation recommandées par Ivanti. En 2025, de nouvelles vulnérabilités ont encore conduit à des alertes. Et en novembre 2026, l'alerte CERTFR-2026-ALE-013 couvre trois nouvelles failles activement exploitées dans les mêmes produits.

Ce pattern répété soulève une question légitime : est-ce que le problème est structurel dans la base de code d'Ivanti, ou est-ce simplement la conséquence du fait qu'Ivanti est l'une des cibles les plus scrutées par les chercheurs et les APT ? La réponse est probablement les deux. Mais au-delà du cas Ivanti, le pattern se répète : SonicWall (CVE-2026-19868 en octobre 2026, CVE-2021-20016 en 2021), Palo Alto (CVE-2024-3400 exploitée par UTA0218), Citrix ADC (CVE-2023-4966 alias CitrixBleed), et Fortinet (CVE-2023-27997, CVE-2024-21762). Ce n'est pas une coïncidence de marché.

Pourquoi les entreprises continuent de déployer ces équipements

La question mérite d'être posée directement : si ces équipements sont si régulièrement compromis, pourquoi les organisations continuent-elles d'en déployer ? La réponse est pragmatique et mérite d'être comprise plutôt que simplement jugée.

D'abord, le coût de migration est élevé. Remplacer une infrastructure VPN IPSec ou SSL déployée depuis 10 ans, avec des milliers de clients configurés, des intégrations LDAP/Active Directory complexes, des règles de split tunneling spécifiques, et des processus RH/IT associés, nécessite un projet de plusieurs mois et un budget conséquent. Les décideurs calculent le coût certain de la migration versus le risque probabiliste d'être touché — et ce risque est souvent sous-estimé, notamment dans les ETI qui ne disposent pas d'une veille sur les CVE en temps réel.

Ensuite, les alternatives existent mais ne sont pas simples à déployer. Le modèle Zero Trust Network Access (ZTNA) représente l'alternative architecturale aux VPN traditionnels. Des solutions comme Cloudflare Access, Zscaler Private Access, ou Palo Alto Prisma Access n'exposent pas d'appliance directement sur Internet. L'accès aux ressources internes passe par un broker cloud qui valide l'identité, l'état du poste et le contexte d'accès avant d'autoriser la connexion. Sur le papier, cette architecture élimine le vecteur d'attaque de l'appliance exposée. En pratique, la migration est complexe et les organisations en transition gardent souvent les deux systèmes en parallèle — ce qui double temporairement la surface d'attaque.

Troisièmement, il y a un conservatisme technique légitime dans certains secteurs. Les VPN traditionnels sont connus, maîtrisés, auditables localement. Les ZTNA cloud introduisent une dépendance à un fournisseur cloud et une opacité potentielle sur le traitement des métadonnées de connexion. Dans certains secteurs réglementés — défense, santé, infrastructure critique, secteur financier sous certaines juridictions — cette dépendance cloud est une contrainte réglementaire réelle, pas un prétexte.

Quatrièmement, la pression budgétaire. Les DSI et RSSI de PME et ETI n'ont pas toujours le budget pour migrer vers un ZTNA moderne. Les solutions ZTNA cloud, facturées par utilisateur par mois, peuvent s'avérer plus coûteuses à grande échelle qu'une appliance amortie sur 5 ans. L'arbitrage n'est pas toujours simple, surtout quand les directions générales comparent le coût certain de la migration au risque hypothétique de compromission.

Ce que les attaquants font une fois dans l'appliance

L'analyse forensique des incidents impliquant des appliances VPN compromises montre des schémas d'exploitation récurrents qui méritent d'être documentés précisément, car ils permettent d'identifier les bons points de détection et de réponse.

La première phase est la reconnaissance silencieuse et l'établissement de la persistance. L'attaquant, une fois dans l'appliance, configure un accès persistant avant d'agir activement : webshell dans un répertoire accessible web, modification de scripts de démarrage, implant en mémoire ou manipulation de la configuration système. Certains groupes APT ont démontré leur capacité à maintenir un accès dans une appliance Ivanti pendant plusieurs semaines sans déclencher d'alerte, en utilisant uniquement des fichiers et binaires légitimes du système (living-off-the-land).

La deuxième phase est l'interception des identifiants en transit. L'appliance VPN traite les authentifications des utilisateurs — souvent avec intégration LDAP ou RADIUS. Un attaquant en position man-in-the-middle dans l'appliance peut capturer des identifiants en clair ou des hashes avant chiffrement. Ces identifiants permettent ensuite un accès direct aux ressources internes sans passer par le VPN — notamment via RDP, SMB, ou les portails web d'applications métier. C'est le vecteur le plus dévastateur car il compromet des comptes légitimes exploitables longtemps après la fermeture de la brèche initiale.

La troisième phase est le mouvement latéral depuis l'intérieur du réseau. Le trafic généré depuis une appliance VPN légitime est rarement filtré par les règles de pare-feu interne — l'appliance est considérée comme un nœud de confiance du réseau. Un attaquant l'exploite pour accéder aux serveurs de fichiers, aux contrôleurs de domaine Active Directory, ou aux systèmes de sauvegarde — les cibles classiques d'une attaque ransomware ou d'une exfiltration de données à large échelle.

La quatrième phase est l'objectif final : exfiltration silencieuse de données sur des mois dans le cas d'un groupe APT à visée d'espionnage, ou déploiement de ransomware et chiffrement de l'infrastructure dans le cas d'un groupe cybercriminel. Ces deux catégories d'acteurs utilisent les mêmes vecteurs d'accès initial et les mêmes techniques de mouvement latéral — seuls les objectifs finaux diffèrent.

Ce que vous devez changer maintenant

La migration complète vers un ZTNA n'est pas toujours possible à court terme — les contraintes budgétaires, techniques et réglementaires sont réelles. Mais il existe des mesures de réduction du risque qui peuvent et doivent être appliquées immédiatement sur des infrastructures VPN existantes, sans projet pluriannuel.

Réduire la surface d'exposition : l'interface d'administration de l'appliance VPN ne doit jamais être exposée sur Internet. Elle doit être accessible uniquement depuis un réseau de gestion dédié hors-bande, avec authentification multi-facteurs renforcée. L'interface utilisateur (portail VPN) doit être protégée par un pare-feu frontal ou un WAF qui filtre les requêtes anormales avant qu'elles n'atteignent l'appliance. Ces mesures n'empêchent pas l'exploitation de failles zero-day dans le portail lui-même, mais elles réduisent significativement la facilité d'exploitation.

Patcher agressivement : les appliances VPN doivent rejoindre le cycle de patch management prioritaire de l'organisation — au même titre que les serveurs exposés directement sur Internet. La politique "on patche quand on a le temps" n'est pas acceptable pour des équipements traitant l'authentification de tous les utilisateurs distants. Les CVE critiques doivent être traitées dans les 48h, et les CVE modérées dans les 7 jours. Cette discipline de patch management doit être mesurée et auditée régulièrement.

Surveiller l'appliance elle-même : les logs de l'appliance doivent être exportés en temps réel vers un SIEM externe — pas uniquement stockés localement où un attaquant peut les effacer. Des règles de détection doivent alerter sur les connexions hors-heures, les volumes de transfert anormaux, les connexions depuis des pays non habituels, et les tentatives d'accès à l'interface d'administration depuis des sources non autorisées. Cette surveillance est généralement absente dans les organisations qui ne traitent pas leurs appliances VPN comme des serveurs critiques à surveiller activement.

Segmenter ce que le VPN peut atteindre : un utilisateur VPN ne doit pas avoir accès à l'ensemble du SI. La micro-segmentation réseau — même basique — permet de limiter les mouvements latéraux en cas de compromission de l'appliance ou des credentials interceptés. Un VPN donnant accès uniquement aux applications métier nécessaires à un profil d'utilisateur donné limite considérablement le rayon d'action d'un attaquant par rapport à un VPN full-tunnel sans restriction d'accès interne.

Planifier la migration ZTNA : c'est une direction incontournable, pas une option. L'objectif est d'éliminer à terme l'exposition d'appliances directement sur Internet pour l'accès distant. La migration peut se faire progressivement — en commençant par les populations les plus mobiles ou les accès à des applications spécifiques — avant d'étendre le ZTNA à l'ensemble des utilisateurs. Un horizon réaliste est 18 à 36 mois pour une organisation de taille intermédiaire.

Mon avis d'expert

Je vois encore trop d'organisations traiter leurs appliances VPN comme des équipements "set and forget". On les déploie, on configure les tunnels, et on n'y retouche plus pendant 3 ans — sauf en cas de panne. C'est une erreur stratégique majeure. Ces équipements sont les murs d'enceinte de votre forteresse numérique. Si vos murs ont des trous et que vous ne les réparez pas, peu importe la solidité de ce qu'il y a à l'intérieur. La question n'est plus "est-ce qu'Ivanti sera encore touché ?" — la réponse est oui, comme Fortinet, SonicWall et les autres le seront aussi. La vraie question est : "qu'est-ce que vous avez mis en place pour qu'une compromission de votre VPN ne soit pas synonyme de compromission de l'ensemble de votre SI ?" C'est précisément là-dessus que je travaille avec mes clients — pas à éliminer le risque de faille, mais à s'assurer que chaque couche de défense limite le rayon d'action d'un attaquant qui aurait passé la première barrière.

Conclusion : l'équation du risque a changé

Les équipements VPN et pare-feux périmètre ne disparaîtront pas du paysage technologique des entreprises dans les deux ou trois prochaines années. Mais leur rôle et leur positionnement dans l'architecture de sécurité doivent évoluer. L'époque où l'on pouvait se contenter d'un VPN SSL bien configuré comme seule ligne de défense pour l'accès distant est révolue depuis 2024. Les APT l'ont compris avant beaucoup de DSI — et ils en profitent activement.

La réponse est une combinaison de mesures d'hygiène renforcée immédiatement applicables (patch management agressif, surveillance des logs en temps réel, segmentation réseau interne) et d'une migration progressive vers des architectures Zero Trust qui réduisent structurellement la surface d'exposition. Ce n'est pas une révolution à faire du jour au lendemain — c'est un programme de transformation qui se planifie, se budgète et s'exécute sur 18 à 36 mois.

En attendant, chaque appliance non patchée, non surveillée, non segmentée est une invitation que vous laissez ouverte. Et en 2026, les acteurs de la menace passent régulièrement derrière ces portes ouvertes.

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

Discutons de votre contexte spécifique.

Prendre contact