Cloud Security Tidbits: Learning AWS Exploitation Through Intentionally Broken Infrastructure

Hook

Your AWS infrastructure can pass every security audit with flying colors—perfect IAM policies, encrypted buckets, VPC isolation—and still be trivially exploitable through application code that uses cloud services incorrectly.

Context

The cloud security industry has spent the last decade obsessing over infrastructure misconfigurations: open S3 buckets, overly permissive security groups, and IAM roles with wildcards. Tools like Prowler, ScoutSuite, and CloudSploit scan for these issues automatically, and most organizations have gotten reasonably good at locking down their infrastructure layer. But there's a more insidious class of vulnerabilities that traditional cloud security tools miss entirely: application-level exploitation of correctly configured cloud services.

Doyensec's cloudsec-tidbits repository tackles this gap by providing hands-on, deployable labs that demonstrate how attackers exploit the way applications use AWS services, not just how AWS resources are configured. Each 'tidbit' is a real vulnerability pattern discovered during professional penetration testing engagements, packaged as Terraform code that builds a vulnerable environment, paired with detailed blog posts explaining the attack and remediation. It's the difference between knowing that an S3 bucket shouldn't be public versus understanding how an application's flawed logic for generating presigned URLs can leak sensitive data even from a perfectly locked-down bucket.

Technical Insight

The repository's architecture is elegantly simple: each vulnerability scenario lives in its own directory containing Terraform files that provision the vulnerable AWS infrastructure, along with sample application code demonstrating the exploitable pattern. The use of Infrastructure as Code makes these labs reproducible and disposable—you can spin up a vulnerable environment, experiment with exploitation techniques, and tear it down without leaving security landmines in your AWS account.

Let's examine one of the most sophisticated tidbits: AWS SDK role assumption vulnerabilities. Many developers don't realize that when you use the AWS SDK's AssumeRole functionality from application code, you're creating a trust boundary that can be exploited if the role ARN isn't properly validated. Here's a simplified example of the vulnerable pattern:

import boto3
import os

# Vulnerable: Role ARN comes from user input
def get_user_data(role_arn, user_id):
    sts = boto3.client('sts')
    
    # Attacker controls role_arn parameter
    assumed_role = sts.assume_role(
        RoleArn=role_arn,
        RoleSessionName='user-session'
    )
    
    credentials = assumed_role['Credentials']
    s3 = boto3.client(
        's3',
        aws_access_key_id=credentials['AccessKeyId'],
        aws_secret_access_key=credentials['SecretAccessKey'],
        aws_session_token=credentials['SessionToken']
    )
    
    # Retrieve user data
    return s3.get_object(Bucket='user-data', Key=f'{user_id}.json')

The vulnerability isn't in the infrastructure configuration—the IAM roles might be perfectly configured with least privilege principles. The problem is that the application trusts user input to specify which role to assume. An attacker can supply a role ARN they control in their own AWS account, configured with a trust policy that allows assumption from your application's role, effectively using your application as a confused deputy to exfiltrate data or perform actions.

The cloudsec-tidbits Terraform code for this scenario sets up the entire attack chain: the vulnerable Lambda function or ECS task, the IAM roles with trust relationships, and even the attacker-controlled infrastructure in a separate AWS account (simulated in the same account with appropriate naming). This is where the educational value shines—you can see the complete picture of how the vulnerability exists in working code, not just conceptual diagrams.

Another tidbit explores AWS Cognito attribute tampering, demonstrating how applications that rely on user pool attributes for authorization decisions can be exploited when those attributes aren't properly protected. The Terraform code provisions a Cognito user pool with custom attributes, an API Gateway protected by Cognito authorization, and a vulnerable backend that makes security decisions based on user attributes that the user themselves can modify:

resource "aws_cognito_user_pool" "main" {
  name = "vulnerable-user-pool"

  schema {
    name                = "role"
    attribute_data_type = "String"
    mutable            = true  # Vulnerable: users can modify their own role
    
    string_attribute_constraints {
      min_length = 1
      max_length = 256
    }
  }
}

The corresponding application code then makes authorization decisions based on this mutable attribute, allowing privilege escalation. What makes these labs valuable is that they show the full context: you can see why a developer might make this mistake (Cognito attributes seem like a natural place to store user metadata), how the infrastructure enables it (the mutable = true setting), and how an attacker exploits it (using the Cognito API to update their own attributes).

Each lab includes detailed setup instructions in the README, including required AWS permissions, estimated costs (typically a few cents if you remember to destroy the resources), and safety warnings. The Terraform variables are parameterized, allowing you to customize resource names and regions, which is crucial for avoiding conflicts if multiple team members are running the labs simultaneously.

Gotcha

The most significant limitation is coverage: with only three vulnerability scenarios currently published, this repository represents a starting point rather than a comprehensive training program. Cloud security encompasses hundreds of potential vulnerability patterns across compute, storage, networking, serverless, container orchestration, and managed services. If you're looking for extensive scenario-based training comparable to CloudGoat's 10+ scenarios, you'll be disappointed. The Doyensec team appears to be publishing these as they extract and sanitize findings from real penetration testing engagements, which means updates are sporadic rather than on a regular release schedule.

Another critical consideration is the AWS-only focus. If your organization runs multi-cloud infrastructure or primarily uses Azure or GCP, these labs won't directly translate. While the conceptual vulnerability patterns (confused deputy attacks, attribute-based access control flaws) exist across cloud providers, the specific implementation details, SDK behaviors, and remediation strategies differ significantly. You'll gain general security awareness but won't get hands-on experience with your actual cloud environment. Additionally, these labs require a certain level of AWS familiarity to set up and use effectively—if you're still learning the basics of IAM roles and policies, you might find yourself struggling to understand what makes the vulnerable configuration different from a secure one.

Verdict

Use if: You're a security professional, penetration tester, or senior developer responsible for cloud application security and need hands-on experience with application-layer AWS vulnerabilities that go beyond infrastructure misconfigurations. This is particularly valuable if you're conducting security reviews of applications that use AWS SDK functionality heavily, implementing secure-by-design patterns for cloud-native applications, or training development teams on cloud security beyond the basics. The labs provide concrete, reproducible examples of real-world vulnerability patterns you can reference in threat models and security guidelines. Skip if: You're looking for comprehensive cloud security training with dozens of scenarios, need coverage beyond AWS, are primarily concerned with infrastructure-layer security issues that existing scanning tools already detect, or don't have the AWS budget and permissions to deploy lab environments. Also skip if you need production-ready security testing tools rather than educational resources—these labs teach you what to look for, but you'll need to build your own tooling for actual security assessments.