Cloud Access Key Leak Playbook: Revoking, Rotating and Investigating Exposed Keys

A long-lived cloud access key that reaches a public repository, a container image or a log file can be found and used by automated scanners before anyone on your team has seen the alert. This playbook template covers the static credentials that cloud workloads and pipelines use: AWS IAM user access keys, Google Cloud service account keys, and Azure storage account keys and application client secrets. It sets out triggers, roles, the order of revocation that avoids outages, the logs to pull, decision points and evidence to preserve, using AWS, Google Cloud and Microsoft documentation and NIST SP 800-61 Rev. 3. It is written for cloud platform, security operations and DevOps teams, with decision points for incident managers. 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 and policy names reflect the cited provider documentation as of October 2026; re-check them yearly and keep your own tested commands in a runbook.
• This playbook is the cloud-key branch of the Leaked Credential Response Playbook. If the key was used to take over wider cloud identity (console users, federation, roles), escalate to the Cloud Credential Compromise Playbook. Practise it with the Tabletop Exercise Scenario Pack.

1. Scope and triggers

1.1 This playbook applies when a long-term cloud credential belonging to [Organisation] is, or may be, visible to anyone who should not hold it.

1.2 Triggers: a provider notification; a GitHub secret scanning alert or push protection block (GitHub scans public repositories and public npm packages by default and sends matches for partner formats to the provider); an internal scanner hit in code, images, CI logs, tickets or chat; a canary key firing; unexpected spend or new resources; a researcher report.

1.3 Relevant ATT&CK techniques: T1552.001 Credentials In Files (how the key is found), T1078.004 Cloud Accounts (its use), T1580 Cloud Infrastructure Discovery, T1098.001 Additional Cloud Credentials (persistence), T1530 Data from Cloud Storage, T1496.004 Cloud Service Hijacking (mining and LLMjacking), T1486 Data Encrypted for Impact and T1485 Data Destruction.

2. Roles and contacts

2.1 Permissions must be granted in advance: in AWS, iam:UpdateAccessKey and iam:PutRolePolicy for responders; in Google Cloud, rights to disable keys, noting that changing organisation policy needs orgpolicy.policy.set, which neither Owner nor Editor includes; in Azure, Microsoft.Storage/storageAccounts/regeneratekey/action (Owner, Contributor or Storage Account Key Operator Service Role).

3. Detection and triage

1. Record the exposure: where the key appeared, public or internal, first exposure time (commit date, image push date) and detection time. Capture the location as evidence before anyone deletes it.
2. Identify the key: provider, account or project, the identity it belongs to, and its owner. In AWS, GuardDuty and CloudTrail show the user name and key ID; check the sessionIssuer element for role sessions.
3. Size the blast radius: attached policies and roles (AWS Access Advisor tab), service account roles in Google Cloud, data and subscriptions an Azure key or service principal can reach. Note whether the identity can create other credentials.
4. Check for use from the first exposure time: AWS CloudTrail events for the key ID; Google Cloud audit logs filtered on the service account principalEmail and serviceAccountKeyName, and the Key Authentication Events metric for last use; Azure storage logs and service principal sign-ins.

D1: Severity. Critical: public exposure with write or IAM permissions, or any evidence of use from an unknown source. High: public exposure with read-only access, or internal exposure with broad permissions. Medium: internal exposure, narrow scope, no use. Public exposure of any active key is at least High, because removal from the repository does not remove copies.

4. Containment

D2: Deactivate now or rotate first? For Critical, deactivate immediately and accept the outage; the [Incident Manager] decides. For High and Medium, issue the replacement first if it can be deployed within [1] hour, then deactivate. AWS's own sequence is create new key, update applications, deactivate (not delete) the old key, confirm applications work, then delete.

4.1 Deleting the commit, file or image is not containment. Google notes that removing a key from a repository is not enough, because version history keeps a record.

5. Eradication

1. Hunt for persistence created with the key: new IAM users, access keys, roles, trust policy changes, service account keys, client secrets added to app registrations (Entra audit category Application Management), federation providers and SSH keys.
2. Hunt for impact in every region, including regions you do not use: compute, Lambda functions, GPU or AI model use (cryptomining and LLMjacking), S3 or bucket policy changes, and lifecycle rules. In the Codefinger S3 ransomware campaign, stolen keys were used to re-encrypt objects with SSE-C keys the attacker kept, and lifecycle rules were set to delete them within seven days.
3. Snapshot before deleting. AWS advises backing up resources you need for investigation, for example an EBS snapshot before terminating an instance.
4. Remove the exposure from repositories, images, packages and logs, and purge history where practical. Check forks and mirrors.
5. Delete the old key once the replacement is confirmed working.

D3: Treat as data breach? If logs show reads of buckets, databases or secrets holding personal or customer data, open the notification track in section 7.

6. Recovery

1. Replace, do not just rotate. Prefer IAM roles, IAM Roles Anywhere, IAM Identity Center, Workload Identity Federation or managed identities over a new static key. See the NHI Authentication Guide.
2. If a static key remains, issue it with least privilege, store it in the secrets manager and set an expiry review. See the Secrets Management Guide.
3. Restore data from versioned or independent backups where objects were altered or deleted.
4. Verify the account: AWS recommends checking account name, root email and contacts, enabling root MFA, and replying to its support case with the actions taken.
5. Monitor the account for [30] days for failed authentication from the old key, which reveals missed dependencies or the attacker retrying.

D4: Close containment? The [Cloud Platform Owner] confirms no unknown principals, resources or credentials remain before the [Incident Manager] closes.

7. Communication and notification

• Provider: respond to the AWS support case or Google notification; raise a billing case for fraudulent charges via [FinOps].
• Internal: notify the key owner's team and the commit author without blame; the exposure is a process failure.
• Regulators and customers: where D3 is yes, [Legal and Privacy] applies the [Regulatory Register], for example GDPR Article 33 (72 hours from awareness).
• Third parties: if the key was exposed in a supplier's system, run the Vendor SaaS Breach Response Playbook in parallel.

8. Post-incident review

8.1 Within [10] working days, using the Post-Incident Review and Root Cause Analysis Template. D5: decide whether static keys of this type are retired for the workload.

8.2 Record: time of exposure, detection, deactivation and deletion; whether the key had an owner in the inventory; why a static key existed; why scanning or push protection did not stop it; and what the attacker did or could have done.

Implementation guidance

Prevention controls that shorten this playbook.

Rollout. Phase 1: inventory every long-term cloud key with owner and last use (AWS credential report, Google key authentication metrics). Phase 2: pre-approve responder permissions and test deactivation and reactivation of a non-production key, which is your rollback path. Phase 3: automate D2 for Critical cases (deactivate on alert) once false positives are understood. Small organisations should start by removing unused keys; large ones should route provider notifications straight into [SIEM]. See the API Key Management Guide and Cloud Incident Response Guide.

Framework mapping.

Metrics. Mean time from exposure to deactivation (target under [1] hour for public keys); number of active long-term keys per provider, trending down; percentage of keys with a named owner; percentage of leaks blocked by push protection rather than found after publication; keys unused for 90 days still active.

Common failure patterns.

• Deleting the commit and calling it fixed while the key stays active.
• Removing the AWS quarantine policy to restore service before the investigation finishes.
• Checking only the main region and missing miners or models running elsewhere.
• Rotating the key but leaving the users, keys or roles the attacker created.
• Rotating an Azure storage key without warning teams whose SAS tokens it signed.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• AWS re:Post Knowledge Center: Responding to a potentially compromised AWS account
• AWS: AWSCompromisedKeyQuarantineV3 managed policy
• AWS: Revoke IAM role temporary security credentials
• Google Cloud: Best practices for managing service account keys
• Microsoft: Manage storage account access keys
• GitHub: Secret scanning partner program
• MITRE ATT&CK: Credentials In Files

Related NHI Mgmt Group resources: Leaked Credential Response Playbook · Cloud Credential Compromise Playbook · Secrets Management Guide · API Key Management Guide · SOC Runbook Template