A compromised serverless function rarely looks like a breached server: there is no host to image, the attacker's foothold is a code change, a new trigger or a stolen execution role token, and the evidence lives in control plane logs that are easy to miss. This playbook template covers suspected compromise of AWS Lambda functions, Azure Functions apps and Google Cloud Run functions (platforms are listed alphabetically). It sets out triggers, roles, decision points, containment that does not break production, the logs and artefacts to preserve, and a clean redeploy path. It is written for cloud security, platform and application teams, with decision points for the incident manager. Adapt the bracketed text before adoption.
How to use this template
- Replace text in square brackets, such as [Organisation], [Cloud Platform Owner] and [SIEM], with your own names. "Must" is mandatory; "should" is recommended.
- Decision points are marked D1 to D5. Record each decision, who made it and when.
- Console paths, setting names and log event names reflect AWS, Microsoft and Google documentation as checked in November 2026. Confirm the current values in each provider's documentation and keep your own tested commands in a runbook.
- Prevention and hardening are covered in the Serverless Security Guide, the AWS Lambda Security Guide, the Azure Functions Security Guide and the Cloud Run and Cloud Functions Security Guide. Detection logic for the technique sits in MITRE ATT&CK T1648 Serverless Execution. This playbook only covers the response.
- If the root cause is a leaked long-term key rather than a function, switch to the Cloud Access Key Leak Playbook.
1. Scope and triggers
1.1 This playbook applies when a serverless function owned by [Organisation], its deployment pipeline or its runtime identity may be under someone else's control.
1.2 Triggers include: an unexpected code deployment or configuration change outside the pipeline; a new or widened invocation permission, public URL or trigger; runtime identity calls from outside the function's normal pattern; a cloud provider security finding; outbound traffic to unknown destinations; sudden invocation or spend growth; a vulnerable dependency known to be exploited in the function's package; or a report from a developer or researcher.
1.3 Relevant ATT&CK techniques: T1648 Serverless Execution, T1078.004 Cloud Accounts, T1552.005 Cloud Instance Metadata API, T1098.003 Additional Cloud Roles, T1546 Event Triggered Execution, T1537 Transfer Data to Cloud Account and T1496.001 Compute Hijacking.
| Compromise pattern | What the attacker gains | Where it shows first |
|---|---|---|
| Code or layer replaced | Persistent code running with the function's identity on every invocation | Control plane write events (code update, layer publish, deployment) not from the pipeline identity |
| Runtime identity token stolen through the function (injection, vulnerable dependency, SSRF) | The execution role or service account's permissions, usable from outside | The function's identity calling APIs from unfamiliar IPs or at unusual volume |
| Trigger or permission added | A way to invoke the function, or a new event source feeding it | Permission, URL or event source mapping changes |
| Role or service account widened | Privilege escalation through the function | IAM policy changes on the function's identity |
| Deployment credential abused | Direct publishing to the function app outside the pipeline | Publishing or deployment endpoint sign-ins |
2. Roles and contacts
| Role | Responsibility | Named contact |
|---|---|---|
| [Incident Manager] | Owns the incident, decisions D1 to D5 and the timeline | [Name, phone] |
| [Cloud Platform Owner] | Applies containment in each account, subscription or project; one per provider | [AWS, Azure, Google Cloud owners] |
| [Function Owner] | Knows the expected code version, triggers, permissions and callers | [From service catalogue] |
| [Pipeline Owner] | Confirms which deployments came from the pipeline; rotates pipeline credentials | [Name] |
| [SOC Analyst] | Log queries, timeline, evidence export | [Rota] |
| [Legal and Privacy] | Notification decisions where data was reachable by the function's identity | [DPO, counsel] |
3. Detection and triage
3.1 The [SOC Analyst] must confirm the alert and establish, within [60] minutes: which function, version and identity are involved; whether the running code matches the last pipeline build; and what the identity can reach.
3.2 Control plane events to query first:
| Provider | Log source | Events to review |
|---|---|---|
| AWS Lambda | AWS CloudTrail (management events); Invoke is a data event and is not logged unless data events are turned on | UpdateFunctionCode, UpdateFunctionConfiguration, PublishLayerVersion, PublishVersion, UpdateAlias, AddPermission, CreateFunctionUrlConfig, UpdateFunctionUrlConfig, CreateEventSourceMapping, PutFunctionCodeSigningConfig, DeleteCodeSigningConfig. Event names carry date suffixes, for example UpdateFunctionCode20150331v2, so match on the prefix |
| Azure Functions | Azure Activity log; AppServiceAuditLogs for FTP and Web Deploy sign-ins (send to a Log Analytics workspace first) | Application settings writes, key renewals or additions, deployment and publishing profile actions, managed identity and role assignment changes, slot swaps |
| Google Cloud Run functions | Cloud Audit Logs, service cloudfunctions.googleapis.com; Admin Activity is always written, CallFunction is a Data Access log | CreateFunction, UpdateFunction, DeleteFunction, SetIamPolicy; plus IAM changes on the runtime service account |
3.3 Then review the runtime identity's own activity: the Lambda execution role's sessions in CloudTrail, the function app's managed identity sign-ins in Microsoft Entra sign-in logs, and the runtime service account's calls in Cloud Audit Logs. Calls from IP addresses outside the provider's function infrastructure, or API calls the function never makes, point to token theft.
3.4 D1: declare. Declare an incident if any write to code, configuration, permissions or identity did not come from the pipeline identity or an approved change, or if the runtime identity was used from outside the function. Severity follows the identity's reach: [High] if it can read sensitive data or change IAM.
4. Containment
4.1 Preserve first, for two minutes. Before changing anything, export the current function configuration, the deployed package or image digest, the resource policy and the identity's attached policies (section 8). Containment overwrites the evidence of what the attacker configured.
4.2 D2: stop invocation or keep serving? If the function handles customer traffic, the [Incident Manager] decides between stopping it and rolling back to a known good version. Stop when the identity reaches sensitive data or IAM; roll back when the known good version is certain.
| Action | AWS Lambda | Azure Functions | Google Cloud Run functions |
|---|---|---|---|
| Stop invocations | Set reserved concurrency to 0 | Stop the function app, or disable the affected function | Remove the invoker binding, or delete the function after the source and configuration are exported |
| Close the front door | Remove unexpected AddPermission statements; delete or set AuthType AWS_IAM on unexpected function URLs; deleting a URL with auth type NONE does not remove its resource-based policy, so remove those statements too | Renew affected function, host and _master keys (renewal does not happen when a function is deleted and recreated); set functionsRuntimeAdminIsolationEnabled to block /admin endpoints | Remove unexpected allUsers or allAuthenticatedUsers invoker bindings |
| Cut the identity | Revoke active sessions on the execution role and attach a deny policy while investigating | Remove the managed identity's role assignments in scope, or detach the user-assigned identity | Remove the runtime service account's role bindings, or disable the service account |
| Block side doors | Disable unexpected event source mappings | Turn SCM Basic Auth Publishing Credentials and FTP Basic Auth Publishing Credentials off; reset publishing profiles | Review and remove unexpected triggers (Eventarc, Pub/Sub) |
4.3 Contain the pipeline as well: suspend deployments for the affected function and rotate the deployment credential if any unexplained write came from it. See the CI/CD Pipeline Compromise Playbook if the pipeline itself is the source.
4.4 D3: scope widening. If the identity could assume other roles, impersonate other service accounts or write IAM, widen scope to those identities and escalate to the [Cloud Credential Compromise] process.
5. Eradication
5.1 Do not patch the compromised function in place. Treat the deployed package, layers and configuration as untrusted.
5.2 Remove every change the attacker made, using the section 3 timeline: permissions, URLs, triggers, event source mappings, application settings, keys, IAM bindings and any new functions, layers or roles created by the same identity in any region.
5.3 Rotate every secret the function could read: environment variables, Key Vault or secrets manager entries it had access to, database credentials and downstream API keys. Assume an attacker with code execution read them all.
5.4 Replace broad runtime identities. On Google Cloud, a function using the Compute Engine default service account ([email protected]), which may hold Editor depending on organisation policy, must move to a user-managed service account with minimal roles. On AWS and Azure, scope the execution role or managed identity to the specific resources the function uses.
5.5 Fix the root cause: the vulnerable dependency, the injectable event handler, the leaked pipeline credential or the over-broad deployer permission.
6. Recovery
- Rebuild from source at a reviewed commit in the pipeline, not from the deployed artefact.
- On AWS, deploy with a code signing configuration set to Enforce (the default is Warn, which only logs); layers must also be signed by an allowed profile. Publish a new version and point the alias at it. Published versions are immutable, so earlier known good versions remain available for rollback.
- On Azure, deploy through the pipeline using Microsoft Entra authentication with basic publishing credentials left off, and store function keys in Key Vault with AzureWebJobsSecretStorageType set to keyvault where your design allows.
- On Google Cloud, redeploy with --service-account set to the new user-managed account.
- Restore invocation (concurrency, app start, invoker bindings) only after the [Function Owner] confirms configuration matches the approved baseline.
- Monitor at heightened alerting for [14] days: any control plane write not from the pipeline identity pages the on-call analyst.
D4: return to service. The [Incident Manager] approves restoration when code provenance, identity scope and secrets rotation are confirmed.
7. Communication and notification
7.1 D5: notification. If the function's identity could read personal data, [Legal and Privacy] must assess notification duties. Under UK and EU GDPR, Article 33 requires notifying the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk. Sector and national clocks may be shorter; see the Cyber Incident Reporting Requirements Map.
7.2 Open a support case with the cloud provider where you need provider-side logs or billing relief for abuse spend.
7.3 Internal updates go to [stakeholder list] every [4] hours while containment is open.
8. Evidence and post-incident review
| Evidence | Why it matters |
|---|---|
| Deployed package, layers or container image digest, before rollback | Shows exactly what code ran; rollback replaces it |
| Function configuration, environment variables (redacted copy), resource policy, triggers | Shows the attacker's configuration changes |
| Runtime identity policies and bindings at time of detection | Defines the blast radius |
| Control plane and identity logs for [90] days before detection | First change, persistence and data access; export to write-once storage |
| Function application logs and traces | Injection attempts and outbound calls |
| Pipeline run history | Separates legitimate and unauthorised deployments |
8.1 Handle exports under the Evidence Handling and Chain of Custody Guide. Cloud evidence methods are in the Cloud Forensics Guide.
8.2 Hold a post-incident review within [10] working days using the Post-Incident Review and Root Cause Analysis Template.
Implementation guidance
Prepare these before you need the playbook:
- Turn on the logs that matter: CloudTrail management events in every region (and Lambda data events for sensitive functions), AppServiceAuditLogs and the Activity log sent to a workspace, and Cloud Audit Logs retained beyond the default period.
- One identity per function: shared execution roles or service accounts turn one compromised function into many.
- Pipeline-only deployment: restrict code update permissions to the pipeline identity, so any other writer is an alert. Our recommendation at NHI Mgmt Group is to alert on every code, permission or identity write from a non-pipeline principal.
- Baseline per function: expected version, triggers, URLs, resource policy and identity, kept in the service catalogue, so triage can diff quickly.
- Exercise it: run a tabletop on a stolen runtime token and a malicious code update once a year. See the Identity Attack Tabletop Exercise Scenarios.
| Framework | Reference |
|---|---|
| NIST CSF 2.0 | RS.AN-03 analysis and root cause; RC.RP-01 recovery executed; DE.CM-01 monitoring |
| NIST SP 800-53 Rev. 5 | IR-4 Incident Handling; IR-5 Incident Monitoring; IR-6 Incident Reporting; AU-6 Audit Record Review |
| MITRE ATT&CK | T1648, T1078.004, T1552.005, T1098.003, T1546, T1537, T1496.001 |
For machine identities behind functions, see the Cloud Workload Identity Guide.
Standards and references
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- AWS: Logging AWS Lambda API calls using AWS CloudTrail
- AWS: Using code signing to verify code integrity with Lambda
- AWS: Control access to Lambda function URLs
- Microsoft: Work with access keys in Azure Functions
- Microsoft: Disable basic authentication in App Service deployments
- Google Cloud: Cloud Run functions audit logging
- Google Cloud: Introduction to service identity
Related NHI Mgmt Group resources: Serverless Security Guide · Cloud Incident Response Guide · Cloud Access Key Leak Playbook · MITRE ATT&CK T1648 Serverless Execution