PlaybooksCloud account compromised
Accesscritical60 minutes to prepare

Cloud account compromised

An attacker may control cloud identities, infrastructure, data, logs, or the account's billing and recovery settings.

01DetectConfirm the signal
02ContainStop more damage
03RecoverRestore control
04VerifyProve it works

Your preparation

0 of 0 safeguards ready
0%
Incident worksheet

Make the next decision with evidence

Establish a clean administrative path, stop attacker control without destroying evidence, and inventory every affected identity, workload, region, and data store.

EvidenceDecisionActionProof

Capture before evidence disappears

  • Export control-plane audit logs, identity sign-ins, access-key use, role assumptions, policy changes, organization changes, and billing events to an external evidence account.
  • Snapshot suspicious instances, functions, containers, startup scripts, images, network rules, DNS records, and storage policies before removing them.
  • Record new users, keys, roles, federation providers, API tokens, support contacts, recovery methods, and logging changes across every region.
  • Preserve data-access logs for databases, object stores, secrets, snapshots, queues, and backup vaults, including failed attempts.

Decisions that change the response

QuestionAct whenAction
Use the existing admin account?Its device, email, MFA, federation, or recovery path may be compromised.Use the provider's emergency recovery route from a clean device and create a known-good incident role.
Isolate or terminate resources?A resource is malicious but still contains volatile evidence or business data.Remove network and identity access, snapshot it, then terminate from trusted infrastructure.
Rebuild the account?Root trust, organization control, logging, images, or broad administrator identities cannot be proven clean.Move critical workloads into a new controlled account using reviewed infrastructure and new secrets.

Proof that recovery worked

  • Root, organization, federation, users, roles, policies, keys, support contacts, and recovery methods match a signed inventory.
  • Audit and data logs flow to an account the production administrators cannot alter.
  • Infrastructure comparison finds no unexplained resources, network paths, scheduled work, images, or policies in any region.
  • Old credentials and attacker-created identities fail while production works through newly issued access.

Controls to put in place

  • Separate organization, security, logging, backup, and production accounts with narrow cross-account roles.
  • Protect root and emergency access with hardware-backed MFA and offline recovery material.
  • Use infrastructure as code plus continuous drift, public-access, cost, and threat-detection alerts.
  • Keep immutable logs and recovery backups outside the production administration boundary.
Tabletop drill

Create a harmless administrator and public security rule in a sandbox account. Recover from a clean role, export evidence, isolate a test instance, find cross-region changes, and rebuild one service from code.

Escalate when

Open the provider's security case immediately when root or organization control is affected. Add incident responders, insurer, counsel, and regulators when data access, cryptomining cost, destructive actions, or customer impact is possible.

What this means

Cloud compromise can spread quickly because one identity may create new administrators, copy data, disable logs, deploy mining workloads, or destroy backups. Keep one known-good recovery identity outside normal daily access.

Do not begin by deleting resources. Preserve logs and contain identities first. A strange server may be both evidence and an active cost.

Warning signs

  • New users, roles, keys, policies, regions, projects, or subscriptions.
  • Security alerts, budget spikes, or resources nobody created.
  • Logging, backups, billing contacts, or security services are disabled.
  • Storage becomes public or data is copied unexpectedly.
  • Root, owner, or administrator credentials change.

Recover now

First 15 minutes

  1. Use the emergency administrator from a trusted device. Verify the provider URL and secure the recovery email first.
  2. Open a provider security case. State that this is an active account compromise and record the case number.
  3. Preserve control-plane logs. Export identity, audit, security, billing, network, storage, and resource-creation events to a protected location.
  4. Contain the known identity. Disable or restrict compromised users, keys, roles, sessions, federation, and automation. Avoid removing your only recovery path.
  5. Apply spend controls. Stop clearly malicious workloads and raise billing alerts. Preserve snapshots or metadata when investigation matters.

Today

  1. Build a timeline of identity, policy, logging, network, resource, data, backup, and billing changes.
  2. Find persistence: new administrators, access keys, trust policies, service principals, functions, startup scripts, snapshots, API tokens, and federation.
  3. Rotate credentials in the cloud and every connected CI/CD, source-control, monitoring, and vendor system.
  4. Rebuild affected workloads from trusted infrastructure configuration and images.
  5. Verify storage permissions, network rules, encryption keys, backups, DNS, and logging.
  6. Determine whether data was accessed or exported. Get security and legal help for serious exposure.

Verify recovery

  • Root, owner, administrator, federation, and recovery settings are known and protected.
  • Every identity, key, role, policy, and trust relationship has an owner and purpose.
  • Logs and security services are enabled and delivered outside normal workloads.
  • Malicious resources are gone and billing has returned to expected levels.
  • Rebuilt services use newly issued credentials.
  • No continuing suspicious activity appears across regions and projects.

Prepare now

Access

  • Daily work never uses the root or owner identity.
  • A protected emergency administrator is tested and monitored.
  • Strong 2FA is required for privileged identities.
  • Long-lived keys are minimized, owned, and reviewed.

Evidence and cost

  • Control-plane logs are retained in a separate protected account or project.
  • Security alerts cover new administrators, disabled logs, public storage, and unusual regions.
  • Budget alerts and quotas detect sudden spend.
  • Backups cannot be deleted by normal production identities.

Practice

  • A drill has disabled a test credential, found its actions in audit logs, and rebuilt one workload with replacement secrets.

Common mistakes

  • Deleting suspicious resources before exporting logs. You destroy evidence and may miss persistence.
  • Rotating keys only in the cloud console. Connected CI/CD systems may still hold old or stolen credentials.
  • Checking one region. Attackers often create resources in regions you do not normally use.
  • Keeping logs in the compromised account only. An administrator can alter retention or delete them.
  • Recovering workloads before identity. The attacker can compromise the replacement.

Sources

Last reviewed July 19, 2026Guidance changes. Confirm provider-specific actions in the linked official sources.