dovughs/mora-hwbpAuf Hardware-Breakpoints (DR0-DR7) basierende, patch-lose User-Mode-Hooking- und Telemetrie-Instrumentierungs-Engine (AMSI, WLDP & ETW-PoC).
Ein Proof-of-Concept (POC) aus der Sicherheitsforschung, der Funktions-Hooking auf Basis von Hardware-Breakpoints (CPU-Debug-Registern) als Alternative zum traditionellen In-Memory-Code-Patching demonstriert.
Zweck & Umfang
Dieses Repository wird ausschließlich für defensive Sicherheitsforschung, Red-Team-/Purple-Team-Ausbildung, Detection-Engineering und akademisches Studium der Windows-Interna veröffentlicht. Es demonstriert, wie ein Angreifer Prozessor-Debug-Register missbrauchen könnte, um Telemetrie im User-Mode zu neutralisieren — und, ebenso wichtig, worauf Verteidiger achten sollten, um solche Techniken zu erkennen. Der Autor ist nicht für jeglichen Missbrauch dieses Codes verantwortlich. Die Verwendung dieser Technik gegen Systeme ohne ausdrückliche Genehmigung ist illegal und verstößt in den meisten Rechtsordnungen gegen die einschlägigen Computerbetrugs- und Missbrauchsgesetze. Setzen Sie dies in keiner Umgebung ein, die Ihnen nicht gehört oder für die Sie keine ausdrückliche schriftliche Testgenehmigung haben.
mora_hwbp.c implementiert eine DLL, die nach dem Laden/Injizieren in einen Zielprozess (z. B. einen PowerShell-Host) vier User-Mode-Funktionen ausschließlich über CPU-Hardware-Breakpoints hookt, die in den architektonischen Debug-Registern (DR0–DR7) jedes Threads im Prozess hinterlegt sind:
| Register | Gehookte Funktion | Modul | Zweck |
|---|---|---|---|
DR0 | AmsiScanBuffer | amsi.dll | AMSI-Inhaltsscan neutralisieren |
DR1 | WldpQueryDynamicCodeTrust | wldp.dll | WLDP-Vertrauen für dynamischen Code erzwingen (Device Guard / WDAC) |
DR2 | WldpIsClassInApprovedList | wldp.dll | WLDP-Klassenfreigabe erzwingen (Device Guard / WDAC) |
DR3 | NtTraceEvent | ntdll.dll | Den gesamten ETW-Stream im User-Mode abschneiden |
Ein prozessweiter Vectored Exception Handler (VEH) empfängt die von den Debug-Registern ausgelösten EXCEPTION_SINGLE_STEP-Fehler (0x80000004), simuliert den erfolgreichen Rückgabepfad der Originalfunktion durch Umschreiben des Exception-Kontexts und setzt die Ausführung fort — all dies ohne ein einziges Byte ausführbaren Speichers zu verändern.
Dies macht die Technik sowohl aus offensiver als auch aus defensiver Sicht besonders interessant:
.text-Abschnitten suchen (klassisches Inline-Hooking, EAT-/IAT-Patching oder Etwp*-Stubbing).GetThreadContext/SetThreadContext), die zur Erkennung genutzt werden können.Traditionelle Hooking-Ansätze im User-Mode — Inline-Detours (5–14-Byte-Überschreibungen), Import Address Table (IAT)-Hooking und Export Address Table (EAT)-Hooking — teilen eine gemeinsame Schwäche: Sie verändern Speicher, den Integritätsscanner und ETW beobachten können.
Moderne AV-/EDR-Produkte implementieren:
pageguard/guard-page-Tricks, VirtualProtect-Übergänge zu PAGE_EXECUTE_READWRITE und Abschnitts-Hash-Abweichungen erkennen.Hardware-Breakpoints umgehen all dies:
.text gibt es nichts zu scannen.SetThreadContext gesetzt, was nicht die klassischen „Speicher modifiziert"-Signale auslöst, die von Integritätsscannern verwendet werden.Dieses POC untersucht die Wirksamkeit und Erkennbarkeit dieser Technik gegenüber AMSI (Antimalware Scan Interface), WLDP (Windows Lockdown Policy) und ETW (Event Tracing for Windows) — den drei am weitesten verbreiteten User-Mode-Sicherheitsprimitiven im modernen Windows-Sicherheitsstack.
AMSI ist der Windows-Plattform-Integrationspunkt, der es Anwendungen (PowerShell, Office, VBScript, .NET-Hosts usw.) ermöglicht, das Scannen von Inhalten durch registrierte Antimalware-Anbieter anzufordern. Der primäre Einstiegspunkt von Interesse ist:
AmsiScanBuffer(HANDLE hamsiContext, PVOID buffer, ULONG length, LPCWSTR contentName, HANDLE hamsiSession, AMSI_RESULT *pResult)Indem das zurückgegebene AMSI_RESULT auf AMSI_RESULT_CLEAN (0) gezwungen wird, geht die Skript-Engine davon aus, dass der Inhalt geprüft und als harmlos eingestuft wurde, sodass die Ausführung ununterbrochen fortgesetzt wird.
WLDP implementiert die Richtlinienauswertung für Windows Defender Application Control (WDAC / Device Guard). Dieses POC hookt zwei WLDP-Einstiegspunkte:
WldpIsClassInApprovedList beantwortet die Frage, ob eine bestimmte COM-Klasse (identifiziert durch GUID) unter der aktuellen Richtlinie zulässig ist. AMSI konsultiert intern WLDP, um zu entscheiden, ob bestimmte Skript-/Inhaltsklassen „vertrauenswürdig" sind (in der genehmigten Liste). Wenn die Funktion die Klasse als genehmigt meldet, kann AMSI zusätzliche Prüfungen für diesen Inhaltstyp überspringen.WldpQueryDynamicCodeTrust beantwortet die Frage, ob ein bestimmtes Stück dynamisch generierten Codes (z. B. .NET-JIT-Ausgabe oder anderweitig generierter ausführbarer Speicher) unter der aktuellen Lockdown-Richtlinie vertrauenswürdig ist.Die DLL setzt den Ausgabeparameter isApproved (RDX) von WldpIsClassInApprovedList auf TRUE und gibt S_OK zurück und erzwingt, dass WldpQueryDynamicCodeTrust S_OK (0) zurückgibt — wodurch sowohl die ausgewertete Inhaltsklasse als auch der abgefragte dynamische Code als vertrauenswürdig erscheinen.
NtTraceEvent in ntdll.dll ist der niederstufigste User-Mode-Einstiegspunkt in das ETW-Subsystem — praktisch die gesamte ETW-Ereignisausgabe läuft darüber (einschließlich EtwEventWrite und der übergeordneten Etw*-APIs). Das Hooking dieser Funktion kappt daher den gesamten ETW-Stream aus dem User Mode, mit weitreichenden Nebenwirkungen für die Sicherheitsüberwachung: