Two things define cloud environments embraced by modern businesses today: Convenience and Complexity. Organizations are attracted because the former and somehow manage the latter. However, for cyber attackers, both convenience and complexity offer attack opportunities. Adoption of adversarial style thinking is thus necessary to secure IT environments comprising cloud.
Also, cloud breaches don’t start with a bang as many presume. They begin with a small misstep, a misconfigured bucket here, a stale IAM role there or a CI pipeline that trusts too much.
What makes cloud red teaming so formidable is this: attackers don’t need to break in. They just need to log in, cleverly, quietly and with the right assumptions to exploit. Let’s explore five advanced, achievable cloud red team scenarios that illustrate how modern adversaries manoeuvre through hardened cloud infrastructure.
5 Advanced Cloud Red Teaming Scenarios
A deep dive into real-world attack paths that cloud red teams use to bypass hardened defences. These cloud red teaming scenarios reveal how subtle missteps in identity, trust, and automation can open the door to full compromise.
1. Scenario 1: S3 Enumeration -> Terraform State -> Credential Theft
The attacker discovers an S3 bucket through passive enumeration. It’s publicly listable, not world-readable, just indexable. Inside: archived Terraform state files from past deployments. These files include plaintext secrets, hardcoded IAM keys and DB connection strings.
With valid credentials now in hand, the attacker impersonates a DevOps engineer, accessing internal APIs and staging services.
Adversary Angle: State files are the new gold. Red teams frequently look for .tfstate, .env, and config.json in exposed buckets – and often win.
2. Scenario 2: IAM Role Chaining -> Trust Policy Pivot
An internal Lambda has permission to sts:AssumeRole into a different AWS account. The attacker, operating inside the first account, follows the chain – hopping through four roles across dev, test, and prod environments. One role has overly broad trust relationships, allowing the attacker to edit its own permissions.
They escalate to AdministratorAccess without ever directly touching a sensitive user or triggering an alert.
Red Team Tactic: Lateral movement via AssumeRole chains is stealthy, persistent, and often misconfigured in multi-account AWS setups.
3. Scenario 3: CI/CD Injection -> Deployment Backdoor
The red team compromises a developer’s personal access token (PAT) for GitHub. They submit a seemingly benign pull request to an internal repo with a Terraform backend. The PR is approved and merged – but the CI pipeline (GitHub Actions) automatically applies the changes using a deploy key.
Buried in the code: a conditionally triggered backdoor that modifies a security group and uploads an innocuous-looking Lambda function that acts as a callback beacon.
Real-World Hit: Red teams increasingly target CI pipelines, not just apps. Deployment automation becomes attacker automation when secrets and infra-as-code are mixed carelessly.
4. Scenario 4: Metadata Abuse in EC2 -> Credential Theft
An EC2 instance running in a misconfigured subnet is compromised through SSRF from a publicly exposed API endpoint. The attacker reaches the metadata service (IMDSv1) and steals temporary IAM credentials.
These credentials allow read/write access to an S3 bucket that stores nightly RDS snapshots. The attacker downloads the snapshots, spins up a clone, and extracts production data.
Tradecraft: Metadata abuse is still relevant. IMDSv1 is deprecated but not dead, and SSRF remains a prime entry vector for cloud pivoting.
5. Scenario 5: Cloud Federation Bypass via OIDC Trust Misconfiguration
The attacker identifies an AWS account that allows GitHub OIDC federation for automated deploys. The trust policy is too broad – it accepts any repo from a specific GitHub org. The attacker creates a public repo mimicking internal naming conventions, triggering the token exchange.
Boom – valid AWS credentials, scoped to the deployment role. From there, they enumerate services, spin up rogue Lambda functions, and create a CloudWatch backdoor for persistence.
Modern Exploitation: Federation is increasingly used in CI/CD and multi-cloud setups. One misconfigured trust relationship = wide-open door for code execution.
Conclusion
Cloud security isn’t about firewalls or antivirus anymore. It’s about trust boundaries, identity sprawl, and automation pipelines. These red team scenarios demonstrate that breaches don’t come from the obvious paths – they come from where complexity, misconfiguration, and convenience intersect.
If you’re defending cloud environments, ask yourself:
- Can I trace cross-account role assumptions?
- Are CI secrets being exposed through PRs or state files?
- Do I enforce OIDC trust with strict sub and aud conditions?
- Are metadata services locked down across all compute layers?
Our red teaming services provide full adversarial assessments, helping organizations understand how well you can handle modern cyberattacks. Contact us today.
Cloud Red Teaming FAQs
How is cloud red teaming different from traditional penetration testing?
Cloud red teaming focuses on exploiting cloud-specific misconfigurations, identity abuse, and automation weaknesses rather than just finding and fixing discrete vulnerabilities. It often simulates persistent, stealthy attacks that blend into normal cloud activity.
Which cloud platforms can be targeted in a red team exercise?
A well-designed cloud red team engagement can target AWS, Azure, GCP, or hybrid environments, tailoring scenarios to each platform’s unique services, trust models, and security pitfalls.
Can cloud red teaming be performed without disrupting production systems?
Yes – by using controlled, non-destructive payloads and agreed-upon testing windows, red teams can simulate attacks without affecting live workloads or customer data.
What’s the most common oversight that enables cloud breaches?
Poorly managed identity and access controls – such as overly broad IAM roles, misconfigured trust policies, and stale credentials – often provide attackers with an easy way in without exploiting software vulnerabilities.
