MITRE ATT&CK for Cloud Teams: What It Is and Why Your On-Call Engineer Needs to Know It

If you run production on AWS and do not have a dedicated security team, security work still lands on engineering. Someone gets a weird CloudTrail alert, someone notices an access key that should not exist, and the on-call engineer is expected to know whether this is noise or the start of something worse.

MITRE ATT&CK gives that engineer a shared language for what attackers actually do. You do not need to memorise the whole matrix. You need enough of it to recognise high-signal cloud patterns and respond without guessing.

What MITRE ATT&CK is

ATT&CK is a structured knowledge base of adversary behavior, built from real incidents rather than theory. It organises that behavior into tactics and techniques.

Tactics are the why. Initial Access, Privilege Escalation, Defense Evasion, Discovery, Exfiltration, and the rest describe what the adversary is trying to achieve at that stage.

Techniques are the how. Each technique is a specific method used to achieve a tactic, with an ID such as T1098 or T1562.008. When your detection says "this looks like T1098," you are naming a known pattern instead of inventing a private vocabulary for every alert.

That shared naming matters during response. "Someone created an access key on a service account" is a symptom. "Possible Account Manipulation, T1098" tells the next person on the call what class of activity you are dealing with and which follow-up checks are worth doing first.

Why cloud teams should care

Attackers in cloud environments follow repeatable paths. Steal or abuse credentials. Escalate through IAM. Disable logging if they can. Enumerate what is reachable. Move data out. Those steps show up in API activity long before they show up as a defaced homepage.

If your only incident muscle is uptime monitoring, you will catch outages and miss account takeovers. ATT&CK helps you decide which API patterns deserve a page at 1 a.m. and which belong in a ticket queue.

The cloud matrix that matters for AWS

ATT&CK has matrices for different environments. The cloud matrix focuses on behaviors that show up in cloud control planes and services, which is a better fit for AWS-hosted infrastructure than assuming every enterprise endpoint technique applies unchanged.

For most small AWS teams, a handful of tactics carry most of the practical weight.

Initial Access. Stolen passwords, phishing that yields console login, leaked API keys in a repo, or long-lived access keys that escape into a laptop backup. The first bad API call often looks legitimate because it uses real credentials.

Privilege Escalation. IAM role abuse, over-broad policies, and creating new credentials for other principals. iam:CreateAccessKey on a user other than the caller is a classic example tied to Account Manipulation (T1098).

Defense Evasion. Turning off the lights. cloudtrail:StopLogging, cloudtrail:DeleteTrail, or otherwise impairing monitoring maps to Impair Defenses (T1562.008). If logging disappears, assume intent until proven otherwise.

Discovery. Listing IAM users, enumerating S3 buckets, calling GetCallerIdentity from unusual places. Attackers map the account before they steal anything valuable.

Exfiltration. Unusual GetObject volume, cross-account access, or data leaving through paths your app does not normally use. Exfiltration often looks like "a script is busy" until you ask why that principal is reading that bucket at all.

How CloudTrail maps to detection

CloudTrail records API activity. Detection is pattern matching on those events, with enough context to tell admin work from abuse.

A few mappings are worth putting on a wall.

• iam:CreateAccessKey for another user → Privilege Escalation / Account Manipulation (T1098)
• cloudtrail:DeleteTrail or StopLogging → Defense Evasion (T1562.008)
• Burst of s3:ListBuckets / ListObjects from a principal that never does inventory work → Discovery
• sts:AssumeRole into a high-privilege role from an unexpected source → Credential access or lateral movement depending on context
• Mass s3:GetObject or large exports from a data account → Exfiltration

CloudTrail alone is not a SIEM. It is the raw material. Without alerting on the high-signal subset, the log is only useful after the damage is done.

Three practical examples

Example 1. Access key created for another user.
CloudTrail shows CreateAccessKey where userName is not the caller. ATT&CK technique T1098. Response should revoke the new key, force credential rotation for the affected user, review recent API calls from both principals, and check whether IAM policies were changed in the same window. Do not treat this as a normal ops task until you know who requested it and why.

Example 2. CloudTrail logging stopped.
Event name StopLogging or DeleteTrail on a trail you rely on. Technique T1562.008. Response should restore logging immediately, freeze other changes in the account where possible, and treat subsequent gaps in telemetry as hostile until explained. Also review who had cloudtrail:StopLogging permission and whether that access is still justified.

Example 3. Unusual S3 enumeration then bulk reads.
A role that normally serves web traffic starts calling ListBuckets, then pulls large object sets from a bucket outside its normal path. Discovery followed by possible exfiltration. Response should revoke or quarantine the role credentials, block outbound paths if you can do so safely, preserve the CloudTrail and S3 access logs, and open a security incident rather than a plain availability incident.

What a small engineering team can realistically do

You will not build a SOC next quarter. You can still raise the floor.

Enable CloudTrail in all regions, including the ones you "do not use." Attackers love empty regions. Turn on log file validation and send logs to an account or bucket that application roles cannot delete. Alert on key creation for other users, trail modification, root account usage, and unexpected AssumeRole into admin roles. Keep a short list of the ATT&CK techniques most common in AWS and put the matching API names in your runbook.

Separate security incident response from operational incident response. Restarting a service can fix an outage and destroy evidence in an intrusion. Your runbook should say when to preserve logs, revoke credentials first, and call for help.

Tooling for the detection layer

Plenty of teams wire CloudTrail into a SIEM or a cloud-native detector and page from there. The important part is deterministic alerts on high-signal APIs, mapped to techniques the on-call engineer can act on.

Vigiles can ingest CloudTrail, run detectors on those events, and map findings to MITRE ATT&CK techniques inside the same incident workflow you already use for uptime events. Whatever tool you choose, the goal is the same. Detection should open a security-aware incident with a technique ID and a clear next step, not a raw log dump at 2 a.m.

Your on-call engineer does not need to become a threat hunter. They need enough ATT&CK literacy to recognise when an API pattern is an attack path, and a process that treats that moment differently from a pod crash.