Cloud detection & response
When it applies
Your assets live in AWS/Azure/GCP and you need to catch control-plane abuse — stolen keys, a role
assumed from a strange place, new persistence — using the provider's audit logs.
Why it works
Every cloud API call is logged (CloudTrail / Azure Activity / GCP Admin Activity). Attacks that are
invisible on the host (assuming a role, reading a secret, adding a key) are loud in the control
plane — if you're actually reading it. The identity and the calling context are in every event.
Method
- Guarantee the telemetry: CloudTrail (all regions + management & data events), Azure Activity
- Entra sign-in logs, GCP audit logs — centralised and immutable. No logs → no detection.
- Credential-theft tells: an IAM user/role key used from a new ASN/region/UA, especially
sts:GetCallerIdentity then enumeration bursts — classic stolen-key triage. IMDS-sourced role
creds used off the instance (compare the session's source IP to the instance).
- Persistence:
CreateAccessKey, CreateUser, new login profile, CreateRole with a broad
trust policy, new identity provider — alert on these in prod accounts.
- Privilege escalation:
AttachUserPolicy/PutUserPolicy granting *, iam:PassRole +
service launch, AssumeRole chains that cross accounts.
- Managed signals: enable GuardDuty / Defender for Cloud / SCC as a baseline, then tune and
layer custom queries (Athena over CloudTrail) on top.
- Respond: disable the key/session, revoke role sessions, snapshot for forensics, rotate, and
review what the identity could reach (
tradecraft-attack-path-mapping).
Gotchas
- CloudTrail data events (S3 object-level, Lambda) are off by default — you miss exfil without them.
- Roles blur "who did it" — correlate the session name and source, not just the principal.
- Automation (CI/CD, Terraform) generates the same API calls; baseline service identities first.
Verify success
A simulated key-abuse / privilege-escalation sequence (e.g. via a lab) surfaces from the audit logs
with the identity, source, and action, and the response revokes access and preserves evidence.
References
AWS CloudTrail & GuardDuty; Azure Monitor / Entra sign-in logs; GCP audit logs; MITRE ATT&CK Cloud matrix.
1---2name: defense-cloud-detection3description: Detect and respond to attacks in cloud control planes — credential abuse, IMDS theft, persistence, and privilege escalation — from audit logs. Load for "detect cloud attacks", "CloudTrail/GuardDuty", "someone used our keys", AWS/Azure/GCP monitoring, or cloud IR. The defensive counterpart to the cloud-* offensive skills.4---56# Cloud detection & response78## When it applies9Your assets live in AWS/Azure/GCP and you need to catch control-plane abuse — stolen keys, a role10assumed from a strange place, new persistence — using the provider's audit logs.1112## Why it works13Every cloud API call is logged (CloudTrail / Azure Activity / GCP Admin Activity). Attacks that are14invisible on the host (assuming a role, reading a secret, adding a key) are loud in the control15plane — if you're actually reading it. The identity *and* the calling context are in every event.1617## Method181. **Guarantee the telemetry**: CloudTrail (all regions + management & data events), Azure Activity19 + Entra sign-in logs, GCP audit logs — centralised and immutable. No logs → no detection.202. **Credential-theft tells**: an IAM user/role key used from a new ASN/region/UA, especially21 `sts:GetCallerIdentity` then enumeration bursts — classic stolen-key triage. IMDS-sourced role22 creds used off the instance (compare the session's source IP to the instance).233. **Persistence**: `CreateAccessKey`, `CreateUser`, new login profile, `CreateRole` with a broad24 trust policy, new identity provider — alert on these in prod accounts.254. **Privilege escalation**: `AttachUserPolicy`/`PutUserPolicy` granting `*`, `iam:PassRole` +26 service launch, `AssumeRole` chains that cross accounts.275. **Managed signals**: enable GuardDuty / Defender for Cloud / SCC as a baseline, then tune and28 layer custom queries (Athena over CloudTrail) on top.296. **Respond**: disable the key/session, revoke role sessions, snapshot for forensics, rotate, and30 review what the identity could reach (`tradecraft-attack-path-mapping`).3132## Gotchas33- CloudTrail data events (S3 object-level, Lambda) are off by default — you miss exfil without them.34- Roles blur "who did it" — correlate the session name and source, not just the principal.35- Automation (CI/CD, Terraform) generates the same API calls; baseline service identities first.3637## Verify success38A simulated key-abuse / privilege-escalation sequence (e.g. via a lab) surfaces from the audit logs39with the identity, source, and action, and the response revokes access and preserves evidence.4041## References42AWS CloudTrail & GuardDuty; Azure Monitor / Entra sign-in logs; GCP audit logs; MITRE ATT&CK Cloud matrix.
NoorQureshi