For more than a decade in IT and security circles, we’ve been talking ad nauseam about enterprise migration—from on-prem storage, servers, and databases to remote cloud computing. It’s a tired conversation at this point—and not one that we have any interest in retreading. What matters is this: the scale of “the cloud” is unfathomably large and the ability to instantaneously access and scale up or down a seemingly unlimited amount of computer power and infrastructure at will has ushered in the invention of new computer-like tools that don’t always act like traditional endpoints.
As security catches up with innovations in the cloud space, we need to develop ways of testing security controls and validating the assumptions we make about what is and isn’t visible on the remote systems where the majority of our work is increasingly done. Until recently, Atomic Red Team lacked the ability to sensibly run this kind of testing.
Enter cloud and container atomics
Most of Atomic Red Team has been focused on testing traditional Windows endpoints. By contrast, much of the world’s cloud infrastructure runs on Linux or in ways that are otherwise incompatible with the methods and specifications we’ve developed for executing atomics. Simply retrofitting the library in a way that would allow people to run tests against things that aren’t endpoints proved to be a non-trivial problem.
We’ve wanted to add cloud and container related tests to Atomic Red Team for a long, long time, and for just as long, we’ve known that there were many blockers preventing us from doing so—specification challenges and a lack of expertise, to name just a couple. However, in the last few months, we welcomed a pair of new maintainers to Atomic Red Team, MITRE made some important changes to ATT&CK, and we were finally able to introduce the first cloud and container atomics to the Atomic Red Team library.
Changing platforms (h/t to ATT&CK®)
As it turns out, many of us had gotten “platforms” exactly backward in Atomic Red Team, and MITRE’s “v9 specification” updates to ATT&CK in April 2021 offered the perfect forcing function to correct our oversights in how we defined and thought about platforms.
Again, we designed Atomic Red Team to validate visibility and detection coverage on endpoints. When you’re running endpoint tests with Atomic Red Team, it’s often the case that you’re executing a test against Windows from a Windows system, and, in many cases, it’s the same system. Atomic Red Team contributors had historically been using the “platform” tag to specify the location from which a test is executed.
For example, for a test designed to run using PowerShell on a Windows workstation that targets a remote Linux endpoint, many of us in the Atomic Red Team community had thought that Windows was the platform, when in fact the platform should have been Linux. This distinction didn’t matter so much when the source and destination of a test were very often the same. However, this distinction is very important when there are multiple methods for executing a test and just as many platforms to run a test against.
So, we made a change. The “platform” tag now specifies what the test is going to be run against. The “executor” specifies how the test will be run. Finally, the “command” specifies what is being run. In other words, if you’re using PowerShell to run an LSASS test on a Windows system, then the “platform” is Windows, the “executor” is PowerShell, and the “command” is the LSASS test.
A few examples of new platforms that enter the fray in light of the cloud and container changes made in ATT&CK and Atomic Red Team include:
- Office 365
- Azure AD
- Google Workspace
- SaaS
- IaaS (AWS, Azure, and GCP)
Introducing our new maintainers
The platform specification change was merely the opening gambit for cloud and container atomics, and a largely semantic one at that. To make Atomic Red Team for cloud and containers what it is for Windows endpoints, we needed new maintainers who specialize in (…wait for it!) cloud and container testing! To that end, we welcomed Jose Hernandez and Bhavin Patel to the team. They work on cloud and container test automation for Splunk, and we are incredibly excited that they are joining the maintainers’ team!
An example
As of right now, we have three cloud atomic tests that map to the following techniques or sub-techniques (as the case may be). Each of these tests runs on Amazon Web Services (AWS), and the platform tag nomenclature for AWS in Atomic Red Team is iaas:aws.
- T1098: Account Manipulation: creates a group and adds a user to the group
- T1098.001: Additional Cloud Credentials: creates an access key and a secret key
- T1136.003: Cloud Account: creates a new identity and access management (IAM) user
By way of an example, we will showcase the test for T1098.001: Additional Cloud Credentials. This test runs against the iaas:aws platform using sh as its executor. The command itself generates an AWS access key and a secret key that the tester (or hypothetical adversary) can then use to programmatically interact with that AWS instance.
Here’s the command:
aws iam create-access-key --user-name #{username} > $PathToAtomicsFolder/T1098.001/bin/aws_secret.creds
cd $PathToAtomicsFolder/T1098.001/bin/
./aws_secret.sh
You need to have a user account to run this script on, and you can satisfy that prerequisite by running the third test referenced above: Create a new IAM user test from T1136.003: Cloud Account.
Watch this video to see both tests in action:
This video demonstrates a user installing Invoke-Atomic and executing a cloud atomic test to create a new AWS IAM user account (T1136.003). The video then navigates to AWS to show that the account was indeed created, before a second test is executed, creating an AWS access key (T1098.001). At the very end, you can see that an access key has been added to the AWS IAM dashboard. Huge thanks to Atomic Red Team maintainers Bhavin Patel and Jose Hernandez for producing this video!
Get started
As new threats, techniques, and technologies emerge, the Atomic Red Team community is committed to proactively growing, adapting, and adjusting, so that we stay relevant and useful for all of your testing and educational needs. We’re hopeful that the community embraces cloud and container atomics and starts adding new tests to the atomic library!
On GitHub you can learn more about Atomic Red Team itself, the cloud & container spec changes, and how to contribute.
And as always, the community is open to all via the Atomic Red Team Slack.
Get Atomic Red Team updates straight to your inbox
Related Articles
Emu-lation: Validating detection for Gootloader with Atomic Red Team
Emu-lation: Validating detection for Gootloader with Atomic Red Team
Safely validate executable file attributes with Atomic Test Harnesses