Attackers use serverless execution to run code in short-lived cloud functions so activity blends into normal application traffic and avoids persistent malware on hosts. They use it for command execution, staging, data theft and proxying. Defenders should review function creation, triggers, permissions, unusual outbound connections and rapid bursts of invocations.
How serverless execution helps attackers hide in plain sight
Serverless functions are attractive because they are ephemeral, hosted in trusted cloud environments, and already generate noisy, legitimate-looking telemetry. That lets attackers execute code without dropping a long-lived implant on a host, and it makes malicious activity harder to distinguish from normal application behaviour when defenders are not watching function lifecycles, event sources, and outbound destinations closely.
Attackers also like serverless because they can scale activity quickly, burst on demand, and shut down just as fast. That combination is useful for command execution, data theft, staging, and proxying, especially when the function is triggered by APIs, queues, object events, or webhooks that blend into business traffic.
For defenders, the important detail is that serverless abuse is usually not about “malware persistence” in the classic sense. It is about abusing legitimate execution rights, trust in cloud control planes, and short-lived compute to reduce visibility while still reaching secrets, data, and internal services.
Where attackers get leverage in a serverless environment
Attackers usually gain leverage through the same surfaces developers rely on for legitimate automation: triggers, environment variables, permissions, dependencies, and function URLs. A weak trigger or overbroad permission set can turn a small foothold into an execution path that looks normal to monitoring systems, which is why the Serverless Security Guide treats function permissions, event injection, and logging as core control points rather than afterthoughts.
Once execution is established, the function becomes a disposable foothold for short tasks. Attackers can use it to run commands, fetch additional payloads, call APIs, scan reachable services, or relay traffic through cloud egress that defenders may already trust. In practice, the most valuable abuse is often not the function itself, but the access path it inherits from the deployment pipeline, execution role, or exposed trigger.
Serverless also changes the defender’s visibility problem. A function may live only for seconds, but the control plane records creation, invocation, identity, and network activity. That means the attack path is often visible if teams know what to correlate, but easy to miss if monitoring focuses only on hosts and ignores cloud-native execution events.
What good detection and response looks like
The most useful detections are behavioural, not signature-based. Look for unusual function creation, privilege changes, trigger tampering, unexpected outbound connections, and bursts of invocations that do not match application demand. Those signals matter because serverless abuse usually depends on scaling quickly, touching data, then disappearing before host-based controls would normally notice.
When investigators find suspicious execution, they should treat the function as both a workload and an access path. The question is not only whether code ran, but what the function could reach: secrets, storage, queues, internal APIs, metadata services, and downstream automation. That is why the State of NHI & AI Agent Breach Report 2026 is useful for understanding how stolen tokens, service credentials, and machine access are abused once attackers gain a reusable execution path.
Response should also account for speed. If the function is being used as a staging or proxy layer, waiting to prove persistence can waste time. Contain the execution path first, then review whether credentials, keys, or other secret material exposed to the function need rotation because the compromise may have already moved beyond the function runtime itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Serverless abuse often runs attacker commands through ephemeral cloud execution. |
| T1105 — Ingress Tool Transfer | Serverless functions commonly stage or retrieve additional payloads from remote infrastructure. | |
| Recommendation — Map suspicious function activity to command execution techniques and hunt for scripted payloads. Inspect function egress for payload retrieval and block unexpected download paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | Abuse often depends on overbroad cloud identities, tokens, and service permissions. |
| Recommendation — Review and remove unnecessary function permissions and service account access. | ||
| NIST SP 800-53 Rev 5 | AU-12 — Audit Record Generation | Function creation, invocation, and trigger events are critical evidence for detecting abuse. |
| SC-7 — Boundary Protection | Serverless abuse often depends on unexpected outbound access and proxying. | |
| Recommendation — Ensure serverless control-plane events are logged and retained for investigation. Constrain function egress and segment access to internal services. | ||
Practitioner Guidance
What to prioritise: Review function creation events, trigger changes, execution role scope, and outbound network patterns before you spend time on the function code itself. In many incidents, the abuse is enabled by configuration and trust relationships, not by a sophisticated payload.
What to verify: Confirm which identities, secrets, and downstream services the function can reach, then check whether those permissions are broader than the application actually needs. If the function can access production data or internal APIs, treat that as a material exposure even if the code appears short-lived.
Decision rule: If a function was created or modified unexpectedly, assume it may have been used for staging, proxying, or data access until logs prove otherwise. If patching or code cleanup must wait, disable the trigger, reduce permissions, and preserve control-plane logs first.
Practitioner takeaway: Serverless abuse is best understood as trusted cloud execution being repurposed for attacker convenience, so the real control point is the combination of trigger, permission, and egress visibility rather than the presence of persistent malware.