Cloud Threat Model

Overview

Threat modelling in the cloud applies the same first principles as threat modelling on premise — what is the asset, who wants it, how can they reach it, and what happens if they succeed — but the attack surface and the response options differ in two consequential ways. First, the control plane (the provider API that creates, modifies, and destroys resources) is itself reachable over the public internet from anywhere a valid credential lives, which collapses the network distance between a phished laptop and a production database into a single API call. Second, the customer's portion of the shared responsibility model puts identity, configuration, and data protection on the customer side at every service model, so the bulk of the exploitable surface is not provider infrastructure but customer policy. The classical STRIDE taxonomy (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege) documented in the Microsoft Learn — Microsoft Threat Modeling Tool (accessed 2026-05) maps cleanly onto the control plane: spoofing becomes credential stuffing against the IdP, tampering becomes API-level resource modification, elevation of privilege becomes role assumption across trust boundaries. The MITRE ATT&CK for Cloud matrix (accessed 2026-05) provides the empirical complement: a curated catalogue of tactics and techniques observed in real cloud intrusions, from Valid Accounts (T1078) through Cloud Service Discovery (T1526) to Exfiltration Over Web Service (T1567). This page synthesises both: who is attacking (adversary classes), how a chain looks end-to-end (attack chains), and how to bound the consequences (blast radius).

Adversary classes

Cloud defenders face five distinguishable adversary classes. The classes differ in motivation, capability, observed campaigns, and the controls that interrupt them. Subsequent control pages tag their Mitigates field against one or more of the classes below.

Opportunistic scanners

The lowest-capability and highest-volume class. Opportunistic scanners enumerate publicly exposed assets — open S3 buckets, unauthenticated Elasticsearch clusters, Kubernetes dashboards on public IPs, exposed Docker daemons — using internet-wide scanning services and commodity tooling. Campaigns are not target-selected: they take whatever they find. The canonical public example is the recurring class of "leaky bucket" incidents, where a single misconfigured storage object ACL exposes millions of records to anyone who can guess the bucket name. The ENISA Threat Landscape 2025 (accessed 2026-05) places opportunistic scanning in the top tier of observed cloud attack volume.

Credential thieves

Cyber-criminal operators whose business model is acquiring valid cloud credentials and either selling them or using them to monetise the underlying account (cryptomining, data theft for extortion, BEC payment redirection). Acquisition vectors include infostealer malware on developer laptops, phishing kits that harvest IdP cookies, leaked secrets in public source repositories, and credential stuffing against IdPs without MFA. The canonical example is the Snowflake/UNC5537 campaign of 2024, where an infostealer-derived credential set was used to access more than 165 customer tenancies that had not enforced MFA. Mandiant's public advisory at Google Cloud / Mandiant — UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion (accessed 2026-05) documents the tradecraft.

Supply-chain attackers

Adversaries that compromise an upstream dependency — a build server, a base container image, a CI/CD action, a developer tool, a managed service provider — in order to reach the real target by transit. Cloud environments are particularly exposed because workload identities are often granted broad permissions on the assumption that the supply chain is trusted. The 2020 SolarWinds intrusion remains the canonical cross-domain example; CI/CD-flavoured variants include the 2023 CircleCI incident and recurring compromises of public GitHub Actions marketplace entries. NIST documents the defensive posture in NIST SP 800-218 — Secure Software Development Framework (SSDF) Version 1.1 (accessed 2026-05).

Insiders

Authorised principals — employees, contractors, partners — acting outside the bounds of their authorisation, whether maliciously or through negligence. The negligence subclass is dominant by volume: developers committing keys to public repos, administrators leaving break-glass roles assumable without MFA, terminated employees retaining cloud access. The malicious subclass is lower in volume but disproportionate in blast radius because insiders already hold valid credentials and knowledge of the environment. Mitigations are dominantly process and detective rather than preventive: separation of duties, just-in-time elevation, anomaly detection on privilege use, and credential rotation on offboarding.

Nation-state APTs

The highest-capability class, characterised by patience, custom tooling, operational security, and willingness to combine multiple low-and-slow techniques over months. Cloud targeting by APTs has grown sharply since 2020 as enterprise identity moved into Entra ID, Okta, and similar consolidated IdPs — compromising the IdP yields access to the entire downstream estate. The canonical 2024 example is the Midnight Blizzard (also tracked as APT29) intrusion into Microsoft corporate, where a legacy non-production OAuth application was abused to grant the actor access to Microsoft executive mailboxes; the Microsoft Security Response Center — Microsoft Actions Following Attack by Nation State Actor Midnight Blizzard (accessed 2026-05) post is the primary public record.

Common attack chains

Three canonical attack chains recur across the public incident record with sufficient frequency to be treated as reference patterns. Each is walked end-to-end below: a real incident callout names the precedent, a numbered list traces the steps, a figure describes the flow, and a threat-model summary names the controls that break the chain at each link. The chains map to MITRE ATT&CK technique IDs where applicable.

Chain A — Credential stuffing without MFA

1. Infostealer malware (RedLine, Vidar, Raccoon) lands on a contractor or developer laptop and exfiltrates browser-stored credentials, including a Snowflake account password.
2. Credential is sold or shared on a criminal marketplace.
3. Adversary authenticates to the Snowflake tenancy directly over the internet — no MFA challenge, no IP allow-list, no conditional access policy.
4. Adversary enumerates accessible warehouses and schemas (ATT&CK T1526 — Cloud Service Discovery).
5. Bulk data export via COPY INTO to an attacker-controlled S3 bucket (T1567 — Exfiltration Over Web Service).
6. Extortion message delivered to the victim organisation referencing the exfiltrated record counts.

Chain B — SSRF to instance metadata to S3 exfiltration

1. Attacker discovers a WAF endpoint that proxies arbitrary URLs (SSRF primitive).
2. Attacker requests http://169.254.169.254/latest/meta-data/iam/security-credentials/<role> through the SSRF proxy. IMDSv1 has no session-token requirement, so the metadata service answers.
3. The response contains an AccessKeyId, SecretAccessKey, and Token for the EC2 instance role.
4. Attacker calls s3:ListBucket across the account from outside AWS using the stolen credentials.
5. Attacker calls s3:GetObject against the customer records bucket and exfiltrates the contents.

Chain C — OAuth application abuse to tenant access

1. Password-spray attack against a legacy non-production tenant identifies a low-privilege account with a weak password and no MFA (ATT&CK T1110.003 — Password Spraying).
2. Inside the tenant, attacker enumerates registered applications and identifies a legacy test OAuth app holding elevated EWS.full_access_as_app grants on the corporate tenant.
3. Attacker creates additional malicious OAuth applications and consents them with the compromised principal (T1098.003 — Additional Cloud Roles).
4. OAuth app tokens authenticate to corporate Exchange Online as the application identity, bypassing user-MFA controls.
5. Attacker reads selected executive mailboxes via Exchange Web Services (T1114.002 — Remote Email Collection).

Blast radius taxonomy

Every control in this guide carries a Blast radius sub-field that records the scope of compromise if the control fails. Blast radius is the unit in which incident severity is measured, and it is also the unit on which segmentation investments are justified. Four scope tiers recur, ordered from smallest to largest.

Single resource. Compromise is bounded to one object — a single S3 bucket, a single Cloud SQL instance, a single VM. The control plane and the identity plane are unaffected; remediation is the resource owner's responsibility and does not require coordinated organisational action.

Single account, subscription, project, or compartment. Compromise reaches every resource inside one provider accounting boundary. This is the primary segmentation unit on all four hyperscalers and is the level at which the shared-responsibility model is most often instantiated. Containment requires revoking principal credentials in that boundary and rotating any keys, secrets, or service-account tokens that lived inside it.

Entire organisation. Compromise reaches across provider accounting boundaries via an inherited trust relationship: AWS Organizations OrganizationAccountAccessRole, Azure Management Group inheritance, GCP Folder-level IAM, OCI tenancy-level policies. Containment requires action at the organisation root and is the scenario for which break-glass procedures exist. Data classification (see General data protection principles) determines the regulatory and reputational impact at this tier.

Cross-tenant. Compromise reaches resources outside the customer's contractual boundary — into a partner tenancy via federation trust, into a downstream customer via MSP credentials, or into the provider control plane itself. Cross-tenant blast is rare but disproportionately consequential because containment depends on a third party's response. The Midnight Blizzard chain is the recent canonical example. The taxonomy aligns with the impact framing in NIST SP 800-30 Revision 1 — Guide for Conducting Risk Assessments (accessed 2026-05).

Mapping threats to controls

Every control article in Phases 5 through 9 of this guide carries a <aside class="threat-model"> box with three labelled sub-fields: Mitigates (the threat this control prevents, detects, or responds to), Attack vector (how the attack proceeds in the control's absence), and Blast radius (the scope of compromise if the control fails). The threat names referenced in the Mitigates field draw from the adversary classes and attack chains catalogued above; the blast-radius values draw from the taxonomy in the previous section. This page is therefore implicitly cited by every downstream control, and the reciprocal link from each domain page back to this one is the editorial guarantee that the guide's threat coverage is consistent across providers.

The mapping is not one-to-one. A single control can mitigate multiple chains — MFA breaks both Chain A and Chain C — and a single chain is typically broken by overlapping controls at different layers. Defenders should expect this redundancy and should resist the temptation to remove "duplicative" controls on the grounds that another control already covers the chain; defence in depth is the entire point. The methodology by which controls are selected, severities assigned, and threat coverage audited is described in the methodology page; the framework crosswalk used to align controls with external regulatory expectations lives in the compliance frameworks page; and the upstream partition that determines which threats are even the customer's to mitigate is the shared responsibility model. The six domain principle pages — IAM, network, data, logging, workloads, and incident response — each operationalise the controls that break the chains documented above into provider-neutral principles, which the provider-specific domain pages then realise as concrete configurations.

Sources

• MITRE ATT&CK for Enterprise — Cloud Matrix (accessed 2026-05)
• ENISA Threat Landscape 2025 (accessed 2026-05)
• NIST SP 800-30 Revision 1 — Guide for Conducting Risk Assessments (accessed 2026-05)
• NIST SP 800-154 (Initial Public Draft) — Guide to Data-Centric System Threat Modeling (accessed 2026-05)
• Google Cloud / Mandiant — UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion (accessed 2026-05)
• Microsoft Security Response Center — Microsoft Actions Following Attack by Nation State Actor Midnight Blizzard (accessed 2026-05)
• KrebsOnSecurity — What We Can Learn from the Capital One Hack (accessed 2026-05)
• Microsoft Learn — Microsoft Threat Modeling Tool (accessed 2026-05)
• CISA and NSA — Cybersecurity Information Sheets: Cloud Security Best Practices, March 2024 (accessed 2026-05)
• NIST SP 800-218 — Secure Software Development Framework (SSDF) Version 1.1 (accessed 2026-05)