At the end of every year, we take a look at all of the data associated with the confirmed threats we detected in our customers’ environments to figure out what threats are occurring most often, why adversaries are leveraging specific techniques, and how security teams can detect those malicious behaviors. The product of this analysis is our annual Threat Detection Report.
Much to the dismay of maybe a dozen people on Twitter, we decided this year that we would no longer create a PDF version of the report. The reasons for this are many, but two stand out in particular:
1. We wanted to create a more dynamic user experience.
2. We wanted to be able to make updates to the report without worrying about version control.
Moving forward, the Threat Detection Report will continue to be recalibrated every year, as we update our prevalence rankings to reflect trends in our detection data. As techniques fall in and out of favor, however, each technique-specific analysis (like this one for T1055: Process Injection) will be preserved as part of a reference library that you can use to understand important threat techniques, what they look like behaviorally, and how you might detect them.
Threat Detection Report 2.1
For our first substantial update, we decided to add a new testing section to each technique-specific page. Along with analysis, definition, and detection sections, each technique page now includes simple instructions on how you can use Atomic Red Team tests to simulate an adversary leveraging that technique in your environment.
What’s Atomic Red Team?
For nearly three years, we’ve maintained an open source detection testing framework called Atomic Red Team. If you think of the MITRE ATT&CK framework as a taxonomy of threats that attempts to describe the many techniques that an adversary might use when attacking an organization, then you can think of Atomic Red Team as a collection of tests for emulating those techniques. It’s a free and agent-less alternative to commercial testing solutions that many security teams use to ensure that their security controls are working as intended or advertised.
There are different ways you can go about running atomics to test your detection coverage. In the testing sections of the Threat Detection Report, we use two:
Testing with Atomic Red Team may seem daunting at first, but it’s really quite simple—and easier than ever with all the recent improvements to Invoke-Atomic, the open source PowerShell module for executing tests. However, even if you don’t use Invoke-Atomic, testing is still as simple as cloning the Atomic Red Team repository and following simple instructions (mostly just copy and pasting command-line scripts) that are included with the tests you want to run. However you use it, the platform is a great resource for checking your visibility, validating assumptions about security controls, and learning about what suspicious or malicious behavior might look like in your endpoint telemetry.
You can find detailed information on how to test against the top 10 most prevalent threats on each of the technique pages in the Threat Detection Report. We’ll run through a quick test for our number one technique, Process Injection, to give you an idea of what you might expect to find in the report.
Testing Process Injection
Before you can test anything, you need to:
- Make sure you have permission to run these tests.
- Set up a non-production or lab environment in which to run these tests.
- Make sure you have PowerShell version 5.0 or later installed.
- Download Invoke-Atomic or the entire Atomic Red Team test repository.
Installing the framework
To keep things relatively simple, we’ll operate under the assumption that you want to install both the execution framework (Invoke-Atomic) and the entire atomic folders. You can find detailed instructions on your various installation options on the Invoke-Atomic wiki.
Run the following script in PowerShell and then wait (it may take a few minutes):