Evasao de EDR para Pesquisa: Direct Syscalls Explicados sem Romantizacao

Direct syscalls viraram meme em canal de YouTube e thread de Twitter, mas a maior parte da pesquisa publicada nem chega perto do que um EDR moderno (CrowdStrike Falcon 7.x, SentinelOne Singularity, Microsoft Defender for Endpoint com kernel ETW-TI) realmente vê. Aqui na Basilisk OffSec a gente estuda essa técnica em lab isolado, com Windows 11 23H2 sem internet, snapshots VMware versionados, e zero intenção de empacotar nada disso como serviço. O objetivo é simples: entender o caminho NTDLL -> SSN -> syscall -> kernel pra escrever detecções melhores, não pra vender bypass. Quem quer empilhar IOC e fingir que isso é red team profissional pode parar de ler agora, esse texto não vai ajudar.

Recapitulando o básico sem condescendência: cada função documentada em ntdll.dll (NtAllocateVirtualMemory, NtCreateThreadEx, NtProtectVirtualMemory) carrega um System Service Number (SSN) que muda a cada build do Windows. O EDR tipicamente coloca um hook inline JMP nos primeiros bytes dessas stubs em user-mode, então quando o seu loader chama VirtualAlloc o controle passa pela DLL injetada antes de chegar ao kernel. Direct syscall significa replicar a stub na sua aplicação - mov r10, rcx; mov eax, SSN; syscall; ret - pulando completamente o hook. Funciona, mas como veremos é uma vitória barata contra telemetria user-mode e absolutamente nada contra telemetria kernel. Para contexto, vale revisitar Bypass de AMSI e ETW para Pesquisa Defensiva: O que Blue Teams Devem Saber porque a lógica é parecida.

Para reproduzir em casa eu uso SysWhispers3 (fork mantido pelo klezVirus) gerando stubs em MASM para projeto C++ compilado com MSVC 19.38. O SSN é resolvido em runtime via Hell's Gate ou Halo's Gate, varrendo a EAT da ntdll mapeada do disco - não a versão em memória, que pode estar adulterada. Em três horas de bancada consegui um POC que aloca RW, escreve shellcode benigno (calc.exe nu, sem nada acoplado), faz NtProtectVirtualMemory pra RX e dispara NtCreateThreadEx. Sysmon 15 com config SwiftOnSecurity registra criação de thread, mas o ProcessAccess fica limpo. Parece vitória até você ligar o Defender com EDR block mode, e aí o sinal vem do kernel via Threat Intelligence ETW provider, não do user-mode.

Aí mora o ponto que ninguém quer dizer em palco: Microsoft-Windows-Threat-Intelligence emite eventos de NtAllocateVirtualMemory, NtProtectVirtualMemory com RWX, NtMapViewOfSection e NtCreateThreadEx independente de hook user-mode. Você pulou a NTDLL, ótimo, mas o kernel ainda viu o syscall chegar, com a stack de retorno apontando pra .text do seu binário em vez de pra ntdll.dll - exatamente o que detecção de call stack anomaly procura. Elastic Security tem regra pública desde 2023, e a turma do Threat Hunting com Sigma e Elastic: Do Indicador a Regra de Deteccao já consome isso por padrão. Indirect syscalls (jump pra dentro da ntdll de novo, syscall lá) mitigam essa stack mas trazem outros problemas, como ROP-like patterns que YARA-X pega.

Em projetos autorizados a gente discute esse trade-off com o cliente antes de qualquer execução, e isso conecta diretamente com Red Team 101: Diferenca entre Pentest e Operacoes Adversariais Reais: emulação de adversário tem escopo, regras de engajamento e janela. Para o lado defensivo o exercício é mais rico - rodar a POC, capturar o ETW-TI com SilkETW ou krabsetw, e escrever uma regra Sigma que cubra a heurística sem gerar falso positivo no Teams Installer. Eu costumo combinar isso com hardening conforme Hardening de Windows 11 para Estacoes de Trabalho de Alto Risco e checar movimentação cruzada como descrito em Lateral Movement em Lab: SMB, WMI e WinRM com Foco em Deteccao, porque syscall direto isolado raramente é a história inteira de um incidente real.

Algumas perguntas que recebo e respondo rápido: não, não publicamos loader pronto; não, unhooking via fresh NTDLL copy do disco não é mágico - o Defender mapeia isso desde 2022 via memory image integrity; e não, ChatGPT escrevendo seu shellcode em Nim não te torna invisível, só te dá entropia esquisita no .text que ML classifier do EDR adora. Para quem está começando a parte ofensiva séria, recomendo construir base em Active Directory Pentest: Kerberoasting Passo a Passo em Lab GOAD e Construindo Infra de C2 com Sliver em Lab Isolado para Estudo Defensivo antes de cair em syscall, porque sem entender o que vem depois da execução você só fica admirando o próprio reflexo no Process Hacker.

Takeaway prático: se você é defensor, habilite o provider Microsoft-Windows-Threat-Intelligence (requer PPL no serviço EDR), ingira no seu SIEM e construa três regras - call stack não originando em ntdll, NtProtectVirtualMemory mudando RW para RX em região private, e NtCreateThreadEx cross-process com start address em heap. Isso pega 80% dos POCs públicos sem custo de licenciamento adicional. Se você é pesquisador, documente, isole, não distribua binários compilados, e lembre que a fronteira entre estudo e crime é o consentimento por escrito do dono do ativo - assunto que OPSEC para Pesquisadores de Seguranca: Modelo de Ameaca Pessoal cobre direito.