Container Forensics: Investigando Comprometimentos em Kubernetes

Tres da manha, alerta do Falco: um pod do namespace payments executou /bin/sh apos abrir um socket reverso para um IP egipcio. O time de plantao isolou o no, mas a primeira pergunta do CISO foi brutal: 'voces tem evidencia que sobrevive ao kubectl delete pod?'. Na maioria dos clusters que a Basilisk audita, a resposta honesta e nao. Container forensics em Kubernetes exige uma cadeia de coleta que comeca antes do incidente, porque o runtime adora reciclar layers, cgroups e namespaces mais rapido do que qualquer analista consegue abrir o Wireshark.

A primeira camada de evidencia vive no proprio pod, e ela e volatil por design. Antes de qualquer kubectl cordon, marcamos o no com um taint NoExecute customizado, fazemos snapshot do disco via CSI (no EKS usamos EBS snapshot direto pelo console, no GKE o gcloud compute disks snapshot resolve), e so entao entramos no container alvo com kubectl debug usando uma imagem ephemeral contendo binarios estaticos de busybox, lsof, ss e tcpdump. Capturamos /proc/[pid]/exe, /proc/[pid]/maps e o conteudo de /tmp antes de qualquer reinicio. Quem ja fez DFIR no Linux: Triagem ao Vivo com UAC e Velociraptor em VM tradicional precisa adaptar o mindset: aqui o filesystem e overlay e a camada superior some quando o pod morre.

Memoria do container e o tesouro real. Em runtime containerd ou CRI-O, o PID do processo dentro do pod e visivel no host, entao rodamos avml --pid ou usamos LiME compilado contra o kernel do node para extrair um dump completo. Esse dump entra direto no fluxo de Memory Forensics com Volatility 3: Analisando Dumps em Lab Reproduzivel, onde plugins como linux.pslist e linux.malfind revelam injecoes que o EDR no host nao viu porque estavam confinadas ao namespace do container. Documentamos cada hash SHA-256 em uma planilha de chain of custody assinada com Sigstore, conectando com a disciplina que descrevemos em Supply Chain Security: Assinatura com Sigstore e SBOM Real em CI/CD.

Subindo a stack, o control plane e onde a investigacao realmente fica interessante. O kube-apiserver com audit policy em nivel RequestResponse grava cada exec, attach e portforward em JSON estruturado. Em um caso real de 2025, recuperamos a evidencia decisiva do atacante criando um ServiceAccount chamado 'monitoring-helper' com cluster-admin via kubectl apply -f - heredoc; o audit log mostrou o user-agent kubectl/v1.29.2 vindo de um IP residencial as 3h47. Cruzamos com etcd snapshots horarios (etcdctl snapshot save) para reconstruir o estado dos Roles antes e depois. Esse tipo de timeline conversa diretamente com a abordagem de Timeline Forensics no Windows: Plaso, Log2Timeline e KAPE na Pratica, so que aplicada a recursos declarativos.

Runtime forensics exige ferramental especifico. Instalamos Tetragon ou mantemos o Falco com regras customizadas exportando para um SIEM externo, nunca para dentro do mesmo cluster comprometido. Para captura ao vivo, o tracee-ebpf da Aqua grava syscalls com contexto de container_id, e o sysdig inspect le scap files como se fossem pcaps de kernel. Cuidado com falsos negativos: se o atacante usou tecnicas de Evasao de EDR para Pesquisa: Direct Syscalls Explicados sem Romantizacao adaptadas para Linux, o hook de seccomp default nao vai pegar. Combinar isso com hunting em KQL ou Sigma, no estilo de Threat Hunting com Sigma e Elastic: Do Indicador a Regra de Deteccao, multiplica a chance de pegar o pivot.

Imagens comprometidas merecem capitulo proprio. Antes de destruir qualquer evidencia, fazemos docker save (ou skopeo copy) da imagem suspeita para um registry forense isolado, depois rodamos dive e trivy fs para mapear layers adicionadas em runtime via kubectl cp ou docker exec. Em 60% dos casos que vimos, o atacante nao alterou a imagem original; ele dropou binarios em /tmp ou /dev/shm contando que ninguem snapshotaria o overlay. Quando ha suspeita de comprometimento upstream, encaminhamos as layers para um lab de Analise de Malware em Lab Isolado: Setup Seguro com FlareVM e Remnux adaptado para ELF, com Remnux rodando em VM sem rede.

Network forensics em Kubernetes e diferente de rede tradicional porque o CNI faz NAT e encapsulamento. Capturamos trafego no nivel do veth pair do pod usando tcpdump -i any no host, filtrado pelo IP do pod alocado pelo IPAM. Se o cluster usa Cilium, o hubble observe --pod payments/checkout-7f4 mostra fluxos L7 ja decodificados. Para C2 persistente, comparamos com IOCs do nosso lab de Construindo Infra de C2 com Sliver em Lab Isolado para Estudo Defensivo e checamos DNS no CoreDNS via query log. Sempre exportamos pcap para storage write-once, porque advogados adoram reclamar de integridade.

Takeaway pratico: ensaie o procedimento antes do incidente. Monte um cluster kind ou k3d, simule um atacante com um pod que abre reverse shell, e cronometre quanto tempo seu time leva entre o alerta e o dump de memoria assinado. Se passar de 20 minutos, automatize com um operator que reage a eventos do Falco aplicando taint, snapshot CSI e job de coleta. Forensics em containers nao e sobre ferramentas exoticas, e sobre coreografia ensaiada antes do palco pegar fogo.