DLLHijackHunter automates discovery, filtering, and canary-based confirmation of Windows DLL hijacking paths for authorized privilege-escalation assessments and defensive hardening.
| Tool | projectmerai/DLLHijackHunter — automated Windows DLL hijacking discovery, validation, and confirmation in C# / .NET |
| Category | Windows local privilege escalation and UAC bypass scanner |
| Primary Use | Enumerating services, scheduled tasks, COM objects, and AutoElevate binaries for hijackable DLL positions during authorized assessments |
| Safe Use | Intended for penetration testers and security teams with written authorization on owned or contracted hosts; equally useful for defenders auditing their own images for weak ACLs before attackers do |
| Telemetry Note | Canary runs create transient DLLs at candidate paths and confirmation files under %ProgramData%\DLLHijackHunter\; defenders can alert on DLL writes into service directories and on those confirmation artifacts |
DLLHijackHunter from projectmerai is a C# tool built on .NET 8.0/10.0 that attacks one of the most tedious problems in Windows privilege-escalation triage: knowing whether a DLL hijacking candidate is real. Most scanners in this space enumerate weak file permissions or missing DLLs and hand you a list of maybes. This tool runs a five-phase pipeline — Discovery, Filter, Load Verification, Canary Confirmation, and Scoring — that progressively eliminates false positives and, where possible, proves execution by actually triggering the target binary. The README is unusually candid about its own limitations, which is a good signal for anyone evaluating its output for a report.
The discovery phase casts a wide net across the persistence and elevation surfaces of a Windows host: services, scheduled tasks, startup items, COM objects, and Run keys are all enumerated by the static engine. A separate AutoElevate engine scans System32 and SysWOW64 for executables with <autoElevate>true</autoElevate> embedded manifests, plus HKLM\SOFTWARE\Classes\CLSID for COM objects with Elevation\Enabled=1. A PE analyzer reads import tables, delay loads, manifests, and exports, while an ETW engine monitors real-time DLL loads and a search-order calculator reconciles everything against the actual Windows resolution order. The breadth here means one pass covers what would normally take several separate utilities.
The filter pipeline is where the engineering effort shows. Hard gates kill candidates outright: api-ms-* and ext-ms-* API set names are dropped, KnownDLLs are excluded, and — critically — ACL writability is computed relative to an unprivileged principal (Users, Authenticated Users, Everyone, plus leak-proof service accounts like LOCAL SERVICE) rather than relative to the token the tool happens to run under. That attacker-relative ACL model means an elevated scan doesn't hallucinate writable System32 paths, which is precisely the failure mode that makes naive permission scanners unreliable during LPE triage. Soft gates then adjust confidence with WinSxS manifest penalties, privilege delta analysis, LoadLibraryEx mitigation checks, signature validation, and error-handling heuristics.
Hijack type coverage is broad: Phantom (DLL missing everywhere on disk), Search Order, Side-Loading, .local redirect, ENV PATH abuse of writable directories, AppInit_DLLs, and AppCertDLLs registry abuse are all implemented, with a CWD variant planned. The README is explicit that IFEO Debugger entries are enumerated for import analysis but not advertised as standalone detections — that kind of scoping honesty matters when you're deciding what to put in a client report. The PATH path is particularly interesting because it evaluates writable PATH folders against a curated map of native Windows services known to search PATH for missing DLLs, a class of finding that generic ACL auditors routinely miss.
A standout feature is the bundled vulnerability knowledge base: a snapshot of the HijackLibs dataset, roughly 590 documented DLL entries spanning about 700 vulnerable executables, embedded as Resources/hijacklibs.json. When a discovered import matches a known entry, the finding's confidence is boosted and linked to its HijackLibs reference page; no match proves nothing. Because the dataset is data-driven, defenders and consultants can refresh it by re-downloading the current JSON from the HijackLibs API over that resource file without touching code — worth doing before an engagement, since the snapshot will age.
The opt-in --verify-load mode is a smart middle ground between static analysis and full canary execution. For each applicable candidate it briefly writes a benign probe DLL to the writable position, then asks the real Windows loader — in a short-lived child process — to resolve the DLL by name. If the loader picks the writable position, the search-order claim is proven; if it loses to a KnownDLL or System32 copy, the candidate is heavily demoted. This catches the classic static-analysis false positive like a search-order finding against ntdll.dll that KnownDLLs renders unexploitable. It runs as a standard user, models modern LOAD_LIBRARY_SEARCH ordering, backs up and restores any pre-existing file, and applies only to Phantom, Search-Order, and Side-Load candidates; the README notes it writes transient files, so leave it off for fully passive triage.
Canary confirmation is the tool's signature capability. Instead of guessing, it extracts a precompiled, harmless canary DLL — shipped for both x64 and x86, statically linked so it has no ucrtbase/vcruntime dependency — places it at the hijack path, triggers the victim binary via service start, task run, or COM activation, and polls for a self-locating confirmation file derived from the canary's own module path. The confirmation captures PID, user, integrity level, and privilege indicators, then the canary is cleaned up. The canary source is auditable at src/DLLHijackHunter/Resources/canary_src.c and rebuildable with Resources/build_canary.bat, though no compiler is ever needed at scan time. The maintainers note the embedded canaries are unsigned, with code-signing left as a release-time step.
The most technically sophisticated piece is the export-forwarding proxy: when a search-order target DLL exists and exports symbols, a plain canary would crash the host process on load. DLLHijackHunter synthesizes a proxy at runtime through in-process PE surgery, grafting a .edata section onto the embedded canary with forwarder strings computed from the victim DLL's export table. The README claims these proxies have been validated against services and scheduled tasks running as NT AUTHORITY\SYSTEM, while honestly flagging remaining edge cases — ordinal-only exports, decorated names, and loader assumptions requiring the real DLL — that can yield inconclusive rather than negative results. That distinction between 'inconclusive' and 'impossible' is exactly the right epistemic framing for a validation tool.
Output lands in three formats — console, JSON, and HTML — ranked by a tiered scorer where canary-confirmed execution sits at the top, loader-verified findings reach High, and static-only candidates are demoted accordingly. A standard-user triage pass without canaries or ETW is a reasonable first touch during an authorized assessment: DLLHijackHunter.exe --lpe-only --no-canary --no-etw --verify-load. Everything beyond that, particularly canary placement into service directories, belongs strictly inside engagement scope on systems you own or are contractually authorized to test, with client sign-off on transient file writes.
For defenders, this tool doubles as a hardening audit: running it against a golden image before deployment surfaces the same writable directories, weak ACLs, and missing-DLL positions an attacker would enumerate, and the JSON report gives remediation teams a prioritized backlog. Detection-wise, its activity is observable — transient DLL writes into service or Program File paths, confirmation artifacts under %ProgramData%\DLLHijackHunter\, and short-lived child processes resolving DLLs from unusual directories are all sane telemetry anchors. With 400+ stars, MIT licensing, and a Black Hat Arsenal 2026 badge, it is an actively maintained, well-documented entry in the Windows LPE toolkit space that earns its place by proving findings rather than merely listing them.
projectmerai/DLLHijackHunter.Educational analysis for authorized security professionals. Use only in controlled, authorized environments.
Related coverage
0 comentários:
Post a Comment
Note: Only a member of this blog may post a comment.