Container Forensics: Kubernetes-Kompromittierungen Professionell Untersuchen

Drei Uhr morgens, Falco-Alarm: ein Pod im payments-Namespace startet /bin/sh, nachdem er einen Reverse-Socket zu einer agyptischen IP geoffnet hat. Das Bereitschaftsteam cordont den Node, doch die erste Frage des CISO ist brutal: 'habt ihr Beweise, die ein kubectl delete pod uberleben?'. In den meisten Clustern, die Basilisk auditiert, lautet die ehrliche Antwort nein. Container Forensics in Kubernetes erfordert eine Sammelkette, die vor dem Vorfall beginnt, denn die Runtime recycelt Layers, Cgroups und Namespaces schneller, als irgendein Analyst Wireshark offnen kann.

Die erste Beweisschicht lebt im Pod selbst, und sie ist volatil by design. Vor jedem kubectl cordon markieren wir den Node mit einem benutzerdefinierten NoExecute-Taint, erstellen ein Disk-Snapshot via CSI (auf EKS losen wir EBS-Snapshot uber die Konsole aus, auf GKE erledigt das gcloud compute disks snapshot), und erst dann betreten wir den Ziel-Container mit kubectl debug uber ein ephemeral Image mit statischen Binaries von busybox, lsof, ss und tcpdump. Wir sichern /proc/[pid]/exe, /proc/[pid]/maps und den Inhalt von /tmp vor jedem Neustart. Wer schon DFIR unter Linux: Live-Triage mit UAC und Velociraptor auf klassischen VMs gemacht hat, muss umdenken: hier ist das Filesystem ein Overlay und die oberste Schicht verschwindet, sobald der Pod stirbt.

Der Container-Speicher ist der eigentliche Schatz. Bei containerd- oder CRI-O-Runtime ist die PID des Prozesses im Pod auf dem Host sichtbar, also fuhren wir avml --pid aus oder verwenden LiME, kompiliert gegen den Node-Kernel, um einen Vollspeicher-Dump zu erzeugen. Dieser Dump flieSSt direkt in den Workflow aus Memory Forensics mit Volatility 3: Dumps im Reproduzierbaren Lab Analysieren, wo Plugins wie linux.pslist und linux.malfind Injections aufdecken, die das EDR auf dem Host nicht sah, weil sie im Container-Namespace eingesperrt waren. Wir dokumentieren jeden SHA-256-Hash in einer Chain-of-Custody-Liste, signiert mit Sigstore, was an die Disziplin aus Supply Chain Security: Sigstore-Signatur und echte SBOMs in CI/CD anknupft.

Weiter oben im Stack wird die Untersuchung im Control Plane richtig spannend. Der kube-apiserver mit Audit-Policy auf RequestResponse-Level protokolliert jedes exec, attach und portforward als strukturiertes JSON. In einem realen Fall aus 2025 sicherten wir das entscheidende Beweisstuck: der Angreifer legte einen ServiceAccount namens 'monitoring-helper' mit cluster-admin via kubectl apply -f - heredoc an; das Audit-Log zeigte User-Agent kubectl/v1.29.2 von einer Wohn-IP um 3:47 Uhr. Wir korrelierten mit stundlichen etcd-Snapshots (etcdctl snapshot save), um den Role-Zustand vor und nach dem Vorfall zu rekonstruieren. Diese Timeline-Arbeit deckt sich mit dem Ansatz aus Timeline Forensics unter Windows: Plaso, Log2Timeline und KAPE in der Praxis, nur angewandt auf deklarative Ressourcen.

Runtime Forensics verlangt spezielles Werkzeug. Wir deployen Tetragon oder behalten Falco mit eigenen Regeln, die in ein externes SIEM exportieren, niemals in denselben kompromittierten Cluster. Fur Live-Capture zeichnet Aquas tracee-ebpf Syscalls mit container_id-Kontext auf, und sysdig inspect liest scap-Dateien wie Kernel-pcaps. Vorsicht vor False Negatives: hat der Angreifer Techniken aus EDR-Umgehung fur Forschung: Direct Syscalls Erklart ohne Romantik auf Linux adaptiert, erkennt der Standard-seccomp-Hook nichts. Kombiniert mit KQL- oder Sigma-Hunting im Stil von Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel vervielfacht sich die Chance, den Pivot zu fassen.

Kompromittierte Images verdienen ein eigenes Kapitel. Bevor irgendetwas zerstort wird, machen wir docker save (oder skopeo copy) vom verdachtigen Image in eine isolierte Forensik-Registry, danach laufen dive und trivy fs, um zur Laufzeit per kubectl cp oder docker exec hinzugefugte Layers zu kartieren. In 60% der von uns gesehenen Falle veranderte der Angreifer das Original-Image nicht; er warf Binaries in /tmp oder /dev/shm und wettete darauf, dass niemand das Overlay snapshotet. Bei Verdacht auf Upstream-Kompromittierung schicken wir Layers in ein ELF-angepasstes Malware-Analyse im Isolierten Lab: Sicheres Setup mit FlareVM und REMnux mit Remnux auf einer netzwerklosen VM.

Network Forensics in Kubernetes unterscheidet sich von klassischem Networking, weil das CNI NAT und Kapselung macht. Wir erfassen Traffic auf Ebene des veth-Pair des Pods mit tcpdump -i any auf dem Host, gefiltert nach der vom IPAM zugewiesenen Pod-IP. Lauft Cilium im Cluster, zeigt hubble observe --pod payments/checkout-7f4 bereits dekodierte L7-Flows. Fur persistente C2 vergleichen wir gegen IOCs aus unserem C2-Infra mit Sliver im Isolierten Lab fur Defensive Forschung Aufbauen-Lab und prufen DNS am CoreDNS uber das Query-Log. Pcaps exportieren wir immer auf Write-Once-Storage, weil Anwalte die Integritat liebend gern anzweifeln.

Praktisches Takeaway: probe das Verfahren vor dem Vorfall. Zieh einen kind- oder k3d-Cluster hoch, simuliere einen Angreifer-Pod, der eine Reverse-Shell offnet, und stoppe die Zeit zwischen Alarm und signiertem Speicher-Dump. Dauert es langer als 20 Minuten, automatisiere mit einem Operator, der auf Falco-Events reagiert, den Taint anwendet, das CSI-Snapshot ausloest und einen Collection-Job startet. Container Forensics geht nicht um exotische Tools, sondern um Choreografie, die geprobt wurde, bevor die Buhne brennt.