DarkMoon est un projet libre de cybersécurité publié sous licence GNU GPLv3. Il propose un moteur de test d’intrusion automatisé, lancé en conteneur Docker, qui orchestre des outils de sécurité existants, des agents spécialisés et un modèle de langage configurable.
Concrètement, l’utilisateur donne une cible autorisée. DarkMoon lance des étapes de reconnaissance, identifie des technologies exposées, choisit certains outils ou agents selon le contexte, puis produit des journaux et un rapport de pentest en Markdown.
Le projet est récent. Le premier commit visible sur GitHub date de novembre 2025, le dépôt a été rendu public en mai 2026, et une première release a été publiée récemment. Au moment de la rédaction, les mainteneurs indiquent un peu plus de 500 clonages du dépôt et environ 1300 téléchargements des images Docker. Ces éléments donnent un premier signal d’usage, sans en faire pour autant un outil éprouvé en production.
DarkMoon essaie de répondre à une question simple : peut-on automatiser une partie d’un pentest sans se limiter à lancer un scanner unique ?
Le fonctionnement attendu est le suivant :
DarkMoon est publié sous licence libre GNU GPLv3. Le dépôt GitHub contient les scripts d’installation, l’orchestration Docker, les composants de l’outil, les configurations et la documentation associée.
Le projet n’a pas vocation à remplacer l’expertise humaine d’un pentester. Il vise plutôt à automatiser des tâches répétitives, à aider à la corrélation des résultats, et à produire des sorties plus facilement exploitables. Dans un audit réel, l’interprétation, la validation des constats, la priorisation et le respect du cadre légal restent des responsabilités humaines.
L’usage prévu est strictement limité aux environnements autorisés: laboratoires, machines volontairement vulnérables, programmes de bug bounty, audits internes ou périmètres contractuels.
DarkMoon repose sur trois blocs principaux :
Connexiondarkmoon.sh pour démarrer les campagnes et suivre les journaux.La séparation entre le modèle, le contrôle et l’exécution est importante. Le modèle peut proposer une stratégie, mais les actions passent par une couche de contrôle avant d’être exécutées dans le conteneur. Cela permet de garder une trace des actions et de limiter l’exécution directe sur l’hôte.
L’installation documentée repose sur Docker et Docker Compose. L’utilisateur clone le dépôt, rend les scripts exécutables, puis lance l’installation.
git clone https://github.com/ASCIT31/Dark-Moon.git
cd Dark-Moon
chmod +x install.sh darkmoon.sh
./install.shLe script prépare l’environnement, construit les images nécessaires et initialise les volumes. Une fois l’installation terminée, DarkMoon peut être lancé depuis la racine du dépôt.
./darkmoon.shIl est aussi possible de lancer directement une cible depuis la ligne de commande.
./darkmoon.sh "TARGET: http://172.19.0.3:3000"
DarkMoon ne force pas un fournisseur unique de LLM. Lors de l’installation, on peut configurer un fournisseur cloud comme OpenAI, Anthropic ou OpenRouter, mais aussi un modèle local via Ollama, llama.cpp ou une URL compatible avec l’API OpenAI.
C’est un point important pour un outil de sécurité. Selon le contexte, on peut préférer un modèle distant plus performant, ou un modèle local pour éviter d’envoyer des informations de cible, de journaux ou de résultats vers un service externe.
Une campagne DarkMoon commence par la définition d’un périmètre. La forme minimale consiste à fournir une cible :
./darkmoon.sh "TARGET: http://172.19.0.3:3000"Une forme plus complète permet de préciser le programme, les cibles incluses, les exclusions, les familles de vulnérabilités à privilégier, le niveau de bruit acceptable et les règles d’engagement.
./darkmoon.sh "TARGET: https://app.example.org PROGRAM='Audit interne' TARGETS=*.example.org,API:https://api.example.org OUT=payments.example.org,10.0.0.0/8 FOCUS=sqli,rce,ssrf,idor EXCLUDE=brute-force NOISE=moderate FORMAT=standard RULES='POC only;no real user data'"Après le lancement, l’outil fournit un identifiant de session. Les journaux peuvent ensuite être suivis avec:
./darkmoon.sh --log <session_id>
Une démonstration vidéo montre DarkMoon exécuté contre OWASP Juice Shop, une application volontairement vulnérable conçue pour l’apprentissage et les tests de sécurité applicative. Ce choix est important: il permet d’illustrer le fonctionnement du moteur sur une cible réaliste, mais explicitement prévue pour l’entraînement, sans viser un système tiers.
La vidéo présente le déroulement général d’une campagne: lancement depuis la ligne de commande, analyse de la cible, collecte de signaux techniques, sélection des actions à mener et production progressive d’observations exploitables. Elle permet aussi de mieux comprendre la logique d’orchestration: DarkMoon ne se limite pas à lancer un unique scanner, mais enchaîne plusieurs étapes selon ce qu’il découvre.
Lien de la démonstration : DarkMoon sur OWASP Juice Shop
L’intérêt de Juice Shop dans ce contexte est double. D’un côté, l’application contient de nombreuses familles de vulnérabilités web connues, ce qui permet de tester la capacité de détection et d’enchaînement du moteur. De l’autre, elle fournit un cadre légal et reproductible pour expérimenter l’outil, comparer les résultats et améliorer les agents sans exposer de service réel.
Le moteur commence par collecter des signaux techniques : ports ouverts, services exposés, technologies web, frameworks, CMS, API, en-têtes HTTP, chemins visibles ou comportements applicatifs.
Ces informations servent ensuite à choisir les actions suivantes. Une cible WordPress, une API GraphQL ou un environnement Kubernetes ne déclenchent pas les mêmes outils ni les mêmes agents.
DarkMoon ne réécrit pas les outils de sécurité existants. Il les regroupe dans une image Docker et les appelle selon le contexte détecté.
Parmi les outils cités dans la documentation ou dans les articles qui présentent le projet, on trouve notamment Naabu, Masscan, Nuclei, ffuf, sqlmap, Arjun, wafw00f, Subfinder, Katana, Waybackurls, httpx, WPScan, CMSeeK, Hydra, dig, ainsi que des outils liés à BloodHound, Impacket, kubectl, Kubescape ou Kubeletctl.
Le point important n’est pas la liste exacte des outils, qui peut évoluer, mais la logique d’orchestration: détecter ce qui est pertinent, lancer l’outil adapté, lire la sortie, puis décider de l’étape suivante.
Une campagne produit des journaux et des artefacts. L’utilisateur peut suivre l’exécution, consulter les étapes et récupérer les résultats dans les répertoires de sortie prévus.
DarkMoon génère aussi un rapport de pentest en Markdown. Ce choix est simple: le fichier est lisible dans un terminal, versionnable avec Git, relisible dans une forge, modifiable à la main et convertible ensuite en HTML ou en PDF.
Le rapport doit conserver le contexte de la campagne : cible, périmètre, hypothèses, commandes ou actions utiles, preuves collectées, vulnérabilités relevées, criticité, impact potentiel et pistes de correction.
DarkMoon est un outil offensif. Il doit être utilisé uniquement sur des systèmes pour lesquels l’utilisateur dispose d’une autorisation explicite: laboratoire local, machine volontairement vulnérable, programme de bug bounty, audit interne ou périmètre contractuel.
L’automatisation ne réduit pas les responsabilités de l’utilisateur: définir le périmètre, obtenir les autorisations, éviter les impacts de production et manipuler les données avec précaution.
Les limites sont celles de tout outil de pentest automatisé:
Un modèle peut proposer une action inutile, trop large ou mal adaptée au contexte. La couche de contrôle et les journaux sont donc utiles, mais ils ne dispensent pas d’une revue humaine.
Le projet est ouvert aux retours techniques. Les contributions les plus utiles concernent:
Les remarques sur la clarté du fonctionnement sont également bienvenues, surtout pour éviter de présenter l’outil comme plus mature qu’il ne l’est réellement.
Commentaires : voir le flux Atom ouvrir dans le navigateur
Voici Estampille. Estampille vise à remplacer les fichiers tableurs partout où l’installation d’une suite complète de tests (Squash, HPALM…) n’est pas possible. Il est distribué sous licence GNU GPL.
Cet outil permet de rédiger des cas de test composés de pas de tests. Il permet d’exécuter manuellement ces cas de test autant de fois que nécessaire. Un cas de test peut être appelé dans d’autres cas de tests pour factoriser la rédaction des cas. Les résultats d’exécution sont exportables sous forme de dossiers PDF.
Enfin une page de statistiques offre une vue générale de l’avancement des tests.
Contrairement aux suites logicielles de tests existantes, Estampille n’a pas besoin de base de données, ni de serveur dédié. Les tests et exécutions de tests sont stockées sous la forme de fichiers JSON partageables facilement ; que ce soit par courriel, répertoire réseau partagé, synchronisation cloud, etc.
Cet outil ultra léger (<300 ko tests unitaires compris) est écrit en python et utilise flask pour présenter l’interface graphique sur le navigateur web. Il fonctionne indifféremment sous Linux ou Windows.
Voilà déjà la fin d’une dépêche courte pour un outil simple qui répond à un besoin concret.
Commentaires : voir le flux Atom ouvrir dans le navigateur
