Before testing your security controls, it’s extremely beneficial to understand the threat actors your organization may be facing. Nick Carr at FireEye published an excellent post a while back on how an actual adversary operates. We strongly encourage you to check it out for a solid understanding of the capabilities and behaviors exhibited by a group of attackers.
We decided to take a subset of this report and model some test capabilities. We are calling these test cases “The Dragon’s Tail” — trademark, copyright pending ;-). While these capabilities don’t represent or map to any particular actor, we feel they represent tradecraft shared by several actors.
This article will show you and your team how to:
Leverage observations on a particular actor
Iterate through a series of tests (or “Chain Reactions”)
Develop detections based on test results
For those who aren’t familiar with our Atomic Red Team testing framework, it’s a suite of small and highly portable detection tests mapped to the MITRE ATT&CK Matrix. One of its objectives is to allow you to chain multiple tests together. We call these tests “Chain Reactions.”
We didn’t want to provide actual weaponized documents; rather, we leave it up to blue and red teams to develop the document and deliver it to their test environment.
Below is a sample VBA code snippet that you may use to simulate this adversary.
Once the macro has been triggered, you will notice that the macro reaches out and executes a second stage payload:
You can see some basic examples of capabilities.
The script sets up persistence by creating, executing, and removing a scheduled task that uses the RegSvr32.exe payload. (Technique 1053, 1117)
The next phase pulls down a credential stealing tool. In this example, we just use Invoke-Mimikatz. You could use another tool to simulate the same activity. (Technique 1086, 1003)
We create a file and use a technique known as Timestomping to modify time attributes on the file. (Technique 1099)
Then we simply delete the file. The indicators here might be to test your ability to see file modifications.
While this basic test doesn’t capture ALL of the activity possible by adversaries, we hope you can begin to see how you might be able to use an open source report to craft your test cases.
Once you have executed these tests in your environment, it is time to check your controls to see what (if any) activity was detected or prevented. In this example, we will use Carbon Black Response to look for the activity:
In the screenshot above, you see the chain of events that occurred once the macro embedded document was executed. From there, we identify the cmd.exe being spawned and the rest of the techniques being used.
This would now help us drive various detections for this activity. It might be simple things like winword.exe spawning cmd.exe, or items based on the command line activity of PowerShell being used to Timestomp a file.
When Red Canary writes threat detections, we send them to our customers in a report like this:
You can see that the Red Canary analyst reviewed and confirmed tagged events to reflect the events that affected the test system.
In conclusion, we were able to take a report on a particular actor, iterate through a series of tests, and develop detections. This won’t be the last test we publish, and we realize there are some gaps. However, we hope that this provides you and your team with a solid way to begin testing against a particular set of capabilities and behaviors exhibited by a threat actor.
We want to thank Nick Carr and FireEye for their excellent research and reporting on this group. And as always, thanks to the team at MITRE for the excellent taxonomy and classification of these types of post-exploit behaviors.
Please feel free to reach out if you have any questions on how to use the Atomic Red Team framework to simulate attacker activity. You can email us at firstname.lastname@example.org.
P.S. If you are a history buff, you may notice two Easter egg references to Atomic Testing in U.S. history. First is a reference to dragon’s tail, the second is a reference to a particular date.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.