Cloud security & red-teaming - AWS, Azure, GCP

Every AI system you’ll assess in Singapore - government and enterprise alike - runs on AWS, Azure, or GCP. The cloud is the substrate under all of it, so a cloud weakness is an AI weakness. I.5 taught you what the cloud is; this is how you test it. The defining idea, and the one to internalize: a cloud pentest doesn’t ask “what can a user of the app do” - it asks “what can an attacker who has compromised one credential, instance, or service reach from there?” That’s a different scope from a web-app test, and it’s where the findings that matter live: IAM privilege escalation, metadata credential theft, exposed storage, and lateral movement across services.

flowchart LR
  FOOT["Foothold<br/>leaked key · SSRF · exposed service"] --> ENUM["Enumerate<br/>identity · resources · permissions"]
  ENUM --> PRIV["Privilege escalation<br/>permission combos · trust abuse"]
  PRIV --> LAT["Lateral movement<br/>cross-service · cross-account"]
  LAT --> EXFIL["Impact<br/>data exfil · persistence"]
  classDef o fill:#241310,stroke:#ff5b4d,color:#ffc4bb;
  class FOOT,ENUM,PRIV,LAT,EXFIL o;

The same shape on all three providers; only the service names and the privilege-escalation tricks differ. AI surfaces (an SSRF from a model’s fetch tool, II.17 Ch9) are a common foothold that drops you into exactly this chain.

The provider trinity - same concepts, different names

Concept	AWS	Azure	GCP
Identity	IAM (users, roles, policies)	Entra ID (formerly Azure AD) + RBAC	Cloud IAM (members, roles, service accounts)
Object storage	S3 buckets	Blob Storage (containers)	Cloud Storage buckets
Compute	EC2 · Lambda	VMs · Functions	Compute Engine · Cloud Functions
Secrets	Secrets Manager · SSM · KMS	Key Vault	Secret Manager · Cloud KMS
Metadata service	IMDS (169.254.169.254)	IMDS (169.254.169.254)	Metadata server (metadata.google.internal)
Audit log	CloudTrail	Activity Log / Entra logs	Cloud Audit Logs
Org boundary	Accounts / Organizations	Subscriptions / Tenants	Projects / Org

Learn the concepts once and you can test any of the three; the names are just translation. Note the metadata service - a high-value cloud-pentest target, below.

The methodology - recon to impact

A cloud red-team walks the same five phases as the diagram. Expand each for what you actually do.

1 Foothold - how you get in

The starting credential or access. Common origins on a real engagement: a leaked access key (in a git repo, a CI log, a public bucket), an SSRF in the application (including an AI feature’s URL-fetch tool - II.17 Ch9) that reaches the metadata service, an exposed service with no auth, or a credential the client provides for an “assumed-breach” test (the most common and realistic scope).

The metadata-service move If you have SSRF or code-exec on an instance, request the cloud metadata endpoint - on AWS/Azure 169.254.169.254, on GCP metadata.google.internal - to retrieve the instance’s temporary IAM credentials. That hands you the instance’s role and drops you straight into enumeration. The defense is IMDSv2 (session-token-bound) on AWS and blocking metadata egress.

2 Enumerate - map what the credential can see

With any credential, even low-privilege, systematically map the environment: which identity am I, what can I do, what resources exist. This is the cloud equivalent of internal network enumeration.

Enumeration starting points (authorized testing only)

# AWS - who am I, then enumerate
aws sts get-caller-identity
aws iam get-account-authorization-details        # full IAM picture (if permitted)
# Azure
az account show ; az role assignment list
# GCP
gcloud auth list ; gcloud projects get-iam-policy PROJECT_ID

Automate posture review with the standard auditing tools: ScoutSuite (multi-cloud, 400+ rules, HTML report) and Prowler (AWS-focused, CIS-benchmark aligned) flag IAM misconfigs, public storage, weak network rules by severity. Run these first for breadth, then go manual for the chained findings scanners miss.

3 Privilege escalation - the heart of a cloud test

The defining cloud finding: a low-privilege identity reaching admin through a combination of permissions, a trust relationship, or a policy flaw. You’re looking for permission sets that let you grant yourself more.

Classic AWS escalation patterns An identity with iam:CreatePolicyVersion can rewrite its own policy to admin; lambda:CreateFunction + iam:PassRole lets you run code as a more-privileged role; iam:CreateAccessKey on another user lets you become them. There are dozens of these known paths.

Map it, don’t guess Use pmapper (Principal Mapper) to build a graph of users/roles and have it compute the escalation paths automatically; Pacu (AWS exploitation framework) enumerates permissions and tests the paths. On Azure, MicroBurst enumerates Entra ID and resources. The skill is reading the graph: “this service account can launch compute and pass a role → it can run as that role → that role is admin.”

4 Lateral movement - pivot across the estate

From one identity/service, reach others. Cross-account/subscription trust relationships (a role that can be assumed from another account), over-shared service accounts, network paths into private subnets, and inter-service trust (a compute instance trusted by a database). Government estates with many subscriptions/projects make trust misconfiguration a rich surface.

AI relevance This is where an AI foothold becomes a breach: an injected agent (II.17 Ch3) holding a broad role, or an SSRF’d instance, lets you pivot from the AI workload into the wider cloud - the II.15 incident pattern (Azure SRE Agent, the RDS-gateway pivot in II.17 Ch11).

5 Impact & persistence - prove it, safely

Demonstrate the consequence without causing harm: reach (don’t exfiltrate) the “crown-jewel” data, show you could create a backdoor identity or tamper with the audit log (CloudTrail/Activity Log), then stop and document. On an authorized test you prove reachability; you don’t detonate.

Logging is a target and your safety net Note whether you could disable or evade CloudTrail/Cloud Audit Logs (a real attacker would) - and rely on those same logs to scope what your test touched.

The findings that recur (your checklist)

• Over-permissive IAM - *:* policies, admin where read-only suffices, escalation chains. The most common and highest-impact finding.
• Public / exposed storage - world-readable S3 buckets / blobs / GCS, often holding data, backups, or the RAG corpus and vectors (II.13).
• Metadata service exposure - reachable via SSRF, no IMDSv2 - instant credential theft.
• Credential hygiene - long-lived access keys, no MFA on privileged accounts, unused/orphaned service accounts (the NHI sprawl of III.2).
• Network exposure - security groups open to 0.0.0.0/0 on admin ports, databases/queues reachable without auth, sensitive workloads in public subnets.
• Cross-account/subscription trust - role assumptions enabling lateral movement.
• Exposed AI infra - unauthenticated model-serving endpoints, vector DBs, MLOps consoles (II.7, II.13).

Rules of engagement - non-negotiable

Read this before you touch a cloud target

Each provider publishes a penetration-testing policy. AWS and Azure permit testing of your own resources for most services without prior approval but prohibit certain activities (notably anything resembling DoS); GCP similarly expects you to stay within your own projects and acceptable-use terms. Always operate under written authorization, scoped to specific accounts/subscriptions/projects, and confirm the provider’s current rules before the engagement - they change. For an accredited Singapore engagement this maps to the II.20 scope/RoE step. Testing cloud you don’t own or aren’t authorized for is a crime, full stop.

The toolchain

Audit/recon: ScoutSuite (multi-cloud), Prowler (AWS/CIS), CloudMapper (network diagrams). IAM analysis: pmapper (escalation graphs). Exploitation: Pacu (AWS), MicroBurst (Azure). Native CLIs (aws/az/gcloud) for manual enumeration. Pattern: scanners for breadth → graph the IAM → manual chaining for the findings that matter → re-scan after remediation to prove the fix. Map every finding to CIS benchmarks + AIVSS severity (IV.2) and report in the two-audience format (II.20).

Cross-reference

Cloud concepts: I.5. Attacking AI infra on the cloud: II.7, II.12, II.13. SSRF-to-metadata via an AI feature: II.17 Ch9. The chained capstone pivot: II.17 Ch11. Identity/NHI controls: III.2. Scoring & reporting: II.20, IV.2.