DLLHijackHunter

By ProjectMerai

Automated DLL hijacking discovery, validation, and confirmation for Windows
From "this DLL might be hijackable" to "a standard user can make SYSTEM load this — here is the proof."

Overview
Quick start
How it works
What it detects
Reducing false positives
Verification: load probe and canary
Scoring, tiers, and attack chains
Usage reference
Safety and operational impact
Building from source
Test lab (HijackRange)
Known limitations
Comparison

Overview

DLLHijackHunter finds DLL hijacking opportunities on a Windows host and works to prove them, not just list them. It:

Discovers every place a binary is launched automatically — services, scheduled tasks, Run keys, Startup folders, COM servers, AppInit/AppCert DLLs, IFEO entries, and auto-elevating UAC binaries — and computes where each imported DLL would be searched for.
Filters out positions an attacker cannot actually use: API sets, KnownDLLs, directories a standard user cannot write, protected processes, and more.
Verifies (optional) with the real Windows loader, by placing a benign probe DLL and checking which copy wins the search.
Confirms (optional) by deploying a harmless canary DLL, triggering the service/task/COM object, and recording the identity it actually ran as.
Scores and reports each finding by confidence and impact, and correlates findings into attack chains (for example standard user → SYSTEM).

Every judgement is made from the attacker's point of view — an unprivileged standard user — regardless of whether the scanner itself runs elevated. Running as Administrator gives the tool more visibility (ETW, canary, service triggers); it never makes protected directories look writable or inflates the privilege gained.

Quick start

Download or build DLLHijackHunter.exe (self-contained; no .NET install needed), then from an elevated prompt:

# Passive, read-only triage: no file drops, no service/task starts
.\DLLHijackHunter.exe --profile safe

# Full static analysis without touching the system, JSON report
.\DLLHijackHunter.exe --profile aggressive --no-canary --no-etw -o report.json

# Static analysis + real-loader verification (writes probe DLLs transiently)
.\DLLHijackHunter.exe --profile aggressive --no-canary --no-etw --verify-load -o report.html

# Everything, including ETW and canary confirmation — lab / authorised targets only
.\DLLHijackHunter.exe --profile aggressive -o report.html

# Focus on one application
.\DLLHijackHunter.exe --target "C:\Program Files\MyApp\app.exe" --no-canary

Antivirus: the canary and probe DLLs are unsigned and behave like hijack payloads, so Microsoft Defender may quarantine them. The tool detects this and reports those results as inconclusive rather than "not hijackable". On a test machine, exclude the target directories and %ProgramData%\DLLHijackHunter to get definitive results.

How it works

flowchart TB
    subgraph S1["1 · Discovery"]
        direction LR
        EN["Launch points<br/>services · tasks · Run keys<br/>startup · COM · AutoElevate"] --> PE["PE analysis<br/>imports · delay loads<br/>manifest"] --> SO["Search order<br/>identity-aware PATH"]
        ETW["ETW runtime trace<br/>optional, elevated"]
    end
    subgraph S2["2 · Filter pipeline"]
        direction LR
        HG["Hard gates<br/>API sets · KnownDLLs<br/>writability"] --> SG["Soft gates<br/>manifest · privilege<br/>PPL · LoadLibraryEx"] --> DD["Dedup and<br/>profile filters"]
    end
    subgraph S3["3 · Verification (optional)"]
        direction LR
        LP["Load probe<br/>real Windows loader"] --> CN["Canary<br/>deploy, trigger, confirm"]
    end
    subgraph S4["4 · Output"]
        direction LR
        SC["Scoring and tiers"] --> AC["Attack chains"] --> RP["Console · JSON · HTML"]
    end
    S1 --> S2 --> S3 --> S4

Phase	Requires admin	Modifies the system
Static discovery + filters	No (admin sees more)	No
ETW runtime discovery	Yes	Starts auto-start services (up to 100) and runs scheduled tasks (up to 30) to provoke DLL loads
Load probe (`--verify-load`)	No	Briefly writes a benign probe DLL at each candidate position, then removes it and restores any original
Canary confirmation	Yes	Writes a canary DLL, stops/starts services, runs tasks, activates COM objects, then cleans up

What it detects

Hijack types

Type	What it means	Notes
Phantom	The DLL does not exist anywhere in the search path	Plant it anywhere the binary searches
Search order	A writable directory is searched before the legitimate copy	Includes overwriting a DLL in a writable directory
ENV PATH	A writable directory in `PATH` is searched for a missing DLL	Services are evaluated against the machine PATH only — the user's own PATH entries are never searched by a service
.local redirect	`<app>.exe.local\<dll>` redirection	Only reported for executables without a manifest (or when IFEO `DevOverrideEnable=1`); the loader ignores `.local` otherwise, and it never redirects KnownDLLs
Side-load (UAC)	Copy an auto-elevating EXE next to a planted DLL	Only for EXEs with `<autoElevate>true</autoElevate>` in their manifest. Auto-elevation requires a trusted location, so the copy must pass that check (e.g. a mock `C:\Windows \System32\` folder)
AppInit DLLs	`AppInit_DLLs` points to a writable DLL	Loaded into every process that loads `user32.dll`
AppCert DLLs	`AppCertDLLs` points to a writable DLL	Loaded into every `CreateProcess`/`WinExec` caller

IFEO Debugger and SilentProcessExit\MonitorProcess binaries are enumerated and analysed like any other launch point. CWD-based hijacks are not currently produced.

Who the target runs as

Correct identity drives both the privilege-escalation verdict and the impact score:

Services — ObjectName (LocalSystem, Local Service, Network Service, or an account); svchost services also analyse their ServiceDll.
Scheduled tasks — the task principal. SID forms such as S-1-5-18 are mapped to NT AUTHORITY\SYSTEM; group principals run as the logged-on member (only Administrators + highest privileges counts as elevated). Payloads wrapped in rundll32, cmd /c, or powershell -File are analysed too.
Run keys / Startup folders — enumerated for every loaded user profile (HKEY_USERS) and every profile's Startup folder, attributed to that user — not just the account running the scanner.
COM — out-of-process servers follow AppID → RunAs / LocalService; in-process servers run as whichever client loads them.

DLLHijackHunter v2.4.0