Apache Caldera: an adversary emulation platform built on MITRE ATT&CK

What Caldera automates, and for whom

Caldera is described in its README as a cyber security platform to automate adversary emulation, assist manual red teams, and automate incident response. Those are three different jobs sharing one command-and-control core, and the intended user differs for each. The emulation case is a red teamer or a detection engineer who wants to run a known adversary playbook rather than improvise one. The incident response case is a defender who wants the same C2 machinery pointed at a live incident, which is why the plugin list includes a Response plugin alongside Stockpile and Sandcat.

The framework is built on the MITRE ATT&CK framework and the README states it is an active research project at MITRE. That origin matters for expectations: techniques arrive mapped to ATT&CK identifiers, so an operation produces output you can line up against a detection coverage map instead of a pile of shell history. The project does not ship a vulnerability scanner or a compliance report generator, and nothing in the README suggests it wants to.

Core system plus plugins: how the pieces connect

The README splits the project in two. The core system is what lives in the apache/caldera repository: an asynchronous command-and-control server with a REST API and a web interface. Everything else is a plugin, kept in separate repositories, and the README lists eighteen of them under Default (supported and maintained by the Caldera team) plus four more that are ready to use but not maintained by the team.

That split is the architecture. Sandcat is the default agent, Stockpile is the technique and profile storehouse, Magma is the VueJS UI for Caldera v5, and Manx supplies shell functionality and reverse shell payloads. The core repository's top-level layout reflects this: app/, conf/, data/, plugins/, static/, templates/, plus server.py as the entry point. A fresh recursive clone pulls the plugins in as submodules, which is why the clone command carries --recursive.

Two consequences follow. First, a technique you cannot find is usually a plugin you did not install, not a bug. Second, plugin repositories can move independently of the core, so the version of Stockpile you cloned matters as much as the version tag on the core.

Installing Caldera and running a first login

The README recommends a Python virtual environment to avoid pip package conflicts, so start there. These three commands create and enter one:

python3 -m venv .calderavenv
source .calderavenv/bin/activate

With the environment active, clone the repository recursively so the plugin submodules come along, then install the pinned requirements and start the server. The README gives this as the concise path:

git clone https://github.com/apache/caldera.git --recursive
cd caldera
pip3 install -r requirements.txt
python3 server.py --insecure --build

The --build flag installs the VueJS UI dependencies and bundles the interface into a dist directory that the server then serves. The README notes you only need it again if you add plugins or change the UI. Once the server is up, the README says to log in at http://localhost:8888 with the default credentials red/admin, then open Plugins -> Training and work through the capture-the-flag style course.

If you prefer containers, the README offers a local build and a pre-built image:

docker build --build-arg VARIANT=full -t caldera .
docker run -it -p 8888:8888 caldera

The README cautions that the ghcr.io/apache/caldera:latest image may be slightly outdated and recommends building the container yourself. It also documents two variants: full, which is suitable for offline operation, and slim, which omits files needed by the emu and atomic plugins and downloads them on demand if those plugins are enabled. The docker-compose.yml in the repository builds the full variant by default and maps eight ports, including 8888 for the UI, 8443, 7010, 7011/udp, 7012, 8853, 8022 and 2222, with the comment that which ports you expose depends on the contacts you plan to use.

Where Caldera stops being the right tool

The README's own requirements section is the first constraint: the core framework runs on Linux or macOS with Python 3.10+, and the recommended hardware is 8GB+ RAM and 2+ CPUs. Windows is not listed as a supported host for the core server, so a Windows-only team is installing this in a VM or a container or not at all. GoLang 1.24+ is recommended only if you want to dynamically compile GoLang-based agents, and NodeJS v16+ is recommended for the v5 VueJS UI, so the build host carries more toolchain than a plain Python service would.

The second constraint is the plugin dependency. Because agents, techniques and the default UI live outside the core repository, a bare clone without --recursive gets you a server with very little to run. The slim container variant makes this explicit: the README states it lacks files necessary for the emu and atomic plugins and will fetch them on demand, which means an air-gapped deployment needs the full variant.

The third is operational. The default credentials red/admin and the --insecure flag are documented as the quick-start path, and the README points readers to its security recommendations for deploying Caldera. A C2 server on port 8888 with known default credentials is a liability the moment it is reachable from anywhere but localhost. Nothing in the README describes a rollback path for an operation that goes wrong, so plan containment outside the tool.

Caldera against a general automation framework

The obvious comparison is with a general-purpose automation or configuration framework, and the difference is in what the unit of work is. In a configuration tool, the unit is a desired end state on a host: this package installed, this file present. In Caldera, the unit is a technique from MITRE ATT&CK executed by an agent through a command-and-control channel. That distinction decides which one answers your question. If you want to know whether a detection fires on a specific ATT&CK technique, a configuration tool cannot tell you; it has no concept of the technique. If you want to know whether a fleet of servers drifted from its baseline, Caldera is the wrong instrument, because it is built to produce adversary behaviour, not to converge state.

Within the emulation space, the choice is mostly about how much you assemble yourself. Caldera ships the C2 core, the REST API and the web interface, and expects you to bring the techniques through Stockpile and the agent through Sandcat. Tooling that bundles a fixed technique library trades that assembly work for less control over what runs. The plugin split is the reason Caldera can cover ICS/OT through caldera-ot, ATLAS techniques through Arsenal, and SAML authentication through a third-party plugin, but it is also why a working deployment is a set of versioned repositories rather than one artifact.

Maintenance, upgrades and the Apache-2.0 licence

The repository is not archived and the last push was on 2026-08-27. The most recent tagged release is 5.3.0 from 2025-04-24, preceded by 5.2.0 and 5.1.0 earlier in 2025. That gap between the last release tag and the last push is worth noting if you pin to tags: you are installing a release that predates several months of commits.

The upgrade surface is larger than a single version number. The core pins its Python dependencies in requirements.txt with exact versions, including aiohttp==3.14.3, cryptography==50.0.1, jinja2==3.1.6 and setuptools==83.0.0. Plugin repositories are separate, so an upgrade means moving the core tag and the submodule revisions together. The README's note that --build is only needed again when you add plugins or change the UI tells you how to avoid a needless front-end rebuild, but it does not describe a migration procedure between major versions.

Caldera is licensed under Apache-2.0, and the repository carries both a LICENSE and a NOTICE file, which is the normal Apache arrangement for attribution. The README also shows Caldera and MITRE ATT&CK as trademarks. If you redistribute Caldera or a derivative, read the NOTICE and the trademark usage terms rather than assuming the permissive licence covers branding; that is a question for your own counsel, not something the README settles.

Editorial conclusion

Adopt Caldera if you need a scriptable C2 server that maps operations to MITRE ATT&CK and you are willing to run the plugin set that supplies the actual techniques and agents. Do not adopt it as a general vulnerability scanner or a SIEM replacement; it emulates behaviour, it does not assess patch level. Before deploying, verify the plugin list you actually need, whether your agents require GoLang 1.24+ and NodeJS v16+ on the server host, and read the security recommendations the README points to before exposing port 8888 beyond localhost.

Frequently asked questions

Official sources

1. apache/caldera on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases