« Red Team Engineer

Phase 09 — Cloud & Container Red Team

Operation Cedar Lattice, Phase 09. Phases 07 and 08 mapped Meridian Freight's detection-gap surface and built the post-exploitation playbook on Windows hosts. Now the engagement pivots to Meridian Freight's cloud footprint: an AWS organization with cross-account roles, an Azure subscription running freight-tracking microservices, and a Kubernetes cluster on EKS whose nodes pull credentials from the Instance Metadata Service.

This phase answers the question the cloud-security team will ask in the report: how does a compromised container reach IAM admin, and what does every step emit into CloudTrail? The deliverable is not "we got Admin." It is "here is the exact permission graph, the lowest-detection path through it, and the CloudTrail event name that fires at each step."

Safety (non-negotiable). Authorized security-education only. Every offensive concept in this phase ends in its detection. The labs are graph-solvers and configuration-analyzers over synthetic metadata. There are no real cloud credentials, no real API calls, no working SSRF chains, no deployable IMDS exploits, and no container escape payloads in this repo. Every technique is presented alongside the CloudTrail event, GuardDuty finding, or Falco rule that catches it.

Why this phase exists

Cloud IAM is the new perimeter. A red team engagement that stops at the EC2 instance and never follows the attached IAM role to see what sts:AssumeRole can reach misses the highest-value finding in the report. A container running as root with a mounted Docker socket is not just a privilege-escalation finding — it is a cloud-account-takeover finding if the node has an instance profile. Understanding the full permission graph — from compromised container to IAM admin — and being able to articulate exactly which CloudTrail event fires at each edge is what distinguishes a principal-level cloud red team consultant from one who just runs pacu.

Learning Objectives

1. Model AWS IAM policy evaluation: SCP → resource-based → identity-based → permission boundaries → session policies, and know which layer wins each conflict.
2. Enumerate at least five IAM privilege-escalation paths (specific permission → specific effect) and name the CloudTrail event each one emits.
3. Explain the difference between IMDSv1 and IMDSv2, including the hop-limit mechanism that prevents SSRF-to-IMDS chains from inside containers.
4. Describe Azure RBAC scope hierarchy and identify the two permissions most commonly abused for lateral movement in Azure tenants.
5. Map the Linux primitives that isolate containers (namespaces, cgroups, capabilities) and explain exactly which primitive each container-escape path defeats.
6. Write a Falco rule condition that detects a privileged container launch or Docker socket mount.
7. Given a synthetic IAM permission graph, compute the lowest-detection-cost path from a compromised principal to admin using Dijkstra over CloudTrail visibility costs.

Cedar Lattice Artifact

Artifact 09-A — Meridian Freight Cloud Permission Graph

FIN-LATTICE's initial foothold is a compromised CI/CD runner that has the IAM role arn:aws:iam::114700000000:role/meridian-cicd-runner. The runner's policy has sts:AssumeRole on arn:aws:iam::114700000000:role/meridian-deploy-staging. The staging role has iam:AttachUserPolicy on arn:aws:iam::114700000000:user/*. A separate EKS node has iam:CreatePolicyVersion on the shared meridian-ops managed policy.

The question this artifact answers: which path reaches IAM admin with the fewest high-signal CloudTrail events, and what does each step look like in the SIEM?

Labs

How to Run

# Lab 01
cd lab-01-cloud-iam-attack-path
pip install -r requirements.txt

# Run stubs (should fail with NotImplementedError)
pytest -q

# Run reference solution
LAB_MODULE=solution pytest -q

# Lab 02
cd ../lab-02-imds-container-escape
pip install -r requirements.txt

pytest -q                       # stubs — fails
LAB_MODULE=solution pytest -q   # solution — passes

All labs use pure Python stdlib + pytest. No cloud SDK, no real credentials, no network calls.

Navigation

« Phase 08 — Post-Exploitation & C2 | Phase 10 — Red Team Reporting & Purple Team »