Singularity: contornando a detecção de rootkits Linux no Elastic Defend via trusted_pids

Singularity: contornando a detecção de rootkits Linux no Elastic Defend via trusted_pids

O pesquisador 0xMatheuZ demonstrou como o rootkit LKM Singularity pode contornar várias camadas de detecção no Elastic Defend 9.5 — desde a varredura YARA de arquivos .ko até o monitoramento eBPF do carregamento de módulos. Em um ambiente de teste com Elastic Defend 9.5.2, 0 alertas foram gerados.

A parte mais interessante — contornando o eBPF O Elastic Defend monitora cargas de módulos do kernel através do programa eBPF tp_btf/module_load. Na versão 9.5, taint_flags foi adicionado ao evento: após a função init do módulo ser concluída, o Elastic lê mod->taints, e a regra Kernel Module Loaded with Tainting Flags é acionada quando o campo taint_flags está presente. No entanto, antes de coletar dados, o programa eBPF verifica o TGID do processo atual em um mapa hash interno: elastic_ebpf_events_trusted_pids Se o TGID for encontrado lá, o programa sai sem gerar um evento. O pesquisador usou esse comportamento como bypass: o loader localiza o mapa BPF necessário em tempo de execução e adiciona temporariamente seu próprio TGID antes de carregar o módulo via finit_module, depois o remove.

O resultado é a seguinte cadeia: Loader TGID → trusted_pids → finit_module → hook eBPF sai cedo → evento module_load não é criado → a regra do Elastic não é acionada Em outras palavras, não se trata apenas de ocultar taint_flags: o evento nunca chega ao sistema de detecção.

Outras camadas de detecção Contornar o eBPF sozinho não é suficiente. O Elastic também detectou o Singularity de outras formas: • O YARA detectou arquivos .ko por strings, nomes de funções e outros indicadores — o autor adicionou ofuscação de código-fonte, renomeando funções, arquivos e o módulo, e ocultando strings sensíveis; • uma regra syslog mais antiga capturava module verification failed ... tainting kernel — o rootkit filtra essa string; • a regra de criação de .ko respondia ao aparecimento de um objeto de kernel no disco — compilá-lo em /var/lib/dkms/, que está na lista de exclusão do Elastic, tornou possível evitar essa detecção; Além disso, o módulo se esconde de lsmod, /proc/modules e /sys/module/, e filtra seu nome do dmesg. No teste, combinar essas técnicas permitiu que o Singularity fosse carregado enquanto o Elastic Defend 9.5.2 estava em execução, sem gerar nenhum alerta.

O autor ainda não publicou o loader que implementa o bypass do trusted_pids.

Artigo: https://matheuzsecurity.github.io/hacking/elastic-trusted-pid-bypass/

Ferramenta: https://github.com/MatheuZSecurity/Singularity