
Motore di hooking in modalità utente senza patch e di strumentazione di telemetria basato su hardware breakpoint (DR0-DR7) (AMSI, WLDP e ETW PoC).
Una Proof-of-Concept (POC) di ricerca sulla sicurezza che dimostra il function hooking basato su breakpoint hardware (registri di debug della CPU) come alternativa al tradizionale patching del codice in memoria.
Scopo e ambito
Questo repository è pubblicato strettamente per la ricerca sulla sicurezza difensiva, la formazione red-team/purple-team, l'ingegneria del rilevamento e lo studio accademico degli internals di Windows. Dimostra come un attaccante potrebbe abusare dei registri di debug del processore per neutralizzare la telemetria di sicurezza in modalità utente — e, altrettanto importante, cosa i difensori dovrebbero monitorare per rilevare tali tecniche. L'autore non è responsabile per qualsiasi uso improprio di questo codice. L'utilizzo di questa tecnica contro sistemi senza esplicita autorizzazione è illegale e viola le pertinenti leggi sulla frode informatica e sull'abuso in vigore nella maggior parte delle giurisdizioni. Non distribuire questo codice in alcun ambiente di cui non siate proprietari o per cui non abbiate esplicita autorizzazione scritta a testare.
mora_hwbp.c implementa una DLL che, una volta caricata/iniettata in un processo target (ad esempio, un host PowerShell), esegue l'hook di quattro funzioni in modalità utente esclusivamente tramite breakpoint hardware della CPU memorizzati nei registri di debug architetturali (DR0–DR7) di ogni thread del processo:
| Registro | Funzione sottoposta a hook | Modulo | Scopo |
|---|---|---|---|
DR0 | AmsiScanBuffer | amsi.dll | Neutralizzare la scansione dei contenuti AMSI |
DR1 | WldpQueryDynamicCodeTrust | wldp.dll | Forzare la fiducia nel codice dinamico WLDP (Device Guard / WDAC) |
DR2 | WldpIsClassInApprovedList | wldp.dll | Forzare l'approvazione della classe WLDP (Device Guard / WDAC) |
DR3 | NtTraceEvent | ntdll.dll | Interrompere l'intero flusso ETW in modalità utente |
Un Vectored Exception Handler (VEH) per processo riceve i fault EXCEPTION_SINGLE_STEP (0x80000004) sollevati dai registri di debug, simula il percorso di ritorno con esito positivo della funzione originale riscrivendo il contesto dell'eccezione e riprende l'esecuzione — tutto senza modificare un singolo byte della memoria eseguibile.
Ciò rende la tecnica particolarmente interessante sia da una prospettiva offensiva che difensiva:
.text modificate (classico inline hooking, patching di EAT/IAT o stubbing di Etwp*).GetThreadContext/SetThreadContext) che possono essere utilizzati per il rilevamento.Gli approcci tradizionali di hooking in modalità utente — detour inline (sovrascritture di 5–14 byte), hooking della import address table (IAT) e hooking della export address table (EAT) — condividono una debolezza comune: modificano memoria che gli scanner di integrità e ETW possono osservare.
I moderni prodotti AV/EDR implementano:
pageguard/guard-page, le transizioni di VirtualProtect verso PAGE_EXECUTE_READWRITE e le discrepanze negli hash delle sezioni.Gli hardware breakpoint aggirano tutto questo:
.text.SetThreadContext, che non attiva i classici segnali di "memoria modificata" usati dagli scanner di integrità.Questo POC esplora l'efficacia e la rilevabilità di questa tecnica contro AMSI (Antimalware Scan Interface), WLDP (Windows Lockdown Policy) ed ETW (Event Tracing for Windows) — le tre primitive di sicurezza in user-mode su cui si fa più affidamento nello stack di sicurezza moderno di Windows.
AMSI è il punto di integrazione della piattaforma Windows che consente alle applicazioni (PowerShell, Office, VBScript, host .NET, ecc.) di richiedere la scansione dei contenuti ai provider antimalware registrati. Il punto di ingresso principale di interesse è:
AmsiScanBuffer(HANDLE hamsiContext, PVOID buffer, ULONG length, LPCWSTR contentName, HANDLE hamsiSession, AMSI_RESULT *pResult)Forzando il valore restituito AMSI_RESULT a AMSI_RESULT_CLEAN (0), il motore di script ritiene che il contenuto sia stato ispezionato e giudicato benigno, così l'esecuzione prosegue senza interruzioni.
WLDP implementa la valutazione delle policy per Windows Defender Application Control (WDAC / Device Guard). Questo POC intercetta due punti di ingresso di WLDP:
WldpIsClassInApprovedList risponde se una determinata classe COM (identificata da un GUID) è consentita in base alla policy corrente. AMSI consulta internamente WLDP per decidere se determinate classi di script/contenuto sono "attendibili" (presenti nella lista approvata). Se la funzione segnala la classe come approvata, AMSI può saltare ulteriori controlli per quel tipo di contenuto.WldpQueryDynamicCodeTrust risponde se un determinato frammento di codice generato dinamicamente (ad es. output JIT .NET o altra memoria eseguibile generata) è attendibile in base alla policy di lockdown corrente.La DLL imposta il parametro di output isApproved (RDX) di WldpIsClassInApprovedList a TRUE e restituisce S_OK, e forza WldpQueryDynamicCodeTrust a restituire S_OK (0) — facendo apparire attendibili sia la classe di contenuto valutata sia il codice dinamico interrogato.