DLLHijackHunter

Di ProjectMerai

Scoperta, Validazione e Conferma Automatica del DLL Hijacking
Trasformare le misconfigurazioni locali in percorsi d'attacco confermati e weaponizzati.

Panoramica

DLLHijackHunter è uno strumento automatizzato di rilevamento del DLL hijacking su Windows che va oltre l'analisi statica. Scopre, valida e conferma le opportunità di DLL hijacking tramite una pipeline multi-fase:

1. Scoperta — Enumera i binari tra servizi, attività pianificate, elementi di avvio, oggetti COM e vettori di bypass UAC AutoElevate
2. Filtraggio — Elimina i falsi positivi tramite gate intelligenti hard e soft
3. Conferma Canary — Distribuisce una DLL canary innocua e attiva il binario per dimostrare che l'hijack funziona
4. Scoring e Report — Classifica i risultati in base alla sfruttabilità con un sistema di confidenza a livelli

La maggior parte degli strumenti di DLL hijacking si ferma a "questa DLL potrebbe essere hijackabile." DLLHijackHunter tenta di validarla, incrociarla con intelligence sulle vulnerabilità note e confermare i percorsi di esecuzione reali dove possibile.

Architettura

flowchart TB
    subgraph Phase1["Fase 1: Scoperta"]
        SE["Motore Statico<br/>Servizi, Attività, Avvio,<br/>COM, Run Keys"]
        AE["Motore AutoElevate<br/>Manifest + Bypass UAC COM"]
        PE["Analizzatore PE<br/>Tabelle Import, Delay Loads,<br/>Manifest, Export"]
        ETW["Motore ETW<br/>Monitoraggio Caricamento DLL<br/>in Tempo Reale"]
        SO["Calcolatore Ordine<br/>di Ricerca"]
    end

    subgraph Phase2["Fase 2: Pipeline di Filtraggio"]
        direction LR
        HG["Gate Hard<br/>(Kill Binario)"]
        SG["Gate Soft<br/>(Aggiustamento Confidenza)"]
    end

    subgraph Phase3["Fase 3: Verifica Caricamento (--verify-load)"]
        LP["LoadProbe<br/>Test loader processo figlio<br/>Probe DLL posizionata &amp; rimossa"]
    end

    subgraph Phase4["Fase 4: Canary"]
        CB["Builder DLL Canary"]
        TE["Esecutore Trigger"]
        VF["Verifica"]
    end

    subgraph Phase5["Fase 5: Output"]
        SC["Scorer a Livelli"]
        RC["Report Console"]
        RJ["Report JSON"]
        RH["Report HTML"]
    end

    SE --> PE --> SO
    AE --> PE
    ETW --> SO
    SO --> Phase2
    HG --> SG
    Phase2 --> Phase3
    Phase3 --> Phase4
    CB --> TE --> VF
    Phase4 --> Phase5

Caratteristiche Principali

Copertura dei Tipi di Hijack

Le voci IFEO Debugger vengono enumerate e il binario referenziato viene analizzato per gli import DLL, ma non esiste un tipo di hijack IFEO/KnownDLL-bypass dedicato — questi non vengono pubblicizzati come rilevamenti autonomi.

Scoperta Bypass UAC

DLLHijackHunter include una scoperta dedicata del bypass UAC:

• AutoElevate Manifest — Scansiona System32 e SysWOW64 per EXE con <autoElevate>true</autoElevate> nei manifest incorporati
• AutoElevation COM — Scansiona HKLM\SOFTWARE\Classes\CLSID per oggetti COM con Elevation\Enabled=1
• Simulazione Side-Load — Per binari AutoElevate che non chiamano SetDllDirectory o SetDefaultDllDirectories, simula il percorso d'attacco "copia EXE in cartella scrivibile + rilascia DLL"

Knowledge Base Mirata sulle Vulnerabilità

• Mappatura vulnerabilità mirate — Incrocia gli import scoperti con uno snapshot integrato del dataset HijackLibs (≈590 voci DLL documentate che coprono ≈700 eseguibili vulnerabili), incorporato come Resources/hijacklibs.json. Una corrispondenza aumenta la confidenza e collega il risultato alla pagina di riferimento HijackLibs; l'assenza di corrispondenza non significa nulla. Il dataset è data-driven — aggiornalo riscaricando https://hijacklibs.net/api/hijacklibs.json su quella risorsa (nessuna modifica al codice richiesta). Dataset © il progetto HijackLibs e i suoi contributori.
• Sfruttamento PATH automatizzato — Valuta le cartelle PATH scrivibili e genera candidati hijack per una mappa curata di servizi Windows nativi noti per cercare DLL mancanti nel PATH
• Caccia phantom DLL ampliata — Cerca una libreria di opportunità phantom DLL ad alto valore in più categorie

Pipeline di Filtraggio

La pipeline riduce i falsi positivi attraverso due fasi:

Gate Hard

• Filtraggio schema API set (api-ms-*, ext-ms-*)
• Filtraggio KnownDLL
• Validazione scrivibilità ACL relativa all'attaccante — un percorso conta come scrivibile solo se un principal non privilegiato (Users / Authenticated Users / Everyone, più account di servizio sub-admin a prova di leak come LOCAL SERVICE/NETWORK SERVICE) ha diritti di scrittura effettivi. Fondamentalmente, questo viene calcolato indipendentemente dal token con cui lo strumento viene eseguito, quindi l'esecuzione con privilegi elevati non rende System32/Program Files scrivibili. Questo è ciò che rende significative le esecuzioni elevate per il triage LPE.

Gate Soft

• Penalità manifest WinSxS
• Analisi delta privilegi
• Controlli mitigazione LoadLibraryEx
• Controlli validazione firma
• Penalità gestione errori graceful

Conferma Canary

Invece di indovinare, DLLHijackHunter tenta di dimostrare che gli hijack funzionano:

sequenceDiagram
    participant H as DLLHijackHunter
    participant B as Builder DLL Canary
    participant T as Esecutore Trigger
    participant V as Binario Vittima

    H->>B: Costruisci DLL canary
    B->>B: Estrai canary precompilata<br/>(o compila un proxy con MSVC)
    B-->>H: canary.dll + percorso file conferma
    H->>H: Posiziona DLL nel percorso hijack
    H->>T: Attiva esecuzione binario
    T->>V: Avvia servizio / esegui attività / attiva COM
    V->>V: Carica DLL canary
    V-->>H: Scrive file conferma<br/>PID, privilegio, livello integrità
    H->>H: Registra: CONFERMATO
    H->>H: Pulizia DLL canary

La DLL canary:

• Viene fornita precompilata sia per x64 che x86, incorporata nello scanner, quindi nessun compilatore è richiesto al momento della scansione. L'architettura corretta viene selezionata per corrispondere alla bitness della vittima ed estratta su richiesta.
• È auto-localizzante: deriva il percorso del suo file di conferma a runtime dal proprio percorso di modulo caricato (%ProgramData%\DLLHijackHunter\canary_<hash>.confirm), quindi un singolo binario serve ogni candidato. Lo scanner calcola lo stesso hash dal percorso di distribuzione e interroga quel file.
• Utilizza un meccanismo di conferma basato su file
• Cattura metadati di esecuzione come utente, livello di integrità e indicatori di privilegio
• Non contiene payload dannoso; è strettamente un meccanismo di rilevamento e validazione
• Collega staticamente il CRT, quindi nessuna dipendenza runtime (ucrtbase/vcruntime) sull'host vittima.

I binari inclusi sono costruiti dal sorgente verificabile in src/DLLHijackHunter/Resources/canary_src.c e possono essere rigenerati con Resources/build_canary.bat (richiede la toolchain C++ MSVC; lo scanner non la richiede).

Eccezione proxy funzionale: Quando un hijack di ordine di ricerca mira a una DLL che esiste ed espone export, mantenere vivo l'host dopo la conferma richiede un proxy di forwarding export, compilato per-DLL con MSVC (cl.exe, localizzato tramite vswhere/vcvarsall). Se non è presente alcuna toolchain, viene utilizzata la canary precompilata — essa conferma comunque il caricamento (DllMain scatta) ma non inoltra gli export, quindi il processo host potrebbe crashare dopo che la conferma è stata registrata. I candidati Phantom-DLL e altri senza export non richiedono alcun compilatore.

Firma: Le canary incorporate non sono firmate. Firmarle con codice (così si caricano sotto policy più rigide e sono attribuibili) richiede un certificato di firma ed è lasciato come passaggio al momento del rilascio per il maintainer.

Nota importante sulla modalità proxy/export-forwarding

Le canary proxy/export-forwarding sono sperimentali e best-effort. Alcuni target potrebbero non caricarsi correttamente o comportarsi in modo inaspettato a seconda di:

• export solo ordinali
• nomi export decorati
• discrepanze nelle calling convention
• assunzioni loader/runtime nel processo target

Ciò significa che una canary proxy fallita non sempre implica che il percorso hijack sottostante sia impossibile.

Verifica Ordine di Caricamento (--verify-load)

Una verifica opt-in, per utente standard, che si colloca tra la pipeline di filtraggio e la fase canary. Per ogni candidato applicabile scrive brevemente una DLL probe benigna nella posizione hijack scrivibile, poi chiede al loader Windows reale — in un processo figlio di breve durata — di risolvere la DLL per nome. Dove il loader risolve determina il verdetto:

• Vittoria verificata — il loader sceglie la posizione scrivibile. L'affermazione sull'ordine di ricerca è provata (questa corroborazione consente al risultato di raggiungere il livello Alto; l'esecuzione canary rimane l'unico percorso verso Confermato).
• Perde contro protetto — il loader sceglie una KnownDLL, la copia in System32 o una copia reindirizzata SxS. La posizione è quasi certamente non hijackabile, quindi il candidato viene fortemente declassato. Questo cattura i classici falsi positivi che un calcolatore statico di ordine di ricerca manca (es. un "risultato" .local/ordine di ricerca per ntdll.dll che KnownDLLs rende inutilizzabile).

Note di progettazione e sicurezza:

• Viene eseguito in un processo figlio così un nome già caricato nello scanner non può cortocircuitare il risultato, e così qualsiasi effetto collaterale di caricamento o crash è isolato. Nessuna elevazione richiesta.
• Ogni probe viene posizionato, risolto e poi rimosso; qualsiasi file preesistente viene sottoposto a backup e ripristinato.
• Modella l'ordinamento moderno LOAD_LIBRARY_SEARCH, quindi viene applicato solo ai candidati Phantom / Ordine di Ricerca / Side-Load. I candidati .local, PATH e AppInit/AppCert usano meccaniche diverse e vengono riportati come Saltati.
• Scrive file in modo transitorio nelle posizioni candidate (impatto medio); lascialo disattivato per un triage completamente passivo, di sola lettura.

# Triage utente standard con ordine di ricerca verificato dal loader (no canary, no ETW)
.\DLLHijackHunter.exe --lpe-only --no-canary --no-etw --verify-load

Confronto

Utilizzo

Prerequisiti

• Windows 10/11 o Windows Server 2016+
• Runtime .NET 8.0 o 10.0 (o usa una build self-contained)
• Privilegi di amministratore consigliati (richiesti per ETW, distribuzione canary e alcuni trigger di servizio)

Build

git clone https://github.com/ghostvectoracademy/DLLHijackHunter.git
cd DLLHijackHunter

# Build (file singolo self-contained)
dotnet publish src/DLLHijackHunter/DLLHijackHunter.csproj `
    -c Release -r win-x64 --self-contained `
    -p:PublishSingleFile=true -o ./publish

# Oppure usa lo script di build
.\build.ps1

Avvio Rapido

# Scansione aggressiva completa (consigliata, richiede admin)
.\DLLHijackHunter.exe --profile aggressive

# Scansione sicura (nessun rilascio file, nessun trigger)
.\DLLHijackHunter.exe --profile safe

# Scansione focalizzata sul bypass UAC
.\DLLHijackHunter.exe --profile uac-bypass

# Mira a un binario specifico
.\DLLHijackHunter.exe --target "C:\Program Files\MyApp\app.exe"

# Mira per nome file (corrispondenza parziale)
.\DLLHijackHunter.exe --target notepad.exe

# Solo risultati confermati
.\DLLHijackHunter.exe --profile redteam --format json -o report.json

Opzioni CLI

DLLHijackHunter — Rilevamento Automatico DLL Hijacking

Opzioni:
  -p, --profile <profile>        Profilo di scansione [default: aggressive]
                                   aggressive | strict | safe | redteam | uac-bypass
  -o, --output <path>            Percorso file di output (rileva automaticamente il formato)
  -f, --format <format>          Formato di output [default: console]
                                   console | json | html
  -t, --target <target>          Mira a binario, directory o nome file specifico
      --min-confidence <value>   Soglia minima di confidenza 0-100. Se omesso, viene applicata
                                   la soglia del profilo selezionato; passarlo lo sovrascrive.
      --no-canary                Disabilita la conferma canary
      --no-etw                   Disabilita la scoperta runtime ETW
      --verify-load              Verifica l'ordine di ricerca con il loader reale (vedi sotto).
                                   Utente standard; scrive transitoriamente un probe benigno.
      --confirmed-only           Mostra solo risultati confermati da canary
      --lpe-only                 Caccia LPE rigorosa: ignora System32/Program Files, mostra
                                   solo vulnerabilità scrivibili da utente standard
      --log-file <path>          Scrive un log diagnostico di scansione su file
  -v, --verbose                  Output verboso

Nota: --min-confidence viene trattato come override solo quando lo passi esplicitamente. Altrimenti viene usata la soglia del profilo selezionato (es. safe = 50%, strict = 80%).

Profili di Scansione

Scoring

Ogni risultato riceve segnali di confidenza e impatto che vengono combinati in un livello di prioritizzazione finale.

Le considerazioni tipiche sull'impatto includono:

• privilegio ottenuto
• affidabilità del trigger
• stealth
• persistenza al riavvio

L'esecuzione canary confermata deve essere trattata come il segnale di validazione più forte.

Gating a livelli: i livelli Alto e Confermato sono riservati ai risultati supportati da un segnale di prova — una canary attivata, un'osservazione di caricamento runtime ETW o una corrispondenza documentata nella knowledge base. Una corrispondenza puramente statica di ordine di ricerca, per quanto pulita, è limitata alla parte superiore del livello Medio e annotata come Solo-statico così le euristiche non verificate non si presentano mai come ad alta confidenza.

Configurazione di triage consigliata

Poiché la scrivibilità viene valutata relativa all'attaccante, sia le esecuzioni elevate che quelle da utente standard sono significative:

• Per il triage LPE, la configurazione più affidabile è un'esecuzione da utente standard con --lpe-only (e --no-canary se non è disponibile un compilatore) — ogni risultato sopravvissuto è genuinamente scrivibile da un principal non privilegiato.
• Le esecuzioni elevate sono richieste per ETW e conferma canary, e ora sono al sicuro dall'inversione storica "tutto in System32 sembra scrivibile".

Sicurezza

DLLHijackHunter è progettato per ricerca difensiva sulla sicurezza, validazione in laboratorio, audit e simulazione red-team in ambienti autorizzati.

Usalo solo su sistemi e reti che possiedi o per cui sei esplicitamente autorizzato a valutare.

Note operative

• La modalità canary scrive DLL di test nelle posizioni candidate
• Alcuni trigger possono avviare o fermare brevemente servizi/attività durante la validazione
• Le canary proxy/export-forwarding possono destabilizzare target fragili
• Il profilo safe è la modalità preferita per il triage in produzione quando i rilasci di file e i trigger non sono accettabili

Output

DLLHijackHunter supporta:

• report console
• export JSON
• export HTML

Flusso di lavoro consigliato:

1. esegui una scansione ampia
2. rivedi i risultati ad alta confidenza
3. usa la conferma canary selettivamente sui percorsi ad alto valore
4. conserva l'output JSON/HTML per report e triage

Licenza

MIT

Crediti

Costruito da ProjectMerai.