Submitted dissertation
Forensic Readiness for Serverless Computing: Designing and Evaluating a Pre-Incident Evidence Framework for AWS Lambda
The problem
Investigating a compromised Lambda function depends on evidence that was enabled before the incident. Customers cannot image the host or acquire its memory, and invocation data events are off by default. I investigated what customer-accessible telemetry can establish, what configuration improves capture, and where attribution remains uncertain.
What I built
ForensicReadyLambda is a Python toolkit with a command-line interface and local graphical interface sharing one analytical core. Its auditor checks CloudTrail, CloudWatch Logs, X-Ray and VPC Flow Logs configuration. Collection and scoring use CloudTrail and CloudWatch Logs; the other sources remain outside the scored evaluation.
The correlator matches function and role identifiers within an incident window. It follows assumed-role sessions and layer attachments, and reads global IAM events from us-east-1 alongside the function region. A timeline builder exports W3C PROV graphs with explicit timestamp order.
Tamper checks report bundle self-consistency, preservation, source integrity and derived-field consistency separately. Bundles can be preserved with an explicit S3 Object Lock COMPLIANCE retention and a receipt. The toolkit checks digest-recorded log-file hashes; signature and digest-chain validation rely on AWS-native tooling. These controls support evidence handling without claiming legal admissibility.
Four controlled scenarios
I defined the expected evidence before execution and compared logging postures across four MITRE ATT&CK-anchored scenarios. Configured runs enabled the relevant management-read or Lambda Invoke data events. Two runs per posture reproduced each result.
| Scenario and comparison posture | Comparison | Configured |
|---|---|---|
| Environment variable disclosureWrite-only CloudTrail trail | 0 of 1 | 1 of 1 |
| Layer supply-chain backdoorManagement events; Lambda data events off | 3 of 4 | 4 of 4 |
| SQS event-source exploitationManagement events; Lambda data events off | 1 of 2 | 2 of 2 |
| Privilege escalation and useManagement events; Lambda data events off | 3 of 4 | 4 of 4 |
A default CloudTrail trail already records management reads. The disclosure comparison therefore measures reduced logging under a write-only trail. Full capture in these scenarios also depended on correctly placed collection windows.
The three assessed incident chains were recovered in full. Across twelve configured layer-backdoor runs, the Invoke event had a median first-seen delay of 328.4 seconds. It appeared after management events in nine runs and in the same polling interval in three. These measured delays describe the test environment, not guaranteed AWS delivery times.
Where attribution stopped
In the SQS scenario, the captured Invoke event identified the Lambda service, leaving the original sender unknown. Additional SQS data events exposed the sender's IAM identity and source IP. Queue identity and timing connected them to execution in the single-message probe; concurrent traffic would need a message-level identifier for stronger linkage. Capturing the invocation alone did not resolve its origin.
Verification and limits
Prespecified negative controls exposed a selector that also admitted a similarly named function. I corrected the identifier boundary and checked that genuine evidence remained. The final release passed 365 tests: 323 exercised the toolkit and 42 guarded the dissertation's figures and examples. Branch coverage was 97% of the analytical core; the interface, scripts and live AWS paths were outside that denominator.
Evaluation covered one AWS account, one deployment region and short chains. Chain ordering was formalised after execution. The submitted code received no end-to-end AWS rerun after the final offline refinements. Three independent evaluators inspected the interface against usability heuristics; task-based user testing was not conducted.