DLLHijackHunter automates discovery, filtering, and canary-based confirmation of Windows DLL hijacking opportunities for defenders and authorized privilege-escalation assessments.
| Tool | ghostvectoracademy/DLLHijackHunter — automated Windows DLL hijacking discovery, validation, and confirmation suite |
| Category | Windows local privilege escalation / DLL hijacking scanner (C#, .NET 8.0/10.0, MIT) |
| Primary Use | Enumerating and confirming DLL hijack candidates across services, scheduled tasks, COM objects, and AutoElevate binaries during authorized assessments |
| Safe Use | Intended for authorized penetration tests, internal hardening audits, and lab triage on systems you own or have written permission to test |
| Telemetry Note | Canary mode writes transient DLLs and confirmation files under %ProgramData%\DLLHijackHunter\, and --verify-load briefly places probe DLLs — EDR and file-integrity monitoring can key on these artifacts |
DLLHijackHunter is a Windows-focused tool from ghostvectoracademy that tries to solve the oldest problem in DLL hijacking research: most scanners tell you a DLL might be hijackable, and then leave you to manually prove it. This project instead runs a five-phase pipeline — discovery, filtration, load-order verification, canary confirmation, and tiered reporting — so that a finding arriving at the top of the report has been validated against the real Windows loader and, where possible, proven to execute. It is written in C# on .NET 8.0/10.0, ships under an MIT license, and has accumulated around 400 stars, which is respectable traction for a niche triage utility. The README also carries a Black Hat Arsenal Sector 2026 badge, which gives some sense of the project's visibility.
The discovery phase is broader than the usual "scan services and hope" approach. A static engine enumerates binaries referenced by services, scheduled tasks, startup items, COM objects, and run keys; a dedicated AutoElevate engine scans System32 and SysWOW64 for executables with <autoElevate>true</autoElevate> in their embedded manifests, plus HKLM\SOFTWARE\Classes\CLSID entries with Elevation\Enabled=1. A PE analyzer parses import tables, delay loads, manifests, and exports, while an ETW engine performs real-time DLL load monitoring and a search-order calculator models where Windows will actually look for each library. The AutoElevate path even simulates the classic copy-to-writable-folder side-load technique for binaries that don't call SetDllDirectory or SetDefaultDllDirectories.
Hijack-type coverage is unusually complete. The tool implements detection for Phantom DLLs (libraries referenced but absent from disk), Search Order hijacks, Side-Loading via the AutoElevate copy-to-temp path, .local directory redirection, writable PATH directory abuse, and registry-based AppInit_DLLs and AppCertDLLs vectors. A current-working-directory hijack is listed as planned, and the README is refreshingly honest that IFEO debugger entries are enumerated and analyzed for imports but not advertised as a standalone hijack detection — a candor that suggests the authors care about not overselling their findings.
The filter pipeline is where the engineering gets interesting. Hard gates kill candidates outright: API set schema filtering for api-ms-* and ext-ms-* names, KnownDLL filtering, and — the standout feature — attacker-relative ACL validation. A path only counts as writable if an unprivileged principal (Users, Authenticated Users, Everyone, or sub-admin service accounts like LOCAL SERVICE and NETWORK SERVICE) has effective write rights, computed independently of the token the scanner runs under. This means running elevated doesn't make System32 or Program Files magically look writable, which is the trap that ruins most naive elevated triage runs. Soft gates then adjust confidence: WinSxS manifest penalties, privilege delta analysis, LoadLibraryEx mitigation checks, signature validation, and graceful error-handling penalties.
Two knowledge-driven features extend the pipeline beyond pure static reasoning. First, a bundled snapshot of the HijackLibs dataset — roughly 590 documented DLL entries spanning about 700 vulnerable executables — is embedded as Resources/hijacklibs.json. A match against a discovered import boosts confidence and links the finding back to its HijackLibs reference page; the dataset is refreshable by re-downloading the project's JSON API over that resource without code changes. Second, automated PATH exploitation evaluates writable PATH folders against a curated map of native Windows services known to search PATH for missing DLLs, which is a class of finding most tools don't model at all.
The --verify-load mode is an opt-in, standard-user verification stage that sits between filtering and canary execution. For each applicable candidate it briefly writes a benign probe DLL to the writable hijack position and 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 and the finding can reach the High tier; if it loses to a KnownDLL, System32 copy, or SxS redirect, the candidate is heavily demoted — catching exactly the classic false positive where a naive calculator flags ntdll.dll as hijackable when KnownDLLs make that path dead on arrival. Probes are placed, resolved, then removed, with pre-existing files backed up and restored, and the mode models modern LOAD_LIBRARY_SEARCH ordering so it only applies to phantom, search-order, and side-load candidates.
Canary confirmation is the tool's signature move. A precompiled, benign canary DLL — embedded for both x64 and x86, statically linked so it has no ucrtbase/vcruntime dependency, and built from auditable source at src/DLLHijackHunter/Resources/canary_src.c — is placed at the hijack path. A trigger executor then starts the service, runs the task, or activates the COM object; if the victim binary loads the canary, it writes a self-locating confirmation file under %ProgramData%\DLLHijackHunter\canary_<hash>.confirm recording PID, user, integrity level, and privilege indicators. The scanner polls for that file, records the hijack as CONFIRMED, and cleans up. Because the confirmation path is derived at runtime from the canary's own loaded module path, a single binary serves every candidate.
The cleverest detail is the functional-proxy mechanism. When a search-order hijack targets a DLL that exists and exports symbols, the host process may die if the replacement DLL doesn't forward those exports, so DLLHijackHunter synthesizes an export-forwarding proxy at runtime through in-process PE surgery — grafting a generated .edata section onto the embedded canary with forwarder strings computed from the victim DLL's export table, no compiler required. The README notes this has been validated against real services and scheduled tasks running as NT AUTHORITY\SYSTEM, while listing honest edge cases (ordinal-only exports, decorated names, loader assumptions) where a proxy canary may report inconclusive without the hijack being invalid.
In terms of invocation, the README shows a conservative standard-user triage example: ./DLLHijackHunter.exe --lpe-only --no-canary --no-etw --verify-load, which runs loader-verified search-order analysis without canary deployment or ETW monitoring. Combined with --verify-load being documented as medium-impact due to transient file writes, the design clearly separates passive read-only triage from active validation, letting an operator choose their footprint on a sensitive host.
Defensively, this tool is a gift for hardening teams. Every finding it confirms is a concrete misconfiguration — an overly permissive ACL, a phantom import, a writable PATH directory — that a defender can remediate before an adversary finds it, and the tiered scoring with console, JSON, and HTML output makes it straightforward to fold results into a remediation workflow. The telemetry note cuts both ways: canary files under %ProgramData% and transient probe DLLs are visible artifacts, so defenders running EDR can observe the tool's activity, and red teams should understand that confirmation-mode testing is not a stealthy operation on monitored hosts.
Comparing it to the crowded field, the README positions DLLHijackHunter against Robber, DLLSpy, WinPEAS, and Procmon on automated discovery, phantom detection, and — uniquely — automated confirmation, which genuinely distinguishes it. WinPEAS surfaces candidates but doesn't prove them; Procmon proves loads only through laborious manual tracing. For an authorized assessor prioritizing local privilege escalation on a Windows estate, or a defender wanting loader-verified evidence before filing a ticket, the multi-phase validation model here is the differentiator, and the honest documentation of its limitations makes it one of the more trustworthy entries in this category.
ghostvectoracademy/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.