Atomic Red Team Tests: Catching the Dragon by the Tail

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.”

To learn how to start testing your security controls, watch the on-demand training session: Atomic Red Team Testing: Ground Zero

Observing Adversarial Behaviors

By leveraging the FireEye report and other sources, we can start to craft tests that emulate the behaviors and capabilities of actual adversaries.

First, we observe an MHT file lure. This is a document format that can be opened in Microsoft Word, and can contain Macros. An example might look like this:

Here is a good reference on MHT files and macro payloads: https://www.cyren.com/blog/articles/new-tricks-of-macro-malware

The likely reason attackers choose this format is to evade detection in Spam filters or other defensive countermeasures that may be looking for more traditional document formats.

Once the user enables the macros by clicking “Enable Content,” horrible things ensue…

Running Chain Reaction Tests

Now that we have gained an understanding of the behavior and actions taken by these actors, it is time to develop our test cases.

In our example, in order to simulate this activity, we have provided you with the VBA code necessary to trigger this process: https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/ARTifacts/Chain_Reactions/chain_reaction_DragonsTail.bat

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.

1. The script sets up persistence by creating, executing, and removing a scheduled task that uses the RegSvr32.exe payload. (Technique 1053, 1117)
2. 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)
3. We create a file and use a technique known as Timestomping to modify time attributes on the file. (Technique 1099)
4. 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.

Checking Controls

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.

Developing Detections

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.

Key Takeaways

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.

Contributions

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 [email protected].

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.

Popular Atomic Red Team Resources

• On-Demand Training Session: Atomic Red Team: Ground Zero
• Atomic Red Team GitHub Repo
• Video: How to Use Atomic Red Team Tests