Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
mora-hwbp — Motore di hooking in modalità utente senza patch e di strumentazione di telemetria basato su hardware breakpoint (DR0-DR7) (AMSI, WLDP e ETW PoC). | Kitploit
Strumenti/GitHubGitHub/dovughs/mora-hwbp
Strumenti DifensiviEvasione IDS/IPSDebuggerApprendimento e FormazioneRed TeamingAttacco Avversario
GitHubdovughs/mora-hwbp

mora-hwbp

Motore di hooking in modalità utente senza patch e di strumentazione di telemetria basato su hardware breakpoint (DR0-DR7) (AMSI, WLDP e ETW PoC).

Vedi Repository
1911023 giorni faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

Mora-HWBP — Hooking della telemetria AMSI / WLDP / ETW tramite breakpoint hardware

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.


Indice

  1. Panoramica
  2. Contesto — Perché i breakpoint hardware?
  3. Componenti di sicurezza presi di mira
  4. Architettura
  5. Approfondimento tecnico
    • 5.1 Breakpoint hardware su x64
    • 5.2 Layout dei registri di debug (DR0–DR7)
    • 5.3 Il Vectored Exception Handler (VEH)
    • 5.4 Logica di intercettazione per componente
    • 5.5 Gestione dei thread e persistenza degli hook
  6. API esportata
  7. Istruzioni di compilazione
  8. Esempio di iniezione e utilizzo
  9. Rilevamento e mitigazione (Blue Team)
  10. Limitazioni note
  11. Riferimenti

Panoramica

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:

RegistroFunzione sottoposta a hookModuloScopo
DR0AmsiScanBufferamsi.dllNeutralizzare la scansione dei contenuti AMSI
DR1WldpQueryDynamicCodeTrustwldp.dllForzare la fiducia nel codice dinamico WLDP (Device Guard / WDAC)
DR2WldpIsClassInApprovedListwldp.dllForzare l'approvazione della classe WLDP (Device Guard / WDAC)
DR3NtTraceEventntdll.dllInterrompere 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:

  • Offensivamente, aggira i controlli di integrità di EDR/HIPS che cercano sezioni .text modificate (classico inline hooking, patching di EAT/IAT o stubbing di Etwp*).
  • Difensivamente, i breakpoint hardware lasciano artefatti forensi altamente distintivi (contenuto dei registri di debug, densità delle eccezioni di single-step, registrazione del VEH, pattern delle chiamate di sistema GetThreadContext/SetThreadContext) che possono essere utilizzati per il rilevamento.

Contesto — Perché i breakpoint hardware?

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:

  • Scansione della memoria / scansioni AMSI dei buffer PowerShell e .NET CLR;
  • Telemetria basata su ETW (Microsoft-Windows-PowerShell, .NET ETW, provider di threat intelligence);
  • Callback del kernel e controlli di integrità in user-mode che rilevano i trucchi pageguard/guard-page, le transizioni di VirtualProtect verso PAGE_EXECUTE_READWRITE e le discrepanze negli hash delle sezioni.

Gli hardware breakpoint aggirano tutto questo:

  1. Sono registri della CPU, non memoria — non c'è nulla da scansionare in .text.
  2. Vengono impostati su base per-thread tramite l'API Windows SetThreadContext, che non attiva i classici segnali di "memoria modificata" usati dagli scanner di integrità.
  3. Il punto di intercettazione è gestito interamente dal dispatch delle eccezioni del processore, che passa attraverso la catena VEH del processo prima che qualsiasi funzione target in user-mode venga eseguita.

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.


Componenti di sicurezza presi di mira

AMSI — Antimalware Scan Interface

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 — Windows Lockdown Policy

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.

ETW — Event Tracing for Windows

Scarica lo strumento