Thursday, November 5, 2026

Consortium for building extensible, multiplayer adversary simulation infrastructure

Consortium for building extensible, multiplayer adversary simulation infrastructure

Consortium is an open-source C2 framework for authorized red team operations and adversary simulation, emphasizing modularity, collaboration, and language-agnostic agent development.

Toolnot-sekiun/Consortium — a modular, extensible command-and-control framework for adversarial simulation
CategoryC2 framework / red team infrastructure (Python, AGPL-3.0)
Primary UseOperating authorized red team engagements and adversary simulations with custom listeners and agents, collaborative sessions, and REST/websockets automation
Safe UseFor use exclusively by authorized professionals in contracted penetration tests, internal red team exercises, and lab environments with written permission
Telemetry NoteThe server binds to 0.0.0.0:9999 by default and exposes /doc and /redoc endpoints on localhost; blue teams can detect lab deployments by monitoring for FastAPI-style service banners on port 9999 and unusual WebSocket traffic patterns

Consortium, hosted at not-sekiun/Consortium, positions itself as a modern command-and-control (C2) framework built around one core design principle: extensibility. Unlike many frameworks that lock operators into a fixed set of implant languages and transport protocols, Consortium describes itself as programming-language agnostic and networking-protocol agnostic. It ships with its own listeners and agents, but the architecture is explicitly designed so that operators can rapidly develop their own customized components — a claim that shapes nearly every design decision documented in the README. At roughly 328 stars and written in Python, this is an active alpha-stage project that deserves attention from anyone building authorized adversary simulation infrastructure.

The project's stated identity is collaborative, highly extensible, and modular. The collaborative aspect is the most distinctive: Consortium offers asynchronous multiplayer and multiserver support, meaning multiple client operators can connect to the same server simultaneously to perform C2 operations, including the sharing of agent sessions between operators. Access control is handled through role-based access control (RBAC) via user roles, which is the kind of multi-operator maturity you normally associate with commercial platforms like Cobalt Strike rather than hobbyist frameworks — and indeed the credits section openly acknowledges Cobalt Strike, Mythic, and Empire as design influences for listeners/agents, framework architecture, and client UI respectively.

Under the hood, the stack is worth noting. The README credits FastAPI for the REST API and websockets server, prompt-toolkit for the client CLI, Rich for terminal presentation, and the websockets library for event-based client communication. This tells you the server exposes a fully documented, automatically generated REST API plus a WebSocket events API for server-initiated push events — a genuinely useful combination for automation. Programmatic automation can go through the external REST API, the websockets events API, or deeper still via native plugins and event hooks that interact directly with the server's internal services. That three-tier automation model (external API, push events, native plugins) is the framework's real differentiator for teams scripting complex, repeatable simulation workflows.

The language-agnostic design deserves closer inspection because of how it is implemented. Agents can be written in any language, which is the easy promise to keep. Listeners are more interesting: they can be written in Python to natively interact with the server, or in any other language to interact through the server's REST API. That dual-path approach is a pragmatic compromise — you get native performance and direct service access if you stay in Python, but nothing stops you from writing a listener in Go or Rust that drives the server over HTTP. For teams with existing toolchains, this removes the usual framework lock-in.

Installation is handled two ways, both reading configuration from the same data/ directory. The manual path requires Python 3.14+, the uv package manager, Git, and optionally Docker for bundled agent generators that compile their payloads inside a container — the README is careful to note that Docker is only needed for those generators, and the server, client, listeners, plugins, event hooks, and other agents run without it. The Docker path needs only Docker and Git, using docker compose up -d --build to start the server and docker compose run --rm client for the interactive client, which is declared under a Compose profile precisely because it needs a terminal.

There is also an automatic installation route via scripts in the scripts/ directory. The install scripts audit prerequisites, prompt before installing missing ones via winget on Windows, apt on Debian-based Linux, or Homebrew on macOS, and then install dependencies. They support --check-only (or -CheckOnly on Windows) for a dry report and --yes for unattended runs. A minimal manual example: git clone https://github.com/not-sekiun/Consortium.git, then uv sync --all-packages, then uv run consortium.py server to start the server (binding 0.0.0.0:9999 by default) followed by uv run consortium.py client connecting to 127.0.0.1:9999. That is the entire operational footprint of getting a lab instance running.

The Docker deployment model shows sensible engineering around persistence and networking. The data/ directory is mounted from the host, so configuration, payloads, agents, and logs survive docker compose down and are shared between Docker and manual installs on the same host. One operational gotcha documented in the README: listeners bind their ports after the container starts, so operators must publish the intended port range by uncommenting it in docker-compose.yml. Updating is straightforward on both paths — git pull plus uv sync --all-packages for manual, git pull plus a rebuild for Docker.

Documentation is a mixed bag and the author is candid about it. The README carries an explicit caution block: the project is in alpha, backwards-incompatible breaking changes may arrive at any time, the framework is not feature-complete, and documentation is lacking in places. The docs site itself is flagged as heavily WIP. That said, the REST API documentation is auto-generated and served at /doc and /redoc from the server's root URL (only accessible from localhost, which is a sensible default), and the client has a tiered help system: help for interpreter-wide command listing, help <command> for summaries with arguments, and <command> --help for comprehensive help with built-in examples. Self-hosting the docs locally requires uv sync --all-packages --group docs followed by uv run zensical serve.

For defenders, Consortium is worth studying as much as operators. A FastAPI-based server publishing auto-generated /redoc endpoints, WebSocket push events, and a default bind on 0.0.0.0:9999 gives blue teams concrete, observable characteristics for spotting misconfigured or rogue lab deployments on corporate networks. Purple team exercises can use the framework's own REST and events APIs as instrumentation: every operation performed by red operators flows through interfaces that can be mirrored for detection engineering, making Consortium a reasonable candidate for environments where detection validation matters as much as offensive capability.

Governance signals are honest and worth weighing before adoption. The author is currently not accepting code contributions because the codebase is too unstable, though feature requests, bug reports, and issues are welcome through GitHub issues. The license is AGPL-3.0, which matters for organizations considering internal forks or commercial integration — AGPL's network copyleft terms apply to modified versions offered over a network. The default branch is dev, consistent with an actively iterating alpha, and the README shows CI with pytest and an online docs site, indicating real engineering hygiene despite the alpha label.

Where does this fit in an authorized workflow? Consortium is a natural fit for internal red teams and adversary simulation programs that want a C2 platform they can fully own, audit, and extend without per-implant licensing, and where multi-operator collaboration with RBAC is a requirement rather than a nice-to-have. Its language-agnostic agent model suits teams standardizing on specific implant languages for evasion research or detection testing. What to watch for: alpha churn means pinning a commit and testing upgrades before engagement use, the Python 3.14+ requirement is unusually aggressive and may complicate deployment on older infrastructure, and incomplete documentation means operators should expect to read source. As an educational and research platform for understanding modern collaborative C2 architecture — FastAPI services, WebSocket event buses, plugin hook systems, containerized payload generation — Consortium is one of the more thoughtfully documented designs currently emerging in the open-source red teaming space.

Official project repository for not-sekiun/Consortium.
Download Tool

Educational analysis for authorized security professionals. Use only in controlled, authorized environments.

Share articleFacebookXLinkedIn

Continue exploring

Browse all articles →

0 comentários:

Post a Comment

Note: Only a member of this blog may post a comment.