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 fremden 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-Forensik in Kubernetes ist keine Variante klassischer Host-Forensik, sondern eine eigene Disziplin: die Runtime recycelt Layers, Cgroups und Namespaces schneller, als ein Analyst Wireshark offnen kann. Dieser Leitfaden beschreibt eine reproduzierbare Sammelkette, die vor dem Vorfall beginnt und bis zur signierten Beweisubergabe reicht.

Warum Container-Forensik anders ist

Ein Container ist kein kleiner Server, sondern ein Prozess in isolierten Namespaces auf einem geteilten Kernel. Das Root-Dateisystem ist ein Overlay aus schreibgeschutzten Image-Layers plus einer dunnen, schreibbaren oberen Schicht (upperdir), die beim Pod-Ende verworfen wird. Es gibt kein persistentes /var/log, keinen stabilen Uptime-Kontext und selten ein Journald im Container. Wer die Beweise nicht dort abholt, wo sie leben, verliert sie: der Scheduler kann den Pod auf einen anderen Node verschieben, ein CrashLoopBackOff setzt den Zustand zuruck, und ein simples kubectl rollout restart loscht den fluchtigen Kontext komplett. Forensische Reife im Cluster misst man nicht an Werkzeugen, sondern an der Zeit zwischen Alarm und erster unveranderlicher Kopie. Hinzu kommt die Ephemeralitat der Identitat: dasselbe Deployment erzeugt Pods mit wechselnden Namen und IPs, sodass ein Beweis ohne festen Anker an Node, Cgroup-Pfad und Container-ID schnell nicht mehr eindeutig zuzuordnen ist.

Bedrohungsmodell: Vektoren im Cluster

Bevor man sammelt, priorisiert man. Die haufigsten Vektoren sind: ein verwundbarer Anwendungscontainer mit RCE, ein gestohlenes oder ubermassig privilegiertes ServiceAccount-Token aus /var/run/secrets, ein Container-Breakout uber privileged: true, hostPath-Mounts oder eine Kernel-Lucke, sowie eine kompromittierte Supply Chain im Image selbst. Jeder Vektor hinterlasst Spuren auf einer anderen Schicht: Applikationsvektor im Pod-Speicher, Token-Missbrauch im kube-apiserver-Audit-Log, Breakout auf dem Node und Prozess-Baum, Supply-Chain-Kompromittierung in den Image-Layers. Das Threat-Modell entscheidet, welche Schicht zuerst eingefroren wird, denn Zeit ist begrenzt und Overlay-Schichten verschwinden zuerst.

Vorbereitung vor dem Vorfall

Die effektivste Forensik ist die vorbereitete. Aktiviere die Audit-Policy des kube-apiserver mindestens auf Metadata, fur sensible Verben (exec, attach, portforward, create von RBAC-Objekten) auf RequestResponse, und schicke die Logs an ein externes, unveranderliches Ziel. Plane stundliche etcd-Snapshots (etcdctl snapshot save), damit du den RBAC-Zustand vor und nach dem Vorfall rekonstruieren kannst. Halte ein forensisches Toolkit-Image bereit (statische Binaries von busybox, lsof, ss, tcpdump, avml) in einer separaten Registry und schreibe eine RBAC-Rolle nur fur die Incident-Responder. Ohne diese Basisarbeit ist jede Sammlung improvisiert und vor Gericht angreifbar.

Schritt fur Schritt: Live-Triage am Pod

Die erste Beweisschicht lebt im Pod und ist volatil by design. Reihenfolge zahlt: markiere zuerst den Node mit einem eigenen NoExecute-Taint, damit der Scheduler nichts verdrangt, aber cordone nicht sofort, denn cordon allein stoppt keine laufenden Prozesse. Loese ein Disk-Snapshot uber CSI aus (auf EKS ein EBS-Snapshot, auf GKE gcloud compute disks snapshot), und betrete den Ziel-Container erst dann mit kubectl debug uber ein ephemeres Image mit statischen Binaries. Sichere /proc/[pid]/exe, /proc/[pid]/maps, /proc/[pid]/environ, offene Sockets via ss -tanp und den Inhalt von /tmp, /dev/shm vor jedem Neustart. Wer DFIR unter Linux: Live-Triage mit UAC und Velociraptor auf klassischen VMs kennt, muss umdenken: hier verschwindet die oberste Schicht, sobald der Pod stirbt.

Speicherakquise des Containers

Der Container-Speicher ist der eigentliche Schatz, weil dateilose Malware und injizierter Code nur dort existieren. Bei containerd- oder CRI-O-Runtime ist die PID des Pod-Prozesses auf dem Host sichtbar (uber crictl inspect oder ctr task ls), also fuhrst du avml --pid <host_pid> aus oder verwendest LiME, kompiliert gegen den exakten Node-Kernel, um einen Vollspeicher-Dump zu erzeugen. Der Dump flieSSt direkt in den Workflow aus Memory Forensics mit Volatility 3: Dumps im reproduzierbaren Lab analysieren, wo linux.pslist, linux.malfind und linux.check_syscall Injektionen aufdecken, die das Host-EDR verpasste, weil sie im Container-Namespace eingesperrt waren. Jeder SHA-256-Hash landet 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.

Control Plane und Audit-Logs

Weiter oben im Stack wird die Untersuchung richtig aufschlussreich. Der kube-apiserver mit Audit auf RequestResponse-Level protokolliert jedes exec, attach und portforward als strukturiertes JSON, inklusive user, sourceIPs, userAgent und objectRef. In einem realen Fall aus 2025 sicherten wir das entscheidende Beweisstuck: der Angreifer legte ein 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. Korreliere mit stundlichen etcd-Snapshots, um den RBAC-Zustand vor und nach dem Vorfall zu rekonstruieren. Diese Timeline-Arbeit deckt sich mit Timeline Forensics unter Windows: Plaso, Log2Timeline und KAPE in der Praxis, nur angewandt auf deklarative Ressourcen.

Runtime-Forensik mit eBPF

Runtime-Forensik verlangt spezielles Werkzeug. Deploye Tetragon oder behalte 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 Direct-Syscall-Techniken aus EDR-Umgehung fur Forschung: Direct Syscalls erklart ohne Romantik auf Linux adaptiert oder ruft er Syscalls unter Umgehung der libc auf, erkennt ein reiner Userspace-Hook nichts. Ein eBPF-Sensor am Kernel-Tracepoint sieht dagegen den tatsachlichen Syscall. Kombiniert mit Sigma-Hunting im Stil von Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel vervielfacht sich die Chance, den Pivot zu fassen.

Netzwerk-Forensik im CNI

Network-Forensik in Kubernetes unterscheidet sich von klassischem Networking, weil das CNI NAT und Kapselung macht und die Pod-IP nach dem Tod recycelt wird. Erfasse Traffic auf Ebene des veth-Pairs 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 mit Prozess-Kontext. Fur persistente C2-Kanale vergleichst du gegen IOCs aus deinem C2-Infra mit Sliver im isolierten Lab fur defensive Forschung-Lab und prufst DNS am CoreDNS uber das Query-Log. Pcaps exportierst du immer auf Write-Once-Storage (WORM oder Object-Lock), weil Anwalte die Integritat liebend gern anzweifeln.

Kompromittierte Images zerlegen

Kompromittierte Images verdienen ein eigenes Kapitel. Bevor irgendetwas zerstort wird, machst du 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 Dateien gegen die Original-Layers zu kartieren. In 60 Prozent 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 schickst du Layers in ein ELF-angepasstes Malware-Analyse im isolierten Lab: sicheres Setup mit FlareVM und REMnux mit Remnux auf einer netzwerklosen VM.

Chain of Custody und Anti-Forensik

Beweiswert steht und fallt mit der Sammelkette. Dokumentiere fur jedes Artefakt: was, wann, von welchem Node/Pod, mit welchem Kommando, wer es sammelte, SHA-256 vor und nach der Ubertragung, und lege alles unveranderlich ab. Rechne mit Anti-Forensik: Angreifer loschen /tmp, manipulieren Container-Zeit uber libfaketime, blenden Prozesse per LD_PRELOAD-Rootkit aus oder nutzen memfd_create fur dateilose Ausfuhrung, die nie das Dateisystem beruhrt. Genau deshalb ist der Speicher-Dump nicht verhandelbar: ein Prozess ohne Datei auf der Platte ist trotzdem im RAM sichtbar. Signiere jedes Artefakt mit Sigstore/cosign und halte den privaten Schlussel getrennt vom Cluster.

Haufige Fehler

Die teuersten Fehler sind prozessual, nicht technisch. kubectl delete pod vor dem Snapshot vernichtet die Overlay-Schicht unwiederbringlich. kubectl exec in den Live-Container hinterlasst eigene Spuren und verandert Timestamps. Das Sammeln von Tools uber das Netz auf den kompromittierten Node lasst den Angreifer wissen, dass du da bist. Den EDR-Agenten des Hosts als einzige Quelle zu vertrauen ubersieht alles im Container-Namespace. Und das Speichern von Beweisen im selben Cluster, den der Angreifer kontrolliert, ist naiv. Ube die Reihenfolge, bevor der Ernstfall kommt.

Checkliste

Kurzfassung fur die Runbook-Wand: (1) Node taint NoExecute, Scheduling einfrieren. (2) CSI-Disk-Snapshot auslosen. (3) Speicher-Dump per avml/LiME gegen Node-Kernel. (4) Volatiles am Pod sichern: /proc/[pid]/*, Sockets, /tmp, /dev/shm. (5) kube-apiserver-Audit-Log und etcd-Snapshot exportieren. (6) Netzwerk-pcap am veth aufzeichnen. (7) Verdachtiges Image via skopeo copy sichern, trivy/dive. (8) Alles hashen, mit Sigstore signieren, in WORM ablegen. (9) Chain-of-Custody schreiben. (10) Erst dann eindammen (isolieren/loschen).

FAQ

Kann ich einen laufenden Container einfrieren, ohne ihn zu toten?

Ja. Nutze kubectl debug mit einem ephemeren Container statt exec, denn der teilt den Prozess-Namespace, ohne den Ziel-Entrypoint zu beruhren. Auf Host-Ebene kannst du den Prozess mit SIGSTOP pausieren (uber die Host-PID), einen Speicher-Dump ziehen und danach entscheiden, ob du fortsetzt oder eindammst. Wichtig: dokumentiere den SIGSTOP, weil er den Zustand einfriert und die Verteidigung das im Bericht sehen will.

Reicht das Host-EDR fur Container-Vorfalle?

Nein. Ein Host-EDR sieht Prozesse und Syscalls, aber ohne Namespace-Bewusstsein ordnet es sie nicht sauber dem richtigen Pod zu und verpasst dateilose Injektionen im Container-RAM. Ergaenze immer einen eBPF-Sensor mit container_id-Kontext und einen Speicher-Dump. Verlasse dich nie auf eine einzige Schicht.

Fazit

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-Forensik geht nicht um exotische Tools, sondern um eine Choreografie, die geprobt wurde, bevor die Buhne brennt. Wer die Reihenfolge im Schlaf beherrscht und die Kette signiert, verwandelt einen chaotischen Nachtalarm in einen sauberen, gerichtsfesten Bericht.