Cloud Breach Response Plan: Leaked Keys, Rogue IAM and Data Export

Most cloud breaches start with a credential: a leaked access key, a stolen console session, or a role with far more permission than it needs. The response that works: deactivate the credential without destroying its record, hunt for the persistence the attacker built, check what your logs can actually prove, and scope what was read. Deleting things quickly feels like containment, but it often removes the evidence you need to know how far it went. This guide is the cloud playbook in the master plan and playbooks structure; the incident response hub has the rest. Examples use AWS terms; the same steps apply in Azure and Google Cloud under different names.

What counts as a cloud breach?

• An access key used from an unknown location, or found in a public repository or build log.
• IAM users, roles or policies you did not create.
• Storage made public, or bulk downloads from a bucket.
• A spike in compute spend, often crypto-mining in regions you do not use.
• A console sign-in through single sign-on by an identity that was itself compromised. That is a hand-off from the identity playbook.

What should you do first when a cloud key leaks?

1. Declare under the master plan. Get the cloud team emergency change authority; IAM changes cannot wait for a maintenance window.
2. Deactivate the key, do not delete it. Deactivation stops it working and keeps its last-used record.
3. Attach an explicit deny-all policy to the user or role, which covers any other credential on that identity you have not found yet.
4. Snapshot the audit trail and export it to a place the attacker cannot reach.
5. List every call the key made, across all regions, from its first unexpected use.
6. Hunt for persistence (next section) across every account in the organisation.

Keys pushed to public repositories are usually found by automated scanners within minutes, so assume use even if the exposure was brief. The Cloud Breach Response Checklist has each step with owners and sample answers.

How do attackers keep access to a cloud account?

Attackers with enough permission rarely rely on the key they arrived with. Look for:

• New IAM users with access keys, often named to look like service accounts.
• Extra access keys on existing users (each user can usually hold two).
• Roles that trust an external account. No key to rotate and no user to delete: anyone in the trusted account can assume the role.
• New identity providers or federation settings.
• Changed serverless functions or scheduled jobs that recreate access.
• Compute backdoors: new SSH keys, instance profiles with broad roles, or user-data scripts.
• Organisation-level changes: new accounts, or weakened guardrail policies.

An access analyser that reports external trust, plus a search of the audit trail for create and attach actions in the window, finds most of these. Then add organisation-level guardrails that block new IAM users, long-lived keys and trust to unknown accounts, so the next attempt fails.

What if your logs don’t cover it?

This is where most cloud investigations stall. As a rule:

• Control-plane actions (create user, attach policy, create key) are logged by default. In AWS, CloudTrail event history keeps 90 days of management events.
• Data reads (downloading an object, reading a table) usually are not, unless you turned on data-event or data-access logging, or storage server access logs. Google Cloud keeps Admin Activity audit logs by default but most Data Access audit logs are off until enabled.
• Network flow logs are off until you enable them.
• Identity sign-in logs often have short default retention, sometimes 7 to 30 days.

If you cannot prove which objects were read, you may have to treat everything the credential could read as taken, which is far more expensive in a data breach. The Cloud Logging Gap Checker shows which incident questions your current settings can answer and which setting closes each gap. Do it before the incident.

How do you scope data exposure in the cloud?

1. List every storage bucket, database and secret store the compromised identity could read.
2. For each, check whether access logs exist for the window.
3. Where they do, list the exact objects read and the volume.
4. Where they do not, record that the exposure cannot be ruled out.
5. Hand the list to the data breach playbook for counting people and starting the notification clocks.

What about crypto-mining and runaway spend?

Mining is the commonest quick payoff from a stolen cloud key. Signs: new instances in unused regions, quota increase requests, and a spend spike. Stop the instances, keep a snapshot of one for evidence, and contact the provider’s support, which often helps with fraudulent usage charges when you act quickly. Budget alerts per account and region are the cheapest early warning there is.

What is the provider’s role?

Under the shared responsibility model the provider secures the platform; you secure your identities, keys, configuration and data. The provider will not run your investigation, but open a support case early: they can confirm abuse, sometimes share additional detail, and help with billing. Report external accounts used in the attack to their abuse team.

Checklist: cloud breach response

• Incident declared; emergency change authority confirmed.
• Compromised key deactivated (not deleted); explicit deny attached.
• Audit trail snapshotted and exported out of the account.
• Every call by the credential listed across all regions.
• Persistence hunted: users, keys, external trust, identity providers, functions, compute.
• Organisation guardrails added against new users, long-lived keys and unknown trust.
• Logging gaps recorded honestly in the incident log.
• Data stores the identity could read listed and scoped.
• Spend checked in every region; provider support case open.
• Data breach playbook opened if personal data was reachable.

Practise the first hour in the Leaked Cloud Key Lab, and run the full identity-to-cloud-to-data cascade in the Cascade Incident Lab.

Frequently asked questions

What should I do if an AWS access key is leaked? Deactivate the key rather than deleting it, so its ID and last-used information remain for the investigation, and attach an explicit deny policy to the user. Review the audit trail for every call made with the key, across all regions, and look for new IAM users, keys, roles and trust policies created with it. Rotate the key for its legitimate use only after you know what it was used for.

Why deactivate a cloud access key instead of deleting it? Deactivating stops the key working immediately but keeps its record, including when and where it was last used, which helps you trace what the attacker did. Deleting removes that record. Delete it later, once the investigation no longer needs it.

Are cloud storage reads logged by default? Often not. Major providers log control-plane actions such as creating users or changing policies by default, but reads of individual objects in storage usually need data-event or data-access logging, or storage server access logging, to be turned on. Without it you may be unable to prove what data was or was not taken.

How do attackers keep access to a cloud account? Common methods are new IAM users with access keys, extra keys on existing users, roles that trust an external account, new identity providers or federation settings, code added to serverless functions, new SSH keys or instance profiles on compute, and changes to organisation-level settings. Each survives a password reset or a single key rotation.