Serverless Persistence

Serverless persistence is an attacker’s ability to maintain access or influence inside a function environment across invocations. In Lambda, this usually depends on modifying deployment state, attaching malicious extensions, or abusing shared runtime mechanics rather than installing traditional endpoint malware. It is harder than on hosts, but not impossible.

Expanded Definition

Serverless persistence describes a class of post-compromise behaviour in which an attacker keeps a foothold inside a function or event-driven compute environment without relying on a long-lived host implant. In practice, that means the adversary tries to survive container recycling, function cold starts, and short execution windows by changing deployment artefacts, adding malicious extensions, tampering with layers, or abusing configuration and runtime reuse. The concept is specific to serverless and function-as-a-service platforms, where the defender’s visibility is often focused on code and control plane events rather than on a stable machine image.

That distinction matters because persistence in serverless environments is usually indirect. The attacker is not “living off the land” in the same way as on an endpoint, but instead is trying to influence what executes next time the function is invoked. The security question is therefore less about a single infected process and more about whether build, deploy, and invocation paths can be trusted. For control mapping, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful reference point for access control, configuration management, and integrity-related safeguards that help constrain this behaviour.

The most common misapplication is treating serverless persistence as if it were endpoint persistence, which occurs when teams only hunt for malware on ephemeral runtimes and ignore deployment permissions, CI/CD compromise, and function-layer modifications.

Examples and Use Cases

Implementing serverless platforms rigorously often introduces operational friction, because the same controls that reduce attacker dwell time can slow deployment, increase review steps, and require tighter separation between developers, CI/CD systems, and cloud administrators.

• An attacker with overbroad deployment access updates a function package so that each new invocation runs the original logic plus a hidden data exfiltration step.
• Malicious code is introduced through a compromised dependency or layer, allowing the attacker to influence multiple functions that reuse the same shared component.
• A hostile extension is attached to a serverless runtime, capturing secrets or telemetry during execution even though no persistent process exists on a host.
• Privileged access to the function’s configuration is abused to redirect logs, modify environment variables, or change event sources so the attacker can keep control of execution paths.
• Infrastructure-as-code or pipeline compromise is used to reintroduce malicious changes after clean redeployments, which makes the persistence survive ordinary incident response actions.

These patterns are especially relevant in cloud-native environments where serverless workloads are managed through identity, policy, and automation rather than through local administrator access. Guidance from cloud security and identity governance communities increasingly treats deployment state as part of the attack surface, not just the running code path.

Why It Matters for Security Teams

Serverless persistence shifts defensive focus from runtime hardening alone to the full lifecycle of code, identity, secrets, and deployment governance. If teams assume that “no server” means “no persistence,” they miss the real control points where attackers can alter future behaviour: CI/CD permissions, artifact integrity, environment variables, managed secrets, and function-level role assignments. That makes the term especially relevant for cloud security, IAM, and NHI governance, because machine identities, service principals, and automation credentials often hold the privileges needed to change serverless workloads.

The practical risk is that a compromise can remain hidden even when individual invocations appear clean, since the malicious logic is embedded in the trust chain rather than on the ephemeral execution surface. Strong change control, least privilege, signed artefacts, and continuous validation are therefore central to reducing dwell time. In operational terms, serverless persistence becomes visible only after repeated abnormal invocations, unexpected data movement, or unexplained redeployment behaviour force teams to investigate the control plane rather than the function body.

Related resources from NHI Mgmt Group

• When does malware persistence become an NHI governance issue?
• How do security teams know if persistence has been established on a compromised AI node?
• How should security teams prevent unwanted persistence in Active Directory and Entra ID?
• Why do stale accounts and old privilege create such a large persistence risk?