Container Forensics: Investigando Compromisos en Kubernetes
Como el equipo Basilisk recolecta evidencia en pods, runtime y control plane tras sospecha de incidente en clusters Kubernetes productivos.
Tres de la manana, alerta de Falco: un pod del namespace payments ejecuto /bin/sh tras abrir un socket reverso hacia una IP egipcia. El equipo de guardia aislo el nodo, pero la primera pregunta del CISO fue brutal: 'tienen evidencia que sobreviva al kubectl delete pod?'. En la mayoria de clusters que Basilisk audita, la respuesta honesta es no. Container forensics en Kubernetes exige una cadena de recoleccion que arranca antes del incidente, porque el runtime adora reciclar layers, cgroups y namespaces mas rapido de lo que cualquier analista logra abrir Wireshark.
La primera capa de evidencia vive en el propio pod, y es volatil por diseno. Antes de cualquier kubectl cordon, marcamos el nodo con un taint NoExecute personalizado, hacemos snapshot del disco via CSI (en EKS usamos snapshot EBS directo desde consola, en GKE gcloud compute disks snapshot resuelve), y solo entonces entramos al contenedor objetivo con kubectl debug usando una imagen ephemeral con binarios estaticos de busybox, lsof, ss y tcpdump. Capturamos /proc/[pid]/exe, /proc/[pid]/maps y el contenido de /tmp antes de cualquier reinicio. Quien ya hizo DFIR en Linux: Triaje en Vivo con UAC y Velociraptor en VM tradicional debe adaptar el mindset: aqui el filesystem es overlay y la capa superior desaparece cuando el pod muere.
La memoria del contenedor es el verdadero tesoro. En runtime containerd o CRI-O, el PID del proceso dentro del pod es visible en el host, entonces ejecutamos avml --pid
Subiendo el stack, el control plane es donde la investigacion se pone interesante. El kube-apiserver con audit policy nivel RequestResponse graba cada exec, attach y portforward en JSON estructurado. En un caso real de 2025, recuperamos la evidencia decisiva del atacante creando un ServiceAccount llamado 'monitoring-helper' con cluster-admin via kubectl apply -f - heredoc; el audit log mostro user-agent kubectl/v1.29.2 desde IP residencial a las 3:47am. Cruzamos con snapshots etcd horarios (etcdctl snapshot save) para reconstruir el estado de los Roles antes y despues. Este tipo de timeline conversa directamente con el enfoque de Timeline Forensics en Windows: Plaso, Log2Timeline y KAPE en la Practica, solo que aplicado a recursos declarativos.
Runtime forensics exige tooling especifico. Instalamos Tetragon o mantenemos Falco con reglas personalizadas exportando a un SIEM externo, nunca dentro del mismo cluster comprometido. Para captura en vivo, tracee-ebpf de Aqua graba syscalls con contexto de container_id, y sysdig inspect lee scap files como si fueran pcaps de kernel. Cuidado con falsos negativos: si el atacante uso tecnicas de Evasion de EDR para Investigacion: Direct Syscalls Explicados sin Romantizar adaptadas para Linux, el hook seccomp default no las atrapara. Combinar esto con hunting en KQL o Sigma, al estilo de Threat Hunting con Sigma y Elastic: Del Indicador a la Regla de Deteccion, multiplica la chance de pillar el pivote.
Las imagenes comprometidas merecen capitulo propio. Antes de destruir cualquier evidencia, hacemos docker save (o skopeo copy) de la imagen sospechosa hacia un registry forense aislado, despues corremos dive y trivy fs para mapear layers anadidas en runtime via kubectl cp o docker exec. En 60% de los casos que vimos, el atacante no altero la imagen original; dropeo binarios en /tmp o /dev/shm contando con que nadie snapshotearia el overlay. Cuando hay sospecha de compromiso upstream, mandamos las layers a un lab de Analisis de Malware en Lab Aislado: Setup Seguro con FlareVM y REMnux adaptado para ELF, con Remnux corriendo en VM sin red.
Network forensics en Kubernetes es distinto de red tradicional porque el CNI hace NAT y encapsulamiento. Capturamos trafico al nivel del veth pair del pod usando tcpdump -i any en el host, filtrado por IP del pod asignado por IPAM. Si el cluster usa Cilium, hubble observe --pod payments/checkout-7f4 muestra flujos L7 ya decodificados. Para C2 persistente, comparamos con IOCs de nuestro lab de Construyendo Infra de C2 con Sliver en Lab Aislado para Estudio Defensivo y revisamos DNS en CoreDNS via query log. Siempre exportamos pcap a storage write-once, porque los abogados aman reclamar integridad.
Takeaway practico: ensaya el procedimiento antes del incidente. Levanta un cluster kind o k3d, simula un atacante con un pod que abre reverse shell, y cronometra cuanto tarda tu equipo entre la alerta y el dump de memoria firmado. Si pasa de 20 minutos, automatiza con un operator que reaccione a eventos Falco aplicando taint, snapshot CSI y job de coleccion. Forensics en contenedores no es sobre herramientas exoticas, es sobre coreografia ensayada antes que el escenario se incendie.