APT groups have adapted their techniques for cloud infrastructure. This article examines the cloud APT kill chain — from initial access through privilege escalation, lateral movement across accounts, and data exfiltration — with detection patterns for each stage.
Sign in to mark this article as read and track your progress.
Advanced Persistent Threat (APT) groups — typically nation-state or state-sponsored actors — initially focused their cloud capabilities on cloud as a target (stealing data from cloud storage) and cloud as a tool (using cloud compute for C2). By 2022, groups including Cozy Bear (APT29), LAPSUS$, and SCATTERED SPIDER had developed cloud-specific TTPs that leverage cloud-native services for every phase of the attack lifecycle.
The cloud kill chain differs from the traditional Lockheed Martin Cyber Kill Chain in several important ways:
| Phase | Traditional Kill Chain | Cloud APT Adaptation |
|---|---|---|
| Reconnaissance | Network scanning, OSINT | Enumerate public S3 buckets, public ECR images, CloudFront origins |
| Initial Access | Phishing, exploit | Phishing for cloud console credentials, SSRF for IMDS creds, compromised CI/CD |
| Execution | Malware dropped on endpoint | Lambda function deployed, ECS task modified, cloud-native tooling abused |
| Persistence | Registry run keys, scheduled tasks | IAM backdoor user, rogue Lambda trigger, S3 event notification to attacker endpoint |
| Privilege Escalation | Local admin exploit | IAM policy confusion, iam:PassRole abuse, sts:AssumeRole chaining |
| Lateral Movement | Pass-the-hash, RDP | Cross-account role assumption, federated access token abuse |
| Exfiltration | FTP, encrypted channel | S3 cross-account replication to attacker-controlled bucket |
The most common initial access techniques (mapped to MITRE ATT&CK):
| Technique ID | Name | How It Works |
|---|---|---|
| T1078.004 | Valid Accounts: Cloud Accounts | Stolen credentials used directly; phishing most common vector |
| T1190 | Exploit Public-Facing Application | SSRF, SQL injection, RCE in cloud-hosted web application |
| T1552.005 | Unsecured Credentials: Cloud Instance Metadata | SSRF to IMDS (see separate topic) |
| T1195.001 | Supply Chain Compromise: Compromise S/W Dependencies | Malicious npm/pip package in Lambda or container image |
Cloud IAM privilege escalation relies on misconfigured policies rather than kernel exploits. The Rhino Security Labs team documented over 20 IAM privilege escalation paths in AWS. Common patterns:
1. iam:PassRole + service creation
If a user can call ec2:RunInstances and iam:PassRole, they can launch an EC2 instance with a more privileged role than their own, then use that instance's credentials.
2. Lambda function creation
If a user can call lambda:CreateFunction and iam:PassRole, they can deploy a Lambda function with an admin execution role. The function code calls sts:GetCallerIdentity or writes secrets to S3.
3. sts:AssumeRole without condition check
A trust policy that allows * principal (or Principal: "arn:aws:iam::*:root") to assume a role allows any authenticated AWS principal — in any account — to assume that role. This is the cloud equivalent of "anyone in the world can escalate to admin."
A cloud attack rarely ends in the account it starts in. The target's production data is often in a different account. Attackers chain role assumptions:
Compromised account (dev)
→ sts:AssumeRole → staging account
→ sts:AssumeRole → production account
→ access production database
This is possible when:
Detection signal: sts:AssumeRole events in CloudTrail where the userIdentity.type is AssumedRole and the source account differs from the target. Alert on cross-account role assumptions that were not seen in the previous 30 days (baseline normal behaviour and detect deviations).
| Technique | How It Works | Detection |
|---|---|---|
| S3 cross-account replication | Attacker creates a replication rule pointing to their bucket | CloudTrail: PutBucketReplication event; alert on replications to unknown accounts |
| Lambda data forwarding | Lambda posts data to external HTTP endpoint | VPC Flow Logs: outbound HTTPS to unknown IPs from Lambda VPC |
| Snapshot sharing | EBS volume shared with attacker's AWS account ID | CloudTrail: ModifySnapshotAttribute with external account ID |
| Glacier archive copy | Copy data to Glacier, then retrieve to external account | CloudTrail: CopyObject, InitiateJob with cross-account parameters |
Every SOC analyst working cloud environments should alert on:
cloudtrail:StopLogging — attacker disabling audit trail
iam:CreateUser — new IAM user created (backdoor)
iam:AttachUserPolicy — policy attached to new user
iam:CreateAccessKey — access key created for any user
ec2:ModifyInstanceMetadataOptions — IMDS downgraded to v1
s3:PutBucketReplication — replication rule added
sts:AssumeRole (cross-account) — role assumption to external account
lambda:CreateFunction (admin role) — privileged Lambda created
These events should generate near-real-time alerts in CloudWatch Metrics or SecurityHub. Do not rely on daily log review — APT exfiltration completes in hours.