Reconstructing Red Team Engagements — Developing Your Own Red Agent

Source: Adversary Village talk page · GitHub: Red_Agent_Workshop

📄 Download this note as Markdown

Overview

With recent advances in AI, LLMs are increasingly applied to red team engagements — but mostly just to automate operations during the engagement itself. This talk introduces “Red Agent,” a system designed to enhance the entire lifecycle. After a red team engagement, blue team members implementing remediation need to evaluate their effectiveness — a bottleneck requiring substantial manual effort to interpret findings, reproduce attack paths, and verify mitigations. Red Agent automates this follow-up process, and in doing so also optimized the engagement artifacts (logs, report structures) that feed it — reconstructing the red team lifecycle so practitioners can focus on higher-value work.

Notes

Red Team Engagement

Red Agent does adversary emulation, targeting specifically the post-engagement validation process. It’s a multi-agent system with an orchestrator managing sub-agents that understand the report, plan re-test procedures, execute tasks, and interpret/summarize results — making the validation process repeatable and scalable.

Architecture

Talk slide showing Red Agent's implementation architecture. One application server runs a SOCKS server, a web frontend, a backend API, and Red Agent. A user accesses the web frontend, and Red Agent sends inference requests to a separate LLM server and gets results back. Re-test traffic goes through the SOCKS server and a SOCKS tunnel into the target environment's workstations and servers.

  • Deep Agent — agents for long-running tasks with memory, planning, and delegation tools
  • Custom Kali MCP Server — lets the agent execute commands on Kali Linux; existing MCP servers were too limited for re-testing workflows
  • Human-in-the-Loop — validates actions before the agent takes them; can approve, edit, or reject (rejecting skips the action)

Capabilities

Creates documents and artifacts that are LLM/agent-friendly, accumulating data and knowledge over time to extend the agent’s capabilities — freeing the human to focus on more advanced, value-add work.

From the Repo

Three-tier architecture: a Vite + React frontend (port 5173) for reviewing findings with human approval gates, a FastAPI backend (port 8000) orchestrating the verification workflow and persisting to SQLite, and an execution layer running commands through the Kali MCP server over stdio. DC auto-discovery pulls AD domain controller info via DNS/SMB; Entra support integrates with roadrecon. Audit logging retains operations for 180 days by default. Quick setup: make install → set LLM_BASE_URL in .env → make dev → UI at localhost:5173.

A Bug I Found and Fixed

Setting up the repo locally ahead of the workshop (macOS, Python 3.11), I hit a missing greenlet dependency — not pinned in requirements.txt. Without it, SQLAlchemy’s async engine throws on every DB operation, breaking the periodic audit-log prune job and retest history persistence. Fixed it locally, then forked the repo, pushed a fix branch, and opened a PR upstream adding greenlet==3.5.4 to requirements.txt.

Filed Under: #defcon34