En juillet 2024, une agence fédérale civile américaine a été victime d’une intrusion informatique sophistiquée. L’équipe de réponse aux incidents de la CISA (Cybersecurity and Infrastructure Security Agency) est intervenue après la détection d’une activité malveillante par les alertes de son outil EDR (Endpoint Detection and Response). L’analyse de cet incident a révélé trois enseignements clés :
- Des vulnérabilités critiques n’avaient pas été corrigées assez rapidement,
- Le plan de réponse aux incidents de l’agence n’avait pas été testé ni pleinement préparé (notamment pour faire appel à des intervenants externes),
- Les alertes de sécurité n’étaient pas surveillées en continu, et certains serveurs exposés manquaient de protection adéquate.
Ces leçons mettent en évidence l’importance de corriger rapidement les failles connues, de préparer et d’exercer les plans de réponse, et de surveiller activement les systèmes afin de détecter toute activité anormale. Dans cet article, nous revenons sur le déroulement de l’intrusion, les techniques employées par les attaquants, puis détaillons les leçons apprises et les mesures recommandées pour renforcer la sécurité.
Déroulement de l’attaque
Les attaquants ont exploité une vulnérabilité critique récemment divulguée dans un serveur GeoServer exposé à Internet. Cette faille (identifiée comme CVE-2024-36401) permettait l’exécution de code à distance sur le serveur vulnérable. Elle avait été rendue publique le 30 juin 2024, mais n’avait pas encore été corrigée par l’agence au moment de l’attaque. Dès le 11 juillet 2024 – soit seulement 11 jours après la divulgation – des acteurs malveillants ont utilisé cette faille pour pénétrer le premier serveur GeoServer de l’agence. Ils ont profité de cette brèche pour installer des outils open source malveillants (scripts, web shells, etc.) et établir une persistance dans le système compromis. Par exemple, un web shell de type China Chopper a été implanté afin de maintenir un accès distant furtif. Les attaquants ont également créé des comptes utilisateur temporaires (rapidement supprimés par la suite) et programmé des tâches planifiées (cron jobs) pour assurer leur présence continue sur la machine.
Au 24 juillet 2024, les cyberattaquants ont compromis un deuxième serveur GeoServer de l’agence en exploitant la même vulnérabilité, toujours non corrigée. À partir de ces points d’ancrage initiaux, ils se sont déplacés latéralement dans le réseau interne. Depuis le premier GeoServer, ils ont accédé à un serveur Web interne, puis ultérieurement à un serveur de base de données SQL. Sur chaque serveur compromis, ils ont tenté de déposer de nouveaux web shells et exécuté des scripts malveillants en vue d’accroître leurs privilèges et d’étendre leur contrôle.
Durant leur progression, les intrus ont combiné des outils publics et des techniques discrètes. Ils ont effectué une reconnaissance du réseau interne en s’appuyant sur un utilitaire de scan automatisé (fscan), ce qui leur a permis de découvrir d’autres machines et services actifs sur le réseau de l’agence. Des balayages ICMP (ping) et des scans de ports ont été utilisés pour identifier les hôtes et services disponibles, comme les serveurs SSH, FTP et autres applications ouvertes. Les attaquants ont exploité des informations d’identification faibles en lançant des attaques par force brute contre des comptes et services, afin de passer d’un système compromis à un autre. Pour élever leurs privilèges, ils ont essayé d’exploiter une vulnérabilité plus ancienne du noyau Linux connue sous le nom de Dirty COW (CVE-2016-5195) à l’aide d’un outil public du même nom, dans le but d’obtenir des droits administrateur sur certaines machines Linux compromises.
En parallèle, les assaillants ont fait usage de techniques dites de “Living off the Land” (LOTL), c’est-à-dire qu’ils ont détourné des outils légitimes déjà présents sur les systèmes pour mener des actions malveillantes en toute discrétion. Par exemple, ils ont utilisé PowerShell et l’outil système Bitsadmin sur les serveurs Windows compromis pour télécharger ou transférer des fichiers malveillants, évitant ainsi d’attirer l’attention par l’installation de programmes externes visibles. Sur un serveur Windows, ils ont activé la fonctionnalité xp_cmdshell de Microsoft SQL Server (qui permet d’exécuter des commandes système depuis SQL) afin de se déplacer vers le serveur de base de données et d’y exécuter des commandes arbitraires.
Pour assurer leurs communications et le contrôle à distance de l’infrastructure compromise, les attaquants ont déployé un malware proxy multi-niveaux appelé Stowaway. Installé sur le serveur Web compromis, cet outil leur a permis d’établir un canal de commande et contrôle (C2) sortant vers leur propre serveur, en faisant transiter furtivement le trafic à travers le serveur de l’agence. Stowaway a ainsi servi de relais pour contrôler d’autres machines internes comme le serveur SQL, tout en échappant aux restrictions réseau en place. Les attaquants ont même mis en place deux canaux de communication distincts (sur des ports TCP différents) pour disposer d’un accès de secours en cas de détection ou de coupure du premier canal. Parmi les fichiers découverts plus tard sur le serveur C2 des attaquants figuraient une panoplie d’outils publics utiles à diverses phases de l’attaque (outils d’évasion antivirus comme RingQ, utilitaires comme BusyBox et WinRAR, archives contenant des web shells, scripts d’automatisation, etc.), ce qui démontre la préparation des assaillants à persister et étendre leur contrôle sur la durée.
Détection et réponse à l’incident
Malgré l’ampleur de l’intrusion, celle-ci est restée invisible pendant près de trois semaines. Un premier signal d’alarme avait pourtant eu lieu dès le 15 juillet 2024 : l’outil EDR de l’agence avait détecté sur le premier GeoServer la présence de Stowaway, le logiciel de proxy malveillant. Cependant, cette alerte n’a pas été remarquée ou traitée par les équipes à ce moment-là. De plus, il s’est avéré qu’un des serveurs critiques (le serveur Web public) n’était pas équipé d’un agent de sécurité EDR, ce qui a privé l’agence de toute visibilité sur les activités malveillantes s’y déroulant.
Ce n’est que le 31 juillet 2024 que l’intrusion a finalement été repérée par le centre opérationnel de sécurité (SOC) de l’agence. Ce jour-là, sur le serveur SQL compromis, l’EDR a signalé un fichier suspect “1.txt” associé à un malware, que les attaquants avaient transféré via Bitsadmin. Plusieurs autres alertes corrélées ont été enregistrées, indiquant des tentatives inhabituelles d’utilisation d’outils système (PowerShell, certutil) pour télécharger des données. Réagissant à ces signaux, les analystes SOC ont immédiatement mis en quarantaine (contenu) le serveur SQL ainsi que le premier GeoServer, empêchant toute nouvelle activité de l’attaquant sur ces machines. L’agence a ensuite sollicité le soutien de la CISA le 1er août 2024 pour conduire une investigation approfondie, de peur que les assaillants aient laissé des portes dérobées ou souches malveillantes ailleurs dans le réseau.
L’intervention de la CISA a mis en lumière l’intégralité du parcours d’attaque décrit précédemment. Les enquêteurs ont confirmé que le point d’entrée initial provenait de la vulnérabilité GeoServer non corrigée et ont reconstitué le cheminement des attaquants à travers les différents systèmes (deux GeoServers, puis serveur Web, puis serveur SQL). Ils ont identifié les outils et malware utilisés par les assaillants, récupéré des indicateurs de compromission (adresses IP, hachages de fichiers malveillants, comptes suspects créés, etc.), et analysé les journaux d’événements disponibles pour comprendre l’ampleur des dégâts. On note que la dernière activité malveillante des attaquants a été observée le 6 août 2024 sur le deuxième GeoServer, ce qui suggère qu’ils ont tenté de continuer l’exploration du réseau peu de temps avant d’être totalement évincés par la réponse de sécurité.
Il est apparu toutefois que la réponse à l’incident a été ralentie par certaines contraintes internes. Le plan de réponse de l’agence n’avait pas prévu les modalités pratiques pour intégrer rapidement des intervenants tiers (comme la CISA) ni pour leur donner un accès immédiat aux outils de sécurité de l’agence. Par exemple, la CISA n’a pas pu obtenir tout de suite un accès à la solution de gestion des journaux (SIEM) de l’agence, ce qui a retardé l’analyse complète des événements. De plus, le déploiement des agents EDR supplémentaires par la CISA sur le réseau de l’agence a nécessité un passage en comité de changement (Change Control Board), introduisant un délai précieux alors que chaque heure compte lors d’une cyberattaque en cours. L’agence n’avait pas réalisé d’exercice récent de son plan d’intervention, ce qui aurait pu mettre en évidence ces écueils logistiques à l’avance.
Leçons tirées
Cet incident offre un retour d’expérience riche en enseignements pour renforcer la cyberdéfense :
- Patcher rapidement les failles critiques : La compromission initiale a été rendue possible par l’absence de correctif appliqué à une vulnérabilité pourtant critique et publique depuis plusieurs jours. Si l’agence avait corrigé la faille CVE-2024-36401 dès son annonce ou dès son ajout au catalogue des vulnérabilités exploitées connues de la CISA, les attaquants n’auraient pas pu s’infiltrer aussi aisément. La rapidité de correction des systèmes exposés est donc cruciale pour prévenir les compromissions.
- Tester et mettre à jour le plan de réponse aux incidents : Bien que l’agence disposait d’un plan de réponse, le cas réel a montré des lacunes dans sa mise en œuvre. L’absence de procédures pour faire intervenir rapidement une aide extérieure et pour déployer sans délai des outils de sécurité additionnels a retardé certaines actions de remédiation. Il est essentiel de tester régulièrement le plan d’intervention (par exemple via des exercices sur table et des simulations réalistes) afin d’identifier les points faibles, de s’assurer de la clarté des rôles et procédures, et de le tenir à jour. Un plan vivant et éprouvé aurait permis une réponse plus efficace, en prévoyant notamment des autorisations préalables pour impliquer des experts tiers et des canaux de communication alternatifs en cas de crise.
- Surveiller en continu et couvrir tous les actifs : La persistance de l’attaquant pendant trois semaines sans être détecté met en évidence un défaut de supervision continue des alertes de sécurité et un manque de couverture sur certains systèmes. Une alerte EDR critique a été ignorée ou manquée, et un serveur clé n’était pas du tout surveillé par un agent de sécurité. Cela souligne l’importance d’une surveillance proactive 24/7 des journaux et alertes, et de l’installation d’outils de détection sur tous les systèmes sensibles, notamment ceux exposés à Internet. Une vigilance accrue et une couverture de sécurité complète auraient pu permettre de repérer l’activité malveillante dès ses débuts (par exemple, l’alerte du 15 juillet aurait pu déclencher une enquête immédiate et potentiellement limiter l’ampleur de la compromission).
Recommandations pour renforcer la sécurité
À la lumière de ces leçons, la CISA a formulé plusieurs recommandations afin que toutes les organisations – agences gouvernementales comme entreprises privées – renforcent leur posture de sécurité :
- Gestion proactive des vulnérabilités : Instaurer un programme de gestion des correctifs efficace, incluant des procédures d’application en urgence des patches critiques. Il est impératif de prioriser la correction des vulnérabilités exploitées activement connues, en particulier sur les systèmes exposés à Internet. Maintenir un inventaire à jour des actifs permet d’identifier rapidement les systèmes à risque et d’appliquer les correctifs de façon prioritaire sur ceux-ci.
- Plans de réponse aux incidents robustes : Établir et maintenir un plan de réponse aux incidents (IRP) clair, approuvé par la direction, et le mettre régulièrement à l’épreuve. Le plan doit définir les rôles et responsabilités, les procédures d’escalade et de communication (y compris vers les autorités, partenaires et médias si nécessaire), ainsi que les scénarios d’actions pour endiguer et éradiquer une menace. Il doit également prévoir les modalités pour impliquer rapidement des experts externes en cas d’incident majeur et pour leur donner l’accès nécessaire (par exemple, déploiement accéléré d’agents de sécurité additionnels, partage des journaux, etc.). Des exercices périodiques (simulations techniques type purple team ou exercices sur table) sont indispensables pour tester le plan dans des conditions réalistes, identifier les améliorations à y apporter et s’assurer que les équipes sont familières avec son application.
- Surveillance et détection renforcées : Mettre en place une collecte centralisée et exhaustive des journaux d’activité (logs) sur l’ensemble des systèmes, de préférence vers une plateforme hors du réseau principal (pour qu’un attaquant ne puisse pas la saboter). Doter le centre opérationnel de sécurité de ressources suffisantes pour surveiller en continu ces événements et enquêter sans délai sur toute anomalie. L’usage d’une solution SIEM (Security Information and Event Management) peut aider à agréger et corréler les logs afin de repérer des comportements suspects (scans réseau internes, création de nouveaux comptes administrateur, utilisation inhabituelle d’outils système, etc.). Il convient de définir des alertes sur ces activités anormales et de former les analystes à reconnaître les signes d’intrusion même discrets (par exemple, usage légitime d’outils système détournés dans un contexte anormal).
En complément, la CISA recommande aussi des mesures de sécurité transverses qui auraient pu limiter l’impact de ce type d’attaque : la généralisation de l’authentification multi-facteurs résistante au phishing sur les comptes sensibles (notamment administrateurs et messageries), et la mise en place de listes d’approbation stricte (allowlisting) pour les applications, scripts et trafics réseau autorisés. Ces contrôles contribuent à empêcher qu’un attaquant exploite des informations d’identification compromises ou exécute librement des programmes malveillants dans l’environnement.
En conclusion
L’incident survenu dans cette agence fédérale illustre de façon frappante combien il est vital d’anticiper les menaces par une hygiène cyber irréprochable. En appliquant rapidement les correctifs essentiels, en préparant méthodiquement les réponses aux incidents, et en surveillant activement les signes d’intrusion, les organisations peuvent réduire considérablement le risque d’une compromission réussie ou en limiter l’impact. Les leçons tirées de cette affaire par la CISA servent d’avertissement et de guide : chaque vulnérabilité négligée, chaque plan non testé et chaque alerte ignorée peuvent ouvrir la voie à une attaque aux conséquences potentiellement graves. Il incombe donc aux responsables de la sécurité de prendre ces enseignements au sérieux et de renforcer sans attendre leurs défenses en conséquence.
Sources
- CISA – CISA Releases Advisory on Lessons Learned from an Incident Response Engagement (Alerte du 23 septembre 2025)
- CISA – Cybersecurity Advisory AA25-266A: CISA Shares Lessons Learned from an Incident Response Engagement (Texte intégral de l’avis, 23 septembre 2025)
