Cloud and SaaS Attacks: Owning the Control Plane, Not the Host

Cloud and SaaS attacks abuse the control plane, identity (IAM) and cloud services rather than deploying host malware. This is distinct from OAuth consent phishing and token theft: the focus here is credential and key abuse, instance-metadata SSRF, over-permissioned roles and privilege escalation, and cloud ransomware or extortion. It matters because a single identity or key compromise can traverse IaaS, PaaS and SaaS and reach data at scale.

How Cloud Gets Attacked

• Stolen/leaked long-lived access keys used directly against cloud APIs. T1078.004
• IMDS SSRF: abusing a server-side request forgery flaw in a public-facing app to query the instance metadata API and retrieve temporary IAM role credentials. T1190 T1552.005
• Over-permissioned roles and privilege escalation: adding cloud roles or admin assignments for persistence and escalation. T1098.003 T1580
• Cloud ransomware/extortion: stealing or encrypting data, and exfiltration through native services. T1537 T1486

Initial access often comes from social engineering of identity-provider accounts (help-desk impersonation, MFA fatigue, SIM swap — the Scattered Spider playbook) or from internet-wide scanning for exposed secrets in .git/config and .env files. T1552.001

Notable Campaigns

• Scattered Spider (MITRE G1015; overlapping UNC3944 / Octo Tempest / Muddled Libra / LUCR-3 / 0ktapus) — financially motivated identity-to-SaaS pivoting; Permiso’s LUCR-3 research details fast IdP-to-cloud data theft.
• EMERALDWHALE (Sysdig, October 2024) harvested a reported 15,000+ cloud credentials from exposed Git configuration files.
• Codefinger (Halcyon, January 2025) abused the legitimate AWS server-side-encryption-with-customer-key (SSE-C) feature with an attacker-generated key to ransom S3 data — no AWS vulnerability involved — against a reported small number of victims.

Detection & Mitigation

• Eliminate and rotate long-lived keys; prefer short-lived IAM roles, federation and just-in-time admin; enforce IMDSv2 and block application access to the metadata address, with a WAF against SSRF.
• Continuously scan for and purge exposed .env and .git/config secrets; treat secret management as necessary but not sufficient.
• Apply least-privilege IAM and alert on role/policy changes, new admin assignments and anomalous API calls (bucket enumeration, user creation, SSE-C writes).
• For object storage, restrict or deny SSE-C, enable versioning, Object Lock and MFA-delete, and monitor lifecycle-rule changes; harden the identity provider with phishing-resistant MFA and strict help-desk verification.