Threat hunting for DLL side-loading

As cyber adversaries become more sophisticated, detecting and neutralizing potential threats before they can cause any harm has become a top priority for cybersecurity professionals. It is also why threat hunting is a crucial skill. By mastering the art of cyber threat hunting, security professionals can build a robust defense and shield their organization from the ever-persistent menace of cyber threats.

This post launches a series called Hunting Rituals, as part of which Group-IB threat hunters will show you how to perform managed threat hunting using Group-IB Managed XDR, and EDR in particular. You will learn what recent threat hunting trends to keep an eye on, how to perform threat hunting within your infrastructure, and what threat hunting tools are used by professionals.

MITRE Attack Technique T1574.002 Hijack Execution Flow: DLL Side-Loading

Among the array of techniques employed by malicious actors, DLL side-loading (T1574.002,MITRE ATT&CK® Enterprise Matrix) has proven to be a cunning method to evade traditional security measures. According to the MITRE ATT&CK Framework, “adversaries may execute their own malicious payloads by side-loading DLLs. Similar to DLL Search Order Hijacking, side-loading involves hijacking which DLL a program loads. But rather than just planting the DLL within the search order of a program then waiting for the victim application to be invoked, adversaries may directly side-load their payloads by planting then invoking a legitimate application that executes their payload(s).”

In this article, we explore real-world use cases and show how effective EDR is in unveiling the concealed dangers of DLL side-loading. By focusing on the elusive threat that is DLL side-loading, we explore how EDR can be harnessed as a proactive tool to detect and analyze the behavior of a potential advanced threat. Read on to find out how APTs such as TA428and Dark Pink have leveraged DLL side-loading in known attacks.

Hunting the threat: from hypothesis to event analysis

To start threat hunting using EDR telemetry, first of all we need to put forth a plausible hypothesis. For DLL side-loading, it could be something like this:

“The process will load an incorrectly signed DLL from the same directory with the process’ executable file. The directory path and/or executable file name may also be suspicious”. The first part of the hypothesis defines the core of the query that we will use later:event_type: “Loading executable code in the process” AND NOT Payload.ImageFileSign.TrustStatus: “3” AND Payload.ImageFileName: “*.dll”

The second part of the hypothesis is a limiting condition and it may vary depending on your threat landscape, analysis/EDR features, the amount of events, or even your assumptions about the attacker’s capabilities. For simplicity, we will add the limiting condition for the directory hosting a potential malicious DLL and executable file that will load such a DLL:event_type: “Loading executable code in the process” AND NOT Payload.ImageFileSign.TrustStatus: “3” AND Payload.ImageFileName: “*.dll” AND Payload.ImageFileName: [“*:\\ProgramData*”, “*\\public*”, “*\\documents*”, “*\\pictures*”, “*\\videos*”, “*\\music*”, “*\\appdata*”] AND Header.ImageFileName: [“*:\\ProgramData*”, “*\\public*”, “*\\documents*”, “*\\pictures*”, “*\\videos*”, “*\\music*”, “*appdata*”]

In this query Payload.ImageFileName defines the full path to the DLL and Header.ImageFileName defines the full path to the executable file, which means that our final hypothesis looks like this:

The process will load an incorrectly signed DLL from the same directory with the process’ executable file; the directory for both should match one of the following patterns: “*:\\ProgramData*”, “*\\public*”, “*\\documents*”, “*\\pictures*”, “*\\videos*”, “*\\music*” or “*\\appdata*”.

Let’s use this query against the collected telemetry:

query against the collected telemetry

There are some events involving the repeated loading of a DLL file named Acrobat.dll. Let’s look at the first event:

a DLL file named Acrobat.dll

We obtained the GUID (global unique identifier) of a process instance which loaded the DLL in question. To perform further analysis, we can search for a process creation event using the obtained GUID:

a process creation event using the obtained GUID

The details relating to a found event can tell us more valuable information about the examined process:

details relating to a found event in managed xdr system

First of all, we can see the full file path of the executable. Then, we can see that the executable itself is properly signed (ImageFileSign.TrustStatus = 3), which is usual evasive behavior during DLL side-loading. Lastly, we can see that the parent process is taskeng.exe, which could mean that this executable is persistently executed using scheduled tasks. We can now combine our findings:

  • The executable file C:\ProgramData\Acrobat\AcrobatAey\Acrobat.exe is repeatedly executed using scheduled task
  • When it is executed, it loads a DLL that is not signed C:\ProgramData\Acrobat\AcrobatAey\Acrobat.dll from the same directory (a possible sign that the DLL side-loading technique is being used)

To perform further checks, we can use the same GUID of the suspicious process to obtain additional information regarding network connections, the file system, and registry operations. In addition, since we know that the executable file has been made persistent through a scheduled task, we can try to search events for scheduled task creation using the following query:event_type: “Process creation” AND Payload.ImageFileName: “*\\schtasks.exe” AND Payload.CommandLine: “*C:\\ProgramData\\Acrobat\\AcrobatAey\\Acrobat.exe*”

This means that we search for schtasks.exe related events that contain the path to the suspicious executable in the command line:

 schtasks.exe related events

Examining such events can help identify additional information (e.g. the task name, user account, additional backdoor files) that could help with further remediation or even with identification of a payload injected into legitimate processes.

To sum up, this blogpost has discussed how to use EDR telemetry to track down the use of DLL side-loading in your environment. It is not the only way to do it, of course, so in the upcoming series we will cover other methods of threat hunting that involve EDR and additional sophisticated hunting techniques, so stay tuned!

Roman Rezvukhin

Roman Rezvukhin – Head of Malware Analysis and Threat Hunting Team