HACKING MY S3: We Simulated the Breach — Here's What We Learned

Unit 42 (May 2025) reports that cloud attacks have surged a whopping 66% year over year—still driven by the usual suspects: misconfigurations, stolen credentials, and exposed vulnerabilities. It’s not that attackers are getting smarter. They're just winning where we’re still slow.

So no, we didn’t just talk about S3 breaches—we simulated them.

Lab: hands-on walkthrough of real-world AWS attack chains, focusing on S3 exploit tactics.

From SSRF pivots to credential abuse, we walk through what attackers actually do — and put Anvilogic’s open-source AWS Detection Packs to the test.

• What gets caught.
  
• What flies under the radar.
  
• What smart defenders should be doing differently right now.
  

Buckets were breached. Detections were challenged. Hygiene checklists were made.

🛡 Detection Deep Dive: What We Simulated

SSRF to AWS Exfiltration Chain:

• Entry Point: Exploited SSRF in an EC2 app to hit the metadata service.
  
• Action: Stole temporary AWS credentials via IMDSv1 abuse.
  
• Impact: Accessed S3 buckets, CloudTrail logs, RDS snapshots with legit creds.
  ‍

‍Detections to Deploy (Now):

Snowflake (Crowdstrike):

id: '25231.46712'
title: AWS Instance Metadata Service Queried for Credentials - *nix
description: The AWS Instance Metadata Service (IMDS) provides detailed information
  about EC2 instances, including identity documents, network details, security credentials,
  and user data. It also offers dynamic data about the instance's AMI, reservation
  information, and configuration scripts passed on instance launch. Threat actors
  have been observed querying the AWS IMDS for security credentials or account IDs
  in attacks, such as the Capital One breach in 2019 or attack attempts by threat
  actor group Kinsing. This use case detects queries to 169.254.169.254/latest/meta-data/iam/security-credentials
  or http://169.254.169.254/latest/latest/dynamic/instance-identity/document with
  a status code in the 200s (indicates successful connection). Legitimate services
  within your infrastructure may access the IMDS; validating and allowlisting is recommended.
logic_format: snowflake
logic: 'select * from crowdstrikefdr_process where event_time > dateadd(hour, -2,
  sysdate()) and (event_platform ilike ''%Lin%'' or event_platform ilike ''%Mac%'')
  and process ilike ''%http://169.254.169.254%'' and (process ilike ''%latest/meta-data/iam/security-credentials/%''
  or process ilike ''%/latest/latest/dynamic/instance-identity/document%'') '
techniques:
- credential-access:unsecured credentials:cloud instance metadata api
technique_id:
- T1552.005
data_category:
- EDR Logs
references:
- https://blog.aquasec.com/loony-tunables-vulnerability-exploited-by-kinsing
- https://www.sans.org/blog/cloud-instance-metadata-services-imds-/
- https://sysdig.com/blog/cloud-breach-terraform-data-theft/
- https://www.sneakymonkey.net/cloud-credential-abuse/
- https://blog.appsecco.com/an-ssrf-privileged-aws-keys-and-the-capital-one-breach-4c3c2cded3af

Access the GitHub link

Splunk

id: '25231.46716'
title: AWS Instance Metadata Service Queried for Credentials - *nix
description: The AWS Instance Metadata Service (IMDS) provides detailed information
  about EC2 instances, including identity documents, network details, security credentials,
  and user data. It also offers dynamic data about the instance's AMI, reservation
  information, and configuration scripts passed on instance launch. Threat actors
  have been observed querying the AWS IMDS for security credentials or account IDs
  in attacks, such as the Capital One breach in 2019 or attack attempts by threat
  actor group Kinsing. This use case detects queries to 169.254.169.254/latest/meta-data/iam/security-credentials
  or http://169.254.169.254/latest/latest/dynamic/instance-identity/document with
  a status code in the 200s (indicates successful connection). Legitimate services
  within your infrastructure may access the IMDS; validating and allowlisting is recommended.
logic_format: Splunk
logic: '`get_endpoint_data` `get_endpoint_data_edr` "http://169.254.169.254" ("latest/meta-data/iam/security-credentials/"
  OR "/latest/latest/dynamic/instance-identity/document") | table _time, host, user
  process, process_* | bin span=1s | stats values(*) as * by _time, host '
techniques:
- credential-access:unsecured credentials:cloud instance metadata api
technique_id:
- T1552.005
data_category:
- EDR Logs
references:
- https://blog.aquasec.com/loony-tunables-vulnerability-exploited-by-kinsing
- https://www.sans.org/blog/cloud-instance-metadata-services-imds-/
- https://sysdig.com/blog/cloud-breach-terraform-data-theft/
- https://www.sneakymonkey.net/cloud-credential-abuse/
- https://blog.appsecco.com/an-ssrf-privileged-aws-keys-and-the-capital-one-breach-4c3c2cded3af

Access the GitHub link

‍

IAM Login Profile Abuse:

• Technique: Created login profiles to maintain persistent AWS access.
  
  
• Detections Referenced:
  
  
  • AWS Attach IAM Role or Policy Detection
    
    
  • AWS Create Login Profile Detection
    
    

Threat Scenario stitching AWS point detections:

‍

‍

Key Lessons Learned:

✅ S3 remains one of the fastest paths to impact.
If buckets are accessible — attackers move quickly to grab and exfiltrate sensitive data.

✅ Credential misuse is harder to spot than traditional malware.
Exfiltration via legit AWS APIs often bypasses traditional alerting unless you’re watching behavior patterns.

✅ Detection alone isn’t enough.
Proactive controls and hardening are mandatory to make S3 exfiltration harder, noisier, and easier to catch early.

Hardening S3: Direct Strategies to Mitigate Exfiltration (based on AWS best practices)

🔒 Block public access at the account and bucket level:
No exceptions unless absolutely necessary — enforce "least privilege" across all objects.

🔒 Use IAM Condition Keys for tight permissions:
Apply conditions like aws:SourceIp, aws:UserAgent, and aws:SecureTransport to control how/where API calls happen.

🔒 Enable CloudTrail data event logging for S3:
Track object-level API actions like GetObject, PutObject, and DeleteObject — not just management operations.

🔒 Use S3 Object Lock or MFA Delete:
Prevent immediate overwrite or delete attacks after compromise.

🔒 Monitor for unusual S3 access patterns:

• High-volume downloads
  
  
• Access from new geographies
  
  
• Unusual IAM role usage targeting S3
  

🔒 Routinely validate S3 bucket policies and ACLs:
Make it a regular hygiene practice — not a one-time setup.

‍

AWS Detections to Deploy (Now):

• Monitor S3 Access Events + Exfiltration Patterns
  
  
• Detect Creation of IAM Login Profiles
  
  
• Detect High-Risk IAM Role or Policy Changes
  
  

Full detection packs: Anvilogic Forge | Cloud Detections

‍Other References: AWS Strategies to Mitigate Exfiltration from S3

‍‍

Watch Kennedy's Episode on Detection Engineering Dispatch: