Bypass de AMSI e ETW para Pesquisa Defensiva: O que Blue Teams Devem Saber

Um operador joga um Invoke-Mimikatz num PowerShell 5.1 sem nenhuma ofuscacao e nao acontece nada. O Defender nao grita, o SOC nao recebe alerta, e o ticket fica em silencio enquanto a memoria do lsass ja foi lida. Isso nao e magia: e uma linha de patch em amsi.dll que zera o AmsiScanBuffer em duas instrucoes. Em 2026, AMSI e ETW continuam sendo o esqueleto da telemetria do Windows, e continuam sendo neutralizados por scripts de quatro linhas circulando no GitHub desde 2016. Antes de comprar mais um EDR, vale entender por que esses bypasses ainda funcionam e o que de fato muda o jogo do lado azul.

AMSI (Antimalware Scan Interface) e uma ponte. PowerShell, VBScript, JScript, WMI e ate macros do Office chamam AmsiScanBuffer para perguntar ao antivirus se o conteudo em memoria e malicioso. O detalhe inconveniente e que essa chamada acontece no proprio processo do alvo, com permissoes do alvo. Se o atacante ja roda codigo dentro do powershell.exe, ele pode escrever na regiao .text de amsi.dll, trocar o prologo de AmsiScanBuffer por mov eax, 0x80070057; ret e desligar a luz. Matt Graeber publicou a versao classica em 2016 e variacoes em hardware breakpoints, patching de AmsiOpenSession e corrupcao do amsiContext continuam aparecendo. Quem trabalha com Evasao de EDR para Pesquisa: Direct Syscalls Explicados sem Romantizacao reconhece o padrao: instrumentacao em user-mode e sempre soft-power.

ETW (Event Tracing for Windows) e mais profundo, mas tem o mesmo calcanhar de aquiles. Providers como Microsoft-Windows-Threat-Intelligence emitem eventos sobre AllocateVirtualMemory, abertura de handles para lsass e injecao de threads remotas, alimentando praticamente todo EDR comercial. O bypass canonico patcha EtwEventWrite em ntdll.dll com um ret simples (xor eax,eax; ret), e pronto: o provider continua registrado, mas nada sai. Variacoes modernas mexem em EtwpEventWriteFull ou removem o provider da TRACE_ENABLE_INFO. Como esses bypasses sao locais e silenciosos, hunting baseado em ausencia de eventos esperados se torna mais valioso que hunting de assinatura. Quem ja monta Threat Hunting com Sigma e Elastic: Do Indicador a Regra de Deteccao sabe que regras de 'silencio anormal' sao chatas de calibrar, mas pegam o que regra positiva nao pega.

Do lado ofensivo etico, reproduzir esses bypasses em laboratorio e obrigatorio para entender o que o blue team realmente ve. Um setup minimo: Windows 11 23H2 com Defender ligado, Sysmon 15 com config do Olaf Hartong, e Elastic Agent enviando para um cluster de teste. Rode o patch classico de AMSI via reflection, depois rode com hardware breakpoints (que nao tocam na .text e por isso passam por integrity checks fracos), e compare o que o Defender e o Sysmon registram em cada caso. Surpresa comum: o Event ID 4104 do PowerShell ainda captura o bloco de script malicioso porque ScriptBlockLogging e independente de AMSI. Esse tipo de exercicio se encaixa bem em um ciclo de Purple Team na Pratica: Construindo Ciclo de Feedback Red x Blue e ensina mais que ler whitepaper.

Hardening real comeca aceitando que bypass em user-mode e barato. Habilite PowerShell Constrained Language Mode via WDAC para usuarios padrao, ative ScriptBlockLogging e Module Logging com forwarding pra fora da maquina (porque log local o atacante apaga), e force PowerShell 7+ com AMSI integration verificada. Habilite Protected Process Light no Defender, ative LSA Protection (RunAsPPL) e considere Credential Guard pra elevar o custo de quem chegou ate lsass. No nivel ETW, o que muda o jogo e mover deteccao pra fora do host: Sysmon + WEF pra um coletor dedicado, e onde possivel kernel callbacks via driver proprio do EDR, que o atacante so derruba com BYOVD. Quem ja faz Hardening de Windows 11 para Estacoes de Trabalho de Alto Risco tem boa parte do caminho andado.

Deteccao de bypass tem padroes claros e baratos de implementar. Procure por NtProtectVirtualMemory mudando permissoes em amsi.dll ou ntdll.dll dentro de processos que nao sao instaladores (Sysmon Event ID 10 + filtros de imagem alvo). Olhe para PowerShell que carrega System.Management.Automation.AmsiUtils via reflection (Event 4104 com 'amsiInitFailed' e quase IOC literal). Monitore divergencia entre eventos esperados de ETW-TI e o que chega no SIEM por host: se um endpoint comecou a emitir 70% menos eventos sem mudanca de carga, algo patchou EtwEventWrite. Essa logica de baseline por host se conecta com Hunting de Living-off-the-Land Binaries no Windows com KQL e com Persistencia em Windows: 10 Tecnicas Documentadas e suas Contramedidas, onde silencio tambem e sinal.

Reportar pesquisa nessa area exige cuidado etico. Bypass de AMSI/ETW nao e 0day, mas publicar PoC novo sem coordenacao com Microsoft e sem foco defensivo polui o ecossistema e ajuda quem nao precisa de ajuda. O padrao saudavel: reproduza em lab isolado, documente o IOC defensivo antes do exploit, e quando publicar, lidere com a regra Sigma, nao com a screenshot do mimikatz feliz. Se o seu trabalho toca cliente, alinhe escopo escrito antes; se toca infra propria, pratique OPSEC para Pesquisadores de Seguranca: Modelo de Ameaca Pessoal pra nao virar alvo do que voce mesmo estuda. Takeaway pratico: assuma que AMSI e ETW vao ser bypassados no host comprometido, e invista em ScriptBlockLogging forwardado, Sysmon com config curada e baseline de volume de eventos por endpoint. Esses tres controles sozinhos pegam a maioria dos bypasses publicos vistos em 2025-2026, sem depender de nenhum vendor especifico.