Sommaire
Ce que fait DarkMoon
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 :
- on fournit une cible autorisée ;
- le moteur lance des outils de reconnaissance ;
- il collecte des indices : ports, services, CMS, API, frameworks, chemins, en-têtes, comportements applicatifs ;
- il choisit les modules utiles selon ce qu’il observe ;
- il exécute les outils dans un conteneur ;
- il conserve les journaux ;
- il génère un rapport Markdown.
Un projet libre orienté sécurité offensive contrôlée
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.
Architecture générale
DarkMoon repose sur trois blocs principaux :
- un conteneur Docker qui fournit l’environnement d’exécution.
- un lanceur
darkmoon.sh pour démarrer les campagnes et suivre les journaux.
- une logique d’orchestration qui choisit les outils ou agents à lancer selon les éléments détectés.
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.
Installation
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.sh
Le 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.sh
Il est aussi possible de lancer directement une cible depuis la ligne de commande.
./darkmoon.sh "TARGET: http://172.19.0.3:3000"
Choix du modèle de langage
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.
Exemple de campagne
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>
Démonstration sur OWASP Juice Shop
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.
Détection et choix des actions
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.
Outils intégrés
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.
Journaux et rapport Markdown
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.
Cadre d’usage et limites
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é:
- faux positifs possibles.
- faux négatifs possibles.
- dépendance aux outils appelés.
- dépendance au modèle de langage choisi.
- interprétation humaine nécessaire.
- risque de bruit sur les systèmes testés.
- nécessité de tester en environnement maîtrisé avant tout usage sérieux.
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.
Contribuer
Le projet est ouvert aux retours techniques. Les contributions les plus utiles concernent:
- l’installation sur différentes distributions.
- la documentation.
- la reproductibilité des exemples.
- la qualité des rapports Markdown.
- la réduction des faux positifs.
- l’ajout d’agents spécialisés.
- la revue des scripts Docker et shell.
- les garde-fous d’exécution.
- les tests sur des laboratoires vulnérables.
- les issues claires et reproductibles.
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.
Connexion
