t1036-009-break-process-trees

# T1036.009 - Break Process Trees ## Descrição **Break Process Trees** é uma subtécnica de [[t1036-masquerading|T1036 - Masquerading]] em que adversários manipulam a relação pai-filho entre processos do sistema operacional para ocultar processos maliciosos de ferramentas de detecção e resposta que dependem de análise de árvore de processos (process tree analysis). Em sistemas Unix-like (Linux, macOS), toda execução de processo cria uma hierarquia: um processo pai (`parent process`) invoca um processo filho (`child process`). Ferramentas de segurança como EDRs, SIEMs e utilitários forenses como `pstree`, `htop` e `ps aux --forest` utilizam essa hierarquia para identificar comportamentos anômalos - por exemplo, `sshd` gerando um filho `bash` que executa `curl` é um padrão de ataque reconhecível. A técnica de Break Process Trees elimina esse contexto de forma intencional. O método mais comum em Linux utiliza a sequência `fork() → fork() → exit()` no processo intermediário: o neto do processo original é adotado pelo `init` (PID 1) ou pelo `systemd`, tornando-se um processo órfão sem vínculo rastreável com o payload original. Ferramentas de detecção que monitoram exclusivamente relações pai-filho perdem a cadeia de contexto necessária para triagem. Em macOS, variações incluem o uso de `launchd` como pai intermediário e chamadas `posix_spawn` com flags que modificam o relacionamento de processo. No Linux, a chamada `daemon()` da glibc automatiza a dupla bifurcação e a desconexão do terminal controlador. > **Técnica pai:** [[t1036-masquerading|T1036 - Masquerading]] > **Tática principal:** Defense Evasion > **Plataformas:** Linux, macOS --- ## Como Funciona ### Mecanismo de Dupla Bifurcação (Double Fork) A técnica se baseia em um padrão clássico de programação Unix para daemonizar processos, redirecionado para fins maliciosos: **Etapa 1 - Fork inicial:** O processo malicioso chama `fork()`, criando um processo filho (Filho 1). O processo pai original pode então terminar (`exit()`), ou continuar normalmente para criar aparência de legitimidade. **Etapa 2 - Segundo fork:** Filho 1 chama `fork()` novamente, criando Filho 2 (o neto do processo original). Filho 1 então termina (`exit()`). **Etapa 3 - Adoção por init/systemd:** Quando um processo pai termina antes de seus filhos, o kernel reparenta os filhos órfãos para o processo `init` (PID 1 - `systemd` em sistemas modernos). Filho 2 agora aparece com `ppid=1` - indistinguível de qualquer serviço do sistema. **Etapa 4 - Execução do payload:** Filho 2 executa o payload malicioso com `ppid=1`, eliminando qualquer rastreamento para o processo original que o iniciou. ### Chamada `daemon()` A função `daemon(nochdir, noclose)` da glibc implementa automaticamente a dupla bifurcação, fecha descritores de arquivo, e opcionalmente muda o diretório para `/`. Adversários usam essa chamada para daemonizar malware com uma única linha de código, obtendo o mesmo efeito de desconexão de árvore. ### Variações Observadas **Uso de `setsid()`:** Adversários podem chamar `setsid()` para criar uma nova sessão sem terminal controlador, desvinculando o processo do grupo de sessão original. Embora não quebre o `ppid`, elimina contexto de sessão útil para análise forense. **Namespace manipulation:** Em ambientes de contêineres (Docker, Kubernetes), adversários podem criar novos namespaces PID via `unshare(CLONE_NEWPID)` para que o processo malicioso apareça com PID 1 dentro de seu próprio namespace, dificultando correlação com o namespace do host. **`posix_spawn` com flags de reparentamento (macOS):** No macOS, adversários podem usar `posix_spawn` com atributos que configuram o novo processo para ser adotado pelo `launchd` diretamente, produzindo efeito similar ao double-fork em Linux. --- ## Attack Flow ```mermaid graph TB A["Execução Inicial (payload entregue via phishing / exploit / C2)"] --> B["Processo malicioso iniciado com PPID do processo legítimo (ex: sshd, bash, python)"] subgraph BREAK["Quebra da Árvore de Processos"] B --> C["fork() - cria Filho 1 PPID = processo original"] C --> D["Filho 1: fork() novamente cria Filho 2 (Neto)"] D --> E["Filho 1: exit() Processo intermediário encerrado"] E --> F["Filho 2 reparentado pelo kernel para PID 1 (init / systemd)"] end subgraph DETECCAO["Visibilidade da Ferramenta de Detecção"] G["EDR/SIEM detecta cadeia: sshd → bash → payload"] H["Após double-fork: processo aparece como filho de PID 1 Sem contexto malicioso"] G --> I["ALERTA gerado (relação suspeita detectada)"] H --> J["SEM ALERTA (processo parece daemon legítimo)"] end B --> G F --> H subgraph C2["Operação Pós-Evasão"] F --> K["Payload executa sem rastreamento para processo de origem"] K --> L["Comúnicação C2 estabelecida como daemon do sistema"] end style BREAK fill:#1a1a2e,stroke:#e94560,color:#fff style DETECCAO fill:#16213e,stroke:#f39c12,color:#fff style C2 fill:#0f3460,stroke:#27ae60,color:#fff style F fill:#e94560,color:#fff style J fill:#c0392b,color:#fff style I fill:#27ae60,color:#fff ``` --- ## Exemplos de Uso ### BPFDoor (China-nexus, telecomúnicações e governo) [[s1161-bpfdoor|BPFDoor]] é o exemplo mais documentado de Break Process Trees em uso operacional. O backdoor Linux, atribuído a um grupo com nexo chinês e descoberto pela Trend Micro em 2022, utiliza a chamada `daemon()` da glibc para desconectar completamente da árvore de processos original após execução. O processo resultante aparece com `ppid=1` e geralmente adota um nome de processo que imita daemons legítimos (`/sbin/udevd`, `/usr/sbin/rsyslogd`). O BPFDoor combina essa técnica com [[t1205-001-port-knocking|T1205.001 - Port Knocking]] via filtros BPF para criar um dos backdoors mais furtivos já documentados em produção. Vítimas confirmadas incluem organizações de telecomúnicações e governo no Oriente Médio e Ásia, com o mesmo modelo de ataque sendo considerado replicável em infraestrutura LATAM. ### Aplicação em Rootkits LKM Rootkits de kernel como [[s1219-reptile|REPTILE]] combinam Break Process Trees com ocultação de PID no kernel - o processo malicioso não apenas aparece com `ppid=1`, como também é removido das listagens `/proc`, tornando-o invisível para ferramentas userspace como `ps`, `top` e `lsof`. A combinação torna o processo detectável apenas via análise direta da estrutura do kernel ou por ferramentas baseadas em eBPF que operam no mesmo nível de privilégio. ### Scripts de Pós-Exploração (Red Team / Pentest) A técnica é amplamente utilizada em frameworks de red team e ferramentas de pós-exploração como: - **Metasploit** - sessões Meterpreter em Linux utilizam migração de processo que pode incluir reparentamento via `fork/exec` para persistir em processos de longa duração - **Cobalt Strike** (Linux beacons) - suporta `fork and run` como padrão para operações pós-exploração, executando tarefas em processos filho que terminam sem deixar rastro na árvore - Scripts Python/Bash ad-hoc que implementam double-fork como primeiro passo após entrega de payload --- ## Detecção A detecção eficaz de Break Process Trees requer visibilidade além das relações pai-filho estáticas. Ferramentas baseadas em eBPF, auditd e análise comportamental de sessão são mais eficazes do que análise de árvore de processos convencional. ### Regra Sigma - Processo Adotado por PID 1 com Comportamento Suspeito ```yaml title: Processo com PPID=1 Exibindo Comportamento de Rede ou Escrita Suspeitos id: e2b7f4c9-5a3d-4e8b-b9c2-3f6a1d8e4b7c status: experimental description: > Detecta processos cujo pai é PID 1 (init/systemd) que realizam conexões de rede de saída, escrita em arquivos suspeitos ou execução de comandos de shell - padrão consistente com double-fork daemonization por malware. references: - https://attack.mitre.org/techniques/T1036/009/ author: RunkIntel daté: 2026-03-25 tags: - attack.defense_evasion - attack.t1036.009 logsource: product: linux category: network_connection detection: selection: ParentProcessId: 1 Initiated: "true" filter_legit_daemons: Image|endswith: - "/sshd" - "/crond" - "/rsyslogd" - "/NetworkManager" - "/systemd-networkd" - "/dockerd" - "/kubelet" condition: selection and not filter_legit_daemons falsepositives: - Daemons de sistema legítimos que estabelecem conexões de rede - Serviços de monitoramento iniciados via systemd level: medium ``` ### Regra Sigma - Sequência fork/fork/exit via Auditd ```yaml title: Sequência de Double Fork Detectada via Auditd Syscall id: f1c9e3b8-7d2a-4f6c-c3b1-9e4d2f7c1a8e status: experimental description: > Detecta padrão de double fork (fork → fork → exit do processo intermediário) via monitoramento de syscalls com auditd. Indicativo de tentativa de daemonização maliciosa para quebra de árvore de processos. references: - https://attack.mitre.org/techniques/T1036/009/ author: RunkIntel daté: 2026-03-25 tags: - attack.defense_evasion - attack.t1036.009 logsource: product: linux service: auditd detection: selection_fork: type: SYSCALL syscall: - clone - fork - vfork selection_exit: type: SYSCALL syscall: exit_group ppid|same_as: selection_fork.pid timeframe: 2s condition: selection_fork | count() by ppid > 1 and selection_exit falsepositives: - Daemons legítimos que usam a função daemon() da glibc - Processos de serviço que bifurcam workers level: low ``` ### Regra Sigma - Uso Direto da Chamada daemon() via strace/ltrace ```yaml title: Chamada daemon() por Processo Não-Privilegiado id: a8d3f2c7-4b9e-5f1a-d7c4-8e2b3a6f9c1d status: experimental description: > Detecta chamada à função daemon() da glibc por processos fora de diretórios de binários de sistema, indicativo de malware que implementa double-fork via wrapper de alto nível. references: - https://attack.mitre.org/techniques/T1036/009/ author: RunkIntel daté: 2026-03-25 tags: - attack.defense_evasion - attack.t1036.009 logsource: product: linux category: process_creation detection: selection: type: SYSCALL syscall: prctl a0: "4" # PR_SET_NAME - comumente chamado após daemon() para renomear processo filter_system: exe|startswith: - "/usr/sbin/" - "/usr/lib/systemd/" - "/lib/systemd/" - "/sbin/" condition: selection and not filter_system falsepositives: - Aplicações de usuário que legitimamente se daemonizam level: medium ``` ### Estrategias de Detecção Complementares | Método | Ferramenta | Eficácia | |--------|-----------|---------| | Monitoramento de `ppid=1` com comportamento anômalo | auditd + SIEM | Alta - combinado com análise comportamental | | Rastreamento de sessão via `sessionid` (independente de ppid) | auditd `ses` field | Alta - sessão não muda com reparentamento | | eBPF tracing com Falco ou Tetragon | Falco / Cilium Tetragon | Muito alta - opera no kernel, difícil de evadir | | Baseline de processos com `ppid=1` por host | EDR + CMDB | Média - requer manutenção de baseline | | Correlação de `loginuid` imutável via auditd | auditd | Alta - `loginuid` persiste mesmo após reparentamento | **Chave de detecção:** O campo `loginuid` em auditd é definido no login do usuário e persiste em todos os processos filhos, mesmo após reparentamento por `init`. Um processo com `ppid=1` mas `loginuid` diferente de `-1` indica que foi reparentado artificialmente e merece investigação. --- ## Mitigação A subtécnica T1036.009 é particularmente difícil de mitigar sem impactar funcionalidades legítimas, pois a dupla bifurcação é um padrão de programação Unix válido. A estratégia de defesa foca em detecção e contenção. | Mitigação | Implementação | Prioridade | |-----------|--------------|-----------| | Habilitar auditd com regras de syscall | `auditctl -a always,exit -F arch=b64 -S clone,fork,vfork -k process_fork` | Alta | | Usar `loginuid` para rastreamento imutável de sessão | Configurar auditd para incluir `auid` em todos os eventos | Alta | | Implantar Falco ou Tetragon para rastreamento eBPF | Regras para processos `ppid=1` com comportamento de rede | Alta | | Segmentação via namespaces Linux | Containers com seccomp profiles restringindo `clone` flags | Média | | Baseline de processos legítimos com `ppid=1` | CMDB + EDR para alertar sobre novos processos fora do baseline | Média | | HIDS com integridade de binários | AIDE, Tripwire - detecta novos executáveis criados por processos daemonizados | Média | --- ## Contexto Brasil/LATAM A técnica de Break Process Trees é especialmente relevante no contexto de infraestrutura crítica brasileira porque a maioria dos servidores Linux em provedores de serviço e telecomúnicações no Brasil opera com configuração mínima de auditoria - sem auditd adequado, sem Falco, e com EDR frequentemente ausente ou focado apenas em Windows. **Relevância de BPFDoor no Brasil:** [[s1161-bpfdoor|BPFDoor]] representa o cenário de ameaça mais imediato: backdoor Linux extremamente furtivo que combina Break Process Trees com port knocking BPF, projetado exatamente para ambientes com pouca visibilidade de rede e processos. Provedores de telecomúnicações, ISPs regionais e operadoras de energia no Brasil compartilham as características de infraestrutura que tornaram as vítimas documentadas vulneráveis. **Ambientes de contêiner em risco:** Com a crescente adoção de Kubernetes e Docker no Brasil - especialmente em fintechs, govtech e telecomúnicações - variações da técnica que utilizam namespace manipulation (`unshare(CLONE_NEWPID)`) são relevantes. Containeres sem seccomp profiles restritivos permitem que adversários criem namespaces PID privados, tornando o processo malicioso ainda mais difícil de correlacionar com o host. **Ausência de ferramentas adequadas:** A maioria das equipes de SOC no Brasil opera com SIEM focado em logs Windows e eventos de autenticação. Logs de syscall Linux (auditd) raramente são ingeridos ou correlacionados. Esta lacuna torna a detecção de T1036.009 práticamente nula sem investimento específico em telemetria Linux. **Recomendações imediatas:** 1. Habilitar auditd em todos os servidores Linux com regras mínimas de fork/exec e conexões de rede 2. Implementar Falco com regra de alerta para processos com `ppid=1` realizando conexões de rede de saída 3. Correlacionar `loginuid` em logs auditd para rastrear origem de processos além da relação pai-filho 4. Inventariar periodicamente processos com `ppid=1` via `ps -eo pid,ppid,comm,args | awk '$2==1'` e comparar com baseline --- ## Técnicas Relacionadas - [[t1036-masquerading|T1036 - Masquerading]] (técnica pai) - [[t1205-001-port-knocking|T1205.001 - Port Knocking]] (frequentemente combinada - BPFDoor) - [[t1106-native-api|T1106 - Native API]] (fork, daemon, setsid - chamadas de sistema usadas) - [[t1543-create-or-modify-system-process|T1543 - Creaté or Modify System Process]] (persistência do daemon resultante) - [[t1055-process-injection|T1055 - Process Injection]] (frequentemente passo seguinte após break de árvore) - [[t1036-005-masquerade-task-service|T1036.005 - Match Legitimaté Name or Location]] (combinado para renomear processo filho) - [[t1564-004-ntfs-file-attributes|T1564.004 - NTFS File Attributes]] (técnica de evasão relacionada em Windows) --- ## Referências - [MITRE ATT&CK - T1036.009](https://attack.mitre.org/techniques/T1036/009/) - [Trend Micro - BPFDoor: An Evasive Linux Backdoor Leveraging BPF (2022)](https://www.trendmicro.com/en_us/research/22/e/network-evasion-bpfdoor-an-evasive-linux-backdoor.html) - [The Linux Programming Interface - Stevens & Rago: UNIX Network Programming](https://man7.org/tlpi/) - [Linux man page - daemon(3)](https://man7.org/linux/man-pages/man3/daemon.3.html) - [Falco Rules - Process Spawned in Pod (similar pattern)](https://falco.org/docs/rules/) - [auditd - Tracking loginuid across process reparenting](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/auditing-the-system_security-hardening)