DLL Persistence Attacks

Many attackers employ these techniques to hide in plain sight and evade detection. They utilize completely legitimate processes but inject a malicious DLL file into the process, either locally or from a remote host.

Background Image

In this blog, we are going to explore the various ways attackers can leverage DLL hijacking techniques. I will approach the topic from the defender’s perspective, providing insight beyond just the attacker’s viewpoint.

First technique: DLL Search Order Hijacking

How it works:

• Windows DLL Loading Mechanism: Windows follows a specific search order when loading DLLs for an application. This includes the current working directory, system directories, and directories listed in the system’s PATH environment variable.
• Exploiting the Search Order: Attackers place a malicious DLL in a location that the operating system searches during this process. By manipulating the search order, they trick the system into loading their DLL instead of the legitimate one.
• Arbitrary Code Execution: Once the malicious DLL is loaded, it executes arbitrary code within the context of the legitimate process, potentially leading to unauthorized actions or compromising the integrity of the application.

Example:

• Imagine we have Explorer.exe, a crucial system process, and it relies on a specific DLL called ntshrui.dll when it runs. Now, how could an attacker go about injecting a DLL into explorer.exe? Here’s where it gets interesting: explorer.exe is typically located in C:\Windows. When the operating system loads DLLs for a process like explorer.exe, it follows a specific search order. It first checks if the required DLL can be found in the same directory as the executable. If the DLL isn’t found there, the OS proceeds to search for it in the System32 directory.
• Exploitation: The attacker identifies that the application does not specify the full path when loading a required DLL named “ntshrui.dll” which is located under C:\Windows\System32.
• Execution: The attacker places a malicious DLL with the same name, “ntshrui.dll,” in the same directory as “Explorer.exe.” (C:\Windows\ntshrui.dll) When the application runs, it attempts to load “ntshrui.dll,” and since the current working directory is searched first, the malicious DLL is loaded, executing arbitrary code within the application’s context.

Note

Windows Search order for DLLs

1. Side-by-Side Components
2. KnownDLLs list “registry”
3. Application Directory
4. C:\Windows\System32
5. C:\Windows\system
6. C:\Windows
7. Application’s registered App Paths directories
8. System PATH

Second technique: Phantom DLL Hijacking

Phantom DLL hijacking relies on a misconfiguration or legacy DLLs that used to be loaded by certain processes in older versions of Windows. When a DLL is no longer necessary, but the code of a process still includes loading that DLL, attackers exploit this situation. They create a DLL with the same name as the legacy DLL, allowing them to take advantage of the outdated configuration or code that attempts to load the now-unnecessary DLL.

How it works:

• Creating a Phantom DLL: Attackers create a fake DLL file with a name matching the expected DLL in a directory the system searches. However, the file itself doesn’t physically exist.
• System Interaction: When an application attempts to load the DLL, the system looks for it in the specified directories. Despite the absence of a physical file, the system recognizes the phantom DLL and attempts to load it.
• Malicious Code Execution: Exploiting this behavior, attackers can execute their malicious code, taking advantage of the system’s attempt to load the non-existent DLL.

Example:

• An antivirus software relies on a DLL named “scan_engine.dll” located in the System32 directory.
• Exploitation: The attacker generates a counterfeit DLL named “scan_engine.dll.” The exploitation occurs because the existing code within the target process prompts it to attempt loading this DLL during its execution. The attacker leverages this behavior to introduce their malicious code into the process.
• Execution: When the antivirus software scans files, it attempts to load “scan_engine.dll” from the system directory. The system recognizes the phantom DLL and attempts to load it, resulting in the execution of the attacker’s code.

Third technique: DLL Side-Loading

This technique is so popular, and it is just like Search order. 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).

This attack uses the Windows side-by-side (SxS) DLL loading mechanism to introduce an “updated” version of a DLL. SxS functionality is a legitimate feature of Windows and is used by many applications to prevent problems that can arise due to updated and duplicate versions of DLLs. SxS gives the ability to load updated DLLs, but has few validity checks for these new DLLs and thus the loading mechanism can be abused due to missing DLLs, use of relative paths, and other shortcuts not taken into account by the application developer.

How it works:

Understanding Windows Side-by-Side (SxS) Mechanism:

• Windows utilizes SxS functionality to manage DLL dependencies for various applications. SxS allows multiple versions of a DLL to coexist on a system without causing conflicts. It helps prevent issues that may arise from applications relying on different versions of the same DLL.

Introduction of an “Updated” DLL:

• Adversaries take advantage of SxS by introducing a malicious DLL that appears to be an “updated” version of a legitimate DLL used by a target application.

Choice of Legitimate Application:

• Rather than directly targeting the victim application, attackers identify and compromise a different, legitimate application that relies on the same DLL. This application serves as the entry point for the malicious DLL.

Planting and Invoking the Legitimate Application:

• The attacker plants the malicious DLL in a location where the compromised legitimate application can access it. They then invoke or execute the legitimate application, which, in turn, loads the malicious DLL.

Abusing SxS Mechanism:

• The SxS mechanism loads the DLL, considering it an “updated” version. Importantly, SxS has limited validity checks for the introduced DLLs. Adversaries exploit this lack of thorough validation to execute their malicious payloads.

Vulnerabilities in Loading Mechanism:

• DLL Side-Loading can be successful due to various factors, such as missing DLLs, the use of relative paths, or other shortcuts not considered by the application developer. Attackers take advantage of these vulnerabilities in the loading mechanism to achieve their goals.

Note

This technique is relatively challenging to execute successfully. If you observe instances of Phantom DLL Hijacking within your organization, it indicates that your security measures are effective. In such cases, sophisticated threat actors, like Advanced Persistent Threats (APTs), might resort to this technique in an attempt to conceal their activities, making detection more difficult.

Due to the vast nature of side loading, it cannot be fully discussed in this short blog. For more detailed insights, you can explore a comprehensive article on the topic by Mandiant

Injection can take place in two ways: it can originate from a DLL physically stored on the disk of the local system, or it can occur remotely, with the injection process being conducted from a remote host. The latter method can be further classified into two types: remote injection and reflective injection.

Maybe we will discuss that in a future blog.

That’s it for now :”