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):

Detect Creation of IAM Login Profiles

id: '28423.51736'
title: AWS CreateLoginProfile
description: Threat actors may change account permissions to maintain access to victim
  systems. CreateLoginProfile creates a password for the specified IAM user which
  allows them to to login through the AWS management console. This use case detects
  CreateLoginProfile events.
logic_format: Splunk
logic: '`get_cloud_data` `get_cloud_data_aws` TERM(CreateLoginProfile) | table _time,
  host, user, account, region, src_ip, http_user_agent, access_key, user, user_id,
  identity_type, role, event_name, event_category, cloud_service, request_parameters,
  response, mfa_enabled, permissions, identity, action, resource_id, object_id | bin
  span=1s | stats values(*) as * by _time, src_ip | lookup dnslookup clientip as src_ip
  OUTPUT clienthost as src_dns | iplocation prefix="src_" src_ip | rename src_Country
  as src_country '
techniques:
- persistence:account manipulation
technique_id: 
- T1098
data_category:
- AWS CloudTrail logs
references:
- https://www.invictus-ir.com/news/the-curious-case-of-dangerdev-protonmail-me
- https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html
- https://permiso.io/blog/s/unmasking-guivil-new-cloud-threat-actor/
- https://www.invictus-ir.com/news/automated-first-response-in-aws-using-sigma-and-athena?utm_source=substack&utm_medium=email

Detect High-Risk IAM Role or Policy Changes

id: '6389.13672'
title: AWS Attach IAM user Role OR Policy
description: 'This use case looks for when an IAM role or user policy has been attached
  or put to a user. '
logic_format: snowflake
logic: select * from awscloudtrail where event_time > dateadd(hour, -2, sysdate())
  and ( event_name = 'AttachRolePolicy' or event_name = 'AttachUserPolicy' or event_name
  = 'PutUserPolicy' or event_name = 'PutRolePolicy' )
techniques:
- persistence:valid accounts:cloud accounts
- privilege-escalation:valid accounts:cloud accounts
- defense-evasion:valid accounts:cloud accounts
technique_id:
- T1078.004
data_category:
- AWS CloudTrail logs
references:
- http://andresriancho.github.io/nimbostratus/pivoting-in-amazon-clouds.pdf

id: '6389.7138'
title: AWS Attach IAM user Role OR Policy
description: 'This use case looks for when an IAM role or user policy has been attached
  or put to a user. '
logic_format: Splunk
logic: '`get_cloud_data` `get_cloud_data_iam` eventName IN(AttachRolePolicy, AttachUserPolicy,
  PutUserPolicy, PutRolePolicy) | table _time, host, user, account, region, src_ip,
  http_user_agent, access_key, user, user_id, identity_type, role, event_name, event_category,
  cloud_service, request_parameters, response, mfa_enabled, permissions, identity,
  action, resource_id, object_id, dest_* | bin span=1s | stats values(*) as * by _time,
  user | lookup dnslookup clientip as src_ip OUTPUT clienthost as src_dns | iplocation
  prefix="src_" src_ip| rename src_Country as src_country '
techniques:
- persistence:valid accounts:cloud accounts
- privilege-escalation:valid accounts:cloud accounts
- defense-evasion:valid accounts:cloud accounts
technique_id:
- T1078.004
data_category:
- AWS CloudTrail logs
references:
- http://andresriancho.github.io/nimbostratus/pivoting-in-amazon-clouds.pdf

Monitor S3 Access Events + Exfiltration Patterns

‍

Full detection packs: Anvilogic Forge | Cloud Detections

‍Other References: AWS Strategies to Mitigate Exfiltration from S3 ‍‍

Watch Kennedy's Episode on Detection Engineering Dispatch: