Darkmoon : l'ancienne distribution Cygwin de sécurité devient une plateforme open source de pentest autonome par IA, forte de 50 agents spécialisés

Le projet toulousain d'ASC-IT, distribué sous GPLv3, mise sur une anonymisation locale des données pour faire tourner des agents offensifs sans jamais envoyer le code ni le trafic vers un modèle hébergé à l'étranger


Les lecteurs qui suivent le projet Darkmoon depuis ses débuts le connaissaient sous une tout autre forme. À l'origine, Darkmoon était une distribution GNU/Cygwin portable pour Windows, orientée « toolbox » de développement. En 2023, son auteur en a fait une version orientée sécurité offensive, toujours basée sur Cygwin, en y portant de nombreux outils de pentest habituellement utilisés sous Linux (l'ancien dépôt et sa documentation Developpez restent en ligne). Cette approche s'est heurtée à des limites de compatibilité propres à Cygwin. Le projet a alors été entièrement repensé sur WSL, avec un serveur MCP (Model Context Protocol) et une console TUI pour piloter des agents d'IA. C'est cette nouvelle plateforme, désormais très éloignée de la distribution d'origine, qui vient de franchir un cap avec un ensemble de 50 agents spécialisés.

Pour rappel, une nouvelle génération d'outils de pentest « autonomes » a émergé depuis 2024 : XBOW, Strix, Shannon, PentAGI, HexStrike AI ou encore NodeZero confient à un modèle de langage le soin d'enchaîner reconnaissance, exploitation et rapport. La plupart partagent deux caractéristiques : ils se concentrent surtout sur la couche web, et ils envoient les données de la cible vers un modèle hébergé dans le cloud, le plus souvent aux États-Unis. C'est précisément sur ces deux points que Darkmoon prend le contre-pied.


Une passerelle d'anonymisation pour ne rien envoyer au modèle

La fonction que l'équipe met le plus en avant est une "Privacy Gateway". Le constat de départ est simple : pour raisonner, un agent IA a besoin de voir les données de la cible (adresses IP, noms de machines, identifiants, parfois le code source). Les envoyer à un modèle tiers, souvent hébergé hors d'Europe, est rédhibitoire pour une banque, un hôpital, un industriel ou un acteur souverain. La conformité l'interdit, les clients l'interdisent, et dans certains secteurs la loi l'interdit.

Le mécanisme retenu repose sur une tokenisation déterministe suivie d'une réhydratation locale. Concrètement, avant que quoi que ce soit n'atteigne le modèle, chaque valeur réelle est remplacée par un marqueur stable : une adresse IP devient IP_PRIVATE_001, un nom de machine devient HOST_INTERNAL_001, et ainsi de suite. Le modèle raisonne sur la structure sans jamais voir la valeur réelle. Celle-ci n'est réinjectée que localement, au moment précis où un outil s'exécute, puis de nouveau masquée au retour. Toute tentative d'exfiltration est bloquée. Darkmoon peut par ailleurs fonctionner entièrement sur un modèle local (Ollama, llama.cpp), ce qui rend l'ensemble compatible avec un environnement isolé (air gap). Le code et le trafic restent ainsi sur l'infrastructure de l'utilisateur.

Pour un public attentif à la souveraineté des données, l'argument est direct : là où les outils concurrents transmettent le contexte d'un test d'intrusion à un modèle américain ou chinois, Darkmoon garde tout en local.


50 agents spécialisés

La particularité de Darkmoon est l'étendue de son périmètre. Là où la concurrence se limite le plus souvent aux applications web, le dépôt compte aujourd'hui 50 agents de méthodologie, écrits en Markdown lisible et auditable, orchestrés par un agent chef (« pentest »). Le maillage couvre notamment :

  • le web et les CMS : agents dédiés à WordPress, Drupal, Joomla, Magento, PrestaShop, Moodle, ainsi qu'aux stacks Node.js/Angular, PHP, Flask, Spring Boot, ASP.NET, Ruby, Go et GraphQL ;
  • le cloud public et privé : AWS, Azure, GCP, Entra ID ;
  • l'infrastructure interne et l'identité : Active Directory, PKI/ADCS, SSO/IdP, VPN et accès distant, pare-feu et réseau, MDM ;
  • les conteneurs et l'orchestration : Kubernetes, Docker, registres de conteneurs, plateformes de conteneurs, GitOps ;
  • la chaîne CI/CD et l'IaC : GitHub, GitLab, Jenkins, Ansible, Terraform ;
  • les données et les secrets : bases SQL et NoSQL, messagerie/cache, stockage, sauvegardes, HashiCorp Vault ;
  • l'embarqué et le mobile : firmware, objets connectés, applications mobiles ;
  • et d'autres surfaces : hyperviseurs, messagerie d'entreprise, observabilité.


Le dispatch est déclenché par un artefact concret et non par une simple inférence : un agent ne se lance que sur une preuve tangible (une clé qui fuit, un port ouvert, une image de firmware), ce qui limite les faux positifs. Quelques exemples parlants tirés des retours publiés : trois agents lancés en parallèle attaquent simultanément un coffre Vault, un registre de conteneurs et un socket Docker exposé ; un agent Terraform lit un fichier d'état et y relève 16 vulnérabilités, dont 10 critiques ; un agent firmware ouvre une image, en extrait mots de passe et portes dérobées, puis obtient un accès root sur l'objet en direct. La plateforme sait aussi enchaîner les couches : un secret oublié dans l'historique Git qui remonte jusqu'à un accès AWS, ou une SSRF transformée en accès initial sur GCP.


Des mesures reproductibles sur différents laboratoire

Chaque découverte est accompagnée d'une preuve d'exploitation (la commande jouée et son résultat brut), ce qui rend les résultats reproductibles. Le banc d'essai de référence est OWASP Juice Shop, une application web délibérément vulnérable, maintenue par l'OWASP à des seules fins de formation et de test (et non une cible réelle, ce qui écarte toute question de légalité). En boîte noire et sur un modèle local, Darkmoon y rapporte 57 vulnérabilités ; une vidéo de démonstration de cette exécution autonome est disponible:



D'autres campagnes publiées font état de 22 découvertes sur un couple PostgreSQL/MySQL, ou de 16 sur un fichier d'état Terraform. L'auteur documente également ses tests sur des environnements de démonstration tiers, comme celui d'OpenNHP, avec la méthodologie associée.

Sur le plan de la comparaison, Darkmoon se distingue moins par un score brut que par deux axes rarement réunis : la capacité à fonctionner sur un modèle local sans exfiltration de données, et l'étendue du périmètre (du web à l'Active Directory, du cloud au firmware, en passant par le CI/CD). Les outils comme Strix ou Shannon, souvent cités pour leurs résultats, opèrent en cloud et se concentrent sur d'autres axes ; l'équipe publie ses conditions de test en clair et invite à contester ou reproduire les chiffres.


Open source, dockerisé et pensé pour le DevSecOps

Darkmoon est publié sous licence GPLv3 et s'installe en auto-hébergement via docker-compose. Le projet fournit également une intégration à la chaîne CI/CD : un dépôt de démonstration montre un déclenchement du test d'intrusion via GitHub Actions, avec remontée des résultats sous forme d'artefacts. L'ensemble s'adresse donc autant à l'équipe sécurité qu'aux pipelines DevSecOps.

Le développement reste actif : les derniers commits ajoutent de nouveaux agents et corrigent des références d'outils avant l'exécution, afin d'éviter qu'un binaire mal nommé ne fasse échouer un vecteur. Le projet est développé à Toulouse par ASC-IT.


Une couverture dans la presse spécialisée

Depuis sa publication, le projet a été présenté par plusieurs médias spécialisés en sécurité et en logiciel libre, en France comme à l'étranger. Help Net Security et Cyber Security News ont détaillé son fonctionnement, de même que SecurityBrief au Royaume-Uni, LinuxLinks et Let's Data Science, ainsi qu'en français UnderNews. Ces articles reviennent tous sur le même parti pris : garder les données de la cible hors du modèle, là où le reste du marché s'appuie sur des modèles hébergés dans le cloud. L'équipe s'en tient par ailleurs à des mesures reproductibles et à des conditions de test publiées, plutôt qu'à des effets d'annonce.

Darkmoon est par ailleurs recensé par le projet de veille LLM4Pentest, qui cartographie les outils de pentest fondés sur les LLM et retient notamment ses sous-agents spécialisés, sa couverture de l'Active Directory et de Kubernetes, et l'orchestration de plus de 80 outils via MCP.


Et vous ?

Que pensez-vous de l'approche par anonymisation locale des données pour le pentest par IA ?
Un périmètre aussi large (web, cloud, AD, conteneurs, CI/CD, firmware) vous paraît-il pertinent, ou préférez-vous des outils spécialisés ?
La souveraineté des données pèse-t-elle dans votre choix d'un outil de sécurité ?


Sources