HADES: Training Blue Teams with AI-Powered Adversaries That Never Sleep

Hook

What if your home lab could be attacked 24/7 by an AI adversary that adapts its tactics, costs pennies per hour, and never needs to coordinate schedules?

Context

Red team exercises are the gold standard for training security operations center (SOC) analysts, but they're expensive, time-consuming, and require coordination between attackers and defenders. A typical red team engagement costs $15,000-$50,000 and might run for a few weeks. For individual security practitioners or small teams trying to build skills in home labs, this model is completely inaccessible. You're left with static malware samples, scripted scenarios that quickly become predictable, or YouTube walkthroughs that don't provide hands-on muscle memory.

HADES (Harnessing AI to Disrupt and Evaluate Security) attempts to solve this accessibility problem by replacing human red teamers with AI agents powered by large language models. It's designed specifically for the home lab training use case—where a defender wants to practice incident response, threat hunting, and forensics against realistic adversary behavior without the overhead of coordinating with another human. The platform runs entirely in Docker containers on your own infrastructure, simulating attacks that you then detect and respond to using whatever defensive tools you're learning.

Technical Insight

HADES implements a microservices architecture where different aspects of adversary emulation are isolated into separate Docker containers that communicate asynchronously through RabbitMQ message queues. This design choice is crucial because real-world attacks aren't monolithic—they're composed of discrete stages (reconnaissance, initial access, privilege escalation, lateral movement) that happen over time with varying speeds and dependencies.

The RabbitMQ message broker sits at the center of the architecture, allowing AI agent containers to publish attack "intentions" that execution containers then consume and implement. For example, an AI agent might decide that the next logical step is credential dumping, publish that decision to a queue, and an execution container with the appropriate tools (like mimikatz simulation) picks up the message and performs the action. This decoupling means you can scale different parts of the attack chain independently—run multiple reconnaissance agents while having a single execution container, or vice versa.

The AI integration happens through OpenAI's API, where agents are given context about the current state of the attack chain and asked to make tactical decisions. Based on the repository structure, this likely follows a pattern like:

import openai
import pika
import json

class AdversaryAgent:
    def __init__(self, rabbitmq_host, openai_api_key):
        self.connection = pika.BlockingConnection(
            pika.ConnectionParameters(host=rabbitmq_host)
        )
        self.channel = self.connection.channel()
        self.channel.queue_declare(queue='attack_decisions')
        openai.api_key = openai_api_key
        
    def decide_next_action(self, current_state):
        # Build context for the AI about what's been accomplished
        prompt = f"""
        You are a red team operator. Current attack state:
        - Access level: {current_state['access_level']}
        - Compromised hosts: {current_state['hosts']}
        - Discovered credentials: {current_state['creds']}
        
        What is the next logical attack step? Respond with a JSON object
        containing 'technique' and 'target' fields.
        """
        
        response = openai.ChatCompletion.create(
            model="gpt-4",
            messages=[{"role": "user", "content": prompt}],
            temperature=0.7  # Some randomness for unpredictability
        )
        
        decision = json.loads(response.choices[0].message.content)
        
        # Publish decision to execution queue
        self.channel.basic_publish(
            exchange='',
            routing_key='attack_decisions',
            body=json.dumps(decision)
        )
        
        return decision

This pattern allows the AI to maintain continuity across attack stages while keeping execution modular. The temperature parameter adds controlled randomness so attack patterns aren't identical across runs—important for training defenders to think adaptively rather than just recognizing specific sequences.

The Makefile-based orchestration is another architectural decision worth examining. Rather than using Kubernetes or docker-compose for a simple multi-container setup, a Makefile provides explicit control over build and deployment sequences. This matters in adversary emulation because you often want to start components in specific orders (message queue before agents, monitoring before attacks begin) and have clear teardown procedures that preserve logs. A typical Makefile target might look like:

.PHONY: start-attack
start-attack: check-api-key start-rabbitmq start-agents
	@echo "Attack simulation started. Monitor logs with 'make logs'"

check-api-key:
	@test -n "$(OPENAI_API_KEY)" || \
		(echo "Error: OPENAI_API_KEY not set" && exit 1)

start-rabbitmq:
	docker run -d --name hades-mq \
		-p 5672:5672 \
		rabbitmq:3-management

start-agents:
	docker run -d --name hades-agent \
		--link hades-mq:rabbitmq \
		-e OPENAI_API_KEY=$(OPENAI_API_KEY) \
		hades/agent:latest

The containerization strategy also enables clean environment resets between training scenarios. After a simulation run, you can tear down all containers, restore your target environment to a clean snapshot, and start fresh with different attack parameters. This repeatability is essential for training—you need to practice detecting the same attack types multiple times with increasing speed and accuracy.

One sophisticated aspect is how HADES likely handles the context window limitations of language models. Attack chains can span hours or days, generating far more state information than fits in a single API call. The system probably maintains a compressed attack graph or timeline, selecting only the most relevant context when querying the AI. This means choosing which compromised credentials matter, which network segments are interesting, and what previous techniques succeeded or failed—essentially creating a "working memory" for the adversary that mirrors how human red teamers think.

Gotcha

The most significant limitation is the external API dependency. Every time the AI agent makes a decision, that's an OpenAI API call at current pricing (around $0.01-0.03 per request for GPT-4). If your agent evaluates next steps every 5 minutes during an 8-hour training session, that's roughly 96 API calls or $1-3 per session. This adds up quickly if you're running continuous training, and more importantly, creates a hard dependency on internet connectivity and a third-party service. If you're practicing incident response in air-gapped networks or simulating scenarios where external communication is blocked, HADES won't work without modification to use local models.

The AI-generated attack quality is another genuine concern. Large language models are trained on text data about security techniques, not on actual offensive security experience. They might suggest theoretically sound attack progressions that don't account for practical realities—tool compatibility issues, timing considerations, or defensive telemetry that experienced penetration testers instinctively avoid. A human red teamer knows that certain noisy techniques will immediately trigger alerts in mature environments, while an AI might confidently recommend them because they appear in ATT&CK documentation. This means HADES is better for training pattern recognition and response procedures than for testing your defenses against sophisticated adversaries. You're practicing against an AI's interpretation of how attacks work, which is valuable for fundamentals but shouldn't replace occasional professional red team assessments.

Verdict

Use HADES if: You're a security practitioner building skills in a home lab and need unpredictable attack scenarios without coordinating human partners. You have budget constraints that make professional red team services impractical but can absorb a few dollars per training session in API costs. You're focused on training SOC analysts to recognize attack patterns and practice response procedures rather than testing production defenses. You want to run adversary simulations on-demand, possibly even scheduled overnight to create "morning surprise" scenarios for practice.

Skip HADES if: You're conducting security testing in production or sensitive environments where external API calls are prohibited or create unacceptable data exposure risks. You need adversary emulation that accurately represents specific APT groups or sophisticated attack methodologies—human red teamers or mature frameworks like MITRE Caldera are better choices. You're operating in air-gapped environments without internet connectivity. Your budget allows for professional red team services that provide post-engagement reports and recommendations alongside the testing itself. You need compliance documentation showing that security testing followed specific approved methodologies.