dovughs/mora-hwbpMotor de instrumentación de telemetría y hooking en modo usuario sin parches basado en puntos de interrupción de hardware (DR0-DR7) (PoC de AMSI, WLDP y ETW).
Una Prueba de Concepto (POC) de investigación de seguridad que demuestra la interceptación de funciones basada en breakpoints de hardware (registros de depuración de la CPU) como alternativa al parcheo tradicional de código en memoria.
Propósito y alcance
Este repositorio se publica estrictamente para la investigación en seguridad defensiva, la formación de equipos rojos/púrpura, la ingeniería de detección y el estudio académico de las interioridades de Windows. Demuestra cómo un atacante podría abusar de los registros de depuración del procesador para neutralizar la telemetría de seguridad en modo usuario y, de igual importancia, qué deberían monitorizar los defensores para detectar dichas técnicas. El autor no se hace responsable de ningún uso indebido de este código. El uso de esta técnica contra sistemas sin autorización explícita es ilegal y vulnera las leyes pertinentes de fraude y abuso informático en la mayoría de las jurisdicciones. No despliegue esto en ningún entorno que no sea de su propiedad o para el que no cuente con permiso escrito explícito para realizar pruebas.
mora_hwbp.c implementa una DLL que, una vez cargada/inyectada en un proceso objetivo (por ejemplo, un host de PowerShell), intercepta cuatro funciones en modo usuario exclusivamente mediante breakpoints de hardware de la CPU almacenados en los registros de depuración arquitectónicos (DR0–DR7) de cada hilo del proceso:
| Registro | Función interceptada | Módulo | Propósito |
|---|---|---|---|
DR0 | AmsiScanBuffer | amsi.dll | Neutralizar el escaneo de contenido de AMSI |
DR1 | WldpQueryDynamicCodeTrust | wldp.dll | Forzar la confianza en código dinámico de WLDP (Device Guard / WDAC) |
DR2 | WldpIsClassInApprovedList | wldp.dll | Forzar la aprobación de clases de WLDP (Device Guard / WDAC) |
DR3 | NtTraceEvent | ntdll.dll | Cortar todo el flujo de ETW en modo usuario |
Un controlador de excepciones vectorizado (VEH) por proceso recibe los fallos EXCEPTION_SINGLE_STEP (0x80000004) generados por los registros de depuración, simula la ruta de retorno exitosa de la función original reescribiendo el contexto de la excepción y reanuda la ejecución, todo ello sin modificar un solo byte de memoria ejecutable.
Esto hace que la técnica resulte especialmente interesante tanto desde la perspectiva ofensiva como defensiva:
.text modificadas (interceptación en línea clásica, parcheo de EAT/IAT o stubbing de Etwp*).GetThreadContext/SetThreadContext) que pueden utilizarse para la detección.Los enfoques tradicionales de interceptación en modo usuario —los detours en línea (sobrescrituras de 5–14 bytes), la interceptación de la tabla de direcciones de importación (IAT) y la interceptación de la tabla de direcciones de exportación (EAT)— comparten una debilidad común: modifican memoria que los escáneres de integridad y ETW pueden observar.
Los productos AV/EDR modernos implementan:
pageguard/guard-page, transiciones de VirtualProtect a PAGE_EXECUTE_READWRITE y discrepancias de hash de secciones.Los puntos de interrupción por hardware eluden todo esto:
.text.SetThreadContext, que no activa las señales clásicas de "memoria modificada" utilizadas por los escáneres de integridad.Este POC explora la eficacia y detectabilidad de esta técnica contra AMSI (Antimalware Scan Interface), WLDP (Windows Lockdown Policy) y ETW (Event Tracing for Windows) — las tres primitivas de seguridad en modo usuario más ampliamente utilizadas en la pila de seguridad moderna de Windows.
AMSI es el punto de integración de la plataforma Windows que permite a las aplicaciones (PowerShell, Office, VBScript, hosts .NET, etc.) solicitar el escaneo de contenido a proveedores antimalware registrados. El punto de entrada principal de interés es:
AmsiScanBuffer(HANDLE hamsiContext, PVOID buffer, ULONG length, LPCWSTR contentName, HANDLE hamsiSession, AMSI_RESULT *pResult)Al forzar el AMSI_RESULT devuelto a AMSI_RESULT_CLEAN (0), el motor de scripts cree que el contenido fue inspeccionado y considerado benigno, por lo que la ejecución continúa sin interrupciones.
WLDP implementa la evaluación de políticas para Windows Defender Application Control (WDAC / Device Guard). Este POC engancha dos puntos de entrada de WLDP:
WldpIsClassInApprovedList responde si una clase COM dada (identificada por GUID) está permitida bajo la política actual. AMSI consulta internamente a WLDP para decidir si ciertas clases de scripts/contenido son "de confianza" (están en la lista aprobada). Si la función informa que la clase está aprobada, AMSI puede omitir el escrutinio adicional para ese tipo de contenido.WldpQueryDynamicCodeTrust responde si un fragmento dado de código generado dinámicamente (por ejemplo, salida JIT de .NET u otra memoria ejecutable generada) es de confianza bajo la política de bloqueo actual.La DLL establece el parámetro de salida isApproved (RDX) de WldpIsClassInApprovedList a TRUE y devuelve S_OK, y fuerza a WldpQueryDynamicCodeTrust a devolver S_OK (0) — haciendo que tanto la clase de contenido evaluada como el código dinámico consultado parezcan de confianza.