Launching today
Darkmoon
Autonomous penetration testing platform
78 followers
Autonomous penetration testing platform
78 followers
Most AI pentesting tools stop at the web layer. Darkmoon goes further. Built by professional pentesters, it combines 18 specialized AI agents and 80+ offensive security tools to assess Active Directory, Kubernetes, cloud infrastructure, APIs, CMSs, and networks. Self-hosted, open-source, MITRE-mapped, and designed to deliver evidence-backed findings, attack paths, and publication-ready reports.
@mehdi_boutayeb Congrats on the launch! It’s refreshing to see a security platform that avoids the AI hype and tackles complex environments like Active Directory and Kubernetes under a GPLv3 license.
Quick question: Since the orchestrator delegates tasks rather than executing tools directly, how do you manage or mitigate potential LLM hallucinations when it parses complex command outputs from tools like NetExec or BloodHound?
@laraib Great question.
This is actually one of the main reasons we designed Darkmoon around MCP-gated tool execution rather than letting the LLM directly interact with the environment.
The orchestrator doesn't generate findings from imagination. It works from structured evidence produced by the tools themselves. Outputs from tools such as NetExec, BloodHound, Nuclei, WPScan, Kubescape, etc. are collected, normalized and passed back as context for reasoning.
A few mechanisms help reduce hallucinations:
The LLM cannot arbitrarily execute commands. All actions must go through controlled MCP workflows.
Findings are expected to be evidence-backed. Reports include commands, outputs and supporting artifacts whenever possible.
Multiple steps often corroborate the same observation before it is promoted into a finding or attack path.
Specialized agents work within narrower scopes (AD, Kubernetes, WordPress, GraphQL, etc.) instead of relying on a single general-purpose agent for everything.
Human validation remains part of the process. Our goal is to assist pentesters, not replace their judgment.
In practice, we treat the model as a reasoning layer sitting on top of offensive tooling, not as a source of truth. The source of truth remains the evidence collected from the target environment.
This is also why we're very careful not to market Darkmoon as "fully autonomous hacking". The value comes from orchestrating tools, methodologies and evidence in a coherent workflow while keeping the process auditable and reviewable.
Mailwarm
What’s the setup like to run a full assessment, and can you plug in your own tools or internal scanners?
@thamibenjelloun Hello, The setup is intentionally lightweight. Darkmoon is Docker-based, so a typical installation is essentially:
Once configured, you simply provide a target and the orchestrator handles methodology selection, tool execution, evidence collection and reporting.
Regarding custom tooling: yes. Darkmoon was designed around an MCP-based architecture and tool orchestration layer rather than a fixed scanner pipeline. The platform already integrates 80+ tools (Nuclei, NetExec, BloodHound, Impacket, Kubescape, WPScan, SQLMap, etc.), but organizations can extend workflows, methodologies and toolchains to fit their own environments.
Using the install-dev workflow, you can also install additional tools directly into the dedicated toolbox container, register them in the MCP server's authorized tools list, and expose them to the orchestration layer. Teams can go further by creating their own methodologies, custom workflows and agent playbooks to adapt Darkmoon to internal processes, proprietary scanners or specialized assessment scenarios.
More details are available in the documentation:
https://docs.dark-moon.org/
The philosophy is simple: the AI reasons, MCP controls execution, and the tools remain the source of truth.
Strong launch. I like the split between model planning and a separate execution layer. For security work, the useful artifact is not only the report, it is the chain from target scope to authorized tool to command output to finding. Do you keep that run record exportable for client or audit review?
@blah_mad Yes, auditability was one of the design goals.
In the open-source edition, you can export a complete session record, including the LLM reasoning process, executed commands, raw tool outputs and the resulting findings. This makes it possible to review how a conclusion was reached rather than only seeing the final report.
In the Professional Edition, the same execution history is preserved and accessible through the session history interface. Teams can review commands, AI observations, raw outputs and generated findings for each assessment.
On top of that, the dashboard keeps a historical view of campaigns and vulnerabilities. Findings can be analyzed across projects, campaigns, severity levels and vulnerability categories. The platform also provides interactive trend visualizations, allowing teams to track whether vulnerability counts are increasing or decreasing over time and drill down into individual findings for investigation and remediation tracking.
Our goal is to make every finding traceable back to the evidence and execution path that produced it, rather than treating the LLM as a black box.
That is the right artifact. The open-source export is the useful bit for teams: not just “AI found X”, but target scope, command, raw output, and why it became a finding. Are those session records machine-readable enough to plug into a client’s ticketing or evidence workflow?