ARES puts campaign governance around offensive modules
ARES tries to replace a folder of red-team scripts with an operator system. Campaigns carry approved CIDR ranges, noise limits, findings, evidence, and credentials. Modules cover Active Directory, Windows, Linux, cloud, and network work, while an attack graph maps possible pivots. Operators can stage dry runs, execute approved work, watch events, and turn results into PDF, HTML, Markdown, or JSON reports.
The README counts 66 active execution modules among 70 catalogued entries and maps them to more than 60 MITRE ATT&CK techniques. A React dashboard sits over a FastAPI backend, SQLite or PostgreSQL storage, encrypted vault records, role-based access, and WebSocket telemetry. Optional Claude, OpenAI, or Ollama planning can propose a sequence. An MCP gateway exposes 9 tools with short-lived human confirmation for live offensive actions.
What happened when we ran it
Our run cloned commit 49bd11a into a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM. Installing the Python project succeeded in 73 seconds, pulled 196 packages, and occupied 499 MB. The build completed in 9 seconds. Pip-audit reported 1 known vulnerability; the supplied measurement does not identify its package or severity, so that requires separate triage.
The test command did not finish within 900 seconds. Its last output showed steady progress through Windows enumeration, WMI cleanup, pivot handling, Active Directory behavior, dependency preflight, adaptive OPSEC, ADCS, and API endpoint tests. The counter reached 22%, with no failure shown in the tail we received. That does not establish a passing suite. It means this broad test run needs more than our 15-minute limit.
The repository contained 529 files, about 273,772 lines of source, and occupied 32.1 MB before installation. Our scan found a tests directory, one CI workflow, and no Dockerfile. ARES documents Docker as one possible isolation tier, yet the checkout did not provide a root Dockerfile for a ready-made deployment. The measured build is encouraging; the unfinished suite and audit finding prevent a clean release verdict.
The security model is more useful than the zero-risk slogan
ARES says every campaign is guarded by approved scope and that strict mode fails closed. Python socket interception covers standard library connections, while elevated host firewall rules can add OS enforcement. The security document deserves credit for saying exactly where those controls stop. Compiled extensions and external binaries can bypass Python hooks, and online Docker bridge traffic is not scope-restricted for external binaries without an explicit exception.
Several boundary checks remain unproved on a live privileged host. The matrix marks Linux Netfilter, Windows Defender Firewall, subprocess network namespaces, and privilege dropping as not verified at actual runtime because they require root, administrator access, or kernel support. Mocked command tests prove construction and state transitions. They do not prove that an offensive packet cannot escape. Any claim of zero collateral risk is therefore stronger than the project's own evidence.
A real deployment needs security operations, not one command
The Windows quick start asks for Python 3.12, Node.js 18 or newer, a virtual environment, Python extras, frontend dependencies, and a browser path for PDF smoke testing. It then starts a development dashboard at 127.0.0.1:5173. The documented initial user is admin, with Admin123456! as the default when ARES_DEFAULT_ADMIN_PASSWORD is absent. Change that before exposing any interface beyond loopback.
Production adds more. The security guide requires separate session-signing and AES-256-GCM encryption secrets, stable backup of the encryption key, HTTPS or WSS through a reverse proxy, protected database storage, and TLS plus authentication for Redis when used. Operators must choose isolation tiers and supply dedicated sandbox identities where UID-wide firewall rules might affect unrelated processes. This is security infrastructure carrying harvested hashes and client evidence, not a disposable scanner.
MCP approval reduces risk without removing operator duty
ARES can connect Cursor, Claude Desktop, Windsurf, Cline, Zed, and other MCP clients. Its setup writes the active Python environment into the client's configuration. Read operations include campaign state and scope checks. A live action uses a single-use HMAC confirmation token with a 60-second life, and the two-pane monitor gives a person an approve or reject control.
That design keeps an AI-generated instruction from immediately becoming offensive traffic. It cannot decide whether a target is legally authorized or whether a module is safe for a fragile production host. An operator still owns the written permission, CIDR boundaries, credentials, noise budget, and final action. Teams that do not already have that discipline should start with isolated Atomic Red Team checks rather than an agent-connected execution surface.
September code activity is newer than the June release
GitHub showed 554 stars, a September 30 push, and 8 open issues and pull requests combined. A separate search returned 0 open issues, so all 8 listed items were pull requests. Their titles were dependency updates, with activity on September 23 and 30. Release v6.0.0 was published June 22. The newer push and PR activity mean the older release date alone is not evidence of abandonment.
ARES is ambitious enough to demand an evidence-led adoption. Our 9-second build proves the package can assemble in a small Debian sandbox, while 22% test progress after 900 seconds shows that full validation is much heavier. Use a segregated lab, resolve the single audit finding, finish the entire suite, and test the real kernel boundary on the exact hosts that will run modules. Only then consider a tightly scoped internal exercise.