Archives par mot-clé : Active Directory

DarkMoon automatise le pentest avec des agents IA

DarkMoon veut transformer le pentest ponctuel en contrôle continu, grâce à des agents IA capables de raisonner, exploiter et documenter chaque vulnérabilité dans un environnement maîtrisé.

DarkMoon est une plateforme open source de pentest autonome conçue par Mehdi Boutayeb. Son ambition : automatiser une évaluation de sécurité complète, depuis la reconnaissance jusqu’au rapport final, en exigeant une preuve avant chaque vulnérabilité confirmée. L’architecture sépare le raisonnement du modèle IA de l’exécution des outils offensifs grâce au Model Context Protocol. Plus de 50 agents spécialisés peuvent intervenir sur le web, les API, Active Directory, Kubernetes, le cloud ou l’IoT. Le projet ajoute une Privacy Gateway destinée à masquer localement les informations sensibles avant leur traitement par un modèle externe. Son objectif est de rendre le pentest continu, reproductible et exploitable dans des infrastructures sensibles.

De la toolbox personnelle au pentest autonome

DarkMoon trouve ses racines bien avant l’arrivée des agents IA. Mehdi Boutayeb explique avoir commencé à développer ses propres outils très jeune. « Lorsque j’avais 13 ans, je bricolais déjà un émulateur pour le plaisir de comprendre la machine de l’intérieur, et cette habitude de fabriquer mes propres outils ne m’a jamais quitté. »

Cette logique donnera d’abord naissance à une distribution GNU/Cygwin utilisée comme boîte à outils de développement. En 2023, Boutayeb réoriente le projet vers la sécurité offensive. Toujours basée sur Cygwin, cette nouvelle version accueille plusieurs outils de pentest initialement conçus pour Linux. Les difficultés de compatibilité finissent toutefois par imposer une nouvelle architecture. Le développement migre vers WSL. Ce changement permet d’intégrer davantage d’outils, puis un serveur MCP et une interface TUI destinée au pilotage des agents IA.

« C’est cette évolution, de la toolbox portable au moteur autonome, qui a donné le Darkmoon d’aujourd’hui. Le fil est le même depuis le début : construire les outils que j’aurais voulu avoir, aller au fond de la machine, et les ouvrir. » explique l’auteur à DataSecuritybreach.fr

Cette histoire personnelle rejoint une problématique professionnelle. Mehdi Boutayeb et Aurélien travaillent comme pentesters dans l’entreprise qu’ils dirigent. Boutayeb revendique également une expertise d’architecte cybersécurité auprès de clients tels qu’Airbus. Sur le terrain, il décrit un écart persistant entre les scanners automatisés et les audits humains.

Les premiers, qu’il s’agisse de SAST, d’analyse de dépendances ou de scanners dynamiques, produisent rapidement une quantité importante de signaux. Leur limite tient à l’interprétation de ces résultats. Un outil SAST peut détecter un motif suspect. Un scanner de dépendances peut identifier une CVE dans un composant qui, en pratique, ne sera jamais appelé. La découverte reste alors à qualifier.

Selon Boutayeb, cette accumulation transfère une partie essentielle du travail vers les analystes. Ils doivent hiérarchiser, reproduire, écarter certains résultats et identifier les vulnérabilités réellement exploitables. La fatigue liée aux alertes devient ainsi un problème opérationnel à part entière. À l’autre extrémité se trouve le test d’intrusion humain. Celui-ci sait enchaîner plusieurs faiblesses, explorer un chemin d’attaque et confirmer concrètement qu’une vulnérabilité peut être exploitée.

Son principal défaut est temporel.

Un audit effectué une ou deux fois par an reste une photographie du système à une date donnée. Lorsque le développement avance en continu, l’environnement examiné peut déjà avoir changé lors de la livraison du rapport. « Dans un SI qui livre en continu, un audit ponctuel est structurellement en retard. Bref, un outillage rapide qui fait du bruit, une expertise lente qui fait de la preuve, et rien qui donne les deux au rythme des changements. » confie l’auteur à Data Security breach.

C’est précisément cet espace que DarkMoon cherche à occuper.

L’objectif du projet consiste à automatiser une partie de l’approche offensive sans abandonner la méthodologie du pentester, la collecte de preuves, la traçabilité de l’exécution ni la possibilité de contrôler les résultats. Le choix de l’open source répond également à une contrainte de souveraineté technique. DarkMoon peut fonctionner en local, une caractéristique présentée comme essentielle pour les infrastructures dont les données ne peuvent pas être transmises à un service d’intelligence artificielle distant.

Boutayeb cite notamment les banques, les établissements hospitaliers, les opérateurs d’importance vitale et la défense.

Son raisonnement est simple : ces organisations doivent pouvoir utiliser des capacités de raisonnement automatisé sans exposer leur système d’information à un modèle hébergé à l’extérieur de leur périmètre. Cette volonté explique une partie de l’architecture de DarkMoon. Le modèle chargé de réfléchir ne commande pas directement le système. Un orchestrateur, OpenCode, dialogue avec le LLM, détermine les prochaines étapes et transmet les actions à une couche de contrôle fondée sur le Model Context Protocol.

Le serveur MCP n’expose qu’une liste prédéfinie d’outils et de workflows. Chaque action passe par le serveur MCP. L’exécution intervient dans un conteneur Docker isolé comprenant de nombreux outils de sécurité. Parmi ceux cités figurent Nuclei, sqlmap, BloodHound et NetExec. DarkMoon découvre les ports et services accessibles, identifie les technologies, établit une représentation de la surface d’attaque, puis mobilise les agents adaptés.

Chaque résultat peut modifier la suite de l’évaluation.

Un WordPress identifié pendant la reconnaissance peut provoquer l’intervention d’un agent spécialisé dans les CMS. Une interface GraphQL découverte plus tard peut réorienter une partie des investigations vers un autre agent.

Les méthodologies revendiquées s’appuient notamment sur ISO 27001, NIST SP 800-115 et MITRE ATT&CK.

Le périmètre autorisé est fourni au lancement sous forme de cibles, domaines, applications ou plages IP. L’orchestrateur doit travailler à l’intérieur de cette frontière.

Ajouter une nouvelle capacité nécessite également une intervention explicite. L’outil doit être installé, enregistré dans MCP et rendu accessible à l’orchestration.

Privacy Gateway, preuves et agents spécialisés

Pour Mehdi Boutayeb, qualifier DarkMoon de système autonome ne revient pas à parler d’un scanner traditionnel auquel une interface conversationnelle aurait été ajoutée.

La différence revendiquée tient au raisonnement et surtout à la validation.

Les agents énumèrent une cible, établissent une hypothèse, tentent de l’exploiter et ne valident un résultat qu’après obtention d’une preuve. L’objectif n’est donc pas seulement d’indiquer qu’une faiblesse pourrait exister. DarkMoon cherche à démontrer un chemin d’attaque exploitable.

Cette distinction rejoint le principe employé pour le reporting.

Les simples réponses HTTP 200, les charges réfléchies ou les indicateurs jugés ambigus sont classés « Unconfirmed ». Une vulnérabilité confirmée doit conserver les commandes exécutées, les sorties brutes, les couples requêtes-réponses HTTP et les traces d’exécution correspondantes. Le modèle sert donc à raisonner sur les observations et à planifier les étapes. La validation repose sur ce que les outils ont effectivement observé ou obtenu sur la cible.

Depuis les premières versions décrites du projet, DarkMoon a également intégré un dispositif que Boutayeb présente comme l’une de ses principales différences : la Privacy Gateway. Son rôle est d’empêcher que des valeurs sensibles soient directement transmises au modèle. Avant l’envoi d’informations au LLM, cette passerelle remplace localement les éléments identifiés comme sensibles par des jetons déterministes. Sont concernés les adresses IP internes, noms d’hôtes, identifiants, secrets, chemins ou portions de code.

Le modèle peut donc recevoir des représentations telles que « IP_PRIVATE_001 » ou « HOST_INTERNAL_001 » à la place des données originales.

Le principe consiste à conserver la structure nécessaire au raisonnement sans communiquer les vraies valeurs.

Lorsque l’un des outils doit agir, DarkMoon réinjecte localement les informations réelles au moment de l’exécution. Les résultats sont ensuite de nouveau masqués avant un éventuel passage par le modèle.

Selon l’auteur, une implémentation correcte de ce mécanisme est compatible avec des environnements air-gap et évite de créer un chemin d’exfiltration.

L’utilisation d’un modèle à poids ouverts exécuté sur une infrastructure locale permet d’aller plus loin. Dans cette configuration, raisonnement, données sensibles et actions restent à l’intérieur du même environnement. Cette capacité répond directement aux contraintes réglementaires, contractuelles ou opérationnelles qui peuvent empêcher certaines organisations d’envoyer des informations internes vers un LLM hébergé dans le cloud.

DarkMoon mise également sur la spécialisation des agents.

Boutayeb évoque désormais plus de 50 agents consacrés à différents domaines : web, API, Active Directory, Kubernetes, AWS, Azure, GCP, CI/CD, bases de données, IoT et firmware.

Le point essentiel n’est pas uniquement leur nombre. Ils partagent un contexte commun et peuvent se transmettre une investigation.

C’est cette continuité que le projet cherche à exploiter pour reconstruire des scénarios dépassant une seule technologie.

Un secret retrouvé dans l’historique Git peut, par exemple, permettre d’obtenir un rôle dans le cloud. Une SSRF peut conduire vers un service de métadonnées. Un registre incorrectement configuré peut exposer un jeton. Un appareil IoT compromis peut offrir un accès au réseau interne, puis conduire vers Active Directory.

Pris séparément, chacun de ces éléments peut sembler relever d’un outil ou d’une équipe différente.

Pris ensemble, ils constituent un chemin d’attaque. Cette lecture transversale correspond davantage au fonctionnement réel d’une compromission. L’intérêt d’un système agentique est alors de conserver le contexte et les preuves lorsque l’investigation passe d’une technologie à une autre. Le projet affirme également disposer de plus de 80 outils offensifs, parmi lesquels NetExec, BloodHound et Impacket.

Chaque commande est explicitement exécutée, encadrée et journalisée. La méthodologie employée par chaque agent reste contenue dans un playbook Markdown lisible et modifiable. DarkMoon est proposé sous licence GPLv3, avec une édition Community gratuite et open source. Le projet revendique l’absence de prompts cachés et de mécanisme propriétaire de notation. Cette transparence doit permettre à un utilisateur d’examiner le comportement du système au lieu de déléguer l’évaluation à une boîte noire.

Le reporting suit la même logique.

Une découverte confirmée est accompagnée de la requête utilisée, de la sortie obtenue et de l’accès éventuellement acquis. L’idée est de diminuer le temps consacré à reproduire les vulnérabilités et à trier les faux positifs. Le rapport cherche ainsi à répondre simultanément aux besoins du pentester, qui doit pouvoir rejouer la preuve, et à ceux du RSSI, qui doit décider rapidement d’une correction ou d’une acceptation du risque.

La continuité constitue l’autre volet du projet

DarkMoon peut être intégré à GitHub Actions afin de déclencher une évaluation depuis un pipeline. Le scénario envisagé n’est plus uniquement un pentest trimestriel ou annuel. Une organisation pourrait lancer des contrôles après des changements significatifs.

Boutayeb cite plusieurs cas : des secrets oubliés dans un historique Git, une configuration Infrastructure as Code accordant trop de privilèges, une image de conteneur contenant une porte dérobée ou un runner CI dont les identifiants permettent d’atteindre la production.

L’ambition est de rapprocher le rythme du pentest de celui des changements apportés au système d’information.

Le coût dépend toutefois du modèle choisi.

Selon Boutayeb, un test typique d’application web avec Claude Opus représente environ 10 $ de frais d’API. La conversion en euros ne peut être calculée rigoureusement à partir des seules informations communiquées, puisqu’aucun taux de change n’est fourni.

Les évaluations portant sur Active Directory ou plusieurs machines consomment davantage de ressources, le modèle devant continuer à analyser les nouvelles informations et planifier des chemins d’attaque.

DarkMoon prend en charge OpenAI, Anthropic et OpenRouter. Une utilisation locale est également proposée avec Ollama ou llama.cpp.

Boutayeb estime que Claude offre actuellement un bon compromis concernant le raisonnement, la stabilité de planification et la gestion de longs contextes.

Le comportement des mécanismes de sécurité intégrés aux modèles reste toutefois une variable importante pour les usages offensifs autorisés.

Dans les essais rapportés par le projet, Claude Opus 4.8 a rencontré des limitations pendant une évaluation. Claude Opus 4.6 aurait exécuté la mission jusqu’à son terme sans interruption. Le projet présente donc Opus 4.6 comme un choix plus stable et mentionne le Cyber Verification Program d’Anthropic pour les organisations susceptibles d’y accéder. Les modèles de petite taille situés dans les gammes de paramètres inférieures ne sont pas pris en charge pour ces missions autonomes. Une exécution entièrement locale peut, à l’inverse, éviter les coûts liés aux API. « En résumé, son utilisation peut être entièrement gratuite si vous exécutez tout en local, ou coûter quelques dollars par évaluation si vous souhaitez bénéficier de la qualité de raisonnement supérieure d’un modèle de pointe. Chaque utilisateur choisit son propre équilibre entre coût et performances. » Résume à DataSecuritybreach.fr l’instigateur du projet.

Le fonctionnement concret reste volontairement accessible. DarkMoon s’installe sur l’infrastructure de l’utilisateur, à partir du dépôt Git ou avec Docker Compose. Le système est ensuite dirigé vers une cible autorisée ou vers un laboratoire conçu pour l’entraînement. L’orchestrateur utilise MCP pour coordonner les agents. Chaque spécialiste applique son playbook Markdown. Le LLM assure la planification et le raisonnement, tandis que la Privacy Gateway intervient avant les échanges contenant des valeurs sensibles. Les vraies données sont réinjectées localement uniquement lorsqu’elles deviennent nécessaires à l’outil.

Chaque étape laisse un artefact : commande, résultat brut et éléments de raisonnement. Le rapport final est construit à partir de ces preuves. Pour tester légalement le système, Boutayeb cite OWASP Juice Shop pour les applications web et les API, GOAD (Game of Active Directory) pour les environnements Active Directory et Kubernetes Goat pour les infrastructures conteneurisées.

Il avance également un résultat obtenu sur Juice Shop : DarkMoon aurait identifié 57 vulnérabilités réelles, chacune associée à un exploit fonctionnel.

Reste la question qui dépasse DarkMoon : l’intelligence artificielle donnera-t-elle d’abord l’avantage aux attaquants ou aux défenseurs ? Medhi Boutayeb refuse une réponse définitive. « Honnêtement, je n’ai pas de réponses tranchées. L’IA abaisse le coût de l’offensive, et les attaquants l’utilisent déjà pour le phishing, la reconnaissance ou l’adaptation d’exploits. »

Selon lui, cette évolution impose toutefois une réaction symétrique côté défense. Si les attaquants automatisent certaines tâches, les équipes de sécurité doivent elles aussi pouvoir absorber davantage de volume. L’IA ne constitue pas, à ses yeux, un remplacement de l’opérateur. Elle automatise surtout les tâches répétitives.

Le jugement humain reste nécessaire pour interpréter, hiérarchiser et décider.

Son analyse porte donc davantage sur la méthode que sur la puissance brute du modèle. L’avantage reviendrait à ceux capables de déployer l’IA avec discipline, tout en conservant la possibilité de vérifier chacune de ses conclusions. L’attaquant bénéficie d’une asymétrie : il peut expérimenter rapidement sans processus d’autorisation interne. Le défenseur doit au contraire agir dans un cadre contrôlé, documenté et reproductible. La réponse passe donc par un outillage capable d’absorber le volume tout en fournissant des preuves.

DarkMoon matérialise cette vision : faire travailler des agents à la vitesse de l’automatisation sans leur accorder une confiance aveugle, et conserver derrière chaque conclusion une chaîne technique qu’un humain peut inspecter, reproduire et contester.

Sources

L’IA au service d’un piratage éclair de FortiGate

Entre automatisation et négligence, une campagne récente montre comment des interfaces d’administration exposées et des mots de passe faibles suffisent à ouvrir des réseaux entiers, à grande échelle.

Une analyse d’Amazon décrit une campagne menée entre le 11 janvier et le 18 février 2026, où un cybercriminel motivé par le profit a compromis plus de 600 équipements FortiGate dans 55 pays. L’attaque ne reposait pas sur des failles logicielles, mais sur des consoles de gestion laissées accessibles depuis Internet et protégées par une authentification simple avec des mots de passe faciles à deviner. En s’appuyant sur plusieurs services commerciaux d’IA générative, l’attaquant a industrialisé la méthode, récupérant configurations, identifiants, plans réseau et paramètres VPN. Objectif final, pénétrer l’interne, viser Active Directory et sonder les sauvegardes, un signal souvent associé aux préparatifs d’un rançongiciel.

Une intrusion sans vulnérabilité, portée par l’automatisation

Le scénario a quelque chose d’inconfortable, parce qu’il n’exige ni exploit sophistiqué ni compétence rare. D’après Amazon, du 11 janvier au 18 février 2026, soit 38 jours si l’on compte du premier au dernier jour, un acteur cybercriminel a pris pied sur plus de 600 équipements FortiGate répartis dans 55 pays. Le volume et la dispersion géographique donnent l’impression d’une opération structurée, pourtant l’analyse conclut à un profil non étatique, plutôt un loup solitaire ou un petit noyau opportuniste.

Le point d’entrée n’est pas une vulnérabilité du produit. L’attaquant a cherché des interfaces de gestion directement exposées sur Internet, puis a tenté de deviner ou de forcer des mots de passe trop faibles, avec une authentification à facteur unique. Le cœur du problème est donc une erreur de configuration élémentaire, que l’on retrouve encore dans des entreprises de toutes tailles, parfois par héritage de choix anciens, parfois par manque de contrôle, souvent parce que l’accès distant “temporaire” finit par devenir permanent.

Ce qui change, selon Amazon, c’est la cadence. Plusieurs services commerciaux d’IA générative auraient servi à mettre en place une chaîne d’actions quasi automatique. L’IA ne « pirate » pas à elle seule, mais elle peut accélérer la préparation, l’enchaînement des étapes, la normalisation des commandes, l’adaptation des scripts et la production de variations lorsque l’environnement diffère légèrement. À l’échelle d’Internet, ce gain de temps transforme une routine d’attaquant en moisson industrielle. Quand la barrière technique baisse, le véritable facteur limitant devient la discipline d’hygiène numérique du côté des défenseurs.

De la configuration au cœur du réseau, la trajectoire classique

Une fois l’équipement compromis, l’attaquant a téléchargé les configurations complètes. C’est un trésor opérationnel, parce qu’il peut y trouver des identifiants, des informations de topologie, des indices sur la segmentation, ainsi que des paramètres de réseau privé virtuel. À partir de là, le basculement est logique, l’objectif n’est pas l’équipement lui-même, mais la porte qu’il ouvre sur l’infrastructure interne des organisations.

L’analyse décrit ensuite une progression vers les domaines Active Directory. Cette étape est un pivot, car Active Directory concentre l’identité, les droits et souvent les clés d’accès aux ressources critiques. L’attaquant a extrait des bases de données de comptes et, dans certains cas, a obtenu des ensembles complets de hachages de mots de passe. Même sans casser immédiatement ces hachages, leur possession facilite la réutilisation d’identifiants, les tentatives hors ligne et la cartographie des privilèges.

Un autre détail pèse lourd, l’intérêt marqué pour les serveurs de sauvegarde. Dans la pratique des intrusions à but lucratif, les sauvegardes sont la bouée de secours des victimes, donc une cible prioritaire pour qui veut monétiser l’accès. L’analyse souligne que cette curiosité pour les systèmes de backup intervient fréquemment avant le déploiement d’un rançongiciel. Autrement dit, la compromission du périmètre n’est qu’un début, le vrai risque se situe dans la capacité à rendre la restauration impossible ou douloureuse.

Enfin, la campagne semble guidée par un pragmatisme froid. Lorsque l’environnement imposait des opérations plus complexes, l’attaquant ne s’acharnait pas et passait à une autre cible. Cette discipline révèle une logique de rendement, maximiser les gains en minimisant le temps passé par victime. C’est précisément là que l’IA générative, utilisée comme accélérateur, renforce le modèle, elle aide à standardiser l’approche et à éliminer les frictions, sans nécessairement augmenter la profondeur technique de l’attaque.

Au bout du compte, cette affaire rappelle une vérité de cyber-renseignement, l’avantage revient à celui qui transforme de petites failles d’hygiène en informations actionnables, vite, à grande échelle.

SwiftSlicer, un nouveau virus pour détruire Windows ?

Des chercheurs identifient un nouveau logiciel malveillant de récupération de données du nom de SwiftSlicer capable de détruire Windows.

Voilà un code malveillant dès plus déplaisant. Son nom, SwiftSlicer. On peut traduire cette chose par « trancheur rapide ». Sa mission malveillante et d’écraser les fichiers importants utilisés par le système d’exploitation Windows.

SwiftSlicer utilise la stratégie de groupe Active Directory qui permet aux administrateurs de domaine d’exécuter des scripts et des commandes sur tous les appareils d’un réseau Windows.

Ce virus a été déployé pour supprimer (ou écraser) les fichiers critiques dans le répertoire système de Windows, en particulier les pilotes et la base de données Active Directory.

SwiftSlicer écrase les données en utilisant des blocs de 4096 octets remplis d’octets générés aléatoirement. Une fois le code de destruction des données terminé, le logiciel malveillant redémarre et remet les systèmes à zéro.

Sécurisation des connexions Active Directory

Comment sécuriser des connexions Active Directory aussi simplement que possible ? La société IS Decisions propose sa solution UserLock qui permet de maintenir les portes fermées aux assauts pirates.

La solution de gestion des accès UserLock est évaluée par James Rankin, spécialiste de la connexion de la protection des accès. Il explique qu’UserLock a beaucoup de potentiel. « J’ai trouvé la configuration initiale très facile et en particulier la configuration MFA était également extrêmement simple.« . La fameuse et indispensable double authentification qui laissera n’importe quel pirate au porte de l’espace qu’il convoite. « Il n’est pas surprenant que la sécurisation de l’accès à Active Directory figure en tête de liste des priorités, car un pourcentage important d’entreprises s’appuient sur AD pour étayer leurs applications et services » confirme James Rankin.

Pour en savoir plus sur UserLock est l’amélioration de la gestion et la sécurité d’une implémentation AD, un test complet est présenté ici.

Observation de l’évolution des tactiques de diffusion des ransomwares

Il y a quatre ans de cela, les criminels envoyaient des mails à des millions d’adresses, diffusant des variantes de logiciels rançonneurs, via des liens infectés ou des documents Word, sans logique ou ciblage apparent. Aujourd’hui, les ransomware se professionnalisent !

Lorsque les logiciels rançonneurs ont commencé à chiffrer les ressources disponibles sur les réseaux, les entreprises ont commencé à y prêter un peu plus attention. Cette étape de l’évolution des logiciels rançonneurs a vu la méthode de diffusion éparpillée précédemment mentionnée se combiner au chiffrement de fichiers disponibles aussi bien sur le serveur local que sur les serveurs d’entreprise. Le chiffrement du serveur de fichiers d’une infrastructure ou de son système de stockage en réseau entraîne plus de dommages pour l’entreprise que le chiffrement d’un poste de travail individuel. Dans ce contexte, la hotline de notre équipe d’intervention a commencé à recevoir plus d’appels, au cours desquels les administrateurs informatiques des systèmes touchés par des logiciels rançonneurs ont commencé à se poser des questions très sérieuses sur les conséquences associées au paiement des rançons.

Cette tendance des ransomwares à chiffrer les partages réseau, et l’attention accrue qui en résulte, est probablement à l’origine des phases suivantes de leurs techniques de déploiement.

Frappes de précision : l’essor du protocole RDP (Remote Desktop Protocol)

En 2016, nous avons commencé à constater des infections massives de logiciels rançonneurs au cours desquelles plusieurs actifs essentiels de l’environnement des victimes étaient simultanément infectés, et avons donc constaté davantage d’interactions entre les agresseurs et leurs victimes (en raison de l’impact de leurs logiciels rançonneurs sur l’environnement des victimes). La communauté de sécurité s’est livrée à des enquêtes plus poussées qui ont confirmé ces soupçons : des cybercriminels utilisaient le protocole RDP, un protocole propriétaire conçu par Microsoft, pour fournir aux utilisateurs l’interface graphique d’un système distant, afin de s’introduire dans l’environnement des victimes.

Une fois en place, les agresseurs déployaient généralement des outils permettant de rechercher et d’exploiter des relations utilisateur/groupe/administrateur mal configurées ou non intentionnelles. Les paramètres Active Directory mal configurés ou non intentionnels sont les meilleurs alliés des cybercriminels, en leur permettant d’accéder aux privilèges de l’administrateur du domaine. Dès que le compte de ce dernier est compromis, les hackers ont la possibilité d’effectuer une reconnaissance du réseau pour identifier les actifs les plus critiques et les infecter.

Après avoir identifié les serveurs critiques et les systèmes de sauvegarde dans l’environnement, les hackers peuvent désormais utiliser les outils d’administration système intégrés à Windows pour déployer largement leurs logiciels rançonneurs.

A ce stade, les agresseurs n’essayaient donc plus d’envoyer un email à chaque personne présente sur le web. Avec le protocole RDP, ils savaient exactement qui et quoi cibler, en infectant simultanément des ressources critiques grâce à leur nouvel accès à l’environnement des victimes.

La prochaine étape des logiciels rançonneurs : les botnets

La tactique consistant à utiliser le RDP comme base initiale pour ces déploiements de logiciels rançonneurs en volume, interactifs, programmés ou manuels, était devenue si courante qu’elle faisait l’objet de nos premières questions lors de la prise en charge de nouveaux incidents. Cependant, pour les cas récents tels que le logiciel rançonneur Ryuk [1], nous assistons à une autre évolution des tactiques de diffusion. Lorsque nous enquêtons sur les victimes pour déterminer si elles sont exposées au niveau du RDP, nous pouvons constater que ce protocole n’est pas activé, ou que l’accès se fait via VPN. Dans cette mesure, il n’expose pas directement les victimes sur Internet.

Ces cas nécessitent des enquêtes plus approfondies. Dans plusieurs cas récents, nous découvrons des infections de bots corrélées à la chronologie des infections de logiciels rançonneurs.

Au cours du mois dernier, nous avons observé des infections de TrickBot, d’Emotet et d’AdvisorsBot qui correspondent parfaitement au moment du déploiement des logiciels rançonneurs. Ces infections par bots sont généralisées dans l’environnement des victimes, et tirent également parti des relations d’approbation mal configurées dans Active Directory pour se répandre latéralement. Cette tendance à l’utilisation des bots pour s’implanter ne fait qu’augmenter.

Dans ces cas, nous constatons que des e-mails de phishing contenant des documents Word malveillants sont le vecteur de diffusion des bots. Ces documents Word malveillants contiennent un contenu exécutable appelé macros. Lors de nos analyses des infections par TrickBot et AdvisorsBot relatives aux logiciels rançonneurs, nous constatons que les victimes ont ouvert le mail. Ouvert les documents joints. Permis aux macros de s’éxecuter.

À ce stade, le contenu exécutable dans les macros installe un bot ou contacte le serveur de commande et de contrôle du botnet pour obtenir du code malveillant supplémentaire, qui est finalement le véritable logiciel malveillant.

C’est une évolution des tactiques de déploiement des logiciels rançonneurs. La tendance observable de diffusion des ransomwares, allant de l’email de phishing opportuniste jusqu’à l’implantation et la reconnaissance via une configuration RDP compromise, se poursuit aujourd’hui par une implantation avancée au cœur du réseau grâce à des infections par bots qui se propagent latéralement.

En conclusion, la tendance d’implantation des bots pour propager des logiciels rançonneurs continuera à se développer. A l’avenir, différents bots seront utilisés simultanément. Mais le fait qu’ils offrent une persistance et facilitent le déploiement de logiciels malveillants supplémentaires en font un choix évident en matière d’implantation malveillante.

Conseil de l’équipe d’intervention Check Point

Au cours des différentes enquêtes, il a été découvert que la plupart des victimes avaient involontairement autorisé l’accès RDP au réseau depuis Internet en raison de la configuration des règles de sécurité sur le pare-feu, autorisant trop de ports ou configurant incorrectement l’IP/le masque réseau. La fonctionnalité « Packet Mode » de R80.10 [1] nous permet de vérifier rapidement si les ports RDP sont exposés sur Internet. Les règles de la blade Compliance (conformité) peuvent également être configurées pour émettre une alerte en cas d’exposition accidentelle de RDP. (Par l’équipe d’intervention de Check Point).