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. Este texto desmonta, camada por camada, por que esses bypasses ainda funcionam, como reproduzi-los de forma limpa em laboratorio e o que de fato muda o jogo do lado azul sem comprar mais um EDR caro.

O que AMSI realmente e e por que ele vive dentro do processo da vitima

AMSI (Antimalware Scan Interface) e uma ponte, nao um muro. PowerShell, VBScript, JScript, WMI e ate macros do Office chamam AmsiScanBuffer para perguntar ao antivirus registrado se o conteudo em memoria e malicioso. O detalhe decisivo e que essa chamada acontece no proprio processo do alvo, com as permissoes dele e no espaco de enderecos dele. Se o atacante ja roda codigo dentro do powershell.exe, ele esta do mesmo lado da fronteira de confianca que a rotina de varredura. Ele pode escrever na regiao .text de amsi.dll, trocar o prologo de AmsiScanBuffer por mov eax, 0x80070057; ret (E_INVALIDARG, lido como "limpo") e desligar a luz. Matt Graeber publicou a versao classica por reflection em 2016, e variacoes com hardware breakpoints, patching de AmsiOpenSession e corrupcao do amsiContext continuam aparecendo.

A longevidade e estrutural, nao desleixo. Enquanto a instrumentacao viver em user-mode e no mesmo processo, ela e por definicao manipulavel por qualquer um que execute codigo nesse processo. Quem trabalha com Evasao de EDR para Pesquisa: Direct Syscalls Explicados sem Romantizacao reconhece o padrao: instrumentacao em user-mode e sempre soft-power. A Microsoft endurece a superficie (assinaturas de bytes de patch conhecidos, integridade AMSI mais rigida no PowerShell 7), mas o principio se mantem: o defensor coloca o sensor dele na sala do atacante.

ETW como camada mais profunda com o mesmo calcanhar de aquiles

ETW (Event Tracing for Windows) e mais profundo no sistema mas compartilha a fraqueza. Providers como Microsoft-Windows-Threat-Intelligence emitem eventos sobre NtAllocateVirtualMemory, 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 simples xor eax,eax; ret, e pronto: o provider continua registrado, mas nada sai do processo. Variacoes modernas mexem em EtwpEventWriteFull, removem o provider do TRACE_ENABLE_INFO ou baixam os niveis de trace por thread. 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 justamente o que a regra positiva nao pega. O valor do ETW-TI e que ele nasce no kernel; o bypass, porem, acontece em user-mode antes de o evento sair do processo. Mova a coleta para mais perto do kernel ou para fora do host e o patch de user-mode perde efeito.

O patch classico de AMSI passo a passo

Conceitualmente o bypass por reflection funciona assim: voce obtem o campo amsiInitFailed via [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils') e o coloca em true, e o PowerShell pula a varredura. O patch de memoria mais robusto resolve o endereco de AmsiScanBuffer com GetProcAddress(LoadLibrary("amsi.dll"), "AmsiScanBuffer"), chama VirtualProtect com PAGE_EXECUTE_READWRITE, escreve os bytes do stub de retorno e restaura a protecao. A variante com hardware breakpoints e mais elegante: nao toca no .text, e sim seta registradores de debug (Dr0-Dr7) sobre AmsiScanBuffer via SetThreadContext e falsifica o valor de retorno em um handler de excecao. Como nao modifica codigo, ela passa por integrity checks fracos que so procuram bytes patchados.

Importante para a analise defensiva: o patch por reflection deixa um rastro muito caracteristico no ScriptBlockLogging (Event ID 4104) porque as strings AmsiUtils e amsiInitFailed sao logadas antes de o AMSI ser desativado. Ja o patch de memoria e visivel via NtProtectVirtualMemory sobre amsi.dll. Cada tecnica troca furtividade por complexidade, e nenhuma e invisivel se voce olhar no lugar certo.

Montagem de laboratorio para ver o que o azul realmente captura

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 a variante com hardware breakpoints, 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.

Isolamento faz parte do exercicio: sem domain join entre laboratorio e producao, sem egress de internet que possa exfiltrar os payloads testados, e snapshots antes de cada rodada para a baseline ficar reproduzivel. Meca sempre primeiro o estado nulo (o que e logado sem bypass) e depois o estado com bypass. A diferenca e a sua chance de deteccao.

Hardening real: o que de fato custa ao atacante

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. A priorizacao importa: WDAC/Constrained Language Mode e ScriptBlockLogging forwardado rendem mais por hora investida que outra licenca de EDR. O objetivo nao e tornar o bypass impossivel (nao da, no mesmo processo) e sim torna-lo caro, barulhento e rastreavel.

Deteccao: padroes concretos e IOCs

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. Adicione regras de comportamento: um processo PowerShell que carrega amsi.dll e logo depois aloca uma regiao RWX e mais suspeito que qualquer indicador isolado.

Erros comuns dos dois lados

Do lado azul, o erro mais comum e confiar no AMSI 4104 sem garantir o forwarding: se o atacante consegue apagar logs locais, seu IOC some. Um segundo erro e cacar so assinaturas de bytes do patch classico e perder por completo a variante com hardware breakpoints. Do lado ofensivo (laboratorio), o erro mais comum e testar bypasses contra ativos de producao ou publicar PoCs sem contexto defensivo. Um terceiro, muito ignorado: muitos assumem que um bypass de AMSI tambem desativa ETW; nao desativa, sao mecanismos separados e precisam ser bypassados separadamente e detectados separadamente.

Checklist para blue teams

Curto e acionavel: (1) habilite ScriptBlockLogging e Module Logging e encaminhe pra fora do host via WEF. (2) force Constrained Language Mode via WDAC para usuarios padrao. (3) ative RunAsPPL e Credential Guard. (4) Sysmon 15 com config curada mais Event ID 10 sobre amsi.dll/ntdll.dll. (5) baseline por endpoint do volume de eventos ETW-TI com alerta em quedas. (6) busca 4104 por "amsiInitFailed"/"AmsiUtils". (7) documente a deteccao com a regra Sigma, nao com a screenshot do mimikatz. (8) valide cada controle em um ciclo purple team contra bypasses reais, nao no papel.

FAQ: Um EDR moderno basta contra o bypass de AMSI/ETW?

Nao, nao sozinho. Um bom EDR dificulta e detecta bypasses via kernel callbacks e analise de comportamento, mas quando o atacante ja esta no processo ele pode manipular sensores de user-mode, e com BYOVD atacar componentes de kernel. O valor esta na defesa em profundidade: EDR mais ScriptBlockLogging forwardado mais WDAC mais telemetria fora do host. Nenhum produto sozinho fecha a lacuna porque a lacuna e arquitetural, nao de produto.

FAQ: E legal pesquisar e publicar esses bypasses?

Reproduzir em laboratorio isolado proprio e pesquisa defensiva legitima. Publicar exige cuidado etico. Bypass de AMSI/ETW nao e 0day, mas publicar PoC sem foco defensivo ajuda sobretudo 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. Se o seu trabalho toca cliente, alinhe escopo escrito; se toca infra propria, pratique OPSEC para Pesquisadores de Seguranca: Modelo de Ameaca Pessoal.

Conclusao

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. O fio condutor e sempre o mesmo: o defensor que assume que seu sensor de host pode ser manipulado, e por isso coloca a deteccao fora do host e baseada em comportamento, ganha de um bypass que aposta na comodidade do defensor.