AWS Breach Investigation: From Compromised Credentials to Data Exfiltration

In modern cloud environments, a single compromised credential can cascade into a full-scale data breach within minutes. This forensic investigation reconstructs how an external attacker exploited a compromised IAM access key to escalate privileges and exfiltrate sensitive data from an S3 bucket—all in less than an hour.

48 min

Attack Duration

6 IPs

Attacker Infrastructure

1 File

Data Exfiltrated

Executive Summary

On August 26, 2023, the Terrapin CloudWorks AWS account experienced a security breach. An external attacker gained initial access using a compromised IAM access key (AKIARSCCN4A3WD4RO4P4) belonging to the user temp-user. Through privilege escalation via sts:AssumeRole, the attacker assumed the high-privilege AdminRole and successfully exfiltrated a sensitive file named emergency.txt from an S3 bucket.

The Attack Timeline: Minute-by-Minute Reconstruction

Using AWS CloudTrail logs, I reconstructed the complete attack chain from initial reconnaissance to data exfiltration. The attacker followed a methodical progression, adapting their tactics when faced with permission barriers.

Phase 1: Initial Access

20:29:37 UTC

Attacker Confirms Compromised Credentials

The attacker makes their first API call from IP 84.32.71.19 to verify the identity of the compromised credentials.

API Call: GetCallerIdentity
IAM Identity: temp-user
Source IP: 84.32.71.19
Status: Success

Significance: This is the "smoking gun"—the first command executed by the attacker using the compromised access key.

Phase 2: Failed Enumeration

20:35:56 - 20:47:31 UTC

Reconnaissance Meets Resistance

The attacker attempts to discover AWS resources but hits permission barriers.

API Calls Attempted:
- ListBuckets
- DescribeInstances
- [Multiple other enumeration calls]

Result: AccessDenied errors
Pattern: High volume of failed API calls

Key Finding: The temp-user had limited permissions, prompting the attacker to seek privilege escalation.

Phase 3: Privilege Escalation

20:54:28 UTC

The Critical Pivot Point

The attacker successfully exploits the sts:AssumeRole permission to escalate from temp-user to AdminRole.

API Call: sts:AssumeRole
From: temp-user (initiator)
To: AdminRole (target)
MFA Authenticated: false
Status: Success

Critical Finding: MFA was not required for role assumption. This single misconfiguration enabled the entire attack.

Phase 4: Target Discovery

21:17:10 UTC

Identifying the Prize

Now operating as AdminRole, the attacker lists the contents of the emergency-data-recovery S3 bucket from IP 84.32.71.125.

API Call: s3:ListObjects
Bucket: emergency-data-recovery
IAM Identity: AdminRole (assumed)
Source IP: 84.32.71.125

Phase 5: Data Exfiltration

21:17:16 UTC

Mission Accomplished

Just 6 seconds after discovery, the attacker downloads emergency.txt from a different IP (84.32.71.3).

API Call: s3:GetObject
File: emergency.txt
Bucket: emergency-data-recovery
Source IP: 84.32.71.3
Time from discovery: 6 seconds

Behavioral Indicator: The IP change suggests distributed infrastructure or proxy chaining to evade detection.

Privilege Escalation: The Smoking Gun

The pivotal moment of this attack was the successful privilege escalation from a low-permission user to an administrative role. The CloudTrail logs reveal critical details:

        Before Escalation
        Identity: temp-user (IAM User)
Permissions: Limited, resulting in multiple AccessDenied errors
Capabilities: Insufficient for S3 access to sensitive buckets

      

        After Escalation
        Identity: AdminRole (Assumed Role)
Permissions: Full administrative access
MFA Status: "mfaAuthenticated":"false" ⚠️
Capabilities: Unrestricted access to S3, EC2, IAM, and all services

      

The AssumeRole API call is the "smoking gun" that explicitly shows temp-user successfully requesting and receiving temporary credentials for AdminRole, fundamentally changing their access level.

Indicators of Compromise (IoCs)

During the investigation, I identified multiple technical and behavioral indicators that can be used for threat hunting and alerting in production environments.

Network Indicators

84.32.71.3

84.32.71.5

84.32.71.19

84.32.71.33

84.32.71.48

84.32.71.125

User Agent Strings

aws-cli/1.27.74 Python/3.10.6 Linux/5.15.90.1-microsoft-standard-WSL2 botocore/1.29.74

aws-sdk-go-v2/1.3.2

IAM Principals Involved

temp-user (Compromised IAM User)
AdminRole (Abused IAM Role)

Behavioral Patterns

🚨 High-Volume Failed API Calls

A sudden spike of AccessDenied errors from temp-user between 20:35-20:47 UTC was a clear indicator of malicious reconnaissance. This pattern should trigger immediate alerts.

✅ Escalation After Recon Failure

The successful AssumeRole call occurred immediately after the period of failed discovery attempts—demonstrating adaptive attacker behavior.

AWS Services Accessed

✓ AWS STS

Used for identity confirmation (GetCallerIdentity) and privilege escalation (AssumeRole)

✓ Amazon S3

Used for reconnaissance (ListObjects) and data exfiltration (GetObject)

✗ Amazon IAM

Multiple failed enumeration attempts

✗ Amazon EC2

Multiple failed DescribeInstances attempts

Prevention Recommendations

Based on the attack chain reconstructed from CloudTrail logs, I developed the following cloud-specific security improvements to prevent similar incidents:

1. Enforce Principle of Least Privilege

The temp-user should not have had the sts:AssumeRole permission for a highly privileged target like AdminRole.

Action: Review and scope down IAM permissions to the minimum required for a user's function. Implement permission boundaries.

2. Require MFA for Sensitive Actions

The trust policy for AdminRole should require multi-factor authentication for assumption.

Action: Add MFA condition to role trust policy. This would have blocked the attacker at the privilege escalation stage, as they only possessed a single factor (the access key).

3. Implement Access Key Rotation and Auditing

The initial point of failure was a compromised access key.

Action: Enforce strict key rotation policy (every 90 days). Disable and remove unused or old access keys. Use AWS Credential Report for auditing.

4. Establish Threat Detection and Alerting

Create automated alerts for high-risk behavioral patterns.

Action: Configure CloudWatch or SIEM alerts for:
• High count of AccessDenied errors from one user
• Successful AssumeRole following failed enumeration
• S3 access from unusual IP addresses

5. Utilize IP-Based Controls

Restrict API calls to known corporate IP ranges.

Action: Use IAM Condition Keys in policies to prevent access from unauthorized locations (e.g., aws:SourceIp).

Key Lessons Learned

Defense-in-Depth is Critical: This investigation highlights how a single compromised credential can lead to a significant data breach if multiple layers of security are not implemented. The absence of MFA, overly permissive IAM policies, and lack of behavioral monitoring created a perfect storm for this attack.

The ability to connect seemingly disparate events in CloudTrail logs was essential to reconstructing the full attack narrative. Key takeaways:

Monitor for Behavioral Anomalies: Failed API calls often precede more severe actions like privilege escalation.
Time Correlation is Critical: The 48-minute timeline shows how quickly an attacker can move from initial access to data exfiltration.
MFA is Non-Negotiable: The lack of MFA requirement for AdminRole was the single point of failure.
Least Privilege Works: If temp-user couldn't assume AdminRole, the attack would have stopped at reconnaissance.

Technical Skills Demonstrated

AWS CloudTrail

Log Analysis

IAM

Forensics

Incident

Response

Attack

Reconstruction

Threat

Hunting

Cloud

Security

📚 Educational Context

This investigation was conducted as part of ENPM665: Cloud Security at the University of Maryland. The attack scenario was created for educational purposes to develop practical skills in cloud forensics, incident response, and AWS security monitoring.