Cloud Account Compromise Response Playbook

What This Playbook Covers

This playbook covers the detection and response for cloud account compromises across AWS, Azure, and GCP. Each cloud provider has different identity systems, audit capabilities, and containment mechanisms
Cloud account compromise is distinct from SaaS account takeover. This playbook focuses on the cloud infrastructure provider accounts (AWS IAM users, Azure AD service principals, GCP service accounts), not the SaaS applications running on top
MITRE ATT&CK maps cloud account compromise under T1525 (Implant Cloud Image), T1556 (Modify Authentication Process), and T1078 (Valid Accounts) for cloud accounts

Cloud-Specific Attack Vectors

Vector	How It Works	Most Affected Provider
Stolen API keys	Hardcoded/leaked cloud API keys (AWS access keys, Azure service principal secrets)	All — AWS most common due to broad IAM key usage
Compromised IAM user/role	Credential theft + MFA bypass for cloud console	All
Cloud shell access	Attacker uses stolen console access to launch cloud shells (AWS SSM, Azure Cloud Shell, GCP Cloud Shell)	All
Cross-account role chaining	Attacker uses compromised account to assume roles into other accounts	AWS Organizations, Azure Lighthouse
Metadata service abuse	SSRF to cloud metadata service (`169.254.169.254`) to retrieve temporary credentials	AWS (IMDS), GCP (metadata), Azure (IMDS)
Cloud-to-cloud lateral movement	Compromised cloud account used to access other connected cloud services	Any with OAuth or service-to-service integration

Phase 0: Detect the Cloud Compromise (0-15 minutes)

Detection Indicators by Cloud Provider

AWS — CloudTrail:

Look for these signals in CloudTrail events:
• IAM credentials retrieved from unusual IPs (GetFederationToken, AssumeRole)
• ConsoleLogin from unexpected locations or without MFA
• RunInstances from an IAM user who has never launched instances
• CreateAccessKey for an IAM user who already has keys
• CreateUser, AttachUserPolicy from unusual sources
• S3 Bucket policy changes (PutBucketPolicy) from anomalous principals

Azure — Activity Log:

Look for these signals in Azure Activity Log:
• Login from unusual IP with a new device
• Privileged Role Activation outside business hours (PIM activation)
• Service Principal credential creation from unexpected users
• Subscription policy modification from non-admin accounts
• Resource creation in a region the account has never used
• Key Vault access from unusual source IPs

GCP — Audit Logs:

Look for these signals in GCP Admin Activity audit logs:
• IAM policy changes on service accounts (SetIamPolicy)
• Service account key creation (CreateServiceAccountKey)
• Compute instances created with custom service accounts
• Cloud Storage bucket IAM policy modification
• VPC network creation or firewall rule changes

index=aws eventName="ConsoleLogin"
| search additionalEventData.MFAUsed != "Yes"
| stats count by userIdentity.arn, sourceIPAddress, _time
| eval is_new_ip = if(match(sourceIPAddress, known_user_ips), 0, 1)
| where is_new_ip = 1
| eval alert = "HIGH — console login without MFA from new IP " . sourceIPAddress . " for user " . userIdentity.arn
| table _time, userIdentity.arn, sourceIPAddress, alert
| sort - _time

Phase 1: Immediate Containment (15-30 minutes)

Critical Actions — Do These First

For all cloud providers:

Identify the compromised credential type — IAM user key, service principal secret, console password, or federated role assumption
Rotate/deactivate the credential — rotate the specific compromised key or secret. Do not disable the entire account if only a key is compromised
Revoke active sessions — invalidate all active console sessions (AWS — RevokeSessions, Azure — Revoke-AzureADUserAllRefreshToken)
Scope the blast radius — determine what IAM policies/permissions are attached to the compromised credential
Block the source IP — add the attacker’s IP to a deny list at the cloud perimeter or in network ACLs

Provider-Specific Containment

AWS:

# Deactivate the compromised access key
aws iam update-access-key --access-key-id AKIAEXAMPLE --status Inactive

# If the user is compromised, create a policy that denies all actions
aws iam put-user-policy --user-name compromised-user --policy-name deny-all --policy-document '{"Version":"2012-10-17","Statement":[{"Effect":"Deny","Action":"*","Resource":"*"}]}'

# Revoke all active sessions
aws iam delete-service-specific-credential --user-name compromised-user

Azure:

# Revoke all refresh tokens
Revoke-AzureADUserAllRefreshToken -ObjectId <user-object-id>

# Revoke service principal credentials
Remove-AzureADServicePrincipalPasswordCredential -ObjectId <sp-object-id> -KeyId <key-id>

# Disable the user
Set-AzureADUser -ObjectId <user-object-id> -AccountEnabled $false

GCP:

# Disable the service account key
gcloud iam service-accounts keys disable <key-id> --iam-account=<sa>@<project>.iam.gserviceaccount.com

# Disable the user (requires Cloud Identity or Workspace)
gcloud alpha cloud-identity users update --user=<email> --suspended=true

What NOT to Do

Action	Why It’s Dangerous
Disable the entire AWS account	The organization may need the account for other legitimate workloads. Scope containment to the compromised principal.
Delete IAM users	Deletion destroys audit trail. Deactivate, investigate, then determine disposition.
Assume only one credential is compromised	The attacker may have created new credentials during their access window. Check for CreateAccessKey, CreateServicePrincipal, CreateServiceAccountKey events.
Ignore cross-account access	The attacker may have assumed roles into other accounts. Check CloudTrail for AssumeRole events.

Phase 2: Evidence Preservation (30-90 minutes)

Evidence by Cloud Provider

Evidence Type	AWS	Azure	GCP
Authentication logs	CloudTrail Management Events	Azure AD Sign-in Logs	GCP Admin Activity Audit Logs
Resource access logs	CloudTrail Data Events	Azure Activity Log	GCP Data Access Audit Logs
All activity timeline	CloudTrail LookupEvents	Azure Activity Log export	GCP Logging export to BigQuery
IAM policy snapshots	IAM policy versions for affected principals	Azure AD role assignments	IAM policy bindings
Resource inventory at compromise time	AWS Config snapshots	Azure Resource Graph	GCP Asset Inventory
Network flow logs	VPC Flow Logs	NSG Flow Logs	VPC Flow Logs

Phase 3: Investigation (1-4 hours)

Questions to Answer

Question	Evidence Source	How to Determine
How was the initial compromise achieved?	CloudTrail/Sign-in logs — credential stuffing, IMDS abuse, leaked API key, phishing	Follow the first anomalous authentication event for the compromised principal
What resources were accessed?	Data event logs, resource access logs	List every API call and resource access during the compromise window
What data was exfiltrated?	S3 access logs, Azure storage logs, GCP Cloud Storage logs	Check for large data transfers, GetObject/BLOB calls, bucket downloads
Were new credentials created?	IAM audit — CreateAccessKey, CreateServicePrincipal, CreateServiceAccountKey	List all new credentials created during the compromise window
Was lateral movement performed?	AssumeRole events, cross-account access logs	Check for role assumption into other accounts
Were resources modified or deleted?	Resource modification logs	Check for EC2/TerminateInstances, DeleteBucket, resource deletion events
Is the attacker still active?	Active sessions, recent CloudTrail events	Check for continued API calls from the attacker’s IP

Phase 4: Recovery and Hardening

Recovery Actions

Action	Detail	Timeline
Rotate all credentials for the compromised account	Access keys, console passwords, service principal secrets	Immediate
Review and restrict IAM policies	Remove excessive permissions. Apply least privilege.	1-4 hours
Audit resource modifications	Identify and revert any attacker-made resource changes	4-8 hours
Restore compromised resources	Rebuild compromised EC2 instances, lambda functions, or containers from known-good state	4-24 hours
Review cross-account trust relationships	Verify that only authorized roles can assume roles across accounts	2-4 hours
Enable mandatory MFA	Require MFA for all console access and critical API operations	Ongoing

Long-Term Hardening

Control	What It Prevents	Implementation
SCP (Service Control Policies)	Cross-account action limits	AWS Organizations SCPs to restrict risky actions across all accounts
Azure Policy	Resource configuration drift	Azure Policy to enforce MFA, audit logging, and encryption
GCP Organization Policies	Organization-wide security baselines	GCP Organization Policy constraints for resource location, service usage
Cloud Security Posture Management (CSPM)	Configuration drift detection	AWS Security Hub, Azure Defender, GCP Security Command Center
IAM Access Analyzer	Unintended resource exposure	AWS IAM Access Analyzer, Azure AD Permissions Management, GCP Policy Analyzer
Short-term credentials	Stolen long-lived API keys	Use IAM roles with STS (AWS), managed identities (Azure), service account keyless auth (GCP)
Cloud workload protection	Instance/container compromise	AWS GuardDuty, Azure Defender for Cloud, GCP Security Command Center

Cloud Threats — detection and response for T1525, T1552, T1613 techniques
Cloud Security Fundamentals — detection and response for T1525 techniques
Cloud Incident Response — detection and response for T1525, T1526, T1078, T1530 techniques
SaaS Account Takeover Response — detection and response for T1078 techniques
Suspicious Authentication — detection and response for T1078 techniques

What This Playbook Covers

Cloud-Specific Attack Vectors

Phase 0: Detect the Cloud Compromise (0-15 minutes)

Detection Indicators by Cloud Provider

Key SPL Query — AWS Cloud Console Anomalous Login

Phase 1: Immediate Containment (15-30 minutes)

Critical Actions — Do These First

Provider-Specific Containment

What NOT to Do

Phase 2: Evidence Preservation (30-90 minutes)

Evidence by Cloud Provider

Phase 3: Investigation (1-4 hours)

Questions to Answer

Phase 4: Recovery and Hardening

Recovery Actions

Long-Term Hardening

Related

Sources