AutomatedEmulation is a Terraform template that builds a fully automated adversary emulation and breach-and-attack-simulation lab in AWS, pairing Caldera with VECTR for authorized purple-team testing.
| Tool | iknowjason/AutomatedEmulation — Terraform-based automated adversary emulation lab deploying Caldera, VECTR, and a hardened Windows client in AWS |
| Category | Breach and attack simulation / range automation (Infrastructure as Code, HCL) |
| Primary Use | Standing up a disposable Caldera + VECTR + Atomic Red Team lab in your own AWS account to run authorized adversary emulation and measure detections |
| Safe Use | Deployed entirely in the operator's own AWS account for authorized purple-team assessments, detection validation, and lab research; all infrastructure is torn down with terraform destroy |
| Telemetry Note | The Windows client ships Sysmon with a SwiftOnSecurity configuration, generating local event telemetry defenders can pipe to their SIEM; MLflow exposes LLM inference traces for the Caldera MCP plugin |
Adversary emulation has always suffered from a bootstrap problem: the tooling is excellent, but the environment that ties attacker framework, victim host, and detection telemetry together takes days to hand-build. iknowjason/AutomatedEmulation attacks exactly that friction point. It is a Terraform template, written primarily in HCL, that provisions a complete breach-and-attack-simulation lab inside a single AWS account: one Ubuntu Linux server running Caldera 5.3 with the Magma VueJS web application and VECTR from Security Risk Advisors, plus one Windows Server 2022 Datacenter client pre-configured as the emulation target. At roughly 220 stars and MIT-licensed, it sits in that practical middle ground between a weekend script and a maintained range product.
The November 2025 update is what makes this repo interesting beyond a simple Terraform wrapper. The author added the Caldera MCP server plugin, which wraps the Caldera REST API so that LLMs can be given structured context for building new abilities, operation planners, and a CTI component with RAG integration — the README links MITRE's own blog post on connecting LLMs to Caldera via the MCP plugin. In practice this means the lab is not just a static range but a testbed for experimenting with LLM-assisted emulation planning, which is a notable architectural bet on where adversary simulation tooling is heading.
Observability of the LLM side is handled thoughtfully. The MCP plugin automatically exposes an MLflow server on port 5000, providing log tracing, debugging, and monitoring of every LLM inference call the Caldera MCP plugin makes. The README is refreshingly candid about the risk here: MLflow normally binds to localhost, but the author adapted it for remote connections and explicitly warns users to ensure EC2 security groups restrict access to authorized sources only. That is the kind of operational caveat a senior operator should read before running terraform apply in any account with shared exposure.
The provisioning philosophy is the project's distinguishing design decision, and the README devotes a section to it. Instead of layering a configuration-management agent like Ansible over the cloud build, the lab relies purely on Terraform providers and native AWS user data. A small master bootstrap script is pushed via user-data; it downloads additional configuration scripts staged in an S3 bucket and executes each one. The author argues this improves stability, consistency, and speed by eliminating agent drift, outdated libraries, and secondary-tool networking issues. This also neatly sidesteps the 16KB user-data size limit — the templatefiles array in scripts.tf combined with s3.tf staging gives you arbitrary post-deployment configuration headroom.
The blue-team story is built in rather than bolted on. The Windows client automatically receives Sysmon with a customized SwiftOnSecurity configuration, deployable and upgradable via the files/sysmon directory and the files/windows/sysmon.ps1.tpl bootstrap template. Every deployment phase writes a progress log — C:\Terraform\bootstrap_log.log, red_log.log, blue_log.log, and caldera_log.log — so you can RDP in mid-build and watch the range assemble itself. Combined with VECTR for tracking red versus blue outcomes across attack scenarios, the lab is genuinely a purple-team instrument, not just a red-team playground.
On the offensive side of the same coin, the Windows host gets Atomic Red Team (ART) and PurpleSharp dropped into C:\Tools\, and the Caldera sandcat agent is automatically installed and launched once the Caldera server is confirmed up. The Caldera Bountyhunter plugin is installed, and the EMU plugin auto-downloads payloads and converts Adversary Emulation Plans from the Center for Threat Informed Defense into runnable abilities — a meaningful shortcut for anyone running threat-informed emulation against ATT&CK-mapped profiles. Custom abilities and payloads can be added locally under files/bas/abilities/ and files/bas/payloads/, which deploy into /opt/caldera/data/ on the server.
The firewall handling deserves attention because it is both clever and fragile. On terraform apply, the code queries ifconfig.so to determine your public IPv4 address and writes a /32 whitelist into the security groups via sg.tf. Move locations, re-run terraform apply, and the whitelist follows you. The README warns the build breaks if the lookup returns IPv6, at which point you must edit the src_ip local variable manually. It is a sensible default-deny posture for a lab — the Caldera console on 8443, the MLflow server, and VECTR on 8081 should never face the open internet — but operators in dual-stack environments should verify the whitelist before trusting it.
Lifecycle management is textbook Terraform: terraform init, terraform apply -auto-approve (or a planned run.plan for the disciplined), and terraform destroy -auto-approve to melt the whole range away. The terraform output command is the operational hub — it prints the Caldera console URL, MLflow endpoint, VECTR URL, admin credentials, API keys, the Windows RDP address, and an SSH line for the Linux host. All of the default credentials shown in the README are placeholder-tier (Caldera2024-style), and the README correctly points to bas.tf and local.yml.tpl as the places to change red, blue, and admin credentials plus API keys before any real use.
Customization is well factored. bas.tf owns the Linux server and Caldera variables, win1.tf owns the Windows build (with instructions for substituting your own AMI), and the files/ tree mirrors the deployment: bootstrap.sh.tpl, caldera.service, local.yml.tpl, and per-role Windows scripts like red.ps1.tpl. Troubleshooting is documented with the same rigor — tail -f /var/log/user-data.log on Linux, sudo systemctl status caldera, and netstat checks on ports 8443 and 5000 confirm the services are live. The README was tested with Terraform 1.5.7 on macOS 13.4, which is worth pinning against since provider drift is the usual failure mode in projects like this.
Where does this fit in an authorized workflow? It is a detection-validation harness: stand it up in a dedicated AWS account, run threat-informed emulation via Caldera or Atomic Red Team, capture Sysmon telemetry from the Windows victim, and score outcomes in VECTR — then destroy everything and repeat against an improved detection stack. It is not a scanning or exploitation tool against third parties; every resource lives inside your own account, and the tool's value is in making the build/teardown cycle cheap enough that purple-team exercises actually happen. For teams exploring LLM-assisted adversary emulation through the MCP plugin, the MLflow tracing layer makes it a rare, observable platform for that experimentation — provided the security-group discipline the README itself insists on is respected.
iknowjason/AutomatedEmulation.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.