DEV Community

Mhammed Talhaouy
Mhammed Talhaouy

Posted on

🔴 RedSwarm: AI-Powered Red Team Simulation Engine

A simple, universal swarm intelligence engine for red teaming — simulate real attackers, not just tools.

Security training often falls into two traps: static labs that feel like a checklist, and dumb automation that chains tools without context. RedSwarm sits in the middle: a multi-agent simulator where each agent has a persona, memory, and tactics, and the system produces an attack narrative you can reason about — including MITRE ATT&CK mapping and a visual attack graph.

RedSwarm dashboard — attack graph, agents, and attack chain


What problem does it solve?

Pain Typical answer RedSwarm’s angle
Red teaming is slow and expensive Manual engagements Many parallel, adaptive attack paths in a controlled model
Training feels fake Scripted scenarios Persona-driven agents (e.g. APT-style, opportunistic, insider)
Blue teams see alerts, not stories SIEM noise End-to-end chain — how, why, what might come next
Hard to test “what if we patch X?” Guesswork God Mode — inject defenses and watch the swarm adapt

The point is not to replace a skilled red team. It is to practice judgment, tell a coherent attack story, and stress-test assumptions in a sandbox.


What you actually run

RedSwarm is a FastAPI backend plus a Vue 3 + Vite + Tailwind frontend. The LLM layer is Anthropic Claude by default (OpenAI is also supported). Agent memory and simulation history live in SQLite.

At a high level:

  • You define a scope (lab-style targets — the project is explicit about ethical constraints).
  • You spin up a swarm of agents with different roles and personas.
  • You get a dashboard: live-ish status, graph, and reports with TTP tags.

Core ideas worth highlighting

1. Swarm intelligence, not a single chatbot

The README describes four agent flavors — recon, exploit, post-exploit, insider — with memory, personality, and tactics grounded in MITRE ATT&CK. Agents can hand off work (one finds weakness, another pushes the chain forward) or compete for paths, which is closer to how real operations feel than a single monolithic “hacker GPT.”

2. God Mode

You can inject constraints — firewall rules, EDR on a host, patch notes, policy changes — and observe how the narrative shifts. That turns the tool into a defense rehearsal instrument, not only an attack toy.

3. Training and CTF angle

Built-in framing includes scenario-style modes (e.g. themed challenges) and gamification hooks like leaderboards for speed or stealth. That makes it approachable for classes, CTF organizers, and internal lunch-and-learns.


Quick start (abbreviated)

Full steps live in the repo README; the shape is:

  1. Clone RedSwarm.
  2. Copy .env.example.env and set ANTHROPIC_API_KEY (or OpenAI).
  3. Backend: Python 3.11+, uvicorn on port 8000.
  4. Frontend: Node 18+, npm run dev on port 3000.
  5. Open the UI and run a simulation; use /docs on the API for Swagger.

From the repo root you can also use the npm run dev workflow (with concurrently) to run backend and frontend together — handy for contributors.


API in one breath

Everything is driven through REST — start a simulation, poll status, pull a report with MITRE mapping, and hit God Mode inject endpoints. The README includes curl examples; the interactive docs at http://localhost:8000/docs are the source of truth while you integrate.


Ethics and license (non-negotiable context)

The maintainers emphasize sandbox-only use: lab ranges, authorized environments, no real-world targeting. Exploit behavior is simulated — this is a training and research system, not a weaponized scanner. The license is AGPL-3.0, which keeps derivatives open and aligns with transparency for security tooling.

Disclaimer: only use this on systems you own or are explicitly authorized to test. Unauthorized access is illegal everywhere that matters.


Why open-source it?

RedSwarm is the kind of project that benefits from public scrutiny: agent logic, guardrails, and API surface are easier to trust when the community can read and patch them. If the idea resonates, the most helpful things are issues (bugs, threats, misleading docs), PRs, and honest feedback on what makes a simulation useful versus theatrical.


Links

If you try it in your lab, leave a comment with what worked, what felt unrealistic, and what you’d want next — that feedback loop is how tools like this get honest.

Top comments (0)