As a Red Team Engineer, part of my responsibilities includes emulating adversary activity in Code42’s environment. The MITRE ATT&CK Framework is a great resource for this as it contains a knowledge base of adversary tactics and techniques based on real-world observations. Due to the nature of offensive operations, adversary TTP’s (tactics, techniques, and procedures) vary greatly in their setup and execution. This makes testing a fairly manual process and, as an engineer, I am not a fan of the phrase “manual process”.
Anything that is repeatable (e.g. monthly TTP tests) can be automated to at least some degree. Automating TTP testing of the MITRE ATT&CK Framework would involve creating a library of tests that map to each TTP in MITRE — sounds like a lot of work. Thankfully, such a library has already been created by Red Canary! Atomic Red Team is an open-source library of tests that map directly to the MITRE ATT&CK Framework. Each test has a common YAML format enabling ease of integration with other tools.
To automate the execution of atomic tests, a C2 (command and control) tool, such as Cobalt Strike, Mythic, or Caldera, could be leveraged and built upon to integrate the atomic test library into the framework. This way atomic tests can be run automatically from a C2 agent as opposed to being manually run on the target server. This means less time setting up and executing tests and more time focusing on improving our defensive security posture.
At Code42, we are in the process of designing and implementing our own infrastructure so that automated testing of our environment may be performed. We are choosing to use Atomic Red Team as our test library and Caldera as our C2 / execution framework. The idea is that we will roll out several machines in various parts of our infrastructure that are solely dedicated to being the target for atomic tests. These machines will be provisioned in such a way that they replicate what “typical” servers/endpoints/ec2 instances/etc look like in our environment. With this setup, we can avoid executing tests on production servers or endpoints while ensuring the tests provide reliable data that can be used to improve our entire environment as a whole.
Now, although the goal here is automating as much as possible, TTP testing will never be a fully hands-off approach. A Red Team Operator should always be aware of exactly what is happening behind the scenes of each test. The cybersecurity world also has a rapidly changing landscape and malicious actors are constantly finding new ways to perform their bidding. This means that to truly have an effective TTP testing program, the test library you use must be kept up to date with the latest techniques — new tests will need to be created and current tests will need to be updated.
Stay tuned for more blog posts as we develop our TTP testing environment. For more security-focused blogs, check out redblue42.com!
