Mapping Cloud Incidents to ATT&CK: Improving Threat Detection

The MITRE ATT&CK framework has become a staple in modern cybersecurity. It’s a shared
language for understanding attacker behavior - what they do, how they move, and where they’re
likely to strike next. But when it comes to cloud environments, applying ATT&CK isn’t always
straightforward. Each cloud provider has its own architecture, logs, and quirks.
So how do you bring structure to cloud incident detection and response?‍

The answer: start mapping your cloud incidents to ATT&CK techniques.
Doing this helps your team think like attackers and detect suspicious behaviors earlier,
even across complex, hybrid environments.

In this guide, we’ll explore what this mapping process actually looks like, with practical tips,
tools, and examples from AWS, Azure, and Google Cloud. Whether you're just starting out with
ATT&CK or looking to operationalize it across your cloud stack, this walkthrough will help.

‍

A Quick Refresher: What Is MITRE ATT&CK?

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) is an open-source
knowledge base that catalogues how real-world adversaries behave - step by step.

Each tactic is a stage in an attack (like initial access, execution, or data exfiltration), and each
‍technique is how that stage is carried out (e.g., using stolen credentials, abusing cloud APIs,
or disabling logging). ATT&CK is constantly updated with data from real breaches.

The value is simple: if you can map your detections to known techniques, you gain clarity on
‍what attackers are doing, and how to stop them.

‍

Why Map Cloud Incidents to ATT&CK?

Cloud environments add complexity - lots of logs, APIs, identity layers, and services that don’t
behave like traditional infrastructure.

Mapping to ATT&CK helps by:

• Standardizing detection logic across providers
  
• Accelerating incident triage by tying behavior to tactics
  
• Enhancing threat hunting with technique-based queries
  
• Improving coverage analysis to find detection gaps
  

This isn’t just a theoretical benefit. In breach reports, poor detection coverage (e.g. no alert for
anomalous token creation in GCP or access to S3 buckets with public ACLs) shows how common
it is to miss obvious signals because teams don’t have a mental model of attacker behaviors.

Real Example: Mapping an AWS S3 Breach to ATT&CK

Let’s say your CloudTrail logs show a series of actions from a new IAM user:

1. ListBuckets
   
2. GetBucketAcl
   
3. GetObject
   
4. PutObjectAcl → public-read
   

This sequence isn’t business-as-usual.

Using ATT&CK, you might map this to:

• T1087.004 – Account Discovery: Cloud Account
  
• T1530 – Data from Cloud Storage Object
  
• T1098.004 – Add Cloud IAM Role
  
• T1562.007 – Disable or Modify Cloud Logging (if logging config changes are detected)
  

Once you map these actions, you can tag the incident as Credential Misuse → Privilege
Escalation → Data Exposure, and hunt for similar behavior across other buckets or accounts.

How to Get Started: Tools and Approach

Here’s how most mature teams begin mapping incidents to ATT&CK in the cloud:

1. Start with Native Logs

Each cloud platform has a primary log source:

• AWS → CloudTrail, GuardDuty, Config, VPC Flow Logs
  
• Azure → Activity Logs, Microsoft Defender for Cloud, Sign-In Logs
  
• GCP → Audit Logs, VPC Flow Logs, SCC (Security Command Center)
  

These logs capture the raw signals (API calls, auth events, config changes) that attackers manipulate.

2. Use Sigma Rules or Detection-as-Code

Sigma is a YAML-based language for writing SIEM-agnostic detections. Many open-source rules already map to ATT&CK.

👉 Check out Sigma HQ GitHub for rules like:

• aws_iam_policy_changed.yml
  
• azure_vm_extension_execution.yml
  
• gcp_service_account_key_created.yml
  

These often include the ATT&CK technique and tactic right in the metadata.

3. Leverage ATT&CK Navigator

The MITRE ATT&CK Navigator lets you visualize your detection coverage against the framework.

You can:

• Overlay which techniques you’re detecting
  
• Identify gaps by cloud platform
  
• Share visual maps with leadership or auditors
  

Some orgs use it for purple team exercises, showing where detections exist vs. where they’re weak.

4. Feed Mapping Into Threat Hunting

Once you’ve mapped detections, use that to build proactive threat hunts. Example:

• If you're hunting for T1078.004 – Valid Accounts: Cloud Accounts, query for:
  
  • Login attempts from unusual geo locations
    
  • Service account key creations outside change windows
    
  • First-time role assumptions in sensitive projects

This gives your team a technique-driven lens, rather than just relying on severity or keywords.

Case Study: Real Cloud Techniques in the Wild

From recent incidents (e.g. Scattered Spider, LAPSUS$, and cloud-targeted ransomware),
we’ve seen these cloud ATT&CK techniques emerge frequently:
‍

‍Technique ID                             Name                                      Cloud Platform                                                   Common Abuse

T1098.004                    Add Cloud IAM Role                  AWS, GCP, Azure                      Privilege escalation through IAM role creation

T1530                              Data from Cloud                          AWS (S3), GCP                          Sensitive file access via overly permissive
                                           Storage Object                            (GCS), Azure Blob                     storage buckets

T1552.001                      Unsecured Credentials:           All                                                     Harvesting secrets from uploaded files or
                                           Credentials in Files                                                                               misconfigured env vars

T1078.004                     Valid Accounts: Cloud               All                                                     Stolen service accounts, user credentials
                                            Accounts

T1600                              Weaken Encryption                    Azure/GCP                                  Downgrading or disabling encryption
                                                                                                                                                                 on resources

These mappings help SOC teams respond faster and build detections tailored to their actual cloud usage.

‍
‍Pro Tip: Build a Cloud-to-ATT&CK Mapping Playbook

Over time, build your own internal playbook:

• List common alerts → mapped to techniques
  
• Note expected vs suspicious behavior per service
  
• Tag mappings with severity or past incidents
  
• Version it quarterly to reflect cloud architecture changes
  

This lets you explain to auditors or execs why your team flagged a certain incident—and how you’re aligned with global best practices.

‍
‍Final Thoughts: Bridging the Gap Between Alerts
and Understanding

Too many security teams drown in cloud alerts that lack context. Mapping to ATT&CK fixes that.
It brings order to chaos by turning logs into stories. Stories you can understand, defend against, and improve from.

Whether you're in AWS, Azure, or GCP, applying ATT&CK gives your team a consistent way
to detect, explain, and defend. Start with the most common techniques. Build playbooks. Use Sigma rules.
And don’t just chase alerts - chase understanding.

‍