
Motor de instrumentação de telemetria e hooking em modo de usuário sem patch, baseado em Hardware Breakpoint (DR0-DR7) (PoC de AMSI, WLDP e ETW).
Uma Prova de Conceito (POC) de pesquisa de segurança que demonstra o hooking de funções baseado em hardware breakpoints (registradores de depuração da CPU) como alternativa ao tradicional patching de código em memória.
Propósito e Escopo
Este repositório é publicado estritamente para pesquisa de segurança defensiva, educação red-team/purple-team, engenharia de detecção e estudo acadêmico de internals do Windows. Ele demonstra como um atacante poderia abusar dos registradores de depuração do processador para neutralizar a telemetria de segurança em modo usuário — e, igualmente importante, o que os defensores devem monitorar para detectar tais técnicas. O autor não é responsável por qualquer uso indevido deste código. O uso desta técnica contra sistemas sem autorização explícita é ilegal e viola as leis relevantes de fraude e abuso computacional na maioria das jurisdições. Não implante isto em nenhum ambiente que você não possua ou para o qual não tenha permissão escrita explícita de teste.
mora_hwbp.c implementa uma DLL que, uma vez carregada/injetada em um processo alvo (por exemplo, um host PowerShell), faz hook de quatro funções em modo usuário exclusivamente através de hardware breakpoints da CPU armazenados nos registradores de depuração arquiteturais (DR0–DR7) de cada thread no processo:
| Registrador | Função com Hook | Módulo | Propósito |
|---|---|---|---|
DR0 | AmsiScanBuffer | amsi.dll | Neutralizar a verificação de conteúdo do AMSI |
DR1 | WldpQueryDynamicCodeTrust | wldp.dll | Forçar a confiança em código dinâmico do WLDP (Device Guard / WDAC) |
DR2 | WldpIsClassInApprovedList | wldp.dll | Forçar a aprovação de classe do WLDP (Device Guard / WDAC) |
DR3 | NtTraceEvent | ntdll.dll | Cortar todo o fluxo ETW em modo usuário |
Um Vectored Exception Handler (VEH) por processo recebe as falhas EXCEPTION_SINGLE_STEP (0x80000004) levantadas pelos registradores de depuração, simula o caminho de retorno bem-sucedido da função original reescrevendo o contexto da exceção e retoma a execução — tudo sem modificar um único byte de memória executável.
Isso torna a técnica particularmente interessante tanto de perspectivas ofensivas quanto defensivas:
.text modificadas (hooking inline clássico, patching de EAT/IAT ou stubbing de Etwp*).GetThreadContext/SetThreadContext) que podem ser usados para detecção.As abordagens tradicionais de hooking em modo usuário — detours inline (sobrescritas de 5–14 bytes), hooking da import address table (IAT) e hooking da export address table (EAT) — compartilham uma fraqueza comum: elas modificam memória que scanners de integridade e o ETW podem observar.
Produtos AV/EDR modernos implementam:
pageguard/guard-page, transições de VirtualProtect para PAGE_EXECUTE_READWRITE e incompatibilidades de hash de seção.Breakpoints de hardware contornam tudo isso:
.text.SetThreadContext, que não dispara os sinais clássicos de "memória modificada" usados por scanners de integridade.Este POC explora a eficácia e a detectabilidade desta técnica contra AMSI (Antimalware Scan Interface), WLDP (Windows Lockdown Policy) e ETW (Event Tracing for Windows) — as três primitivas de segurança em modo usuário mais amplamente utilizadas na pilha de segurança moderna do Windows.
AMSI é o ponto de integração da plataforma Windows que permite que aplicações (PowerShell, Office, VBScript, hosts .NET, etc.) solicitem a varredura de conteúdo a provedores antimalware registrados. O principal ponto de entrada de interesse é:
AmsiScanBuffer(HANDLE hamsiContext, PVOID buffer, ULONG length, LPCWSTR contentName, HANDLE hamsiSession, AMSI_RESULT *pResult)Ao forçar o AMSI_RESULT retornado para AMSI_RESULT_CLEAN (0), o mecanismo de script acredita que o conteúdo foi inspecionado e considerado benigno, então a execução continua sem interrupção.
WLDP implementa a avaliação de políticas para o Windows Defender Application Control (WDAC / Device Guard). Este POC intercepta dois pontos de entrada do WLDP:
WldpIsClassInApprovedList responde se uma determinada classe COM (identificada por GUID) é permitida sob a política atual. O AMSI consulta internamente o WLDP para decidir se certas classes de script/conteúdo são "confiáveis" (estão na lista aprovada). Se a função relatar a classe como aprovada, o AMSI pode pular escrutínio adicional para aquele tipo de conteúdo.WldpQueryDynamicCodeTrust responde se um determinado trecho de código gerado dinamicamente (por exemplo, saída do JIT do .NET ou memória executável gerada de outra forma) é confiável sob a política de lockdown atual.A DLL define o parâmetro de saída isApproved (RDX) de WldpIsClassInApprovedList como TRUE e retorna S_OK, e força WldpQueryDynamicCodeTrust a retornar S_OK (0) — fazendo com que tanto a classe de conteúdo avaliada quanto o código dinâmico consultado pareçam confiáveis.
NtTraceEvent em ntdll.dll é o ponto de entrada em modo usuário de mais baixo nível no subsistema ETW — virtualmente toda a emissão de eventos ETW passa por ele (incluindo EtwEventWrite e as APIs Etw* de nível superior). Interceptá-lo, portanto, corta todo o fluxo ETW do modo usuário, com amplos efeitos colaterais relevantes para o monitoramento de segurança: