Exposed .env Files Fuel an AWS Extortion Campaign (Aug 2024)
Retrospective: this article looks back at events from August 2024, written in 2026 with the benefit of hindsight.
In August 2024, researchers at Palo Alto Networks' Unit 42 described an extortion campaign that started with publicly exposed environment (.env) files on web applications.
How it worked
Many applications store configuration — including cloud access keys, database credentials and API tokens — in .env files. Misconfigured web servers sometimes served these files publicly. The attackers scanned large numbers of domains for exposed .env files, collected credentials, and used AWS access keys to:
- Run reconnaissance (
GetCallerIdentity, listing users and buckets). - Escalate privileges by creating new IAM roles with administrative permissions.
- Deploy Lambda functions to automate further internet-wide scanning for more
.envfiles. - Exfiltrate data from S3 buckets and then delete it, leaving ransom notes demanding payment.
Unit 42 reported finding exposed environment variables across tens of thousands of domains, including thousands of cloud credentials.
Why it mattered
- No vulnerability was exploited — just exposed secrets.
- Long-lived IAM user keys made it possible.
- Overly permissive permissions let attackers create admin roles.
- Cloud-native extortion didn't need ransomware — just data theft and deletion.
Lessons in hindsight
- Never deploy
.envfiles to web roots; block access to dotfiles in web server configuration. - Use roles and secrets managers instead of keys in configuration.
- Least privilege: application keys shouldn't be able to create IAM roles.
- Enable versioning and Object Lock on critical S3 data.
- Detect reconnaissance and privilege escalation in CloudTrail.
- How to Keep Secrets Out of Web Roots and Into AWS Secrets Manager How-To & Hardening
- Detecting Exposed Environment Variables: CloudTrail, GuardDuty and Athena Queries Detection & Response
- CIO Brief: Leaked Configuration Files Are Leaked Keys CIO Briefings