ARES: a red team platform where scope enforcement is the hard part

The problem ARES is built against

The README's executive summary is a critique of two things. Traditional penetration testing is called fundamentally flawed because it is expensive, episodic and point-in-time, and it leaves organisations blind to newly introduced misconfigurations and emerging adversary tradecraft. Alongside that, automated vulnerability scanners are described as overwhelming SOC teams with thousands of hypothetical CVEs without demonstrating exploitability or multi-stage lateral attack paths. ARES is positioned between those two failure modes: it is an operator-directed red team engagement platform that models real-world threat actors and aims to prove exploitability rather than list possibilities. The stated output is the shortest compromise path to what the README calls the Active Directory Crown Jewels, plus executive-ready deliverables, with the claim of zero operational downtime. The audience is named in the project description as enterprise red teams, MSSPs and security operations centres, and the package is MIT licensed at version 6.0.0, with the badge showing a Python 3.12+ engine, a FastAPI async backend and a React 18 with Vite front end.

Scope enforcement is designed to fail closed

This is the part of the design that separates the project from a scanner, and it is worth understanding before the offensive features. Every campaign executes inside what the README calls a hardened, isolated boundary. The mechanism is dual layered. ARES pairs deterministic application-layer ScopeGuard pre-checks with a Scope Firewall and Egress Filter that combines OS-level packet filtering, Windows Defender Firewall or Linux Netfilter when elevated, with transport-level socket interception in Python user space through socket.connect, socket.sendto and asyncio.create_connection. The stated guarantee is fail-closed enforcement, so that zero offensive packets reach unapproved IP addresses or subnets.

The Python-level interception is the part that works regardless of privilege, since it sits in the process, while the packet filter is the part that works even if the process is wrong. Neither alone is sufficient, which is the argument for having both. For an operator, the practical consequence is that the scope definition is enforced rather than merely displayed, and a module that attempts an out-of-scope connection is stopped in the process before a packet leaves the host. That is a meaningful difference from a checklist, and it is also the reason the project treats scope as a first-class concept rather than a field in a report template.

Objective-driven planning over an attack graph

The planning model is goal directed. Operators set high-level objectives, with domain_admin, full_compromise and cloud_audit given as the examples, and the decision engine synthesises multi-stage execution paths using graph heuristics and optional LLM agents, described as Claude, OpenAI or a local Ollama model, under explicit operator authorisation. The graph layer is separate and is described as a multi-vector attack graph: you can ingest BloodHound collections or map active domain sessions in real time, and the built-in engine calculates shortest attack paths, highlights chokepoints and simulates lateral pivot feasibility. The graph engine is networkx in the dependency list, which is the obvious choice for the shortest-path and chokepoint work.

The two halves are worth separating in your head, because they answer different questions. The graph tells you where the weaknesses are and what the shortest way through them looks like. The decision engine turns an intent such as domain_admin into a sequence of modules to run. And the LLM involvement is bounded, since it is optional and requires explicit operator authorisation, which means an engagement can be run with no model involved at all if your policy forbids it.

Zero-trust session handling and an encrypted local vault

The credential side is described as a defense-in-depth security model engineered for zero-trust environments. Sessions are database-authoritative, access tokens are short-lived and held in memory only, refresh credentials are HttpOnly and rotating, and local vaults are encrypted with AES-256-GCM in AEAD mode, with key derivation by PBKDF2-HMAC-SHA256 at 600k iterations. The vault is where harvested hashes and sensitive client evidence are kept.

Two details in the environment template are worth reading carefully, because they are the ones a deployment gets wrong. The secret key is not provided as a shared default, and the example says to generate it yourself per deployment with openssl rand -hex 32 and never commit it. The JWT algorithm is configurable between HS256, which is symmetric and suitable for a single service, and RS256, which is asymmetric and recommended when several services verify the token and only the public key is distributed to them. The commented RS256 instructions show the keypair generation, and the private key path is pointed at a secrets mount rather than a file in the repository.

ARES_SECRET_KEY=CHANGE_ME_USE_openssl_rand_-hex_32
ARES_API_HOST=127.0.0.1
ARES_API_PORT=8080
ARES_DEBUG=true
ARES_JWT_ALGORITHM=HS256
ARES_JWT_EXPIRE_MINUTES=60
ARES_DATABASE_URL=sqlite+aiosqlite:///./ares.db

The database default is SQLite with no setup required for a single node, and PostgreSQL is documented as the multi-operator production option, with the requirement to install the postgres extra and run alembic upgrade head before switching the URL. The browser origin setting is same-origin only, and the example says that for production with ARES_DEBUG false it must be set to your exact HTTPS origin, with that host added to ARES_TRUSTED_HOSTS.

Reporting is a pipeline, not a document you write yourself

The deliverables side is described as a one-click generation of branded, audit-ready compliance deliverables in PDF, HTML, Markdown and JSON, with automated headless browser PDF rendering on Windows and Linux without external GTK dependencies. The PDF path is visible in the container build, where the runtime image installs the pango, gdk-pixbuf, ffi and cairo libraries with a comment saying they are needed for weasyprint PDF generation only, and the wheel is installed with the pdf extra.

FROM python:3.11-slim AS runtime

# Security: non-root user
RUN groupadd --system ares && useradd --system --gid ares --no-create-home ares

The container is a three stage build: a Node 22 frontend builder that runs npm ci and npm run build, a Python 3.11 wheel builder that runs python -m build --wheel, and the runtime stage that installs the built wheel, copies the compiled dashboard assets in from the frontend stage, and runs as a system user with no home directory. The wheel carries the configuration, so there is no external config directory to mount, and the extras are chosen at install time: pdf for report generation, ad for Active Directory modules, cloud for AWS, Azure and GCP, postgres for the PostgreSQL backend. The optional dependency groups in the project metadata match that, with impacket, ldap3, pywinrm and asyncssh in the ad group, and boto3, the Azure management packages and google-cloud-resource-manager in the cloud group.

What the module catalogue actually contains

The README claims 66 active production execution modules, 70 catalogued in total, covering 60 or more mapped adversary techniques across MITRE ATT&CK, and the coverage badge points at a modules document. The repository also ships an example_modules/ directory, which is the sensible place to look for what a module is expected to look like, alongside ares/ for the package itself, frontend/ for the dashboard, migrations/ with alembic.ini for the database schema, docker/ and scripts/ for operations, tests/ and docs/.

The module and extras split also tells you where the operating risk sits. The ad group includes the pieces needed for Active Directory work, and the adcs exploit is visible in the dependency comments as a reason for httpx-ntlm, which points at ADCS certificate enrolment abuse as one of the implemented paths. Cloud modules arrive as an extra rather than in the base install, so a default deployment does not carry cloud credentials handling. In other words, the offensive surface area is opt-in by dependency group, which is a reasonable default for a tool whose whole purpose is to run offensive code, and a reason to review the extras list before choosing what to install.

Where a red team platform is the wrong tool

Three cases point elsewhere. The first is a team that wants continuous vulnerability validation without a red team. The comparison matrix in the README is explicit that automated scanners match CVEs theoretically without validating exploitability, and the point cuts both ways: if your requirement is a validated exploit path to a domain admin credential, a scanner does not answer it, but a full engagement platform is also a lot of machinery for a monthly compliance check. The second is an environment where you cannot run offensive code at all, since a tool designed to execute attack modules is not deployable in a locked-down or audited environment even with scope enforcement, and the fail-closed design reduces the blast radius without removing the question. The third is a single-operator assessment where the governance layer costs more than the work.

The alternative worth weighing is a human-led engagement with a documented methodology and an off-the-shelf scanner for coverage, where the difference in approach is that the value comes from the operator rather than from the platform. ARES earns its complexity in teams that run many engagements with many operators, where the scope firewall, the vault and the report pipeline are reused every time. For a single assessment, the platform's setup cost, the state you have to maintain in the database, and the requirement to authorise a plan before each run are overhead rather than a benefit.

Editorial conclusion

ARES fits an enterprise red team, an MSSP or a security operations centre that runs engagements under a signed scope and needs the operator, the scope and the report in one place, and that can host its own instance. It does not fit a team looking for a lightweight scanner, given the FastAPI, database and container stack it requires, and it does not fit a use case that depends on the platform's own judgement of what is in scope, since that enforcement is the operator's responsibility. Before you deploy it, set ARES_SECRET_KEY from your own openssl rand -hex 32 value rather than the placeholder, keep ARES_DEBUG false in production, and read the security model document, because a tool that exists to run offensive code should not be the part of your stack you configured from defaults.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Mafifrizi/ARES on GitHub
4. README
5. Releases