Serverless Persistence

What serverless persistence means

Serverless persistence is a compromise pattern, not a traditional implant. The attacker is trying to survive function re-invocations by changing the environment that runs the code, rather than by dropping a long-lived agent on a host.

That distinction matters because serverless platforms intentionally recreate, recycle, and scale execution contexts. Persistence therefore tends to come from control-plane changes, reusable deployment artefacts, or runtime features that outlast one invocation and reappear in later ones.

How persistence shows up in function environments

In practice, persistence can take the form of modified function code, altered configuration, malicious layers or extensions, event triggers that keep reactivating the code path, or abused permissions that let the attacker redeploy after cleanup. It can also involve living off the platform's own mechanics, such as shared runtime state or trust in the deployment pipeline.

This is why the term overlaps with cloud abuse techniques rather than endpoint malware. In function platforms, the attacker often needs only a narrow foothold and a way to influence the deployment or invocation lifecycle. The persistence target is the service boundary, not the machine disk.

Why serverless persistence is difficult to spot

Serverless environments reduce the defender's usual signals. There may be no interactive login session, no persistent process tree, and limited filesystem evidence between invocations. That makes the compromise look intermittent even when the attacker has durable influence over the workload.

Detection has to focus on control-plane activity, unusual redeployments, unexpected runtime extensions, and changes to triggers, permissions, or environment variables. A function can appear clean at rest while still being reactivated through a path the attacker quietly preserved.

What defenders should assume

Serverless persistence should be treated as a lifecycle and access problem, not just a malware problem. If an attacker can alter deployment state or retain execution authority, then remediation must include review of the code package, attached services, event sources, and any secrets or credentials that enabled the change.

For broader context on the attack pattern, MITRE ATT&CK T1648 Serverless Execution covers how persistence and abuse can emerge across function platforms, while Identity Threat Detection and Response (ITDR) Guide helps frame the identity and session signals that often accompany cloud persistence. The same control lens is reinforced by Salt Typhoon telecom intrusions 2025, which shows how stolen credentials and reused trust can support long-lived access.

Risk and Threat Considerations

Serverless persistence is risky because the attacker can remain active without a conventional installed payload. That makes cleanup harder, increases the chance of reinfection after deployment changes, and can let an intruder survive across a platform that looks ephemeral from the outside.

Failure mechanism: The attacker preserves influence by modifying deployment artifacts, triggers, runtime extensions, or privileged configuration paths that are reused on future invocations.

Impact: The function can continue to execute malicious logic, leak data, or re-establish access after a patch, redeploy, or partial incident response.

Practitioner Guidance

Why practitioners should care: Serverless persistence requires defenders to investigate the function's control plane, not only its runtime. If cleanup stops at code review or instance replacement, an attacker may still retain a surviving path through configuration, attached permissions, or event-driven reactivation.

What to watch for: Repeated unauthorized redeployments, unexpected trigger changes, new layers or extensions, and environment changes that do not match approved release activity are all strong indicators that persistence may be embedded in the function lifecycle.

Practitioner takeaway: Treat serverless compromise review as a redeployment and trust-boundary problem, and validate both the artifact and the surrounding permissions before declaring the environment clean.

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?