TTP Analysis: DLL Hijacking & Sideloading

Danger

Threat Model Alert: Dynamic Link Library (DLL) manipulation represents one of the most pervasive defense evasion and privilege escalation techniques in the Windows ecosystem (MITRE ATT&CK T1574.001). By forcing a legitimate, digitally signed application to load a malicious DLL, threat actors can bypass Application Whitelisting (AppLocker/WDAC), masquerade their execution flow, and establish stealthy persistence.

1. Executive Summary

Windows relies heavily on shared libraries (DLLs) to execute code efficiently. When an application requests a DLL without specifying its absolute path, the Windows operating system initiates a predictable search process to locate the file.

Threat actors abuse this mechanism. If an attacker can place a maliciously crafted DLL in a directory that is searched before the legitimate DLL’s location, the application will blindly load and execute the attacker’s payload within its own memory space. Because the parent process is often a trusted, signed Microsoft binary (e.g., svchost.exe, calc.exe, teams.exe), traditional Endpoint Protection Platforms (EPP) frequently fail to block the execution.

2. Technical Mechanics: The DLL Search Order

To understand the attack, analysts must understand the defense. By default, modern Windows systems employ SafeDllSearchMode. When a program calls LoadLibrary() or LoadLibraryEx() without an absolute path, Windows searches for the DLL in the following exact order:

1. The application directory: The folder from which the application was launched.
2. The System directory: Typically C:\Windows\System32\.
3. The 16-bit System directory: C:\Windows\System\.
4. The Windows directory: C:\Windows\.
5. The Current Working Directory (CWD): The directory the process is currently executing in.
6. The PATH environment variables: Directories listed in the system and user PATH variables.

3. Attack Vectors and Variations

“DLL Hijacking” is an umbrella term. Incident Responders must differentiate between the specific operational variations used by adversaries.

1. DLL Search Order Hijacking

The classic attack. The attacker places a malicious DLL (with the same name as a legitimate one) higher in the search order. For example, dropping a fake version.dll in the application’s root directory. When the app launches, it finds the fake DLL at Step 1 and stops searching, ignoring the real DLL in System32.

2. DLL Sideloading

Unlike Search Order Hijacking, where the attacker targets an existing application on the victim’s machine, Sideloading involves the attacker bringing both the vulnerable, signed executable and the malicious DLL onto the system. They drop them in the same folder (e.g., C:\Users\Public\) and execute the signed binary to proxy the payload.

3. Phantom DLL Hijacking

Many legacy Windows applications attempt to load obsolete DLLs that no longer exist in modern Windows versions (e.g., fxsst.dll). Because the real DLL is missing entirely, the OS will search the entire PATH. Attackers can drop their payload in any writable directory listed in the PATH to achieve execution.

4. Exploitation Flow

Adversaries, from ransomware affiliates to sophisticated APTs, use tools like Sysinternals Process Monitor (ProcMon) during the reconnaissance phase to identify NAME NOT FOUND results when applications attempt to load libraries.

Once a vulnerable application is found, the attacker compiles a malicious DLL. This DLL often exports the exact same function names as the legitimate library (using “DLL Proxying” or “Forwarding”) to ensure the host application does not crash, keeping the compromise entirely silent. The payload is typically executed inside the DllMain function, triggering immediately upon load.

5. Forensic Investigation (DFIR)

Detecting DLL hijacking retrospectively is challenging because the malicious execution occurs within the memory space of a legitimate process. Event ID 4688 (Process Creation) alone is insufficient, as it only records the launch of the benign parent executable.

DFIR analysts must pivot to Image Load telemetry.

Sysmon Event ID 7 (Image Loaded)

Sysmon Event ID 7 is the ultimate artifact for detecting this TTP. It logs every DLL loaded by every process.

• Hunting Strategy: Look for signed Windows binaries (e.g., binaries residing in C:\Windows\System32\) that are loading unsigned DLLs, especially if those DLLs are being loaded from user-writable directories (e.g., C:\Users\*\AppData\Local\, C:\ProgramData\, or C:\Temp\).

File System Artifacts

• MFT Anomalies: Identify the creation of .dll files in directories where they do not belong (e.g., a .dll sitting next to a standalone executable in the Downloads folder).
• Execution Evidence: Cross-reference Prefetch files to confirm if the vulnerable host application was executed around the time the malicious DLL was dropped.

6. Detection & Threat Hunting

KQL (Defender XDR)

hunt_dll_sideloading.kql

// Detects signed Microsoft binaries loading unsigned DLLs from suspicious paths
DeviceImageLoadEvents
// Focus on DLLs loaded from highly abused user directories
| where FolderPath has_any ("\\AppData\\Local", "\\AppData\\Roaming", "\\ProgramData", "\\Users\\Public")
// Ensure the DLL itself is unsigned
| where isempty(SignatureInfo) or SignatureState != "Valid"
// The parent process is a legitimate Windows binary
| where InitiatingProcessFolderPath startswith "c:\\windows\\system32" or InitiatingProcessFolderPath startswith "c:\\windows\\syswow64"
| project TimeGenerated, DeviceName, InitiatingProcessFileName, FolderPath, FileName, SHA256
| sort by TimeGenerated desc

Sigma (Sysmon EID 7)

sigma_phantom_dll_hijack.yaml

title: Potential Phantom DLL Hijacking (Sysmon Event 7)
id: 1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects the loading of known missing/phantom Windows DLLs (like fxsst.dll, wlbsctrl.dll) from outside the System32 directory.
logsource:
    category: image_load
    product: windows
detection:
    selection:
        ImageLoaded|endswith:
            - '\fxsst.dll'
            - '\wlbsctrl.dll'
            - '\ntshrui.dll'
            - '\profapi.dll'
    filter_legit:
        ImageLoaded|startswith: 'C:\Windows\System32\'
    condition: selection and not filter_legit
level: high
tags:
    - attack.defense_evasion
    - attack.t1574.001

7. Mitigation and Hardening

1. Absolute Paths: Software developers must enforce the use of absolute paths (e.g., C:\Program Files\App\lib.dll) rather than relative paths when calling LoadLibrary().
2. Application Control (WDAC/AppLocker): Configure Windows Defender Application Control to block the execution of unsigned DLLs, severely limiting an attacker’s ability to side-load custom payloads.
3. CWDIllegalInDllSearch: Administrators can implement the CWDIllegalInDllSearch registry mitigation to remove the Current Working Directory from the DLL search order globally or for specific applications.

---

Sources & References

• MITRE ATT&CK: Hijack Execution Flow: DLL Search Order Hijacking (T1574.001)
• CrowdStrike: 4 Ways Adversaries Hijack DLLs
• Palo Alto Unit 42: DLL Hijacking Techniques
• Google Cloud Threat Intelligence: Abusing DLL Misconfigurations
• Dragos: DLL Hijacking Whitepaper (PDF)
• Related Analysis: Sysmon (System Monitor) Telemetry