Automated Emulation is an open-source Terraform template designed to create a customizable, automated breach and attack simulation lab.
The solution automatically constructs the following resources hosted on AWS:
- One Linux server deploying Caldera, Prelude Operator Headless, and VECTR
- One Windows Client (Windows Server 2022) auto-configured for Caldera agent deployment, Prelude pneuma, and other Red & Blue tools.
This lab stands out from other well-known cyber ranges due to its unique design and approach. Secondary tools like Ansible are unnecessary, although you can use them if preferred. However, they are not essential for configuration management. This lab opts for Terraform providers (AWS SDK) and built-in AWS features (user data) instead of relying on third-party configuration management tools.
Developing Automated Emulation
The creator of Automated Emulation, Jason Ostrom, aimed to develop an infrastructure security lab to enhance skills in adversary simulation, focusing on linking TTPs and evaluating various endpoint security products. He envisioned this as a customizable “Security Playground” for personal skill enhancement.
“It’s really powerful to have automation like this at your fingertips to quickly build things, test an attack, and then destroy. What better way to do this than having a disposable adversary emulation lab where you can build Caldera with different Atomic Red Team atomics and custom payloads? For any changes to TTPs and payloads, the Terraform and bash scripts allow you to push any new, saved changes automatically. So, the next time you build the lab, they get automatically pushed,” Ostrom told Help Net Security.
Ostrom strongly advocates for open-source security and is passionate about contributing to the community. Having previously worked for SANS as a Cloud Engineer developing Cyber Ranges, Ostrom utilized Terraform to build AWS and Azure projects. With this lab, his goal was to make some aspects of the technology approach more accessible to the community, exposing users to new methods without revealing the custom and proprietary terraform modules used in SANS’s lab creations. Automated Emulation is research from a new SANS class called SEC598 (“Security Automation for Offense, Defense, and Cloud”).
Features
“The biggest unique capability is it doesn’t use a secondary Configuration Management (CM) tool to bootstrap OS and services after the VM has been created. Instead, it uses the AWS SDK with terraform and cloud native features (user-data) to bootstrap. This meets the goal of the project of striving for speed, stability, and consistency,” said Ostrom.
Ostrom provided an explanation regarding the construction of Infrastructure as Code (IaC) in the cloud, focusing particularly on Infrastructure as a Service (IaaS) Virtual Machines. He highlighted that there are two primary components in this process. The first is the creation of a new VM in the cloud using terraform, which involves pushing the infrastructure. The second component is the configuration management (CM) or bootstrapping, which is essential for installing and setting up the OS services and applications on the VM after it has been deployed.
The developer noted that most companies and users typically employ a secondary tool for CM to configure the VM. This approach is common in many other security labs and Cyber Range tools, where tools like Ansible playbooks are used to push changes. However, he pointed out the distinctive aspect of the lab he was discussing: it does not utilize such secondary tools. Instead, the lab leverages a cloud provider feature known as “user-data.” This feature, in combination with terraform and the cloud provider’s native capabilities, is used to implement changes, differentiating this lab’s approach from others in the field.
“You can write your own bash and PowerShell scripts and the documentation shows the capability. Those scripts are stored in a staging S3 bucket and the Windows and Linux systems download and run them. I used to use Ansible when I first got started with this type of building. I’ve now switched to this method for those reasons,” comments Ostrom.
“A lot of security people I know love Ansible and only use it for CM. It definitely has a lot of valid use cases. You can certainly use Ansible playbooks if you want to here, but they aren’t necessary. Whenever you add a secondary tool, it adds another layer of IT “cruft”, of potential things that can go wrong. Like network latency, mis-configured credentials, Security Groups not allowing WinRM/SSH, and outdated python libraries around these tools (not to mention you might have to install Ansible on the originating system and sometimes the destination you are building on). I’m also not saying “this is the way” that things should always be done. Far from it. I just think it’s important to be transparent, open, and flexible to alternative approaches.”
Ostrom highlighted several unique and innovative aspects of his project. He emphasized that the project is designed to automatically bootstrap the Caldera Sandcat agent on the Windows system, ensuring it’s fully registered and ready to use. This feature allows users to immediately start testing payloads and abilities against the target Windows system as soon as the lab is operational. He noted this automation as a significant time-saver. Additionally, the project is configured to upload all payloads and abilities from a local directory directly to the Caldera server. This means that as soon as the Caldera system is up and running, all the user’s local work is instantly available, eliminating the need to re-upload their work.
“Overall, lots of nice capabilities combined together. It also automatically deploys VECTR for Red and Blue team activity tracking on the Linux server, as well as a Prelude Operator deployment that automatically bootstraps a registered Pneuma agent on Windows. On the Windows target, it also automatically adds Atomic Red Team and PurpleSharp,” Ostrom concluded.
Automated Emulation is available for free on GitHub.
More to consider: