Container Forensics: Enqueter sur les Compromissions Kubernetes

Trois heures du matin, alerte Falco: un pod du namespace payments lance /bin/sh apres avoir ouvert un socket reverse vers une IP egyptienne. L'equipe d'astreinte isole le node, mais la premiere question du CISO est brutale: 'vous avez des preuves qui survivent au kubectl delete pod ?'. Dans la majorite des clusters que Basilisk audite, la reponse honnete est non. Le container forensics sur Kubernetes exige une chaine de collecte qui commence avant l'incident, parce que le runtime recycle layers, cgroups et namespaces plus vite que n'importe quel analyste n'ouvre Wireshark.

La premiere couche de preuves vit dans le pod lui-meme, et elle est volatile par conception. Avant tout kubectl cordon, on marque le node avec un taint NoExecute personnalise, on snapshot le disque via CSI (sur EKS via snapshot EBS depuis la console, sur GKE gcloud compute disks snapshot fait l'affaire), et seulement ensuite on entre dans le container cible avec kubectl debug en utilisant une image ephemere contenant des binaires statiques busybox, lsof, ss et tcpdump. On capture /proc/[pid]/exe, /proc/[pid]/maps et le contenu de /tmp avant tout redemarrage. Qui a deja fait du DFIR sous Linux: Triage Vivant avec UAC et Velociraptor sur VM classique doit changer de mindset: ici le filesystem est overlay et la couche superieure disparait des que le pod meurt.

La memoire du container est le vrai tresor. Avec un runtime containerd ou CRI-O, le PID du processus dans le pod est visible sur l'hote, donc on lance avml --pid ou on utilise LiME compile contre le kernel du node pour produire un dump complet. Ce dump alimente directement le flux de Memory Forensics avec Volatility 3 : Analyser des Dumps en Lab Reproductible, ou les plugins linux.pslist et linux.malfind revelent des injections que l'EDR de l'hote n'a pas vues parce qu'elles etaient confinees au namespace du container. On documente chaque hash SHA-256 sur une chain of custody signee avec Sigstore, en lien direct avec la discipline decrite dans Supply Chain Security: Signature Sigstore et SBOM Reels en CI/CD.

En remontant la stack, le control plane est l'endroit ou l'enquete devient vraiment interessante. Le kube-apiserver avec audit policy au niveau RequestResponse enregistre chaque exec, attach et portforward en JSON structure. Sur un cas reel de 2025, on a recupere la preuve decisive: l'attaquant avait cree un ServiceAccount nomme 'monitoring-helper' avec cluster-admin via kubectl apply -f - heredoc; l'audit log montrait user-agent kubectl/v1.29.2 depuis une IP residentielle a 3h47. On a croise avec des snapshots etcd horaires (etcdctl snapshot save) pour reconstruire l'etat des Roles avant et apres. Ce type de timeline rejoint l'approche de Timeline Forensics sur Windows : Plaso, Log2Timeline et KAPE en Pratique, mais appliquee a des ressources declaratives.

Le runtime forensics demande un outillage specifique. On deploie Tetragon ou on garde Falco avec des regles personnalisees qui exportent vers un SIEM externe, jamais dans le cluster compromis. Pour la capture live, tracee-ebpf d'Aqua enregistre les syscalls avec contexte container_id, et sysdig inspect lit des fichiers scap comme des pcaps kernel. Attention aux faux negatifs: si l'attaquant a utilise des techniques adaptees de Evasion EDR pour la Recherche: Direct Syscalls Expliques sans Romance pour Linux, le hook seccomp par defaut ne verra rien. Combiner ca avec du hunting KQL ou Sigma, dans l'esprit de Threat Hunting avec Sigma et Elastic: De l'Indicateur a la Regle de Detection, multiplie les chances d'attraper le pivot.

Les images compromises meritent un chapitre dedie. Avant de detruire la moindre preuve, on fait docker save (ou skopeo copy) de l'image suspecte vers un registry forensique isole, puis on lance dive et trivy fs pour cartographier les layers ajoutees au runtime via kubectl cp ou docker exec. Dans 60% des cas observes, l'attaquant n'a pas modifie l'image originale; il a depose des binaires dans /tmp ou /dev/shm en pariant que personne ne snapshoterait l'overlay. Quand on suspecte une compromission upstream, on envoie les layers vers un lab Analyse de Malware en Lab Isole: Setup Securise avec FlareVM et REMnux adapte pour ELF, avec Remnux sur une VM air-gapped.

Le network forensics sur Kubernetes differe du reseau classique parce que le CNI fait du NAT et de l'encapsulation. On capture le trafic au niveau du veth pair du pod avec tcpdump -i any sur l'hote, filtre par l'IP du pod attribuee par l'IPAM. Si le cluster utilise Cilium, hubble observe --pod payments/checkout-7f4 affiche des flux L7 deja decodes. Pour un C2 persistant, on compare avec les IOC de notre lab Construire une Infra C2 avec Sliver en Lab Isole pour la Recherche Defensive et on inspecte le DNS sur CoreDNS via les query logs. On exporte toujours les pcap vers un stockage write-once, parce que les avocats adorent contester l'integrite.

Takeaway pratique: repete la procedure avant l'incident. Monte un cluster kind ou k3d, simule un attaquant avec un pod qui ouvre un reverse shell, et chronometre le temps entre l'alerte et le dump memoire signe. Si ca depasse 20 minutes, automatise avec un operator qui reagit aux evenements Falco en appliquant le taint, en declenchant le snapshot CSI et en lancant un job de collecte. Le forensics en container, ce n'est pas une affaire d'outils exotiques, c'est une choregraphie repetee avant que la scene ne s'embrase.