Serverless-Forensik: Wenn die Rechenumgebung sich selbst zerstört
13.08.2026 cloud-forensicsserverlessaws-lambdaazure-functions
Der Tatort löst sich auf, bevor der Ermittler eintrifft
Kubernetes-Forensik gilt bereits als Königsdisziplin der flüchtigen Beweissicherung. Serverless-Umgebungen wie AWS Lambda und Azure Functions treiben dieses Problem auf die Spitze. Ein Container lebt zumindest für die Dauer eines Tasks und lässt sich im Zweifel pausieren oder als Image committen. Eine Lambda-Ausführungsumgebung bietet diese Gnadenfrist nicht: Dies ähnelt funktional dem Volatilitätsproblem, das bei der Container-Forensik beschrieben wurde, nur schlimmer: Ein Container überlebt zumindest die Lebensdauer eines Tasks und lässt sich manchmal mitten im Vorfall pausieren oder zu einem Image committen. Eine Lambda-Ausführungsumgebung bietet diese Kulanz nicht. Die Plattform ist schlicht nicht für forensische Erhaltung konzipiert – nichts an der Plattform ist auf Beweissicherung ausgelegt, weil nichts an der Plattform darauf ausgelegt ist, dass man die zugrunde liegende Rechenleistung überhaupt berührt.
Diese Eigenschaft hat MITRE längst als eigenständige Angriffstechnik anerkannt. MITRE ATT&CK hat diese Angriffsfläche als Serverless Execution (T1648) formalisiert und nennt explizit Lambda, Google Cloud Functions und Azure Functions als dokumentierte Vektoren zur Erstellung bösartiger Workflows, die sich in legitimen Automatisierungsverkehr einfügen. Genau diese Eigenschaften – geringer Betriebsaufwand, vertrauenswürdige TLS-Zertifikate und dynamische Reaktion auf Verteidigermaßnahmen – machen Serverless-Plattformen für Angreifer als Command-and-Control-Infrastruktur so attraktiv. Eine SANS-Präsentation zum Missbrauch von AWS-Serverless-Technologie für durchgängiges C2 beschreibt dies unmissverständlich.
Was tatsächlich als Beweis übrig bleibt
Bei Lambda zerfällt die forensische Beweisbasis in vier Quellen absteigender Zuverlässigkeit. An erster Stelle stehen die CloudTrail-Data-Events: jede Invocation, die übernommene IAM-Rolle, die Identität des Aufrufers und alle API-Aufrufe, die die Funktion selbst an andere AWS-Dienste gerichtet hat. Auf die zentrale Frage, welche Log-Quelle für die Lambda-Incident-Response am wichtigsten ist, lautet die Antwort entsprechend eindeutig: AWS-CloudTrail-Data-Events für Lambda, da sie Invocation-Metadaten, IAM-Kontext und API-Aufrufe der Funktion erfassen – oft der einzige verbleibende Datensatz, nachdem die Ausführungsumgebung abgebaut wurde. Und dieser Abbau geschieht schnell: Dieser Abbau kann in Minuten geschehen. Nichts an der Plattform ist auf Beweissicherung ausgelegt, weil nichts an der Plattform darauf ausgelegt ist, dass man die zugrunde liegende Rechenleistung überhaupt berührt.
Die Praxis zeigt, dass diese Lücke aktiv ausgenutzt wird. Ein Trainingsfall beschreibt den sogenannten „Groundhog Day"-Angriff: eine Serie schneller, niedrigvolumiger, erfolgreicher Einbrüche, die flüchtige Logging-Lücken ausnutzen. Genau solche Muster – kurze, unauffällige Invocations, die keine dauerhafte Infrastruktur hinterlassen – sind der Grund, warum Standard-SIEM-Regeln, die auf persistente Hosts ausgelegt sind, hier versagen.
Governance vor Incident, nicht danach
Die zentrale Lehre für Verteidiger ist unbequem, aber klar formuliert: Wenn ein Angreifer in Minuten flüchtige, vertrauenswürdige Domain-Infrastruktur aufbauen kann, muss die Verteidigungshaltung davon ausgehen, dass jede Serverless-Funktion ohne explizit aktiviertes Logging von Natur aus ein blinder Fleck ist – nicht durch Zufall, sondern durch Design. Die einzige wirksame Abhilfe besteht darin, Logging vor dem Deployment zu erzwingen: CloudTrail-Data-Events und Azure-Diagnostic-Settings standardmäßig zu aktivieren, bevor deployt wird und nicht erst nach einem Vorfall, ist die einzige Maßnahme, die die beschriebene Lücke tatsächlich schließt.
Praktisch bedeutet das: IAM-Rollen nach dem Prinzip geringster Rechte, verpflichtende Data-Event-Protokollierung als Teil jeder Infrastructure-as-Code-Vorlage, und Runtime-Tools wie das Open-Source-Werkzeug „varc", das flüchtige Ausführungsdaten direkt innerhalb einer laufenden Lambda-Funktion einfängt, bevor die Umgebung verschwindet. Cloud-native Playbooks müssen automatisiertes Einfrieren von IAM-Rollen (Deny-All statt Löschen) und sofortige Exportfunktionen für CloudWatch-Logs enthalten – denn im Serverless-Zeitalter ist die einzige verfügbare “Festplatte” ein API-Aufruf, der bereits Geschichte ist, sobald man ihn braucht.
← Zurück zur Übersicht