🔒 AWS Security Lab: Breach in the Cloud

📝 Overview

This repository documents my completion of the "Breach in the Cloud" security lab from PwnedLabs.io. Through this hands-on exercise, I performed forensic analysis on AWS CloudTrail logs to investigate a simulated security breach, trace the attack path, and validate data exfiltration.

Lab Link: Breach in the Cloud - PwnedLabs

Screenshot: PwnedLabs lab interface

---

🎯 Lab Information

Attribute	Details
Lab Name	Breach in the Cloud
Platform	PwnedLabs
Difficulty	Beginner
Focus Areas	AWS CloudTrail Analysis, IAM Security, S3 Enumeration
Scenario	Huge Logistics detected unusual AWS activity
Incident ID	INCIDENT-3252

---

🎓 Learning Objectives

Through this lab, I developed practical skills in:

• ✅ CloudTrail Log Analysis - Analyzing AWS CloudTrail logs for suspicious activity patterns
• ✅ IAM Security Investigation - Identifying compromised IAM users and roles
• ✅ Privilege Escalation Detection - Tracing AssumeRole privilege escalation attacks
• ✅ S3 Security - Investigating S3 bucket enumeration and data exfiltration
• ✅ Attack Path Validation - Replicating attacker steps to confirm breach methodology

---

🔍 Executive Summary

The Incident

The Huge Logistics security team detected unusual activity in their AWS account on August 26, 2023. Through systematic analysis of CloudTrail logs, I confirmed a successful security breach involving:

• Compromised Account: temp-user (IAM user)
• Attack Origin: 84.32.71.19 (UAB Cherry Servers, Chicago)
• Attack Duration: 45 minutes (20:35 - 21:20 UTC)
• Data Exfiltrated: 2,232 bytes from S3 bucket
• Critical Vulnerability: No MFA on privileged role assumption

Attack Timeline

20:35 UTC → Initial Access (GetCallerIdentity)
20:50 UTC → Failed S3 Access (13 errors)
20:50-20:55 UTC → Massive Enumeration (450 errors)
21:00 UTC → Privilege Escalation (AssumeRole successful)
21:20 UTC → Data Exfiltration (S3 GetObject)

🗺️ Attack Flow Diagram

Attacker (84.32.71.19)
        │
        ▼
Compromised IAM User (temp-user)
        │
        ▼
Enumeration (450+ AccessDenied Errors)
        │
        ▼
Privilege Escalation (AssumeRole → AdminRole)
        │
        ▼
S3 Bucket Access (emergency-data-recovery)
        │
        ▼
Data Exfiltration (emergency.txt)

---

🛠 Custom CloudTrail Viewer Tool

During this investigation I built a browser-based CloudTrail analysis tool to make log investigation easier.

Features:

• Upload and parse CloudTrail JSON logs
• Identify IAM users and roles
• Visualize API activity timeline
• Detect suspicious IP addresses
• Highlight privilege escalation events

Live Tool: https://abdurrahman-cybersec.github.io/AWS-cloudtrail-viewer/

Repository: https://github.com/AbdurRahman-cybersec/AWS-cloudtrail-viewer

---

📊 Investigation Process

Phase 1: Initial Log Analysis

Objective: Identify suspicious usernames in CloudTrail logs

grep -r userName | sort -u

Finding: Discovered suspicious username temp-user that doesn't match internal naming conventions.

Screenshot: Terminal output showing suspicious temp-user account

---

Phase 2: Timeline Analysis

2.1 First Contact (20:35 UTC)

Log File: 107513503799_CloudTrail_us-east-1_20230826T2035Z_PjmwM7E4hZ6897Aq.json

Key Details:

• Action: GetCallerIdentity (AWS STS)
• User: temp-user
• Source IP: 84.32.71.19
• User Agent: aws-cli/1.27.74 Python/3.10.6 Linux/5.15.90.1-microsoft-standard-WSL2
• Location: Chicago, IL (UAB Cherry Servers)

Screenshot: CloudTrail log showing initial GetCallerIdentity call

Analysis: The GetCallerIdentity action functions like the whoami command, allowing attackers to confirm their access level. The IP address traces to a VPS provider not used by Huge Logistics—a major red flag.

Screenshot: IP geolocation showing UAB Cherry Servers

---

2.2 Initial Reconnaissance Failure (20:50 UTC)

Log File: 107513503799_CloudTrail_us-east-1_20230826T2050Z_iUtQqYPskB20yZqT.json

Findings:

• Attempted ListObjects on S3 bucket emergency-data-recovery
• Result: Access Denied (13 error messages)

grep errorMessage 107513503799_CloudTrail_us-east-1_20230826T2050Z_iUtQqYPskB20yZqT.json

Screenshot: Access Denied error for S3 bucket

---

2.3 Aggressive Enumeration Attack (20:50-20:55 UTC)

Log Files:

• 107513503799_CloudTrail_us-east-1_20230826T2050Z_iUtQqYPskB20yZqT.json
• 107513503799_CloudTrail_us-east-1_20230826T2055Z_W0F5uypAbGttUgSn.json

Attack Signature:

# Count errors in each log file
grep errorMessage *T2050Z*.json | wc -l
# Output: 13

grep errorMessage *T2055Z*.json | wc -l
# Output: 450

Total Access Denied Errors: 463

Screenshot: Terminal showing 450 access denied errors

Attempted IAM API Actions:

• iam:ListAccountAliases
• iam:ListInstanceProfiles
• iam:ListUsers
• datapipeline:ListPipelines
• organizations:ListAccounts
• route53:ListHealthChecks
• And many more...

Screenshot: Snippet of failed enumeration attempts

Significance: 450 access denied errors from a single user in minutes is a textbook indicator of automated enumeration. A legitimate user would never generate this pattern.

---

2.4 Privilege Escalation Success (21:00 UTC)

Log File: 107513503799_CloudTrail_us-east-1_20230826T2100Z_APB7fBUnHmiWjHtg.json

🚨 Critical Discovery: No error messages in this log file!

grep errorMessage *T2100Z*.json
# No results - all actions succeeded

Successful Action: AssumeRole to AdminRole

{
  "eventName": "AssumeRole",
  "requestParameters": {
    "roleArn": "arn:aws:iam::107513503799:role/AdminRole",
    "roleSessionName": "MySession"
  },
  "responseElements": {
    "credentials": {
      "accessKeyId": "ASIARSCCN4A3VHM46DJU",
      ...
    }
  }
}

Screenshot: CloudTrail log showing successful AssumeRole

Security Gap: The AdminRole had no MFA requirement, allowing privilege escalation with only compromised credentials.

Screenshot: Role showing mfaAuthenticated: false

---

2.5 Data Exfiltration (21:20 UTC)

Log File: 107513503799_CloudTrail_us-east-1_20230826T2120Z_UCUhsJa0zoFY3ZO0.json

With elevated AdminRole privileges, the attacker executed:

1. ListObjects - Listed contents of emergency-data-recovery bucket
2. GetObject - Downloaded emergency.txt (2,232 bytes)

Screenshot: CloudTrail Viewer showing ListObjects and GetObject actions

Exfiltration Details:

{
  "eventName": "GetObject",
  "requestParameters": {
    "bucketName": "emergency-data-recovery",
    "key": "emergency.txt"
  },
  "additionalEventData": {
    "bytesTransferredOut": 2232
  }
}

---

🔬 Attack Path Validation

To validate the breach, I replicated the attacker's steps using the provided credentials:

Step 1: Confirm Identity

aws sts get-caller-identity

Screenshot: Confirming temp-user identity

Step 2: Check IAM Policies

aws iam list-user-policies --user-name temp-user

Output: Policy named test-temp-user

Screenshot: Discovering inline policy

Step 3: Examine Policy Details

aws iam get-user-policy --user-name temp-user --policy-name test-temp-user

Critical Finding: Policy allows sts:AssumeRole on AdminRole

{
  "PolicyDocument": {
    "Statement": [{
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::107513503799:role/AdminRole"
    }]
  }
}

Screenshot: IAM policy granting AssumeRole permission

Step 4: Assume AdminRole

aws sts assume-role \
  --role-arn arn:aws:iam::107513503799:role/AdminRole \
  --role-session-name MySession

Screenshot: Successfully assuming AdminRole with temporary credentials

Step 5: Configure New Credentials

export AWS_ACCESS_KEY_ID="ASIARSCCN4A3VHM46DJU"
export AWS_SECRET_ACCESS_KEY="..."
export AWS_SESSION_TOKEN="..."

Step 6: Verify Elevated Access

aws sts get-caller-identity

Screenshot: Confirmed AdminRole context

Step 7: Access S3 Bucket

aws s3 ls s3://emergency-data-recovery

Screenshot: Successfully listing S3 bucket contents

Step 8: Retrieve Exfiltrated Data

aws s3 cp s3://emergency-data-recovery/emergency.txt .
aws s3 cp s3://emergency-data-recovery/message.txt .

Screenshot: Downloading files from compromised bucket

Flag Retrieved: 3eb222cf55522f0f321f1ed5ed9a3663

---

📈 Attack Path Visualization

The attack followed this pattern:

1. Compromised Credentials → Initial access as temp-user
2. IAM Enumeration → Discovery of AssumeRole capability
3. Privilege Escalation → Assumption of AdminRole (no MFA)
4. Data Access → S3 bucket compromise and file exfiltration

---

🛡️ Security Vulnerabilities Identified

Vulnerability	Severity	Description
Compromised Credentials	🔴 Critical	The temp-user account credentials were compromised, likely through credential exposure or phishing
No MFA on Privileged Roles	🔴 Critical	AdminRole allowed assumption without MFA, enabling privilege escalation with only stolen credentials
Overly Permissive IAM Policy	🟠 High	temp-user had inline policy granting AssumeRole to administrative role—violation of least privilege
Inadequate Monitoring	🟠 High	450+ access denied errors in minutes went undetected—no real-time alerting for enumeration patterns
Weak Naming Conventions	🟡 Medium	temp-user doesn't follow internal standards, making it harder to identify as suspicious initially

---

💡 Recommendations

Immediate Actions (Day 0)

1. Revoke Compromised Credentials

   • Disable temp-user account immediately
   • Rotate all access keys
   • Terminate all active sessions

2. Implement MFA Requirements

   {
     "Condition": {
       "Bool": {
         "aws:MultiFactorAuthPresent": "true"
       }
     }
   }

   Add MFA condition to all privileged role trust policies

3. Enable S3 Protections

   • Enable bucket versioning
   • Enable MFA Delete
   • Review and restrict bucket policies

Short-Term Actions (Week 1)

4. Implement Real-Time Alerting

   • CloudWatch alarm for >50 access denied errors in 5 minutes
   • SNS notifications for AssumeRole events
   • AWS GuardDuty for automated threat detection

5. Review IAM Policies

   • Audit all inline policies
   • Remove unnecessary AssumeRole permissions
   • Implement least privilege access

6. Credential Management

   • Implement AWS Secrets Manager
   • Enable automated credential rotation
   • Enforce strong password policies

Long-Term Improvements (Month 1+)

7. Enhanced Monitoring

   • Deploy AWS Security Hub
   • Centralize CloudTrail logs
   • Implement SIEM integration

8. Security Training

   • Conduct incident response drills
   • Train team on CloudTrail analysis
   • Establish clear escalation procedures

9. Network Segmentation

   • Implement IP allowlisting for sensitive operations
   • Review VPC configurations
   • Enable VPC Flow Logs

---

🧰 Tools & Commands Used

Log Analysis Commands

# Find all usernames in CloudTrail logs
grep -r userName | sort -u

# Search for specific user activity
grep -h -A 10 temp-user <logfile>.json

# Count error messages
grep errorMessage <logfile>.json | wc -l

# Search for specific actions
grep -A 20 AssumeRole <logfile>.json

AWS CLI Commands

# Verify identity
aws sts get-caller-identity

# List user policies
aws iam list-user-policies --user-name temp-user

# Get policy details
aws iam get-user-policy --user-name temp-user --policy-name test-temp-user

# Assume role
aws sts assume-role --role-arn <role-arn> --role-session-name <session-name>

# List S3 bucket
aws s3 ls s3://emergency-data-recovery

# Download from S3
aws s3 cp s3://emergency-data-recovery/emergency.txt .

---

📚 Key Learnings

1. CloudTrail is Essential: Every AWS action leaves a trace in CloudTrail. Proper log analysis can reveal the complete attack chain.

2. Pattern Recognition: 450 access denied errors is a clear enumeration pattern. Automated alerting for such patterns is critical.

3. MFA Prevents Escalation: Even with compromised credentials, MFA on privileged roles would have stopped this attack.

4. Least Privilege Matters: The temp-user should never have had AssumeRole permissions to AdminRole.

5. Time is Critical: The attack took 45 minutes. Faster detection and response could have prevented data exfiltration.

---

🔗 Resources

• Lab Platform: PwnedLabs.io
• Lab Link: Breach in the Cloud
• AWS CloudTrail Documentation: AWS CloudTrail User Guide
• AWS IAM Best Practices: IAM Security Best Practices
• CloudTrail Viewer Tool: GitHub - AWS CloudTrail Viewer

---

🏆 Lab Completion

Screenshot: Lab completion badge

Completion Date: March 3, 2026
Flag: 3eb222cf55522f0f321f1ed5ed9a3663

---

📝 Notes

This lab was completed in a controlled environment provided by PwnedLabs. All credentials, IP addresses, and AWS account details are part of the lab scenario and are no longer active.

---

🤝 Connect With Me

If you found this writeup helpful or have questions about AWS security, feel free to connect with me on LinkedIn!

---

📄 License

This writeup is for educational purposes only. All lab materials and scenarios are property of PwnedLabs.

---

#AWS #CloudSecurity #CyberSecurity #CloudTrail #IAM #S3Security #ThreatHunting #DFIR #PwnedLabs