Serverless Forensics: When Compute Vanishes Before You Arrive
13.08.2026 cloud-forensicsserverlessaws-lambdaazure-functions
The Crime Scene Dissolves Before the Investigator Arrives
Kubernetes forensics already ranks among the hardest volatile-evidence problems in DFIR. Serverless platforms like AWS Lambda and Azure Functions push that problem to its extreme. A container at least survives for the duration of a task and can sometimes be paused or committed to an image. A Lambda execution environment offers no such courtesy: this is functionally similar to the volatility problem described in container forensics, except worse: a container at least persists for the life of a task and can sometimes be paused or committed to an image mid-incident. A Lambda execution environment gives you no such courtesy. The platform simply wasn’t built with evidence preservation in mind — nothing about the platform is designed with evidence preservation in mind, because nothing about the platform is designed with you touching the underlying compute at all.
This isn’t a theoretical concern. MITRE has already formalized it as a distinct attack technique: MITRE ATT&CK formalized this attack surface as Serverless Execution (T1648), explicitly calling out Lambda, Google Cloud Functions, and Azure Functions as documented vectors for creating malicious workflows that blend into legitimate automation traffic. The very properties that make these platforms operationally convenient are what make them attractive as C2 infrastructure — low overhead, trusted TLS certificates, and dynamic response to defender activity — as a SANS presentation on abusing AWS serverless for end-to-end C2 has laid out explicitly.
What Actually Survives as Evidence
In Lambda, the practical forensic surface breaks down into four sources of descending reliability. Topping the list are CloudTrail data events, which capture every invocation, the IAM role assumed, the caller identity, and any API calls the function itself made to other AWS services. Asked which log source matters most for Lambda incident response, the answer is unambiguous: AWS CloudTrail data events for Lambda, since they capture invocation metadata, IAM context, and API calls made by the function, which is often the only record left after the execution environment is torn down. And that teardown happens fast: that teardown can happen in minutes. Nothing about the platform is designed with evidence preservation in mind, because nothing about the platform is designed with you touching the underlying compute at all.
Real-world tradecraft already exploits this gap. One training case study describes a so-called “Groundhog Day” attack: a series of rapid, low-volume, successful breaches that exploit ephemeral logging gaps. Short, unremarkable invocations that leave no persistent infrastructure behind are exactly why SIEM detection rules built around long-lived hosts routinely miss this activity class.
Governance Before the Incident, Not After
The core lesson for defenders is uncomfortable but precise: if an attacker can stand up ephemeral, trusted-domain infrastructure in minutes, the defensive posture has to assume that any serverless function without explicit logging enabled is effectively a blind spot by design, not by accident. The only remedy that actually closes this gap is enforcing logging before deployment: enabling CloudTrail data events and Azure diagnostic settings by default, before deployment rather than after an incident, is the only fix that actually closes the gap.
In practice, that means least-privilege IAM roles baked into every function, mandatory data-event logging enforced through infrastructure-as-code templates rather than left to individual teams, and runtime capture tools — such as the open-source “varc” utility — that snapshot volatile execution data from inside a running Lambda function before the environment disappears. Cloud-native IR playbooks need automated IAM containment (deny-all policies rather than deletion, to preserve the role for later analysis) and instant log-export routines for CloudWatch and Azure Monitor. In the serverless era, the only “disk” available for imaging is an API call — and it’s already history by the time you realize you need it.
← Back to overview