DLL Loading

The DLL search order, LoadLibrary internals, DllMain semantics, the KnownDLLs shortcut, and how DLL search order hijacking and side-loading give attackers persistent, signed-binary execution

DLL Search Order

When a process calls LoadLibrary("example.dll") with a DLL name but no path, Windows searches for the DLL in a specific order. The exact order depends on whether Safe DLL Search Mode is enabled (it is by default on modern Windows):

LoadLibrary Flow

When LoadLibraryW is called, the Windows loader performs these steps:

1. Check already-loaded modules: Walk the PEB InLoadOrderModuleList. If found, increment the DLL's load count and return its existing base address.
2. Check KnownDLLs: Open \KnownDlls\dllname.dll section in the Object Namespace. If found, map from the pre-created section — no file search needed.
3. Apply search order: Search directories in order; open the DLL file when found.
4. Create section object: Map the PE image into the process's address space, with ASLR if the DLL has DYNAMICBASE.
5. Apply base relocations: If the DLL loaded at a different address than its preferred ImageBase, apply relocation fixups.
6. Resolve imports: Recursively load the DLL's imports (this may cause further DLL loads).
7. Process TLS: Initialize TLS data if the DLL has a TLS directory.
8. Call DllMain with DLL_PROCESS_ATTACH: Execute the DLL's initialization code.
9. Add to PEB module list: Insert the LDR_DATA_TABLE_ENTRY into all three module lists.
10. Return base address: The module handle (= base address) is returned to the caller.

DllMain

Every DLL that needs initialization implements DllMain. The loader calls it on four events:

BOOL WINAPI DllMain(HMODULE hDll, DWORD reason, LPVOID reserved) {
    switch (reason) {
    case DLL_PROCESS_ATTACH:
        // DLL loaded into a process for the first time
        // Initialize global state here
        // CAUTION: Loader lock is held — do not call LoadLibrary here!
        break;
    case DLL_THREAD_ATTACH:
        // A new thread was created in the process
        // Allocate per-thread resources
        break;
    case DLL_THREAD_DETACH:
        // A thread is exiting
        // Free per-thread resources
        break;
    case DLL_PROCESS_DETACH:
        // DLL being unloaded (FreeLibrary or process exit)
        // Cleanup global state
        break;
    }
    return TRUE;  // Return FALSE to fail the load (PROCESS_ATTACH only)
}

KnownDLLs Protection

KnownDLLs is a registry list at HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs that includes critical system DLLs: ntdll.dll, kernel32.dll, user32.dll, etc. These DLLs are pre-mapped as section objects in the Object Namespace under \KnownDlls\ at system boot.

When the loader searches for a KnownDLL by name, it opens the pre-existing section object rather than searching any filesystem path. This means:

• A malicious kernel32.dll placed in the application directory cannot replace the real kernel32.dll — KnownDLLs check happens before the directory search
• KnownDLLs protection is enforced system-wide without application participation
• Adding to the KnownDLLs list (requires registry write access to HKLM) can protect additional DLLs

DLL Side-Loading

DLL side-loading (ATT&CK T1574.002) places a malicious DLL with a name that a legitimate application loads, in a directory that takes search priority over System32. The technique works because:

1. Many legitimate applications load DLLs by name only (no full path) — they rely on the search order
2. The application directory (step 3 in the search order) comes before System32
3. The attacker places the malicious DLL in the application's directory alongside the legitimate executable
4. When the legitimate executable runs, it loads the malicious DLL instead of the real one from System32
5. The malicious DLL typically proxies legitimate exports to the real DLL to avoid breaking the application

DLL Search Order Hijacking vs Side-Loading

Detection Signatures

# Sigma rule: DLL loaded from same directory as known Microsoft executable
# when that DLL is not in KnownDLLs and not signed by Microsoft

title: Suspicious DLL Side-Loading from Application Directory
logsource:
    category: image_load
    product: windows
detection:
    selection:
        ImageLoaded|startswith:
            - 'C:\Program Files\'
            - 'C:\Program Files (x86)\'
            - 'C:\ProgramData\'
        Signed: 'false'
    filter_legit:
        Signed: 'true'
    condition: selection and not filter_legit
fields:
    - Image
    - ImageLoaded
    - User

# Python: detect DLLs loading from non-standard paths
import re

SYSTEM_PATHS = {
    r"c:\windows\system32",
    r"c:\windows\syswow64",
    r"c:\windows\sysnat",
}

def is_suspicious_dll_load(image_path: str, dll_path: str) -> bool:
    dll_dir = dll_path.rsplit("\\", 1)[0].lower()
    img_dir = image_path.rsplit("\\", 1)[0].lower()
    # DLL loaded from same dir as executable, but not from system paths
    if dll_dir == img_dir and dll_dir not in SYSTEM_PATHS:
        return True
    return False

Q & A