HADES: Teaching Your Home Lab to Attack Itself with AI Agents
Hook
Most security teams spend 95% of their time defending against attacks they never get to practice against. What if your infrastructure could automatically attack itself while you sleep, generating endless training scenarios without hiring a single penetration tester?
Context
Blue team defenders face an asymmetric training problem that no amount of reading can solve. You can study MITRE ATT&CK matrices until your eyes glaze over, configure SIEM alerts until perfection, and build elaborate detection rules—but without actually facing adversary behavior, you’re shadowboxing. Traditional solutions require either expensive red team consultants (often $300+/hour), coordination overhead to schedule internal red team exercises, or complex adversary emulation platforms designed for enterprise SOCs with dedicated staff.
For the solo security practitioner running a home lab, the small startup with one overworked security person, or the blue teamer at an organization without red team resources, this creates a painful gap. You need repetition and variety to internalize detection patterns, but you can’t conjure attackers on demand. HADES (Harnessing AI to Disrupt and Evaluate Security) emerged from this frustration: a containerized platform that leverages OpenAI’s API to power autonomous adversary agents that can simulate realistic attack behaviors in your environment, whenever you want, without human operators. It’s adversary emulation for the rest of us.
Technical Insight
HADES implements a microservices architecture where AI-driven adversary agents communicate through RabbitMQ message queues to coordinate distributed attack simulations. This design choice is crucial—rather than a monolithic attack script, the system decomposes into independent services that can scale horizontally and operate asynchronously, mimicking how real attackers use multiple tools and persistence mechanisms across a network.
The containerized approach means each component (adversary agent, command relay, target listeners) runs in isolation with Docker, making deployment to a home lab or VM cluster trivial. The RabbitMQ message bus serves as the command-and-control backbone, allowing adversary agents to publish attack intentions and results while defender-side components subscribe to specific event types for logging and analysis. This architecture mirrors real APT operations where attackers use resilient C2 channels that survive individual node compromises.
What makes HADES distinctive is how it integrates LLM capabilities into the attack decision loop. Rather than following deterministic playbooks like traditional frameworks, the AI agent can receive environmental context (open ports, discovered services, credential material) and use the OpenAI API to reason about next steps. A simplified view of how an agent might make decisions:
# Pseudocode illustrating AI-driven decision making in HADES
import openai
import json
class AdversaryAgent:
def __init__(self, target_context):
self.context = target_context
self.completed_actions = []
def decide_next_action(self):
prompt = f"""
You are a red team operator. Given this reconnaissance data:
{json.dumps(self.context)}
Previously completed: {self.completed_actions}
What is the next logical attack step? Respond with:
- technique: MITRE ATT&CK ID
- command: exact command to execute
- reasoning: why this step
"""
response = openai.ChatCompletion.create(
model="gpt-4",
messages=[{"role": "user", "content": prompt}]
)
return json.loads(response.choices[0].message.content)
def execute_attack_chain(self):
while not self.objective_complete():
action = self.decide_next_action()
result = self.execute_technique(action['command'])
# Publish to RabbitMQ for defenders to observe
self.publish_event({
'technique_id': action['technique'],
'command': action['command'],
'result': result,
'timestamp': time.time()
})
self.completed_actions.append(action)
self.context.update(result) # Feed results back for next decisionThis approach allows the adversary behavior to adapt based on what it discovers, rather than blindly executing Attack Sequence #47. If the AI discovers a Windows environment instead of Linux, it can pivot to Windows-specific techniques. If credentials are found, it can escalate privileges before attempting lateral movement. The defender practicing against this sees more realistic, context-aware attack patterns.
The RabbitMQ integration enables multiple simultaneous attack simulations with different objectives. One agent might focus on data exfiltration while another attempts persistence, both operating independently but visible through your defensive tooling (SIEM, EDR, IDS). Since all events flow through the message queue, you can replay attack sequences, compare detection coverage across scenarios, and even build automated grading systems that evaluate whether your defenses caught specific techniques.
The containerization also solves the “attack tool installation” problem that plagues home labs. Instead of maintaining Kali Linux VMs with tool dependencies, each adversary container includes only what it needs for specific techniques. Want to simulate a ransomware attack? Spin up the encryption adversary container. Testing network discovery detection? Launch the reconnaissance container. This modularity keeps resource usage low—critical for running meaningful scenarios on modest hardware.
Gotcha
The OpenAI API dependency is both HADES’s superpower and its Achilles heel. Every attack decision requires an API call, which introduces latency (expect 1-3 second delays between actions), ongoing costs (complex attack chains could consume substantial tokens), and an external dependency that breaks if your internet connection drops or OpenAI experiences an outage. For continuous training in a home lab, those API costs accumulate. A single extended attack simulation might consume thousands of tokens; run these nightly and you’re looking at non-trivial monthly expenses. There’s also the philosophical concern of sending your network reconnaissance data and infrastructure details to a third-party API, even in a lab environment.
More importantly, HADES appears to be in early stages with limited documentation on what specific attack techniques are actually implemented. Unlike MITRE Caldera’s extensive TTP library mapped to ATT&CK, or Atomic Red Team’s hundreds of documented tests, it’s unclear whether HADES currently supports comprehensive coverage across the ATT&CK matrix or focuses on specific domains. The 24 GitHub stars suggest a small community, meaning you’ll be largely on your own for troubleshooting, extending capabilities, or finding examples. If you need production-grade adversary emulation with compliance requirements or detailed reporting for stakeholders, HADES’s maturity level may not meet those needs. The AI-driven approach is innovative but unproven at scale compared to established frameworks with years of enterprise deployment experience.
Verdict
Use HADES if you’re a blue team practitioner with a home lab or small security team looking for on-demand, automated adversary simulation without coordinating human red teamers—especially if you value adaptive, context-aware attack behaviors over exhaustive TTP coverage and you’re comfortable with OpenAI API costs and latency. It’s ideal for continuous skills development, testing new detection rules against realistic attacks, and training scenarios where variety matters more than repeatability. Skip HADES if you need comprehensive, production-grade adversary emulation with extensive documentation and enterprise support (choose MITRE Caldera instead), require offline/air-gapped operation without external API dependencies (consider Atomic Red Team or local LLM alternatives), have strict data privacy requirements that prohibit sending network context to third-party APIs, or need mature tooling with large community support and proven reliability for formal assessments. The project’s innovative use of AI agents is compelling, but early-stage maturity and API dependencies make it best suited for experimental training environments rather than formal red team exercises.
