One of my favorite techniques, which every APT group uses in cyber attacks, involves DLL SideLoading.

Most commonly, we see APT groups using signed Microsoft executables to load malicious DLLs.

From the attacker’s point of view :
The threat actor sends a zip file containing a malicious DLL and a Microsoft-signed executable. The threat actor tricks the user into executing the signed executable. When the executable is run, the malicious DLL is loaded, downloads the second stage payload, creates persistence, or establishes a reverse connection to the C2 server.

In the example below, you can see a folder containing ‘WFS.exe’ and a malicious DLL. ‘WFS.exe’ is a Microsoft-signed executable.

The DLL contains a simple C program, which is designed to pop up a message box saying ‘Success,’ and establishes a reverse connection whenever the executable is run.

‘WFS.exe’ is vulnerable to a DLL called ‘scansetting.dll,’ which has a function named ‘ProgDlgTakeFgIfShowing().’

To recreate this in your lab, copy ‘WFS.exe’ from the System32 folder, paste it into any folder, and also place the crafted DLL file in the same folder. Then execute the exe. Boom! You get the reverse connection, and the initial access is complete.

In recent red team engagements, we observed that top XDR solutions failed to detect the DLL SideLoading and successfully established the connection back.

This is where Threat Hunters come into the picture. To hunt for DLL SideLoading when EDRs or XDRs fail to detect.

Threat Hunters can build queries or rules to look for these kinds of behaviors.

Use Cases:

1. Hunt for signed executables that are executed from an unknown path and load unsigned DLLs.
2. Hunt for executables where the DLL is loaded from the same folder. For example, if the executable is present in the ‘Documents’ folder and the DLL is loaded from the same folder, it is suspicious and needs further investigation.

Include these commonly targeted paths in your query: ‘\Documents,’ ‘\ProgramData,’ ‘\Public,’ ‘\AppData,’ etc.