# T1055.008 - Ptrace System Calls ## Descrição A técnica **T1055.008** consiste no uso da chamada de sistema `ptrace()` para injetar código malicioso no espaço de endereçamento de processos em execução em sistemas **Linux** e macOS. O `ptrace` é uma interface nativa do kernel originalmente projetada para fins de depuração - permite que um processo pai observe e controle completamente outro processo filho, incluindo leitura e escrita na memória, registradores e sinais. Adversários abusam desse mecanismo legítimo para ocultar a execução de código malicioso sob a identidade de um processo confiável, evadindo produtos de segurança baseados em assinatura de processo e controles de execução. A técnica é classificada como sub-técnica de [[t1055-process-injection|T1055 - Process Injection]] dentro da tática de [[_defense-evasion|Defense Evasion]], mas também pode servir para **escalada de privilégios** quando o processo-alvo possui permissões superiores. O `ptrace` está presente em práticamente todas as distribuições Linux e é frequentemente encontrado em ambientes de desenvolvimento e contêineres, o que dificulta o bloqueio indiscriminado da chamada. > **Técnica pai:** [[t1055-process-injection|T1055 - Process Injection]] > **Tática:** [[_defense-evasion|Defense Evasion]] · [[privilege-escalation|Privilege Escalation]] > **Plataformas:** Linux, macOS --- ## Como Funciona O fluxo de ataque via `ptrace` segue etapas bem definidas que exploram a semântica do kernel Linux: ### 1. Attach ao processo-alvo O adversário executa `ptrace(PTRACE_ATTACH, pid, ...)` para se conectar a um processo em execução. Isso envia um sinal `SIGSTOP` ao alvo, pausando sua execução. Essa operação exige que o processo atacante sejá pai do alvo **ou** possua a capability `CAP_SYS_PTRACE`. ### 2. Leitura do estado atual Com `PTRACE_GETREGS` o adversário obtém o contexto completo dos registradores (incluindo o ponteiro de instrução `RIP`/`EIP`). Com `PTRACE_PEEKDATA` lê o conteúdo atual da memória no endereço desejado. ### 3. Injeção do payload Duas abordagens principais: - **PTRACE_POKETEXT / PTRACE_POKEDATA** - sobrescreve palavras de memória (8 bytes por chamada) diretamente no endereço do próximo opcode a ser executado. O adversário substitui instruções legítimas pelo shellcode. - **PTRACE_SETREGS** - redireciona o ponteiro de instrução (`RIP`) para uma região já contendo shellcode previamente alocada (ex: via `malloc` dentro do processo-alvo usando `PTRACE_POKETEXT` para chamar a função). ### 4. Retomada da execução `ptrace(PTRACE_CONT, pid, ...)` retoma o processo, que agora executa o código injetado com a identidade e os privilégios do processo-alvo. ### 5. Restauração (opcional) Para manter a furtividade, o adversário pode restaurar os opcodes originais após a execução do payload - tornando o ataque transitório e difícil de detectar post-mortem. ### Limitações conhecidas - Processos com `PR_SET_DUMPABLE = 0` bloqueiam `ptrace` de processos não-raiz - Distribuições com `kernel.yama.ptrace_scope = 1` (ex: Ubuntu padrão) restringem attach somente a processos filhos - Processos com capabilities elevadas (`CAP_SYS_PTRACE` ausente) não conseguem atacar processos de outros usuários --- ## Attack Flow ```mermaid graph TB A([Adversário com acesso inicial]) --> B[Identifica processo-alvo privilegiado] B --> C{Verifica ptrace_scope} C -->|scope = 0 - sem restrição| D[PTRACE_ATTACH ao PID alvo] C -->|scope = 1 - somente filho| E[Cria processo filho do alvo via fork] E --> D D --> F[SIGSTOP - processo pausado] F --> G[PTRACE_GETREGS - lê registradores] G --> H[PTRACE_PEEKDATA - lê memória atual] H --> I{Método de injeção} I -->|Sobrescrita direta| J[PTRACE_POKETEXT - escreve shellcode no RIP] I -->|Redirecionamento| K[Aloca shellcode via malloc interno] K --> L[PTRACE_SETREGS - aponta RIP para shellcode] J --> M[PTRACE_CONT - retoma execução] L --> M M --> N([Código malicioso executa com identidade do processo-alvo]) N --> O[Acesso à memória / rede / privilégios do processo] O --> P{Persistência?} P -->|Sim| Q[Instala backdoor ou modifica binário em disco] P -->|Não - furtivo| R[Restaura opcodes originais] R --> S([Execução transitória - sem artefatos em disco]) style A fill:#c0392b,color:#fff style N fill:#e67e22,color:#fff style S fill:#27ae60,color:#fff style O fill:#8e44ad,color:#fff ``` --- ## Exemplos de Uso ### PACEMAKER (APT41 / UNC2165) O malware [[s1109-pacemaker|PACEMAKER]], documentado pelo Google Mandiant em operações do [[g0096-apt41|APT41]], utiliza `ptrace` para injetar código em processos de servidor web (`httpd`, `nginx`) em ambientes Linux. A técnica permite que o implante opere mascarado como um processo legítimo de servidor, dificultando a detecção por ferramentas de monitoramento de processos. ### Implantes de APTs em Servidores Linux Grupos como [[g0032-lazarus-group|Lazarus Group]] e operadores de [[ransomware]] em Linux (ex: variantes do [[blackcat|ALPHV]] para Linux/VMware ESXi) utilizam injeção via `ptrace` para elevar privilégios de um shell de usuário para contexto de processo de serviço, evitando acionamento de alertas de criação de processo privilegiado. ### Ferramentas de Red Team Frameworks como [[s0154-cobalt-strike|Cobalt Strike]] (via Beacon Linux), **Sliver** e **Metasploit** oferecem módulos de injeção via `ptrace` para operações de pós-exploração em ambientes Linux on-premises e cloud (VMs, contêineres com `--privileged`). ### Contêineres Privilegiados Em ambientes Kubernetes e Docker, contêineres executados com `--privileged` ou com a capability `SYS_PTRACE` habilitada tornam-se vetores críticos: o adversário pode usar `ptrace` para injetar código no processo do host visível pelo namespace do contêiner, realizando **container escape** via injeção de processo. --- ## Detecção ### Regra Sigma - Monitoramento de Chamadas ptrace Suspeitas ```yaml title: Suspicious ptrace System Call for Process Injection id: a1b2c3d4-e5f6-7890-abcd-ef1234567890 status: experimental description: > Detecta uso de ptrace com PTRACE_ATTACH, PTRACE_POKETEXT ou PTRACE_SETREGS em processos que não são depuradores legítimos conhecidos (gdb, strace, lldb). Pode indicar tentativa de injeção de código via T1055.008. references: - https://attack.mitre.org/techniques/T1055/008/ - https://man7.org/linux/man-pages/man2/ptrace.2.html author: RunkIntel daté: 2026-03-24 tags: - attack.defense_evasion - attack.privilege_escalation - attack.t1055.008 logsource: category: process_creation product: linux detection: selection_syscall: type: syscall syscall: ptrace a0|contains: - PTRACE_ATTACH - PTRACE_POKETEXT - PTRACE_POKEDATA - PTRACE_SETREGS filter_legitimate_debuggers: exe|endswith: - /usr/bin/gdb - /usr/bin/strace - /usr/bin/ltrace - /usr/bin/lldb - /usr/bin/valgrind condition: selection_syscall and not filter_legitimate_debuggers fields: - pid - ppid - exe - a0 - a1 falsepositives: - Ferramentas legítimas de debugging não listadas acima - CI/CD pipelines com suporte a depuração dinâmica level: high ``` ### Estrategias de Detecção Complementares | Método | Descrição | Ferramenta | |--------|-----------|------------| | Auditd | Monitorar syscall `ptrace` com `a0=PTRACE_ATTACH` | `auditd` + `auditctl` | | eBPF/Falco | Rastrear `ptrace_attach` para processos não-filhos | Falco, Tetragon | | /proc monitoring | Detectar mudanças em `/proc/<pid>/mem` por processo externo | inotify, osquery | | Análise de capabilities | Alertar quando processo comum tem `CAP_SYS_PTRACE` | seccomp profiles | | Behavior analytics | Correlacionar PTRACE_ATTACH + acesso a processo de serviço | SIEM (Splunk, Elastic) | --- ## Mitigação | ID | Mitigação | Descrição | Prioridade | |----|-----------|-----------|------------| | M1040 | [[m1040-behavior-prevention-on-endpoint\|M1040 - Behavior Prevention on Endpoint]] | Soluções EDR com suporte a Linux (CrowdStrike Falcon, SentinelOne) devem monitorar chamadas `ptrace` e bloquear quando provenientes de processos não-depuradores | Alta | | M1026 | [[m1026-privileged-account-management\|M1026 - Privileged Account Management]] | Restringir execução de processos com `CAP_SYS_PTRACE`; usar perfis seccomp para bloquear a syscall em contêineres de produção | Alta | | - | Kernel Hardening (`ptrace_scope`) | Configurar `kernel.yama.ptrace_scope = 2` ou `3` em servidores de produção para bloquear `ptrace` entre processos sem relação pai-filho | Crítica | | - | Seccomp Profiles | Aplicar perfis seccomp que bloqueiam `ptrace` em contêineres Docker/Kubernetes não-privilegiados | Alta | | - | AppArmor / SELinux | Políticas de MAC que impedem que processos comuns realizem `ptrace` em processos de serviços críticos | Média | ### Configuração recomendada de ptrace_scope ```bash # /etc/sysctl.d/99-ptrace-hardening.conf # 0 = sem restrição (padrão em alguns distros - NÃO recomendado em produção) # 1 = somente processos filhos (padrão Ubuntu) - mínimo aceitável # 2 = somente processos com CAP_SYS_PTRACE ou uid=0 # 3 = desabilitado para todos (recomendado em servidores de produção) kernel.yama.ptrace_scope = 2 ``` --- ## Contexto Brasil/LATAM O `ptrace` como vetor de injeção é especialmente relevante no contexto brasileiro e latino-americano pelos seguintes fatores: **Infraestrutura Linux subestimada:** Grande parte dos servidores de aplicação em bancos, fintechs e governo no Brasil roda Linux sem EDR adequado - historicamente, a maioria das soluções de segurança de endpoint no mercado LATAM tem foco em Windows. **APTs contra setor financeiro:** Grupos como [[g0032-lazarus-group|Lazarus Group]], com histórico de ataques a **SWIFT** e sistemas bancários no Brasil (operação [[operation-dream-job|Operation DreamJob]]), utilizam técnicas de injeção em processos Linux para comprometer servidores de transação e manter persistência furtiva. **Ambientes de contêiner mal configurados:** A adoção acelerada de Kubernetes no Brasil (especialmente em grandes bancos digitais e fintechs como Nubank, PicPay, Mercado Pago) sem implementação de seccomp profiles e sem revogação de `SYS_PTRACE` representa uma superfície de ataque crescente. **Red Teams locais:** Equipes de red team no Brasil relatam uso frequente de `ptrace` durante exercícios em clientes do setor financeiro e telecomúnicações, encontrando ambientes sem `auditd` habilitado ou com `ptrace_scope = 0` - configuração que permite injeção irrestrita entre processos. **Recomendação prioritária para o Brasil:** Auditar `kernel.yama.ptrace_scope` em todos os servidores Linux de produção e implementar Falco ou Tetragon para visibilidade de syscalls críticas em ambientes de contêiner. --- ## Referências - [MITRE ATT&CK - T1055.008](https://attack.mitre.org/techniques/T1055/008/) - [Linux man page - ptrace(2)](https://man7.org/linux/man-pages/man2/ptrace.2.html) - [Kernel Yama Security Module - ptrace_scope](https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html) - [Google Mandiant - PACEMAKER malware analysis](https://www.mandiant.com/resources/blog/apt41-us-state-governments) - [Falco - ptrace detection rules](https://falco.org/docs/reference/rules/) - [CISA - Securing Linux Systems](https://www.cisa.gov/resources-tools/resources/securing-linux-based-systems) **Técnicas relacionadas:** [[t1055-process-injection|T1055 - Process Injection]] · [[t1055-001-dynamic-link-library-injection|T1055.001 - DLL Injection]] · [[t1055-012-process-hollowing|T1055.012 - Process Hollowing]] · [[t1068-exploitation-for-privilege-escalation|T1068 - Exploitation for Privilege Escalation]] **Software associado:** [[s1109-pacemaker|PACEMAKER]] --- *Fonte: [MITRE ATT&CK - T1055.008](https://attack.mitre.org/techniques/T1055/008)*