MITRE ATT&CK for Cloud: A Practitioner's Guide to Detection Coverage

 

TL;DR

Coverage percentages make for nice slides. They don't stop cloud breaches. Here's how to use MITRE ATT&CK to build detection coverage that actually maps to how attackers operate in AWS, Azure, OCI, and GCP — and where cloud detection and response solutions fit in.

Key takeaways MITRE ATT&CK for Cloud is part of the Enterprise matrix — it covers IaaS (AWS, Azure, GCP), SaaS, identity providers, and Office Suite platforms. Credential abuse is the dominant cloud attack vector: Verizon's 2025 DBIR pegs it at 22% of all breaches; CrowdStrike reports 79% of attacks are now malware-free. ATT&CK v18 (released late 2025) added depth on Kubernetes, CI/CD pipelines, cloud databases, and cloud identities. If your last coverage review predates v18, you're working from an outdated map. Stop chasing 100% technique coverage. Score detections by confidence, prioritize techniques attackers actually use against your stack, and measure improvement over time. Adequate cloud detection and response (CDR) solutions map detections to ATT&CK, tie them to identity and exposure context, and correlate technique events into investigation stories instead of standalone alerts.

Walk into any SOC and ask how their cloud detection coverage looks. You'll get one of three answers.

• “We map everything to ATT&CK. We're at 78%.”
• “We have a SIEM. We get alerts.”
• “It's complicated.”

All three are warning signs. The first treats ATT&CK as a scoreboard. The second treats detection as a volume problem. The third is at least honest.

This guide is for the people stuck in the middle of those three answers — the cloud security engineers, detection engineers, and SOC leads who know ATT&CK is useful but haven't quite figured out how to make it operationally real. We'll cover what ATT&CK for Cloud actually is, the tactics and techniques that matter most in 2026, how to build coverage that holds up to scrutiny, and where a cloud detection and response (CDR) solution plugs in.

 

What MITRE ATT&CK for Cloud actually is

First, a clarification that costs more confusion than it should: there is no standalone “ATT&CK for Cloud” matrix anymore. Cloud is a set of platforms inside the Enterprise matrix, alongside Windows, macOS, Linux, Containers, Network, and ESXi. When practitioners say “ATT&CK for Cloud,” they mean the Enterprise matrix filtered to these platforms:

• IaaS — AWS, Azure, GCP, and other Infrastructure-as-a-Service providers
• SaaS — SaaS applications more broadly
• Identity Provider — Microsoft Entra ID (formerly Azure AD), Okta, and other IdPs
• Office Suite — Microsoft 365 and Google Workspace

The same tactic columns apply (Initial Access through Impact), but the techniques surfaced are the ones you can actually observe in cloud telemetry — control-plane logs like CloudTrail and Azure Activity, identity events, API calls, and SaaS audit trails — instead of endpoint EDR data.

MITRE ATT&CK v18 dropped in late 2025 with deeper Kubernetes, CI/CD, cloud database, and cloud identity coverage, along with a restructured Detection Strategies and Analytics model. If you mapped your detections against v14 or v15 and haven't refreshed, your coverage layer is showing a snapshot of an environment attackers no longer live in.

 

The cloud tactics — and what they mean in practice

Tactics describe what an attacker is trying to accomplish. Techniques describe how. In a cloud breach you'll see most of these chained together, usually 4 to 7 of them, over hours or days. Here's the operational read on each one.

Tactic	Attacker goal in a cloud context	High-signal techniques to detect
Initial Access	Get a foothold in the cloud tenant or account.	T1078.004 Valid Accounts: Cloud Accounts; T1190 Exploit Public-Facing Application; T1566 Phishing
Execution	Run code in cloud resources.	T1059 Command and Scripting Interpreter; T1651 Cloud Administration Command; T1610 Deploy Container
Persistence	Survive credential rotations and workload restarts.	T1098.001 Additional Cloud Credentials; T1136.003 Create Cloud Account; T1556 Modify Authentication Process
Privilege Escalation	Gain higher entitlements inside the account or tenant.	T1548 Abuse Elevation Control Mechanism; T1078.004 Valid Accounts: Cloud Accounts
Defense Evasion	Disable logging, evade controls, hide activity.	T1562.008 Disable or Modify Cloud Logs; T1535 Unused/Unsupported Cloud Regions; T1578 Modify Cloud Compute Infrastructure
Credential Access	Steal keys, tokens, secrets, and account credentials.	T1552.005 Cloud Instance Metadata API; T1552.001 Credentials In Files; T1528 Steal Application Access Token
Discovery	Map the environment, identities, and entitlements.	T1580 Cloud Infrastructure Discovery; T1087.004 Account Discovery: Cloud Account; T1538 Cloud Service Dashboard
Lateral Movement	Pivot between cloud workloads, identities, and accounts.	T1550.001 Application Access Token; T1021.007 Cloud Services
Collection	Stage sensitive data from cloud storage and SaaS.	T1530 Data from Cloud Storage; T1213.003 Code Repositories
Exfiltration	Move data out of the cloud environment.	T1537 Transfer Data to Cloud Account; T1567 Exfiltration Over Web Service
Impact	Destroy data, deny service, or extract financial value.	T1485 Data Destruction; T1496 Resource Hijacking (cryptomining); T1657 Financial Theft

One observation worth dwelling on: notice how many of these techniques start with a stolen credential or a token. That's not a coincidence. It's the defining feature of cloud attacks in 2026.

 

Why this matters: the data behind cloud detection in 2026

If you're trying to justify investment in cloud-specific detection — or push back on the idea that your existing SIEM rules cover cloud — these are the numbers to bring to the conversation.

Stat	What it tells you	Source
$4.44M	Global average cost of a data breach in 2025. The U.S. average hit a record $10.22M.	IBM Cost of a Data Breach 2025
22%	Share of breaches where compromised credentials were the initial access vector — the leading entry point.	Verizon 2025 DBIR
44%	Share of breaches involving ransomware, frequently paired with exfiltration from cloud storage.	Verizon 2025 DBIR
79%	Share of attacks that are malware-free, relying on valid credentials and identity abuse instead.	CrowdStrike Global Threat Report
30%	Share of breaches involving data across multiple environments. These cost an average of $5.05M.	IBM Cost of a Data Breach 2025
241 days	Average breach lifecycle (identify + contain). Credential-related breaches take ~292 days.	IBM Cost of a Data Breach 2025
$1.14M	Average savings when a breach is contained within 200 days vs. exceeding the threshold.	IBM Cost of a Data Breach 2025

Stitch those numbers together and the picture is clear. Cloud attackers aren't breaking in with novel exploits. They're logging in with stolen identities, using legitimate API calls, moving fast, and getting out before traditional detection catches up. ATT&CK for Cloud is the framework for describing those behaviors — and your detection program needs to be built around them.

“The 2025 hype that runtime detection is the only thing that matters and could replace posture or identity analysis will fade in 2026. Runtime-only tools miss most attack paths because the path starts well before runtime.” — Liat Hayun, Tenable SVP of Product Management & Research

 

Anatomy of a cloud attack, mapped to ATT&CK

The fastest way to internalize ATT&CK is to walk a realistic kill chain. The sequence below is composed from publicly reported cloud incidents — the kind of intrusion most cloud-mature teams have seen at least the early stages of.

#	Technique	What the attacker does	What the telemetry shows
1	T1566 Phishing	Targeted email to a cloud admin; admin enters credentials on a lookalike portal.	IdP sign-in from a new IP and user agent.
2	T1078.004 Valid Accounts: Cloud Accounts	Logs into AWS Console / Azure Portal, often bypassing weak MFA.	Successful console sign-in; MFA prompt-bomb or AiTM token replay in IdP logs.
3	T1580 Cloud Infrastructure Discovery	Enumerates accounts, regions, S3 buckets, IAM policies, key vaults.	Burst of List* and Describe* API calls.
4	T1098.001 Additional Cloud Credentials	Creates a new access key tied to a privileged role for persistence.	CreateAccessKey or AddCloudCredentials by an unusual principal.
5	T1562.008 Disable or Modify Cloud Logs	Stops CloudTrail in a single region to mask follow-on activity.	StopLogging or DeleteTrail event — high-fidelity detection trigger.
6	T1530 Data from Cloud Storage	Reads sensitive objects from an S3 bucket holding customer PII.	Unusual GetObject volume from a non-baseline principal/IP.
7	T1537 Transfer Data to Cloud Account	Copies data to an attacker-controlled cloud account to evade egress DLP.	Cross-account S3 PutObject / replication events.

Every row is a detection opportunity. The difference between a contained intrusion and a $5M breach is usually whether your SOC caught the chain at step 3 (Discovery) or step 7 (Exfiltration). Step 5 — disabling logs — is the single highest-value detection in this chain. Almost nothing legitimate generates a StopLogging event.

 

The coverage gaps every cloud detection program has

After enough cloud incident reviews, the same blind spots keep showing up. Audit your program against this list before your next attacker does.

 

Identity provider blindness

Most ATT&CK cloud techniques begin or escalate through an IdP. If your detections don't cover token issuance, conditional access changes, persistent refresh tokens, and federation trust modifications, you're missing the most common kill-chain steps. MFA bypass — prompt bombing, token theft, adversary-in-the-middle — is now mainstream. Verizon's 2025 DBIR explicitly calls out the surge.

 

Non-human identity drift

Service accounts, API keys, IAM roles, and machine identities outnumber human identities by orders of magnitude in most cloud accounts. They don't respond to MFA. They often have no clear owner. Tenable Research's 2026 predictions go further: non-human identities will become the primary vector for cloud breaches this year. If your coverage map doesn't include T1098 (Account Manipulation) and T1528 (Steal Application Access Token), you have a problem you haven't named yet.

 

Cross-account, cross-tenant movement

Cross-account role assumption and T1550.001 (Application Access Token) reuse are difficult to detect when you're looking at a single AWS account or Azure subscription in isolation. You need detection that spans the entire org — multi-account, multi-cloud, multi-tenant — with consistent context.

 

Runtime-only blind spots

Some techniques — T1610 (Deploy Container), T1496 (Resource Hijacking), reverse shells in serverless — can only be seen at runtime. Configuration scans miss them. eBPF-based workload sensors and cloud detection and response (CDR) cover this layer.

 

Log tampering treated as a misconfiguration

T1562.008 — disabling cloud logs — is one of the highest-fidelity detection opportunities in the matrix. Yet many programs file it under “cloud posture finding” and route it to the cloud team's Jira queue. Wire it directly to the SOC. Treat it as the active-attack signal it is.

 

Building ATT&CK-aligned coverage that holds up

Here's a step-by-step playbook for putting ATT&CK for Cloud to work — not as a slide, as an operating model. Run it in this order. Don't skip steps.

1. Start with a threat profile, not the matrix. Identify three to five threat groups, ransomware crews, or campaign patterns relevant to your industry. Pull their known techniques from MITRE's group pages. That's your initial coverage target — typically 40 to 80 techniques, not 200+.
2. Map current detections in ATT&CK Navigator. Tag every rule, alert, and analytic with technique IDs. Export the layer JSON. This becomes the single artifact you share with leadership, auditors, and the team — a colored heatmap, not a 40-slide deck.
3. Score detections by confidence, not presence. A noisy heuristic and a high-fidelity behavioral analytic both “cover” a technique. The operational outcomes are wildly different. Use low/medium/high confidence scoring instead of a binary checkbox.
4. Correlate techniques into stories. Cloud intrusions chain 4 to 7 techniques across hours or days. Detection that surfaces the full chain — instead of 47 individual alerts — cuts investigation time and reduces alert fatigue.
5. Layer exposure context onto every detection. A technique seen against an internet-exposed workload with admin permissions and access to sensitive data is fundamentally different from the same technique against an isolated dev sandbox. Risk-based prioritization needs detection and exposure data in the same platform.
6. Test coverage with adversary emulation. Stratus Red Team, Atomic Red Team, Caldera, and Pacu let you execute ATT&CK techniques safely and verify detections fire. Run a small set monthly. Skip the annual all-hands red team marathon.
7. Refresh quarterly. ATT&CK evolves with each release. Your cloud environment evolves faster. Schedule quarterly reviews of your coverage layer and your threat profile.

 

Common challenges (and how to solve them)

Challenge: too many techniques, not enough engineers

Solution: prioritize ruthlessly. Cover the top quartile of techniques used by threat actors in your industry first. You'll have meaningful coverage with 30 to 60 well-tuned detections — more valuable than 200 noisy ones.

 

Challenge: cloud telemetry is fragmented across AWS, Azure, GCP, and SaaS

Solution: adopt a CNAPP that normalizes control-plane logs, identity events, runtime data, and configuration findings across providers into one data model. The same technique should be detectable regardless of which cloud it occurred in.

 

Challenge: ATT&CK doesn't capture exposure context

Solution: pair ATT&CK detections with an exposure management layer. The framework tells you what an attacker is doing; an exposure platform tells you why this asset matters — blast radius, identity privileges, data sensitivity, reachability.

 

Challenge: alert volume makes per-technique alerts unmanageable

Solution: move from alert-per-technique to story-per-incident. Correlate related techniques into a single investigation, ordered by tactic progression. Instead of 47 cloud alerts, the SOC sees one story showing all seven steps in the chain.

 

Challenge: demonstrating coverage to auditors and the board

Solution: use ATT&CK Navigator layers as the artifact. A heatmap of covered vs. uncovered techniques, broken down by cloud platform, communicates more in 30 seconds than a packed deck. Trend the same layer quarterly to show progress.

 

The bottom line

ATT&CK for Cloud isn't a coverage scorecard. It's a working language for describing how cloud attacks actually happen — and a tool for measuring whether your detections, your exposure data, and your SOC workflows can see them.

Programs that thrive in 2026 won't be the ones with the highest coverage percentage on a slide. They'll be the ones that map the right techniques, score detections honestly, layer in exposure context, correlate alerts into investigations, and refresh the map every quarter. The framework is free. The discipline isn't.

 

Frequently asked questions

What's the difference between ATT&CK for Enterprise and ATT&CK for Cloud?

ATT&CK for Cloud isn't a separate framework. It's the Enterprise matrix filtered to cloud platforms — IaaS, SaaS, Identity Provider, and Office Suite. Same tactic columns, different techniques surfaced — the ones visible in cloud control-plane logs and identity events rather than endpoint EDR.

 

How many techniques are in the cloud-platform view?

It depends on the ATT&CK release and which sub-platforms you filter. The full Enterprise matrix in v18 contains 200+ techniques and 450+ sub-techniques across all platforms; a few dozen are specifically applicable to cloud when filtered. MITRE publishes the current count at attack.mitre.org/matrices/enterprise/cloud/.

 

Do I need to cover every technique?

No, and trying to is one of the most common failure modes. Identify the techniques used by threat actors most likely to target your environment, then prioritize detection engineering against those. A focused 40 to 60 technique coverage map outperforms a scattered 200-technique one every time.

 

How is ATT&CK for Cloud different from the Cyber Kill Chain?

The Cyber Kill Chain (Lockheed Martin, 2011) models attacks as a linear seven-phase sequence. ATT&CK maps techniques without assuming a fixed order — real intrusions skip phases, loop back, or run multiple tactics in parallel. For detection engineering, ATT&CK's technique-level granularity is what makes it operationally useful.

 

What changed in MITRE ATT&CK v18?

Released in late 2025, v18 added deeper coverage of Kubernetes clusters, CI/CD pipelines, and cloud databases, plus enhanced guidance on software supply chains, cloud identities, and virtualization. It also restructured the Detection Strategies and Analytics sections for greater precision. If your coverage layer was built against an earlier version, refresh it.

 

Can I use ATT&CK Navigator with my existing tools?

Yes. ATT&CK Navigator is an open-source web tool for creating visual layers — colored overlays representing coverage, threat group activity, or test results. Most modern CNAPP, SIEM, and XDR products can export technique mappings as Navigator-compatible JSON.

 

How does ATT&CK relate to compliance frameworks like NIST CSF or PCI DSS?

Compliance frameworks describe what controls should exist. ATT&CK describes what attackers do. They're complementary. Mapping ATT&CK techniques to your control framework answers the harder question: do my compliant controls actually detect the techniques attackers use against cloud environments?

 

What's the easiest way to start an ATT&CK for Cloud program?

Three steps: pick three to five threat groups relevant to your industry, export their technique sets from MITRE, and overlay them in Navigator against your current coverage. The gaps you see are your starting backlog. Don't try to map everything in week one.