# T1622 - Debugger Evasion ## Descrição Adversários empregam múltiplas técnicas para detectar a presença de um depurador (debugger) e alterar o comportamento do malware com base nessa detecção. Depuradores são instrumentos centrais na análise dinâmica de malware: permitem que analistas acompanhem a execução passo a passo, inspecionem memória e identifiquem comportamentos maliciosos. Ao detectar que está sendo depurado, o malware pode encerrar sua execução, remover payloads, exibir comportamento benigno ou aguardar indefinidamente - frustrando a análise. A técnica é intimamente relacionada a [[Sandbox Evasion]], mas focada específicamente em ferramentas de análise interativa como OllyDbg, x64dbg, WinDbg, GDB e LLDB, em vez de ambientes virtualizados. O malware frequentemente emprega múltiplas checagens em paralelo para aumentar a robustez da detecção. Grupos como [[g0129-mustang-panda|Mustang Panda]] incorporam checagens de debugger em implantes como [[s0013-plugx|PlugX]] e [[s1228-pubload|PUBLOAD]] para proteger payloads de estágio seguinte. Famílias de infostealer como [[lumma-stealer|Lumma Stealer]], [[darkgaté|DarkGaté]] e [[pikabot|Pikabot]] também implementam evasão de debugger como camada adicional de proteção contra engenharia reversa. ## Como Funciona As checagens de debugger podem ser agrupadas em quatro categorias técnicas principais: ### 1. Verificação de flags de processo (Windows) A abordagem mais comum em Windows é consultar diretamente o Process Environment Block (PEB) da aplicação. O campo `BeingDebugged` do PEB é definido como `1` pelo sistema operacional quando um depurador está presente. A função `IsDebuggerPresent()` da Win32 API é essencialmente um wrapper para essa leitura. Variantes mais sofisticadas usam `NtQueryInformationProcess()` com a classe `ProcessDebugPort` para verificar se um debugger está conectado via porta de depuração - método que evita detecção por hooking da API de alto nível. ### 2. Verificação de artefatos do sistema (Linux/macOS) Em Linux, o arquivo `/proc/self/status` contém o campo `TracerPID`, que vale `0` quando nenhum processo de rastreamento está ativo e contém o PID do tracer quando GDB ou strace estão conectados. Em macOS, a chamada `sysctl` com `KERN_PROC` e a flag `P_TRACED` cumpre função similar. ### 3. Ataques de temporização (timing attacks) Depuradores introduzem latência mensurável na execução porque o processamento passo a passo e os breakpoints consomem tempo. O malware registra o tempo antes e depois de uma operação - usando `QueryPerformanceCounter`, `rdtsc` (Read Time-Stamp Counter) ou `GetTickCount` - e, se o delta for maior que um limiar, conclui que está sendo analisado. ### 4. Tratamento de exceções e breakpoints Depuradores de software inserem a instrução `INT 3` (opcode `0xCC`) em pontos de interesse. O malware pode varrer sua própria memória em busca desse byte para detectar breakpoints. Outra variante usa Structured Exception Handling (SEH): lança intencionalmente uma exceção e verifica se o fluxo de controle é desviado para o depurador (que "engole" a exceção) ou para o próprio handler SEH da aplicação. O flood de mensagens via `OutputDebugStringW()` em loop também é usado para saturar logs de depuração e dificultar o acompanhamento da execução. ## Attack Flow ```mermaid graph TB A[Malware executado no host] --> B{Checagem de debugger} B --> C[IsDebuggerPresent / PEB.BeingDebugged] B --> D[NtQueryInformationProcess - ProcessDebugPort] B --> E[Timing attack - rdtsc / QueryPerformanceCounter] B --> F[Scan de breakpoints INT 3 na memória] B --> G[SEH - exceção sem handler externo] B --> H[/proc/self/status TracerPID - Linux] C --> I{Debugger detectado?} D --> I E --> I F --> I G --> I H --> I I -->|Sim| J[Comportamento de evasão] I -->|Não| K[Execução normal do payload] J --> L[Encerrar processo] J --> M[Dormir indefinidamente / loop] J --> N[Exibir comportamento benigno] J --> O[Suprimir payload de estágio 2] ``` ## Exemplos de Uso **Mustang Panda / [[s0013-plugx|PlugX]]:** o loader do PlugX utilizado por [[g0129-mustang-panda|Mustang Panda]] implementa checagens de PEB e timing antes de descriptografar e carregar o payload principal. Se um debugger for detectado, o processo encerra silenciosamente, sem registros de erro. **[[lumma-stealer|Lumma Stealer]]:** infostealer amplamente distribuído via malspam e malvertising; utiliza combinação de `IsDebuggerPresent`, checagem de `NtGlobalFlag` no PEB e timing attack com `rdtsc` para detectar análise antes de iniciar a coleta de credenciais. **[[s1087-asyncrat|AsyncRAT]]:** trojan de acesso remoto open-source muito usado por grupos de ameaça com menor sofisticação técnica; incorpora rotinas de anti-debug em `.NET` usando `System.Diagnostics.Debugger.IsAttached` e verificações de timing. **[[darkgaté|DarkGaté]]:** loader polimórfico distribuído via Microsoft Teams e phishing; combina detecção de debugger com detecção de VM e sandbox ([[t1497-virtualizationsandbox-evasion|T1497]]) em uma camada unificada de anti-análise antes de descompactar o payload final. **[[s0240-rokrat|ROKRAT]]:** RAT atribuído ao grupo Kimsuky (Coreia do Norte); utiliza `NtQueryInformationProcess` com `ProcessDebugObjectHandle` e checagem de timing para detectar análise antes de estabelecer comunicação C2. ## Detecção A detecção de evasão de debugger é inerentemente difícil em produção, pois as checagens em si são operações legítimas do sistema. A estratégia mais eficaz é correlacionar múltiplos sinais comportamentais: - Processo que chama `IsDebuggerPresent` ou `NtQueryInformationProcess` logo após a inicialização, especialmente combinado com encerramento abrupto sem erro visível - Leitura direta do PEB via acesso a `fs:[0x30]` (x86) ou `gs:[0x60]` (x64) - comum em malware que evita a API de alto nível - Uso de `rdtsc` em sequências de curta duração seguidas de salto condicional (indicativo de timing check) - Processo que varre sua própria memória em busca de breakpoints (leitura em páginas de código do próprio processo) - Chamadas repetitivas a `OutputDebugStringW` em volume anormalmente alto (flood de logs) ```yaml title: Possível Detecção de Debugger via NtQueryInformationProcess status: experimental logsource: category: process_access product: windows detection: selection: TargetObject|endswith: "\\lsass.exe" selection_api: CallTrace|contains: - "ntdll.dll!NtQueryInformationProcess" selection_self: SourceImage|endswith: - ".exe" TargetImage: "\\Device\\HarddiskVolume*" filter_legit: SourceImage|startswith: - "C:\\Windows\\System32\\" - "C:\\Program Files\\" condition: (selection_api or selection_self) and not filter_legit level: medium tags: - attack.defense_evasion - attack.t1622 ``` ```yaml title: Loop Anômalo de OutputDebugStringW - Possível Anti-Debug Flood status: experimental logsource: category: process_creation product: windows detection: selection: Image|endswith: ".exe" CommandLine|contains: "OutputDebugString" filter_devtools: ParentImage|startswith: - "C:\\Program Files\\Microsoft Visual Studio\\" - "C:\\Windows\\System32\\devenv.exe" condition: selection and not filter_devtools level: low tags: - attack.defense_evasion - attack.t1622 ``` ## Mitigação O MITRE ATT&CK não lista mitigações preventivas específicas para T1622, reconhecendo que as APIs e syscalls utilizadas são legítimas. A defesa é predominantemente detectiva: | Abordagem | Descrição | |-----------|-----------| | Análise estática aprimorada | Usar ferramentas de análise estática (YARA, Capa) para identificar padrões de anti-debug em binários antes da execução - checagens de PEB, strings de API de debug, opcodes de timing. | | Sandbox multi-camada | Configurar sandboxes com técnicas de patching transparente que retornam valores falsos para `IsDebuggerPresent` e similares, forçando o malware a executar normalmente. | | Monitoramento de comportamento pós-evasão | Focar detecção nos comportamentos que ocorrem após a evasão ser bem-sucedida - conexões C2, injeção de processo, acesso a credenciais - em vez de nas checagens de debugger em si. | | EDR com visibilidade de syscalls | Soluções EDR com captura de syscalls (não apenas API de alto nível) detectam chamadas diretas a `NtQueryInformationProcess` e acesso ao PEB que contornam hooks de userspace. | ## Contexto Brasil/LATAM O ecossistema de malware direcionado ao Brasil é dominado por famílias de trojan bancário - como Grandoreiro, Mekotio e Guildma - que historicamente incorporam técnicas de anti-análise avançadas para proteger seus módulos de captura de tela e hook de teclado. A evasão de debugger é uma componente padrão dessas famílias, frequentemente combinada com verificações de idioma do sistema operacional (rejeitando execução fora do ambiente PT-BR) e detecção de sandbox. Grupos como [[g0129-mustang-panda|Mustang Panda]] e Kimsuky - com presença documentada em campanhas contra alvos governamentais e de infraestrutura crítica na América Latina - utilizam implantes com múltiplas camadas de anti-análise, dificultando investigações de resposta a incidentes que dependem de análise dinâmica. Times de threat intel da região precisam complementar análise dinâmica com abordagem estática (YARA + Capa) e análise de comportamento em sandbox com evasão neutralizada via patching de API. ## Referências - [[Sandbox Evasion]] - técnica relacionada de anti-análise - [[t1106-native-api|T1106 - Native API]] - mecanismo de baixo nível usado nas checagens - [[g0129-mustang-panda|Mustang Panda]] - grupo que utiliza a técnica - [[s0013-plugx|PlugX]] - malware com implementação documentada de anti-debug - [[lumma-stealer|Lumma Stealer]] - infostealer com anti-debug ativo - [[s1087-asyncrat|AsyncRAT]] - RAT com checagens de debugger em .NET - [[darkgaté|DarkGaté]] - loader com camada unificada de anti-análise - [[s0240-rokrat|ROKRAT]] - RAT APT com NtQueryInformationProcess - [[pikabot|Pikabot]] - loader modular com evasão de debugger - [[s1228-pubload|PUBLOAD]] - malware do Mustang Panda com anti-debug --- *Fonte: MITRE ATT&CK - T1622*