Cloud Detection and Response Guide: Investigating and Containing Attacks in AWS, Azure and Google Cloud

Cloud attackers move from a stolen credential to running workloads in minutes, so a response process built around tickets and next-day forensics loses the race. Cloud detection and response (CDR) is the live part of cloud security: triaging a control plane alert, scoping what the identity behind it can reach, and containing it without breaking production or destroying evidence. This guide covers the CDR loop end to end, the containment actions that actually stop activity in AWS, Microsoft Azure and Google Cloud (and the ones that only look like they do), pre-approved automation, and how to measure the result. It is for SOC analysts, cloud security engineers and incident leads. Rule writing is covered in the Cloud Detection Engineering Guide and evidence handling in the Cloud Forensics Guide; this page sits between them.

Key takeaways

• Contain the identity first, then the workload. Almost every cloud intrusion runs on a credential, so the first question is which principal is acting and what it can reach.
• Disabling a key rarely ends existing sessions. Temporary tokens issued before the change usually stay valid until expiry, so each provider needs its own session revocation step.
• Deactivate, do not delete. Reversible containment keeps the key or principal ID for log queries and lets you undo a false positive quickly.
• Hunt for persistence before declaring containment. New users, keys, roles, trust policy changes and public function URLs survive the revocation of the original credential.
• Pre-approve the playbooks. Decide in advance which actions automation may take alone, which need a human, and which identities and accounts are excluded.

What cloud detection and response covers

CDR is not a product category here but a capability: detecting attacker behaviour in cloud control planes and workloads, then responding fast enough to limit impact. It differs from on-premises response in three ways that shape everything below.

• The control plane is the battleground: attackers act through provider APIs with valid credentials, so detections and containment both target identities, policies and API calls rather than hosts. ATT&CK T1078.004 Cloud Accounts is the usual entry point.
• Speed: in the Amazon AWS Crypto-Mining Campaign 2025, miners were running about ten minutes after the attacker first got in, on container tasks and auto scaling groups that grew to hundreds of instances (T1496.001 Compute Hijacking).
• Containment is policy, not cabling: you isolate by changing IAM policies, trust relationships, security groups and organisation policies, all of which propagate with some delay and all of which can break legitimate workloads.

Posture tooling finds the open doors; CDR deals with someone already walking through one. The CNAPP Guide covers how runtime detection and posture work together in one platform.

The CDR loop: from alert to contained

NIST SP 800-61 Revision 3 (final, April 2025) frames incident response as part of cybersecurity risk management under CSF 2.0, with containment as outcome RS.MI-01 and eradication as RS.MI-02. In the cloud, that loop runs in five steps, ideally within one shift.

1. Triage and validate (RS.MA-02): confirm the principal, the API calls, source IP and user agent. AWS guidance asks the credential owner three things: did you invoke this operation, at this time, from this IP address? If any answer is no, treat it as compromise.
2. Scope the blast radius (RS.AN-03): list what the principal can do now, not what it did. Check attached policies, role assumption paths, cross-account trust and data stores it can read. AWS points responders to the IAM Access Advisor tab for recent service use.
3. Contain (RS.MI-01): cut the identity, then isolate affected workloads, then block the attacker's new access paths. The provider sections below give the specific actions.
4. Verify: watch the audit log for the same key, user or role session for at least 30 minutes after containment, as the AWS credential compromise playbook advises. Continued activity means propagation delay or another credential.
5. Eradicate and hand off (RS.MI-02): remove persistence, then pass evidence to forensics and recovery. Eradication often uncovers more credentials, so expect to loop back to containment.

The full incident lifecycle, communications and notification duties are in the Cloud Incident Response Guide; credential-specific steps are in the Cloud Credential Compromise Playbook.

Containing identities in each cloud

This is where most responses go wrong: an analyst disables a key, sees the alert stop, and closes the case while the attacker's existing session keeps working. The table lists what each action does and does not stop, from the providers' own documentation.

Points that change the plan

• AWS role sessions: revoking sessions affects every user of the role, legitimate workloads included, and cannot be used on service-linked roles. Roles created from IAM Identity Center permission sets are revoked through Identity Center. If the attacker can still call AssumeRole, change the trust policy as well; the trust change blocks new sessions but not existing ones, which is why both steps are needed.
• AWS console passwords: there is no deactivate. Attach a deny-all inline policy, consider deleting the login profile, and remove any MFA device the attacker registered.
• Azure: disabling an administrator needs the Privileged Authentication Administrator role, so make sure responders hold it through just-in-time elevation before an incident, not during one. Where admin credentials may be compromised, Microsoft advises coordinating the disable with a full eviction so every route is cut at once.
• Google Cloud: keys cannot be disabled in the console, only with gcloud iam service-accounts keys disable or the API, so the runbook must include the command and the permission to run it.
• Cross-account and cross-tenant paths: check for AssumeRole calls into other accounts, and repeat containment there. Federation and workload identity trust are covered in the Cloud Workload Identity Guide.

Containing workloads and data

Once the identity is cut, isolate what it touched. The aim is to stop harm while keeping the evidence the forensics team needs.

• Compute: AWS advises a dedicated isolation security group allowing traffic only to and from specific responder IPs, associated with the instance in place of all other groups. AWS notes that existing tracked connections are not terminated by a security group change, only future traffic, so use network ACLs to cut a live attacker connection. Azure network security groups and Google Cloud VPC firewall rules play the same role; test which existing flows survive in each before you need it.
• Snapshot before you terminate: take disk snapshots and capture memory where your tooling allows before replacing an instance, then hand them to forensics. See the Cloud Forensics Guide.
• Instance credentials: credentials taken from the metadata service belong to the instance role, so isolating the instance does not stop their use elsewhere. Revoke the role's older sessions too. See the Cloud Instance Metadata Services Compared Guide.
• Storage: in the Codefinger S3 Ransomware 2025 campaign, stolen keys were used to re-encrypt objects with attacker-supplied keys (SSE-C) and lifecycle rules scheduled deletion within seven days (T1486, T1485). Containment there means freezing lifecycle and bucket policy changes as well as revoking the key. The Cloud Storage Exposure Playbook covers public exposure cases.
• Organisation-level brakes: a temporary deny policy at the organisation, management group or folder level (for example blocking new access key creation or instance launches in one account) contains faster than chasing resources one at a time. Write and test these policies in advance so they are ready to attach; the AWS Organizations and SCPs Guide, Azure Policy and Management Groups Guide and Google Cloud Organization Policy Guide cover the mechanics.

Hunting for persistence before you close

Attackers expect their first credential to be found. The AWS credential compromise playbook lists the persistence to look for after containment, and the crypto-mining campaign above used several of these at once.

Search by principal and by time window, then by the resources each new object can reach. Persistence created through a second compromised identity will not show up under the first one, so pivot on source IPs and user agents too. Log source requirements are in the Cloud Logging and Audit Trail Guide.

Automating response safely

Automation is what lets CDR keep pace, and also what causes self-inflicted outages. NIST SP 800-53 IR-4(1) calls for automated incident handling processes; the design question is which actions run without a human.

• Exclusion lists: break-glass accounts, the responders' own roles and the automation's own identity must never be auto-contained. See the Break-Glass Account Guide.
• The automation is a privileged identity: a function that can revoke sessions and rewrite policies across the organisation is a prime target. Give it its own role, scoped to containment actions, and alert on any use outside its pipeline. The SOAR and Security Automation Guide covers playbook design.
• Rollback: every automated action writes what it changed, so an analyst can reverse it in one step if the alert was a false positive.

Decision guidance

• Native provider detections or a third-party platform: native services cover each cloud deeply and cheaply; a cross-cloud platform helps when one team responds across several providers and needs one identity view. Either way, containment uses the provider APIs above. Evaluation criteria are in the Cloud Detection and Response Buyer's Guide.
• Contain now or watch: if the activity could be legitimate, investigate before acting to avoid disruption, as the AWS playbook advises. Contain immediately when you see data destruction, mass resource creation, or changes to logging.
• Small teams: pre-write three runbooks (leaked key, compromised human admin, compromised workload identity), store the commands, and rehearse them. Lean on provider support for scoping help.
• Large estates: run containment from a central security account with delegated rights in every account, subscription and project, and test that reach quarterly.

Where identity fits

Most cloud incidents are identity incidents. Workload identities, CI/CD roles and long-lived access keys are frequent entry points because they skip MFA and rarely have an owner on call when they misbehave. Your CDR runbooks should record, for every non-human identity, the owner to call and what breaks if it is disabled; without that, responders hesitate. See the Cloud Access Key Leak Playbook and the Cloud PAM and CIEM Guide.

Detection and measurement

• Mean time to contain (MTTC): from first alert to confirmed containment, measured in minutes, per incident type.
• Containment verified rate: share of incidents where post-containment log review confirmed no further activity from the principal.
• Persistence found after containment: count of new keys, roles or resources discovered in the hunt step; a rising number means attackers are faster or detection is later.
• Runbook coverage: share of high-severity detection types with a tested containment runbook.
• Automation reversal rate: share of automated actions rolled back as false positives, which tells you whether confidence thresholds are right.
• Responder reach: share of accounts, subscriptions and projects where the response role works, tested by drill.

Framework mapping

Common failure patterns

• Disabling the key and closing the case: existing temporary sessions keep working. Revoke sessions explicitly in each cloud.
• Stopping the miners, missing the backdoor: new IAM users, function URLs and termination-protected instances outlive the original credential, as the crypto-mining campaign showed.
• Deleting first: deleted keys and users remove the identifiers you need for log queries and cannot be undone if the alert was wrong.
• Responders without rights: the on-call analyst cannot disable an admin or attach a policy at 2am because the role was never granted or tested.
• Automation without exclusions: a playbook revokes the break-glass account or a production deployment role and turns an alert into an outage.
• Trusting a security group change to cut a live session: tracked connections survive; plan a network ACL or equivalent step.

Practitioner checklist

• Write and rehearse containment runbooks for leaked keys, compromised human admins and compromised workload identities in each cloud you use.
• Include session revocation as a separate step from key or account disablement in every runbook.
• Pre-grant responders the roles needed to disable admins, revoke sessions and attach deny policies, through just-in-time elevation.
• Keep an isolation security group or firewall rule set ready in every network, plus a network ACL step for live connections.
• Snapshot and capture evidence before terminating or deleting anything.
• Run a persistence hunt (keys, roles, trust policies, compute, public endpoints, logging changes) before closing any case.
• Define which actions automation may take alone, with exclusion lists for break-glass and response identities.
• Monitor the audit log for 30 minutes after containment and record every action with time and actor.
• Track MTTC, verified containment and persistence found, and review them monthly.

Standards and references

• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• AWS: Revoke IAM role temporary security credentials
• AWS Samples: IAM Credential Compromise Incident Response Playbook
• AWS: Remediating a potentially compromised Amazon EC2 instance
• Microsoft Learn: Revoke user access in Microsoft Entra ID
• Microsoft Learn: Compromised and malicious applications investigation
• Google Cloud: Disable and enable service account keys
• Google Cloud: Disable and enable service accounts

Related NHI Mgmt Group resources: Cloud Incident Response Guide · Cloud Detection Engineering Guide · Cloud Forensics Guide · Cloud Credential Compromise Playbook · CNAPP Guide