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