Mora-HWBP — Interceptação de Telemetria AMSI / WLDP / ETW via Breakpoints de Hardware

Uma Prova-de-Conceito (POC) de pesquisa em segurança demonstrando hooking de funções baseado em breakpoints de hardware (registradores de depuração da CPU) como alternativa à tradicional correção de código em memória.

Propósito e Escopo

Este repositório é publicado estritamente para pesquisa defensiva em segurança, educação em red-team/purple-team, engenharia de detecção e estudo acadêmico de detalhes internos do Windows. Ele demonstra como um atacante poderia abusar dos registradores de depuração do processador para neutralizar telemetria de segurança em modo usuário — e, igualmente importante, o que defensores devem monitorar a fim de 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 de computadores na maioria das jurisdições. Não implante isto em qualquer ambiente que você não possua ou para o qual não tenha permissão escrita explícita para testar.

Sumário

1. Visão Geral
2. Contexto — Por que Breakpoints de Hardware?
3. Componentes de Segurança Visados
4. Arquitetura
5. Análise Técnica Aprofundada
   • 5.1 Breakpoints de Hardware em x64
   • 5.2 Layout dos Registradores de Depuração (DR0–DR7)
   • 5.3 O Tratador de Exceções Vetorizado (VEH)
   • 5.4 Lógica de Interceptação por Componente
   • 5.5 Gerenciamento de Threads e Persistência do Hook
6. API Exportada
7. Instruções de Compilação
8. Exemplo de Injeção e Uso
9. Detecção e Mitigação (Blue Team)
10. Limitações Conhecidas
11. Referências

Visão Geral

mora_hwbp.c implementa uma DLL que, uma vez carregada/injetada em um processo alvo (por exemplo, um host do PowerShell), intercepta quatro funções em modo usuário exclusivamente por meio de breakpoints de hardware da CPU armazenados nos registradores de depuração arquiteturais (DR0–DR7) de cada thread do processo:

Um Tratador de Exceções Vetorizado (VEH) por processo recebe as falhas EXCEPTION_SINGLE_STEP (0x80000004) geradas 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 isso sem modificar um único byte da memória executável.

Isso torna a técnica particularmente interessante tanto do ponto de vista ofensivo quanto defensivo:

• Ofensivamente, ela contorna verificações de integridade de EDR/HIPS que procuram seções .text modificadas (hooking inline clássico, correção de EAT/IAT ou stubbing de Etwp*).
• Defensivamente, breakpoints de hardware deixam artefatos forenses altamente distintivos (conteúdo dos registradores de depuração, densidade de exceções de passo único, registro do VEH, padrões de syscall GetThreadContext/SetThreadContext) que podem ser usados para detecção.

Contexto — Por que Breakpoints de Hardware?

Abordagens tradicionais de hooking em modo usuário — detours inline (sobrescritas de 5–14 bytes), hooking na tabela de endereços de importação (IAT) e hooking na tabela de endereços de exportação (EAT) — compartilham uma fraqueza comum: elas modificam memória que scanners de integridade e ETW podem observar.

Produtos modernos de AV/EDR implementam:

• Varredura de memória / varreduras AMSI de buffers do PowerShell e do CLR .NET;
• Telemetria baseada em ETW (Microsoft-Windows-PowerShell, ETW .NET, provedores de inteligência de ameaças);
• Callbacks de kernel e verificações de integridade em modo usuário que detectam truques de pageguard/guard-page, transições VirtualProtect para PAGE_EXECUTE_READWRITE e incompatibilidades de hash de seção.

Breakpoints de hardware contornam tudo isso:

1. Eles são registradores da CPU, não memória — não há nada para escanear em .text.
2. Eles são definidos por thread por meio da API do Windows SetThreadContext, que não dispara os sinais clássicos de "memória modificada" usados por scanners de integridade.
3. O ponto de interceptação é tratado inteiramente pelo despacho de exceções do processador, que passa pela cadeia VEH do processo antes de qualquer função alvo em modo usuário ser executada.

Esta POC explora a eficácia e a detectabilidade dessa técnica contra AMSI (Interface de Varredura Antimalware), WLDP (Política de Bloqueio do Windows) e ETW (Rastreamento de Eventos para Windows) — os três primitivos de segurança em modo usuário mais amplamente utilizados na pilha de segurança moderna do Windows.

Componentes de Segurança Visados

AMSI — Interface de Varredura Antimalware

AMSI é o ponto de integração da plataforma Windows que permite que aplicativos (PowerShell, Office, VBScript, hosts .NET, etc.) solicitem varredura de conteúdo a provedores antimalware registrados. Dois pontos de entrada são de interesse primário:

• AmsiScanBuffer(HANDLE hamsiContext, PVOID buffer, ULONG length, LPCWSTR contentName, HANDLE hamsiSession, AMSI_RESULT *pResult)
• AmsiScanString(HANDLE hamsiContext, LPCWSTR string, 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 — Política de Bloqueio do Windows

A WLDP implementa a avaliação de políticas para o Controle de Aplicativos do Windows Defender (WDAC / Device Guard). WldpIsClassInApprovedList responde se uma determinada classe COM (identificada por GUID) é permitida sob a política atual. Internamente, o AMSI consulta a WLDP para decidir se certas classes de script/conteúdo são "confiáveis" (na lista aprovada). Se a função relatar a classe como aprovada, o AMSI pode dispensar o escrutínio adicional para esse tipo de conteúdo.

A DLL define o parâmetro de saída isApproved (RDX) como TRUE e retorna S_OK, fazendo com que a classe avaliada pareça confiável.

ETW — Rastreamento de Eventos para Windows

EtwEventWrite em ntdll.dll é o sumidouro central em modo usuário para praticamente toda a emissão de eventos ETW no sistema. Suprimi-lo tem efeitos colaterais amplos relevantes para o monitoramento de segurança:

• Eventos de log de pipeline e script-block do PowerShell
• Eventos de carregamento de assembly .NET (Microsoft-Windows-DotNETRuntime)
• Telemetria de resultado de varredura AMSI
• Eventos de provedores de Inteligência de Ameaças consumidos por agentes EDR

A DLL simplesmente retorna ERROR_SUCCESS (0) sem executar a função real.

Arquitetura```

┌──────────────────────────────────────────────────────────────────────────┐ │ Target Process (e.g. powershell.exe) │ │ │ │ ┌──────────────────────────┐ ┌──────────────────────────────────┐│ │ │ mora_hwbp.dll │ │ CPU / Windows ││ │ │ │ │ ││ │ │ DllMain / InstallHook │ │ Thread A Thread B ││ │ │ │ │ │ ┌────────┐ ┌────────┐ ││ │ │ ▼ │ │ │ DR0..3 │ │ DR0..3 │ ││ │ │ Resolve exports │ │ └────────┘ └────────┘ ││ │ │ (amsi/wldp/ntdll) │ │ ││ │ │ │ │ │ #DB (single-step) ││ │ │ ▼ │ │ exception ──► Windows Dispatch ││ │ │ AddVectoredException │ │ │ ││ │ │ Handler(VEH) │ │ ▼ ││ │ │ │ │ │ ┌─────────────────────────────┐ ││ │ │ ▼ │ │ │ VectoredHandler (ours) │ ││ │ │ SetHwbpOnThread(ALL) │ │ │ • match #DB address │ ││ │ │ │ │ │ │ • rewrite context (RIP/RSP)│ ││ │ │ ▼ │ │ │ • spoof return value (RAX) │ ││ │ │ MonitorThread ◄──┐ │ │ │ • continue execution │ ││ │ │ (re-hook every │ │ │ └─────────────────────────────┘ ││ │ │ 500ms) └──────┘ │ ││ │ └──────────────────────────┘ └──────────────────────────────────┘│ └──────────────────────────────────────────────────────────────────────────┘

**Fluxo de alto nível:**

1. A DLL é carregada no processo de destino (por meio de qualquer técnica de injeção — consulte [Uso](#injection--usage-example)).
2. No `DLL_PROCESS_ATTACH` (ou por meio da função exportada `InstallHook`), as exportações de destino são resolvidas com `GetProcAddress` (opcionalmente forçando o carregamento de módulos via `LoadLibraryW`).
3. Um **Manipulador de Exceção Vetorizado** é registrado como o **primeiro** manipulador no processo (`AddVectoredExceptionHandler(1, ...)`).
4. A **thread atual** é interceptada imediatamente e, em seguida, **todas as threads existentes** no processo são enumeradas via `CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, 0)` e interceptadas.
5. Uma **thread de monitoramento** acorda a cada 500 ms e reaplica os breakpoints em todas as threads — incluindo **threads recém-criadas** — garantindo a persistência do hook mesmo que uma thread seja criada depois do hook ou que os breakpoints sejam limpos externamente.
6. Quando qualquer função interceptada é chamada em qualquer thread, a CPU gera uma exceção de passo único `#DB`; o Windows a despacha para o VEH, que simula um retorno benigno e continua a execução.

### Exemplo de Saída de Depuração

![Diagnósticos de status de hook do HWBP Engine capturados no Sysinternals DebugView](https://assets.kitploit.com/production/public/readmes/50594/5cf99fadc07272ff598cbb9486ff7803a3234eb6aeaa8202684c27e97bd7e161.png)

*Figura 1 — Exemplo de saída de diagnósticos capturada com o Sysinternals DebugView. Cada linha informa o endereço alvo resolvido e o contador de acertos ao vivo para seu respectivo registrador de depuração.*

---

## Detalhamento Técnico

### 5.1 Breakpoints de Hardware em x64

Em x86/x64, cada CPU fornece **quatro registradores de endereço de depuração de hardware** (`DR0`–`DR3`) e um registrador de controle (`DR7`). Qualquer thread em execução com um breakpoint diferente de zero em `DR0`–`DR3` sofrerá uma falta sempre que o ponteiro de instrução atingir esse endereço (ou o acesso a dados corresponder às condições configuradas). O registrador de status `DR6` registra qual breakpoint foi acionado.

Breakpoints de hardware são **sensíveis ao contexto**: eles são armazenados na estrutura `CONTEXT` da thread e se aplicam apenas à thread na qual foram definidos. É por isso que uma implementação robusta deve definir breakpoints em **todas as threads** do processo (e reaplicá-los continuamente para novas threads).

### 5.2 Layout dos Registradores de Depuração (DR0–DR7)

`DR7` é um campo de bits que controla a habilitação e o comportamento dos breakpoints:

| Bits   | Campo  | Significado                                         |
|--------|--------|-----------------------------------------------------|
| `0`    | `L0`   | Habilitação local para o breakpoint 0 (DR0)         |
| `2`    | `L1`   | Habilitação local para o breakpoint 1 (DR1)         |
| `4`    | `L2`   | Habilitação local para o breakpoint 2 (DR2)         |
| `6`    | `L3`   | Habilitação local para o breakpoint 3 (DR3)         |
| `8`    | `LE`   | Habilitação local legada (mantida para compatibilidade) |
| `9`    | `GE`   | Habilitação global legada (mantida para compatibilidade) |
| `16–17`| `R/W0` | Tipo de acesso para BP0 (`00` = execução de instrução) |
| `18–19`| `Len0` | Tamanho para BP0 (`00` = 1 byte)                    |
| `20–21`| `R/W1` | Tipo de acesso para BP1 (`00` = execução de instrução) |
| `22–23`| `Len1` | Tamanho para BP1 (`00` = 1 byte)                    |
| `24–25`| `R/W2` | Tipo de acesso para BP2 (`00` = execução de instrução) |
| `26–27`| `Len2` | Tamanho para BP2 (`00` = 1 byte)                    |
| `28–29`| `R/W3` | Tipo de acesso para BP3 (`00` = execução de instrução) |
| `30–31`| `Len3` | Tamanho para BP3 (`00` = 1 byte)                    |

Todos os quatro breakpoints são configurados para **execução (busca de instrução) em um único byte**, que é a condição apropriada para hooks de entrada de função.

### 5.3 O Manipulador de Exceção Vetorizado (VEH)

Quando um breakpoint é acionado, o processador gera uma exceção `#DB`. No Windows x64, a rotina de despacho do `ntdll` a encaminha pela **cadeia VEH** de todo o processo antes da cadeia do Manipulador Estruturado de Exceções (SEH) da thread. O manipulador neste projeto:

1. **Filtra** — só trata `EXCEPTION_SINGLE_STEP` (`0x80000004`); todo o resto cai em `EXCEPTION_CONTINUE_SEARCH`.
2. **Compara** — compara `ExceptionAddress` com os quatro endereços de função conhecidos.
3. **Reescreve o contexto**:
   - `RIP = *(RSP)` → “retorna” ao chamador original desempilhando o endereço de retorno.
   - `RSP += 8` → simula um `ret` (unwind de instrução única em x64).
   - `RAX = 0` → falsifica `S_OK` / `ERROR_SUCCESS` (código de retorno bem-sucedido).
   - `DR6 &= ~0xF` → limpa os bits de status do breakpoint para que a instrução possa ser executada novamente posteriormente sem estado espúrio.
4. **Modifica parâmetros de saída** (consulte [5.4](#54-per-component-interception-logic)).
5. **Retorna `EXCEPTION_CONTINUE_EXECUTION`**, o que diz ao Windows para reiniciar a thread com o contexto modificado — ou seja, a execução é retomada no *chamador*, e a função alvo real **nunca é executada**.

Cada local de interceptação é adicionalmente envolvido em uma proteção SEH `__try/__except` para que um layout de pilha malformado ou inesperado não possa derrubar o processo — uma consideração de robustez para alvos hostis/endurecidos.

### 5.4 Lógica de Interceptação por Componente

**DR0 — `AmsiScanBuffer`** (x64, primeiros 6 argumentos em `RCX, RDX, R8, R9, [RSP+0x28], [RSP+0x30]`):```
HRESULT AmsiScanBuffer(HANDLE, PVOID, ULONG, LPCWSTR, HANDLE, AMSI_RESULT* pResult);
                                                        [RSP+0x28]  [RSP+0x30]

• Escreve AMSI_RESULT_CLEAN (0) no 6º parâmetro (pResult, em [RSP+0x30]).
• Retorna S_OK (0) em RAX.

DR1 — AmsiScanString (x64, primeiros 5 argumentos em RCX, RDX, R8, R9, [RSP+0x28]):``` HRESULT AmsiScanString(HANDLE, LPCWSTR, LPCWSTR, HANDLE, AMSI_RESULT* pResult); [RSP+0x28]

- Escreve `AMSI_RESULT_CLEAN (0)` no 5º parâmetro (`pResult`, em `[RSP+0x28]`).
- Retorna `S_OK (0)` em `RAX`.

**DR2 — `WldpIsClassInApprovedList`** (primeiros 3 argumentos em `RCX, RDX, R8`):```
HRESULT WldpIsClassInApprovedList(const GUID* classId, PBOOL isApproved, DWORD evalCriteria);
                                         RCX             RDX             R8

• Escreve TRUE em *isApproved (via RDX).
• Retorna S_OK (0) em RAX.
• Consequência: a classe de conteúdo avaliada é considerada "aprovada" pela política de lockdown, e o AMSI confia nesse julgamento para a classe.

DR3 — EtwEventWrite (primeiros 4 argumentos em RCX, RDX, R8, R9):``` ULONG EtwEventWrite(HANDLE RegHandle, PCEVENT_DESCRIPTOR EventDescriptor, ULONG UserDataCount, PEVENT_DATA_DESCRIPTOR UserData);

- Retorna `ERROR_SUCCESS (0)` em `RAX` sem tocar em nenhum parâmetro de saída.
- Consequência: os provedores de ETW **não** recebem eventos do processo com hook, suprimindo o registro de execução de scripts, carregamento de módulos, criação de processos e telemetria AMSI.

### 5.5 Gerenciamento de Threads e Persistência de Hook

Como os registradores de depuração são específicos por thread, o mecanismo deve manter continuamente os hooks:

1. **Hook imediato** — `DllMain` (ou `InstallHook`) aplica hook na thread chamadora com `SetHwbpOnThread(GetCurrentThread())`.
2. **Varredura de todas as threads** — `HookAllThreads()` enumera todas as threads do processo por meio de um snapshot `TH32CS_SNAPTHREAD`, suspende cada thread externa (`SuspendThread`), aplica os breakpoints (`SetHwbpOnThread`), a retoma e fecha o handle. A suspensão evita uma condição de corrida em que a thread falha no meio da troca de contexto entre `GetThreadContext` e `SetThreadContext`.
3. **Monitor de persistência** — `MonitorThreadProc` faz loop com `Sleep(500)` e chama `HookAllThreads()` a cada 500 ms. Isso **rearma quaisquer breakpoints que tenham sido removidos** (por exemplo, por uma chamada externa a `SetThreadContext`, uma ferramenta de depuração ou encerramento/criação de threads) e **cobre threads criadas após o hook inicial**.
4. **Sincronização** — `HookAllThreads` é executado sob uma `CRITICAL_SECTION` (`g_HookLock`) para que a thread do monitor e a rotina inicial de hook nunca intercalem trocas de contexto.
5. **Encerramento limpo** — `UninstallHook` interrompe o monitor, limpa `DR0–DR7` em todas as threads e remove o VEH.

> **Resposta explícita à pergunta sobre "persistência do hook":** sim — se os breakpoints forem removidos de qualquer thread (por outro agente, um depurador ou um EDR), a thread do monitor **os reaplica dentro de 500 ms**. Além disso, qualquer thread criada após o carregamento da DLL recebe hook dentro de um ciclo do monitor. A única maneira confiável de derrotar esse mecanismo específico é encerrar a thread do monitor *e* remover o VEH *e* limpar os registradores dentro da mesma janela — ou usar anti-debugging que negue `SetThreadContext` desde o início.

---

## API Exportada

| Exportação       | Assinatura                        | Comportamento                                                              |
|-------------------|------------------------------------|-----------------------------------------------------------------------|
| `InstallHook`     | `BOOL WINAPI InstallHook(void)`    | Resolve os alvos, registra o VEH, aplica hook em todas as threads, inicia o monitor. |
| `UninstallHook`   | `BOOL WINAPI UninstallHook(void)`  | Interrompe o monitor, limpa os breakpoints em todas as threads, remove o VEH. |
| `GetStats`        | `void WINAPI GetStats(void)`       | Emite o status atual do hook (via `OutputDebugStringA`) — endereço, contadores de acertos. |

Os contadores de acertos (`g_HaveAmsiBuf`, `g_HaveAmsiStr`, `g_HaveWldp`, `g_HaveEtw`) são mantidos com `InterlockedIncrement` e são expostos na saída de depuração, o que é útil para validar que a interceptação está de fato ocorrendo em um ambiente de laboratório.

Observe que o próprio `DllMain` executa a sequência completa de hook em `DLL_PROCESS_ATTACH`, portanto as exportações são conveniências opcionais para cenários de carregamento/descarregamento em tempo de execução.

---

## Instruções de Compilação

**Requisitos:** Windows 10/11 x64, Visual Studio Build Tools (`icx.exe`), SDK.

Compile a DLL (x64):```bat
icx.exe /nologo /O3 /MT /EHsc "mora_hwbp.c" /link /DLL /out:"mora_hwbp.dll" /LIBPATH:"C:\Program Files (x86)\Intel\oneAPI\compiler\latest\lib"

Explicação das flags:

O resultado é mora_hwbp.dll, que pode ser carregado em um processo alvo.

Exemplo de Injeção e Uso

A DLL deve ser carregada em um processo que usa AMSI/WLDP/ETW — um host do PowerShell é o ambiente de teste canônico. O carregamento pode ser feito com qualquer técnica padrão de injeção de DLL. Uma demonstração mínima e autossuficiente usando injeção Refletiva/LoadLibrary pode ser realizada com um pequeno carregador em C:```bat rem Run from an x64 developer prompt (example with a generic loader) loader.exe mora_hwbp.dll powershell.exe

Ou, para uma verificação manual em laboratório, injete com a sua ferramenta preferida e depois valide a partir do PowerShell:```powershell
# 1. Inject mora_hwbp.dll into the PowerShell process (via external tool).
# 2. Verify that classic AMSI test vectors now return clean.
"AmsiTestSample:7e72c3ce-861b-4339-8740-0ac1484c1386"

Apenas validação em laboratório. Observe com um depurador ou GetStats/OutputDebugString que todos os quatro breakpoints reportam acertos à medida que o conteúdo do script é executado.

Detecção & Mitigação (Blue Team)

Este POC tem dupla finalidade: as mesmas características que o tornam eficaz ofensivamente são exatamente o que os defensores devem procurar.

Indicadores de Comprometimento (IOCs)

Mitigações Recomendadas

1. Agentes de vigilância/automonitoramento — consulte GetThreadContext(CONTEXT_DEBUG_REGISTERS) em processos de alto valor e audite qualquer thread com DR0–DR3 diferente de zero fora dos perfis de depurador aprovados.
2. Auditoria ETW do kernel — habilite o rastreamento de Microsoft-Windows-Kernel-Process + Thread e alerte sobre NtGetContextThread/NtSetContextThread direcionados a processos relevantes para a segurança.
3. Integridade de hooks em modo de usuário do EDR — como os hooks de hardware contornam verificações de memória, confie na detecção comportamental (hooks de consumidor de ETW abaixo de EtwEventWrite, ETW do kernel, reverificação do consumidor de AMSI) em vez de apenas na integridade de .text.
4. Proteja o monitor — em ambientes genuinamente hostis, trate SetThreadContext por thread em outros processos como um sinal explícito de alta severidade.
5. Endurecimento de endpoints — habilite WDAC (que este POC explicitamente contorna para aprovação de classe — não trate WDAC como uma defesa autônoma contra ferramentas em memória), Credential Guard e proteção do LSASS quando aplicável.

Limitações Conhecidas

• Somente x64 — as reescritas de deslocamento de pilha assumem a convenção de chamada x64 (argumentos RCX/RDX/R8/R9 e depois [RSP+0x20…]). Uma variante x86 precisaria de reconstrução de parâmetros no estilo [EBP+…].
• Apenas quatro slots — a arquitetura x64 oferece exatamente quatro registradores de breakpoint; você não pode hookar mais de quatro funções por thread apenas com este método.
• Janela de corrida do monitor — existe uma janela (intencionalmente pequena) entre iterações de Sleep(500); criação extremamente rápida de threads combinada com stripping agressivo poderia teoricamente ultrapassar o monitor por algumas centenas de milissegundos.
• Interferência de anti-debug — qualquer componente que monitore ou limpe ativamente os registradores de depuração (um depurador real, alguns sandboxes, certos EDRs) interferirá na técnica.
• Status baseado em OutputDebugStringA — o diagnóstico depende de um canal de saída de depuração; em um ambiente totalmente stripped/headless, você deve anexar um depurador ou redirecionar a saída para observação em laboratório.
• Não é uma primitiva de persistência de memória — esta é uma técnica apenas em tempo de execução, no processo. Ela não fornece persistência em disco/registro, nenhuma escalada de privilégio e nenhum movimento lateral entre processos por si só. Seu propósito inteiro é o estudo controlado de uma primitiva de interceptação.

Referências

• Microsoft Learn — Antimalware Scan Interface (AMSI)
• Microsoft Learn — Windows Lockdown Policy (WLDP)
• Microsoft Learn — Event Tracing for Windows (ETW)
• Microsoft Learn — Estrutura CONTEXT & Registradores de Depuração
• Manual do Desenvolvedor de Software das Arquiteturas Intel® 64 e IA-32, Vol. 3B — Debug Registers (Dr0–Dr7, exceção #DB)

Licença & Divulgação Responsável

Este projeto é licenciado sob a Licença MIT - consulte o arquivo LICENSE para detalhes.

Este projeto é disponibilizado apenas para fins educacionais e de pesquisa defensiva. Se você é um fornecedor de segurança, blue team ou engenheiro de detecção, incentivamos você a usar o conteúdo deste repositório para melhorar sua cobertura de detecção para evasão baseada em breakpoints de hardware. Se você descobriu esta técnica sendo abusada na natureza, relate-a por meio do processo de divulgação responsável da sua organização e dos canais relevantes de fornecedor/autoridade.

Use por sua conta e risco. O uso não autorizado desta técnica pode violar leis aplicáveis.