Kubernetes-Forensik: Wenn der Tatort sich selbst löscht
09.07.2026 kubernetescontainer-forensikcloud-forensikephemeral-workloads
Ein kompromittierter Windows-Server bleibt in der Regel so lange stehen, bis jemand ihn abschaltet. Ein kompromittierter Kubernetes-Pod dagegen kann sich selbst aus der Welt schaffen – durch Auto-Scaling, ein Rolling Update oder schlicht, weil der Container-Lebenszyklus es so vorsieht. Genau das macht Container-Forensik zu einer der unbequemsten Disziplinen im aktuellen DFIR-Alltag.
Ephemere Workloads, permanente Beweisprobleme
Die Kernherausforderung ist strukturell: Kubernetes-Sicherheitsvorfälle unterscheiden sich grundlegend von klassischen IT-Breaches, da Workloads ephemer sind – manche Container leben nur Sekunden oder Minuten, werden erstellt, zerstört und verschoben, was die Nachverfolgung von Angriffen erheblich erschwert. Wer erst nach der Erkennung reagiert, findet oft nur noch Asche vor. Verschärft wird das Problem dadurch, dass die ephemere Natur, dezentrale Architektur und fehlende persistente Speicherung von Containern forensische Untersuchungen häufig erschweren.
Ein FOSDEM-2026-Vortrag bringt das Dilemma auf den Punkt: Das Fehlen von Forensikdaten kann ebenso gefährlich sein wie das Vorhandensein bösartiger Aktivität selbst, denn containerisierte Umgebungen wie Kubernetes stellen neue Herausforderungen für die Beweissammlung dar, da Malware oft keine Spuren hinterlässt. Als Lösungsansatz diskutieren die Autoren, forensische Snapshots mittels transparenter Checkpointing-Methoden zu sammeln, zu bewahren und zu analysieren, während die Chain of Custody erhalten bleibt, inklusive Automatisierung für reale Einsatzszenarien.
Die erste Reaktion entscheidet
Google Cloud warnt seit Jahren vor dem naheliegendsten Reflex: Container einfach neu starten oder Pods terminieren. Der Rat lautet stattdessen: Man mag versucht sein, Pods zu beenden oder Nodes neu zu starten – doch das sollte man vermeiden, denn zwar stoppt das die akute Situation, es alarmiert aber auch den Angreifer und beraubt das Team der Möglichkeit zur Forensik. Stattdessen empfiehlt sich ein strukturiertes Vorgehen, wie es auch AWS für EKS beschreibt: Zunächst den betroffenen Node identifizieren und isolieren, dann den Container für die forensische Erfassung pausieren und die EBS-Volumes der Instanz snapshotten. Erst danach folgt die Bereinigung – neue, gepatchte Pods ausrollen und die kompromittierten Workloads entfernen.
Sysdig fasst den Workflow ähnlich: Container isolieren, ein forensisches Image des Dateisystems inklusive aller Daten und Metadaten erstellen und dieses Image für die Analyse nutzen, ohne den Originalcontainer zu verändern.
Werkzeuge gegen das Verschwinden
Für Azure-Umgebungen hat Invictus Incident Response mit KubeForenSys ein Open-Source-Tool vorgestellt, das genau dieses Timing-Problem adressiert: eine der größten Herausforderungen bei Untersuchungen ist der Aufbau einer akkuraten forensischen Timeline, wobei Teams oft mit fragmentiertem Logging, dezentralen Daten und der kurzen Lebensdauer von Containern kämpfen – KubeForenSys nutzt die Kubernetes-API, um Events, Logs, RBAC-Änderungen und verdächtige Pod-Aktivität in einer einzigen Timeline zusammenzuführen.
Auf der Runtime-Ebene setzen Anbieter wie Wiz auf eBPF-Sensorik, um Beweise unabhängig von der Lebensdauer eines Containers zu erfassen: eBPF-Sensoren laufen im Kernel und erfassen Prozessausführung, Dateizugriffe und Netzwerkaktivität mit unter einem Prozent CPU-Overhead. Für die Einordnung von Angriffstechniken hat Microsoft zudem eine eigene Threat-Matrix für Kubernetes veröffentlicht, die Organisationen hilft, Bedrohungen für ihre Cluster zu kategorisieren und zu verstehen, basierend auf der ursprünglichen Matrix, aber spezifisch für containerisierte Umgebungen, mit Taktiken wie Initial Access, Execution und Persistence.
Fazit
Container-Forensik verlangt ein Umdenken: weg von der Annahme, Beweise seien statisch und warteten geduldig auf den Ermittler, hin zu kontinuierlicher Erfassung, die dem Tempo ephemer Workloads standhält. Wer Logging, Snapshotting und Threat-Matrix-Mapping nicht vor dem Vorfall etabliert, verliert die Beweise oft schneller, als der Incident-Response-Prozess überhaupt anlaufen kann.
← Zurück zur Übersicht