DLL search-order hijacking

DLL hijacking sounds exotic until you read the loader docs. Then it just sounds like an unfortunate default.

The search order

When a process loads a DLL by name (no absolute path), Windows walks a list of locations. Roughly:

1. The application directory
2. The system directory (C:\Windows\System32)
3. The 16-bit system directory
4. The Windows directory
5. The current directory
6. Directories listed in PATH

If your binary lives in a writable directory and asks for version.dll without an absolute path, anyone who can drop a file there gets code execution inside your process.

A toy example

# Drop a payload DLL next to a vulnerable signed binary.
# When the binary launches, the loader finds our DLL first.
shutil.copy("payload.dll", target_dir / "version.dll")

Defender notes

• Prefer SetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32) in your own code.
• Hunt for unsigned DLLs loaded from %APPDATA%, %TEMP%, and %PUBLIC%.
• Alert on signed Microsoft binaries loading DLLs from non-standard paths.

There's more to write here — particularly around phantom DLLs and how often vendors ship binaries that reference DLLs that don't exist — but that's the gist.