🎯 Objective

To demonstrate how attackers can abuse the aws:ResourceOrgID condition key to brute-force AWS Organization IDs by interacting with a vulnerable S3 bucket using IAM role assumption and conditional access attempts.

🧾 Lab Overview

  • Lab Title: Discover AWS Organization ID via S3 Bucket
  • Platform: CybrLabs
  • Focus: IAM policy condition misconfiguration exploitation
  • Target: S3 bucket with vulnerable aws:ResourceOrgID condition

🛠 Tools Used

The lab utilized a focused set of AWS tools and custom Python scripts to exploit the IAM policy misconfiguration and demonstrate the vulnerability.

AWS Services

  • AWS CLI: Primary interface for API calls and authentication
  • IAM: Role enumeration and policy analysis
  • STS: Security Token Service for identity verification
  • S3: Target bucket for conditional access testing

Custom Scripts

  • conditional-love.py: Python3 script for brute-forcing Organization IDs
  • CloudTrail Analysis: Simulated log review for enumeration detection

📚 Methodology & Steps Performed

The exploitation followed a systematic approach to discover and abuse the IAM policy misconfiguration, demonstrating real-world attack techniques.

1

AWS CLI Configuration

Configured the AWS CLI with valid access and secret keys to initiate authenticated API calls

2

Identity Verification

Queried active credentials to verify identity and account number using aws sts get-caller-identity

3

IAM Enumeration

Listed all IAM users and roles to explore permissions and entities in the AWS account

4

Role Analysis: S3AccessImages

Searched for and analyzed the S3AccessImages role potentially linked to S3 bucket access

5

Policy Extraction

Retrieved inline policies to analyze permissions and identify the vulnerable aws:ResourceOrgID condition

6

Organization ID Brute-force

Used conditional-love.py script to enumerate possible AWS Organization IDs through conditional access testing

🔍 Key Findings & Analysis

Critical: IAM Policy Condition Misconfiguration

Issue: The S3AccessImages role policy allowed s3:* actions but used a StringLike condition on aws:ResourceOrgID, creating a blind brute-force opportunity

Impact: Attackers can enumerate AWS Organization IDs through conditional access attempts

Evidence: Policy analysis revealed vulnerable condition key usage without proper restrictions

High: Successful Organization ID Enumeration

Issue: Successfully brute-forced AWS Organization ID through conditional policy testing

Method: Used conditional-love.py script targeting s3://img.cybrlabs.io/ with role arn:aws:iam::565765288591:role/S3AccessImages

Impact: Exposure of sensitive organizational infrastructure details

Medium: CloudTrail Logging Gaps

Issue: Limited visibility into enumeration attempts through CloudTrail logging

Impact: Brute-force activities may go undetected without proper monitoring

Observation: Simulated logs showed detectable patterns: "aws:ResourceOrgID": ["o-8qt9p69*"]

🧠 Key Learnings & Security Implications

This hands-on lab provided critical insights into AWS IAM policy vulnerabilities and their real-world exploitation potential.

🔐 Security Implications

  • IAM policy conditions like aws:ResourceOrgID can be exploited for enumeration
  • Lack of monitoring increases risk of undetected brute-force attempts
  • Overly permissive resource policies enable lateral movement
  • Organization ID exposure can reveal infrastructure details

🧠 Key Learnings

  • aws:ResourceOrgID must be used cautiously to prevent enumeration
  • CloudTrail plays crucial role in identifying enumeration activities
  • Security tools like GuardDuty can detect policy misconfigurations
  • Hands-on practice deepens understanding of cloud attack vectors

🛠 Technical Skills

  • IAM policy analysis and condition key exploitation
  • Python scripting for automated enumeration
  • AWS CLI proficiency for cloud reconnaissance
  • CloudTrail log analysis for attack detection

💻 Technical Implementation

AWS CLI Commands - IAM Role Analysis 
# Configure AWS CLI
aws configure

# Verify current identity
aws sts get-caller-identity

# List all IAM users and roles
aws iam list-users
aws iam list-roles

# Query specific role details
aws iam list-roles --query "Roles[?RoleName=='S3AccessImages']"

# List inline role policies
aws iam list-role-policies --role-name S3AccessImages

# Extract policy details
aws iam get-role-policy \
  --role-name S3AccessImages \
  --policy-name AccessS3BucketObjects
Organization ID Brute-force Script Execution 
# Execute conditional brute-force attack
python3 conditional-love.py \
  --role arn:aws:iam::565765288591:role/S3AccessImages \
  --target s3://img.cybrlabs.io/ \
  --action=s3:HeadObject \
  --condition=aws:ResourceOrgID \
  --alphabet="0123456789abcdefghijklmnopqrstuvwxyz-"

# Purpose: Test various aws:ResourceOrgID values
# to trigger successful response based on valid Org ID match
Simulated CloudTrail Log Pattern 
# Example enumeration patterns visible in CloudTrail
{
  "eventTime": "2025-04-12T10:15:30Z",
  "eventName": "AssumeRole",
  "sourceIPAddress": "203.0.113.12",
  "userIdentity": {
    "type": "IAMUser",
    "userName": "attacker-user"
  },
  "requestParameters": {
    "roleArn": "arn:aws:iam::565765288591:role/S3AccessImages",
    "conditions": {
      "aws:ResourceOrgID": ["o-8qt9p69*"]
    }
  }
}