The function that runs the attacker's code forever
A Lambda function executes as an IAM role and fires on triggers you cannot easily see. Modify one and the attacker has durable execution and your role's rights, on every invocation. Here is the backdoor, and the fix.
There is no host to scan, no process to find. The backdoor is a function that runs on a schedule you did not set.
What it is
An AWS Lambda function runs as an execution IAM role and is invoked by triggers (API Gateway, S3 events, EventBridge schedules, and more). An attacker with Lambda permissions modifies a function’s code, adds a layer, or wires a new trigger, gaining code execution as the role on every invocation, plus durable persistence that no host scan will find. This is T1059 (command execution) with T1098 (account manipulation) and T1078 (valid accounts).
Why it works
Lambda is serverless, so there is no box to inspect, and a function quietly running attacker code on a schedule is easy to miss. The execution role’s rights are the blast radius.
How to detect it
In CloudTrail, look for UpdateFunctionCode, UpdateFunctionConfiguration, or AddPermission, and new event-source mappings, from a principal that does not normally manage Lambda, and the execution role behaving unusually.
The fix that holds
Least-privilege execution roles, restrict who can update functions and triggers, require code signing for Lambda, and alert on function and trigger changes. Review functions and event sources during response, because a deleted session does not remove a planted function.
Practice it
We built a Lambda backdoor scenario in GraphLattice Range so teams learn to find serverless persistence and the role rights behind it.