Identity is the new perimeter: attack paths, misconfig, and guardrails across clouds.
Module overview
In the cloud, identity and configuration are the primary attack surface. This module covers IAM privilege-escalation paths, exposed data and metadata, and the control-plane logging (CloudTrail/Activity Log/Audit Logs) that makes detection possible. You will assess a deliberately misconfigured lab account with open-source tooling and implement preventative guardrails.
Lesson 1
IAM Attack Paths & Detection
Deep explanation
Cloud breaches usually follow identity, not exploits. Over-permissioned roles, long-lived access keys, and policies with wildcards create escalation paths: a role that can iam:PassRole + run compute can assume higher privileges; a principal that can edit its own policy can self-escalate. The defensive baseline is least privilege, short-lived credentials (SSO/STS), and full control-plane logging analyzed for anomalies.
Examples
A developer role with iam:CreatePolicyVersion can rewrite its own permissions to admin.
Leaked long-lived access keys in a repo grant durable API access until rotated.
Commands & tools
# Enumerate effective permissions / find risky policies (lab account you own)
aws iam get-account-authorization-details > iam.json
pmapper graph create && pmapper visualize # maps privilege-escalation paths
# Detection: query control-plane logs (Athena over CloudTrail)
SELECT eventtime, useridentity.arn, eventname FROM cloudtrail
WHERE eventname IN ('CreatePolicyVersion','AttachUserPolicy','PassRole')
# Prevention
aws iam update-account-password-policy ... # baseline
# enforce SSO/short-lived creds; remove long-lived keys; SCPs to deny risky actions
Diagram
principal --has--> [ iam:PassRole + ec2:RunInstances ] --> assume higher role --> ADMIN
principal --has--> [ iam:CreatePolicyVersion ] --> rewrite own policy --> ADMIN
detect: CloudTrail( PassRole / policy-edit ) -> GuardDuty / SIEM alert
Hands-on lab
In a sandbox cloud account, run pmapper (or ScoutSuite) to map IAM and identify at least one escalation path.
Trace the path manually (which action enables which) and document it.
Implement the fix: remove the dangerous permission or add an SCP/deny guardrail.
Add detection: a CloudTrail/Athena query (or GuardDuty finding) for the risky API calls.
Expected output: A diagram of one IAM escalation path, the policy change that closes it, and a detection query that fires on the risky API calls.
What to observe: Cloud privilege escalation is a graph problem; tooling that maps principal-to-permission edges finds paths humans miss.
How attackers exploit · how defenders respond
Exploit: Harvest leaked keys or assume over-permissioned roles, then self-escalate via policy edits or PassRole to admin and pivot to data.
Detect & respond: Control-plane logging (CloudTrail/Activity/Audit Logs) analyzed for policy edits, PassRole, new keys, and anomalous regions/identities; GuardDuty/Defender for Cloud.
Red teamFollow identity edges to admin; abuse PassRole and self-policy-edit.
Blue teamLeast privilege, short-lived SSO creds, SCP guardrails, and control-plane anomaly detection.
Real-world scenario
Repeated cloud incidents trace to a single over-broad role plus long-lived keys; pmapper-style graphing and an SCP denying policy self-edits both find and stop the path.
Lesson 2
Misconfiguration, Data Exposure & Guardrails
Deep explanation
The other dominant cloud risk is misconfiguration: public object storage, over-shared snapshots, exposed databases, and the instance metadata service feeding SSRF (see Module 2). Posture tools (ScoutSuite, Prowler, Cloud Custodian) audit at scale; preventative guardrails (S3 Block Public Access, Azure Policy, GCP Org Policy, Config rules) stop drift before it ships.
Examples
A public S3 bucket exposes backups to the internet — found instantly by Prowler.
IMDSv1 left enabled turns any app SSRF into cloud-credential theft (require IMDSv2).
Commands & tools
# Posture assessment (lab account)
prowler aws # hundreds of checks incl. public buckets, weak IAM, logging gaps
scout suite aws # html report of misconfig
# Preventative guardrails
aws s3api put-public-access-block --bucket my-bucket \
--public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
aws ec2 modify-instance-metadata-options --http-tokens required # IMDSv2
# Azure Policy / GCP Org Policy to deny public exposure org-wide
Diagram
drift: someone makes a bucket public
detect: Prowler/Config rule -> finding -> alert
prevent: Block Public Access / Org Policy -> action denied at create time
Hands-on lab
Run Prowler or ScoutSuite against the sandbox account and triage the top findings.
Reproduce one exposure (e.g., a public bucket) and confirm it is reachable.
Apply the preventative guardrail (Block Public Access / Org Policy) and confirm the exposure is now denied.
Add a Config/Custodian rule that auto-flags or auto-remediates future drift.
Expected output: A posture report, one reproduced-then-remediated exposure, and a guardrail/Config rule that prevents recurrence.
What to observe: Detection finds drift after the fact; guardrails prevent it at creation — defense in depth needs both.
How attackers exploit · how defenders respond
Exploit: Scan for public storage/exposed services and metadata; exfiltrate data with the access found.
Detect & respond: Continuous posture management (Prowler/ScoutSuite/CSPM), Config rules, and storage access logging with anomaly alerts.
Red teamInternet-wide scanning for public buckets/exposed DBs; metadata theft via SSRF.
Blue teamOrg-wide guardrails (Block Public Access/Org Policy), CSPM, IMDSv2, and access-log detections.
Real-world scenario
Countless data leaks are simply public buckets; org-level Block Public Access plus a Config rule converts a recurring incident into an impossible state.
End-of-module assessment
Tap an answer to check it.
1. The primary attack surface in cloud environments is:
Cloud breaches predominantly follow identity and misconfiguration.
2. IMDSv2 mitigates SSRF-to-metadata by:
Session-token + hop-limit defeats simple SSRF reads of metadata.
3. Guardrails (Block Public Access / Org Policy) differ from detection because they:
Guardrails deny the bad state proactively rather than reporting it afterward.
Key takeaways
Identity is the perimeter: least privilege, short-lived creds, and graph your IAM for escalation paths.
Enable full control-plane logging and alert on policy edits, PassRole, and new keys.
Pair CSPM detection with preventative guardrails (Block Public Access, Org Policy, IMDSv2).
