ZAPPER: OCULTANDO PROCESSOS MALICIOSOS NO LINUX COM PTRACE

Por que processos visiveis entregam um invasor

Quanto mais experiente e um atacante, mais dificil e detecta-lo. Iniciantes sao ruidosos: deixam processos rodando com nome, argumentos e variaveis de ambiente a mostra, e qualquer administrador que rode ps aux encontra o scanner, o minerador ou o reverse shell. A deteccao de ameacas em Linux comeca exatamente ai – na listagem de processos.

O Zapper e uma ferramenta criada pelo grupo The Hacker’s Choice (THC) para atacar essa premissa. Diferente de metodos grosseiros de ocultacao, ele funciona de verdade: apaga a linha de comando e as variaveis de ambiente de um processo em execucao – inclusive o que aparece em /proc//environ – sem depender de LD_PRELOAD ou de truques com libc. O binario estatico pode ser renomeado e nao exige privilegios de root. Ja ha relatos de uso real por atacantes para disfarcar processos de longa duracao como atividades legitimas do sistema.

Como o Zapper funciona: ptrace e o ELF Auxiliary Vector

O mecanismo e o diferencial da ferramenta. Quando o kernel do Linux entrega os argumentos de um novo programa durante a execução de execve(), o Zapper intercepta esse momento via ptrace(), move as opcoes originais da linha de comando para um novo endereco de memoria e destrroi a localizacao antiga. Em seguida, corrige os ponteiros na tabela auxiliar ELF (Elf Auxiliary Vector) do programa e devolve a execucao ao processo alvo. Da perspectiva do kernel – e de qualquer ferramenta de listagem como o procps – as opcoes de comando simplesmente deixam de existir.

O rastreamento continua: cada chamada posterior a fork() ou execve() do programa alvo recebe o mesmo tratamento, o que oculta tambem os processos filhos. Como o Zapper monitora apenas eventos de execve() e fork() – e nao todos os syscalls – o impacto de performance e de cerca de 0,01%, imperceptivel na pratica.

O recurso -n merece nota: ele permite iniciar o programa sob um PID escolhido. O kernel atribui PIDs em sequencia ate o limite de 4.194.304 (2^22) e depois reinicia a contagem; o Zapper itera pelos PIDs disponiveis em poucos segundos ate encontrar o anterior ao desejado, usando chamadas clone() que entram direto em exit() com CLONE_VM – a forma mais rapida de consumir PIDs.

Instalacao: obtendo o binario do repositorio oficial

O caminho canônico e o download direto da release oficial no GitHub do projeto, ja compilado para a arquitetura correta via uname -m.

O comando abaixo baixa o binario, aplica permissao de execucao e abre o menu de ajuda:

curl -fL -o zapper https://github.com/hackerschoice/zapper/releases/latest/download/zapper-linux-$(uname -m) && chmod 755 zapper && ./zapper -h

A opcao -f do curl faz falhar silenciosamente em erro HTTP em vez de gravar um HTML de erro como se fosse o binario; -L segue redirecionamentos. O chmod 755 concede execucao ao dono e ao grupo. Nenhuma instalacao de pacote e necessaria – e um binario estatico, que tambem pode ser compilado a partir do fonte com make.

Renomear o binario: por que nome de arquivo nao e deteccao

Defensores monitoram trafego e palavras-chave; baixar um arquivo chamado zapper deixa rastro. A recomendacao da propria demonstracao e renomear a ferramenta e hospeda-la na infraestrutura do atacante – o binario estatico aceita qualquer nome:

mv zapper systemd-control

O nome escolhido na demonstracao, systemd-control, imita um componente do sistema. Em muitas distribuicoes os componentes do systemd ficam em /lib/systemd; mover o arquivo renomeado para la e ajustar timestamps (por exemplo com touch -r /etc/passwd) torna a descoberta por listagem dependente de monitoring dedicado ao diretorio. O ponto defensivo e direto: deteccao baseada apenas em nome de arquivo nao basta, porque o atacante escolhe o nome. E exatamente o comportamento mapeado no MITRE ATT&CK como Masquerading: Match Legitimate Resource Name or Location (T1036.005) – colocar um binario malicioso com nome e local que parecem legitimos.

O menu de ajuda e as formas de uso

O menu de ajuda traz exemplos e formas criativas de uso:

./systemd-control -h

Entre as capacidades listadas estao: ocultar binarios junto com seus processos filhos (-f), criar sessoes tmux ocultas para manter persistencia em um servidor sem aparecer em listagens de processos, e deixar o nome do programa exposto mas apagar todos os argumentos da linha de comando – o processo parece generico. A combinacao -f (ocultar filhos) com -a (assumir um nome escolhido) e o padrao mais eficaz.

Demonstracao: um nmap invisivel na lista de processos

Para a demonstracao, a ferramenta esconde um scan do nmap com todos os seus argumentos, disfarcado como thread de kernel:

exec ./systemd-control -f -a '[kworker/2:2-events_power_efficient]' nmap <IP-DO-ALVO> -Pn -sV -sC > /dev/shm/scan.txt &

O exec substitui o shell atual pelo Zapper, que por sua vez inicia o nmap; -f estende a ocultacao aos processos filhos; -a define o nome exibido como [kworker/2:2-events_power_efficient], um thread de kernel – a maioria dos administradores passa direto por esse tipo de entrada. O redirecionamento para /dev/shm/scan.txt grava o resultado em memoria (sistema de arquivos tmpfs, apagado no reboot).

Enquanto o scan roda, a verificacao padrao do defensor nao encontra nada:

ps aux | grep nmap
# nenhum nmap no ps
cat /dev/shm/scan.txt

O grep retorna vazio: nao ha processo com nome nmap na listagem. O resultado completo do scan, porem, esta gravado em /dev/shm/scan.txt – a prova de que a varredura executou de ponta a ponta sem nunca aparecer no ps.

O que a ocultacao de processos significa para o defensor

A conclusao da demonstracao e desconfortavel: um scan nmap completo, com todos os argumentos, rodou em uma maquina e ps nao viu nada. Para o defensor, isso significa que a listagem de processos nao e mais uma evidencia confiavel sozinha.

Em um pentest, a ferramenta serve para emular uma ameaca realista e testar se o time de defesa consegue detecta-la – o uso construtivo e obvio: melhor descobrir a cegueira em um exercicio autorizado do que durante um incidente real.

Perspectiva defensiva

Se a listagem de processos pode ser manipulada, a deteccao precisa se apoiar em outras camadas: telemetria de auditd/eBPF no kernel, monitoramento de chamadas ptrace() sobre processos que nao sao depuradores (o mecanismo do Zapper deixa esse rastro), verificacao de integridade de binarios em diretorios de sistema via AIDE, e correlacao de rede – o scan oculto ainda gera trafego visivel no firewall e no IDS, ainda que o processo nao apareca no ps. Binarios estaticos renomeados em /lib/systemd com timestamps manipulados pedem baseline de integridade de arquivos, nao varredura por nome. No plano de ameacas, o comportamento corresponde a Masquerading (T1036.005) e, quando o objetivo e impedir a observacao defensiva, a Impair Defenses (T1562/004).

Limitacoes

Artigo documental: descreve a ferramenta e o percurso conforme o repositorio oficial do projeto e a demonstracao de referencia, sem execucao propria nesta ocasiao. O Zapper nao oculta trafego de rede nem conexoes – esconde o processo, nao os pacotes; solucoes de monitoramento baseadas no kernel e no syscall tracing estao fora do alcance da manipulacao da tabela auxiliar ELF. Alem disso, o mecanismo depende de ptrace(): processos monitorados ou ambientes restritos podem limitar a tecnica.

Conclusao

O Zapper condensa em um binario estatico renomeavel a capacidade de apagar argumentos e ambiente de um processo em execucao, disfarca-lo como thread de kernel e estender a ocultacao aos filhos – tudo sem root e sem LD_PRELOAD, via manipulacao da tabela auxiliar ELF com ptrace(). A popularidade rapida e justificada: e a resposta pratica ao fato de que boa parte da deteccao em Linux ainda depende do que ps mostra. Para o defensor, o aprendizado e duplo – nao confiar em nome de processo como evidencia e fechar as brechas de deteccao com telemetria de kernel e integridade de arquivos. Em laboratorio proprio ou em pentest autorizado, e uma das melhores formas de medir se sua defesa enxerga o que o ps nao ve.