On passe beaucoup de temps, en sécurité informatique, à empêcher les intrusions : durcir les systèmes, réduire l’exposition, surveiller les alertes. Pourtant, une enquête récente met en lumière une réalité tout aussi cruciale : après l’intrusion, ce que font les attaquants peut transformer une brèche “gérable” en incident durable. Et ce n’est pas seulement une question de logiciels malveillants déposés sur la machine : l’objectif devient de modifier l’environnement pour rester en contrôle.
Dans un cas observé en juin, des analystes ont retracé une séquence complète. L’attaquant ne s’est pas précipité vers une action spectaculaire. Au contraire, il a pris le temps de s’installer, de créer des accès de secours et de masquer ses traces, avant de lancer d’autres activités à partir de la même base. Voici les étapes principales et ce qu’elles devraient changer dans vos pratiques de remédiation.
Comment l’attaquant a franchi la première porte
Les signaux initiaux ont été observés autour d’un processus Microsoft SQL Server. Mais l’histoire n’était pas celle d’une attaque directe contre la base de données. L’analyse a révélé un élément plus classique côté applicatif : une page web sur le même serveur qui ne validait pas correctement les entrées des utilisateurs.
Cette absence de contrôle ouvre la voie à une vulnérabilité d’injection SQL. En pratique, si une application prend une saisie (par exemple dans une zone de recherche ou un formulaire de connexion) et la transmet à une base de données sans vérifier qu’elle est “safe”, l’attaquant peut manipuler la requête et atteindre le système sous-jacent.
Ce point mérite d’être souligné : l’injection SQL reste une des failles web les plus fréquentes, et surtout une des plus évitables. Elle rappelle qu’une architecture “dure” côté serveurs ne suffit pas si une application laisse entrer du trafic non maîtrisé.
Une fois dedans : reconnaissance et préparation
Après l’accès initial, l’attaquant ne s’est pas contenté d’exécuter quelque chose de rapidement destructeur. Il a d’abord réalisé une phase de reconnaissance en s’appuyant sur un outil intégré à Windows, destiné à lister les services en cours.
Ce type d’exploration sert généralement à deux choses : comprendre ce qui tourne réellement et identifier des éléments exploitables, notamment pour masquer une activité malveillante sous un comportement “normal” ou choisir ce qui mérite d’être ciblé.
Ensuite, les résultats de cette vérification ont été envoyés vers un serveur contrôlé par l’attaquant. L’idée n’est pas seulement d’agir tout de suite : il peut aussi préparer la suite, analyser plus tard ou alimenter des outils automatisés.
Persistance : rendre l’accès durable
Ce qui rend ce cas particulièrement parlant pour la remédiation, c’est la façon dont l’attaquant a transformé l’environnement pour sécuriser son retour. Plusieurs actions visent directement la persistance :
- Activation de l’accès Remote Desktop sur une machine où il n’était pas auparavant configuré.
- Création d’un nouvel utilisateur puis ajout de cet utilisateur au groupe Administrateurs locaux, ce qui fournit un niveau élevé de privilèges et peut survivre à des nettoyages “superficiels”.
- Connexion via Remote Desktop en utilisant ce compte nouvellement créé.
- Désactivation de Windows Defender, la protection antivirus intégrée à Windows.
Un détail attire l’attention : les analystes notent que d’autres solutions de surveillance, par exemple un composant de type EDR, n’ont pas été désactivées. Cela peut indiquer soit une absence de détection de cet outil, soit une impossibilité (technique ou opérationnelle) de le neutraliser.
Exploiter le serveur web : transformer IIS en vecteur
La suite ne s’est pas limitée au poste compromis. L’attaquant a également installé des add-ons malveillants pour Internet Information Services (IIS), le logiciel de serveur web présent sur la machine.
Ces modules font partie d’une famille connue sous le nom de BadIIS. Leur fonction typique est de détourner le trafic vers des objectifs frauduleux liés au référencement et à la publicité : redirection de visiteurs, injection de liens cachés, ou présentation de contenu différent de ce que l’utilisateur croit atteindre.
En clair, l’attaquant transforme le serveur de la victime en plateforme pour manipuler la visibilité en ligne et générer un trafic “utile” à la fraude, tout en restant discret.
Rentabiliser la compromission : minage de cryptomonnaies
Un autre levier a été introduit sur la machine : un programme de minage de cryptomonnaies. L’objectif est généralement de tirer profit de la puissance de calcul de la victime, en échange d’un coût électrique supporté par l’organisation compromise.
Pour réduire la probabilité de détection, l’attaquant a mis en place des mesures de masquage :
- Dissimulation des fichiers via des attributs “hidden”, “system” et “read-only”, ce qui complique une vérification manuelle dans l’explorateur de fichiers.
- Exécution en tant que service Windows à l’aide d’un outil d’administration disponible librement, afin que le processus démarre automatiquement et continue après un redémarrage.
- Ajout d’un outil complémentaire conçu pour aider la charge malveillante à échapper à la détection.
Orchestration silencieuse : scripts, PowerShell et persévérance
Tout au long de l’incident, l’intrus a téléchargé plusieurs scripts PowerShell et des fichiers batch depuis des serveurs externes. C’est une pratique fréquente : elle évite de tout embarquer dès la première compromission et permet d’évoluer au fil de l’action.
De plus, le recours à PowerShell a été fait de manière silencieuse : exécution sans fenêtre visible, sans invites de sécurité et sans contraintes liées aux politiques d’exécution habituelles de Windows.
Pris un par un, ces mécanismes ne sont pas “uniques”. Ce qui se démarque dans ce dossier, selon l’analyse, c’est l’accumulation d’ajustements opérés dans un seul incident, sur une seule machine. C’est précisément ce que les équipes doivent anticiper au moment de nettoyer.
Ce que cela signifie pour la défense
Beaucoup d’organisations ont l’impression d’avoir un “avantage de terrain” parce qu’elles administrent leurs propres environnements. Toutefois, cet avantage disparaît dès que la protection est incomplète : si l’on ne planifie pas la détection et la réponse, un attaquant peut remodeler la machine à son avantage.
La leçon majeure pour la sécurité n’est pas seulement de supprimer ce qui est évident. Il faut surtout trouver et corriger le point d’entrée. Sans cela, l’attaquant peut revenir par la même porte, même si les comptes et les outils visibles ont été retirés.
Dans ce cas, l’entrée reposait sur une faille d’entrée non validée dans une page web exposant une injection SQL. Une approche centrée uniquement sur l’éradication “post-attaque” aurait pu échouer à stopper le retour.
Plan d’action pragmatique après un incident
Pour réduire la probabilité d’un scénario similaire, l’enquête encourage de démarrer par les bases, puis d’aller vers des actions systématiques :
- Faire l’inventaire : connaître précisément les systèmes physiques et virtuels, ainsi que les applications en service et leurs versions.
- Réduire la surface d’attaque : moins de services exposés et moins d’applications disponibles, moins d’opportunités.
- Supprimer l’inutile : ce qui n’est pas requis n’apporte pas de bénéfice et augmente le risque.
- Verrouiller les accès : réserver l’accès aux personnes autorisées et généraliser l’usage de l’authentification multifacteur (MFA) lorsque possible.
- Mettre à jour et surveiller : patcher régulièrement les applications actives et s’assurer qu’elles sont couvertes par les systèmes de monitoring.
- Rechercher la cause racine à chaque fois : au-delà de retirer la charge malveillante, comprendre comment l’attaquant est entré afin d’améliorer durablement la posture.
En résumé, l’attaquant parie sur le fait que les équipes se contenteront d’un nettoyage “au niveau de la surface”. En descendant au point d’entrée réel, vous conservez votre avantage, celui du contrôle.
Pourquoi cette approche “après l’intrusion” change tout
Le cœur du problème est psychologique autant que technique. L’intrusion est souvent perçue comme l’événement principal, mais l’incident devient réellement dangereux quand l’attaquant s’installe, crée des accès et trouve des moyens d’opérer sans être stoppé.
Le cas étudié illustre cette trajectoire : reconnaissance, persistance via comptes et accès distants, neutralisation d’une partie de la protection antivirus, puis abus du serveur web et exploitation des ressources pour le minage. Cette séquence montre que la réponse doit être complète : elle doit viser autant l’éradication que la correction.
Si vous traitez les symptômes uniquement, l’intrus peut exploiter la même faiblesse pour revenir. Si vous corrigez la porte d’entrée, vous coupez la possibilité de réexécution et vous réduisez fortement le risque de récidive.
Conclusion : l’étape après l’intrusion est souvent celle où l’attaquant “choisit sa maison”. Votre tâche, de votre côté, est de reprendre le contrôle en corrigeant la cause réelle de l’accès initial, tout en renforçant les pratiques de surveillance, d’hygiène applicative et de durcissement des accès.
