The Cloud Kill Chain

Cloud environments don’t have a network perimeter to defend. The attacker doesn’t need to break through a firewall — they need one valid credential. Everything that follows is API calls.

Why Cloud Changes the Attack Model

Traditional network-centric thinking fails in cloud for three reasons:

1. There is no “inside.” Every resource is accessed via authenticated API call — whether from within the cloud VPC or from the attacker’s laptop across the internet. Protecting the network edge does not protect cloud resources.

2. Misconfiguration is the vulnerability class. The most common cloud breaches don’t exploit software vulnerabilities — they exploit misconfigured S3 bucket policies, overpermissioned IAM roles, and publicly exposed storage. No CVE required.

3. Identity is the perimeter. Valid credentials grant resource access regardless of source IP. A stolen API key or OAuth token is equivalent to physical access in an on-prem model — the attacker is already “inside.”

┌─────────────────────────────────────────────────────────┐
│              CLOUD KILL CHAIN                           │
├─────────────────────────────────────────────────────────┤
│ 1. INITIAL ACCESS                                       │
│    Credential theft (leaked keys, phished tokens)       │
│    SSRF → metadata service credential theft             │
│    OAuth consent phishing                               │
├─────────────────────────────────────────────────────────┤
│ 2. DISCOVERY                                            │
│    Enumerate IAM permissions (GetCallerIdentity)        │
│    List accessible resources (S3, EC2, RDS, Secrets)    │
│    Identify high-privilege roles to target              │
├─────────────────────────────────────────────────────────┤
│ 3. PRIVILEGE ESCALATION                                 │
│    AssumeRole to more privileged role                   │
│    Create IAM user / attach AdministratorAccess         │
│    Exploit iam:PassRole or iam:CreatePolicy             │
├─────────────────────────────────────────────────────────┤
│ 4. PERSISTENCE                                          │
│    Create backdoor IAM user with long-lived credentials │
│    Add malicious Lambda trigger or EC2 user data        │
│    OAuth app persistent consent                         │
├─────────────────────────────────────────────────────────┤
│ 5. COLLECTION / IMPACT                                  │
│    Bulk download S3 buckets (T1530)                     │
│    Snapshot and export EBS volumes (data theft)         │
│    Encrypt resources for ransomware                     │
│    Cryptocurrency mining (resource hijack)              │
└─────────────────────────────────────────────────────────┘

Each step is an API call — and each API call (when control plane logging is enabled) appears in the log trail.

Log Sources: What You Have and What You Don’t

Provider	Control Plane	Data Plane	Identity/Auth
AWS	CloudTrail (enabled by default in most orgs)	S3 Server Access Logs, CloudFront (must enable)	IAM Access Advisor, Access Analyzer
Azure	Activity Log (retained 90 days)	Storage Analytics, Diagnostic Logs	Azure AD Sign-in Logs, Audit Logs
GCP	Cloud Audit Logs: Admin Activity (always on), Data Access (must enable)	GCS access logs, BigQuery logs	Google Workspace Admin, Login audit

The critical gap: data plane logging is often disabled by default due to cost and volume. An attacker who exfiltrates 10 TB from an S3 bucket leaves no trace if S3 access logging is off. Before hunting or writing detection rules for cloud data exfiltration, verify that data plane logging is enabled.

The Metadata Service: SSRF to Cloud Takeover

Web App on EC2 (IMDSv1)
         │
         │ HTTP GET request
         │ (attacker-controlled URL)
         ▼
http://169.254.169.254/latest/meta-data/iam/security-credentials/
         │
         │ Returns:
         │ { AccessKeyId, SecretAccessKey, Token }
         ▼
Attacker has temporary credentials for the EC2 instance's IAM role

AWS IMDSv2 requires a session token obtained via PUT request — SSRF using GET-only can’t obtain this token, breaking the attack path. Detection: CloudTrail event GetSessionToken or API calls from the instance’s role to unusual services or regions.

Cloud vs On-Prem Detection Comparison

Dimension	On-Prem Detection	Cloud Detection
Primary log source	Endpoint (Sysmon, WEL)	Control plane (CloudTrail, Activity Log)
Key artifact	Process creation, file write	API call (action, principal, resource)
Privilege escalation signal	Token impersonation, SUID abuse	`iam:CreateUser`, `iam:AttachUserPolicy`
Lateral movement signal	SMB traffic, PsExec, WinRM	`sts:AssumeRole`, cross-account API calls
Persistence signal	Registry Run key, scheduled task	New IAM user, Lambda trigger, OAuth grant
Exfiltration signal	Large outbound network transfer	S3 GetObject on bulk objects, snapshot export
Data source blind spot	Kernel-level rootkits	Disabled data plane logging

What Makes Cloud Detection Harder

Ephemeral resources. Lambda functions run for seconds. Container tasks spin up and down. By the time an alert fires, the resource may no longer exist — there’s no host to forensicate. Detection must operate on API call logs, not host artifacts.

Shared responsibility confusion. Cloud providers secure the infrastructure; the customer secures workloads and configurations. Misunderstanding the boundary leads to gaps — “the cloud provider handles security” is wrong; IAM misconfiguration is entirely the customer’s responsibility.

Multi-cloud blind spots. An organization using AWS, Azure, and GCP has three separate control plane log pipelines, three separate SIEM connectors, and three separate alert tuning queues. Attackers who move between clouds exploit the seams.

ATT&CK for Cloud Matrix— MITRE Cloud Security Docs— Community

Retrieval Practice

An attacker compromises an EC2 instance running a web application and exploits an SSRF vulnerability. The EC2 instance has an IAM role with S3 read access. Walk through the complete attack path and the CloudTrail events it generates.

Reveal answer

Step 1: SSRF exploited → attacker sends request to http://169.254.169.254/latest/meta-data/iam/security-credentials/[role-name]. No CloudTrail event for the metadata service call itself (it's an EC2 internal API). Step 2: Attacker uses returned credentials to call the AWS API from their own IP. First API call is typically GetCallerIdentity to confirm the credentials work — CloudTrail: GetCallerIdentity from external IP using the EC2 role's credentials. Step 3: Discovery — ListBuckets, ListObjects to find accessible data — CloudTrail: S3:ListBuckets, S3:ListObjects from external IP. Step 4: Exfiltration — GetObject on target files. CloudTrail: S3:GetObject events (IF S3 data event logging is enabled). Detection signals: (1) GetCallerIdentity from a non-AWS IP using an EC2 instance role (role credentials used from outside the instance). (2) S3 API calls from an unexpected source IP for this role. (3) Unusual volume of S3:GetObject calls.

Retrieval Practice

Your organization uses AWS. CloudTrail is enabled but S3 data event logging is disabled. An attacker exfiltrates 50 GB from an S3 bucket. What evidence do you have, and what evidence don't you have?

Reveal answer

Evidence you DO have: (1) S3:GetBucketAcl, S3:ListBucket — attacker discovery of the bucket via management API (CloudTrail). (2) Any IAM events leading up to the access (credential creation, role assumption). (3) Source IP of the API calls (CloudTrail always captures this for management events). Evidence you DON'T have: (1) Which specific objects were downloaded — S3 data events (PutObject/GetObject/DeleteObject at object level) require explicit enablement. Without them, you know the attacker listed the bucket but not which files were exfiltrated. (2) Volume of data transferred — CloudTrail doesn't include response body sizes. Lesson: S3 data event logging is mandatory for any bucket containing sensitive data, despite its cost. The detection gap is known and documented — remediate it before the breach, not after.