Massive AWS Attack Compromises 230 Million Cloud Endpoints by Exploiting Exposed .env Files for Credential Theft

Executive Summary

A large-scale, automated attack campaign has resulted in the compromise of an estimated 230 million unique cloud endpoints hosted on Amazon Web Services (AWS). The attackers' primary initial access vector was the exploitation of a simple but widespread misconfiguration: publicly exposed environment (.env) files. These files, often containing plaintext credentials such as API keys and database passwords, were systematically harvested by the attackers. Once inside a victim's AWS account, the threat actors escalated privileges, deployed malicious AWS Lambda functions to expand their operation, and ultimately exfiltrated massive amounts of data to their own Amazon S3 buckets before leaving ransom notes. The incident is a stark reminder of the critical importance of basic security hygiene and the devastating consequences of leaking credentials in a cloud environment.

Threat Overview

The campaign was notable for its scale and automation. The threat actors operated by scanning millions of domains for accessible .env files. These configuration files are commonly used in web development to store environment-specific variables, and due to developer error, are frequently left on web servers where they can be accessed by the public.

The attackers were particularly interested in credentials for services like Mailgun, likely to use them for follow-on phishing campaigns, but the primary goal was the compromise of AWS accounts. The attack's success hinges on the high value of the credentials typically stored in .env files, which can provide a direct, authenticated entry point into an organization's most sensitive cloud infrastructure.

Technical Analysis

The attack followed a clear, multi-stage methodology:

1. Reconnaissance: Attackers used automated scanners to crawl the web, sending HTTP requests for /.env on over 110,000 domains (T1595.002).
2. Initial Access: When a scanner found a publicly exposed .env file, the contents, including AWS API keys (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY), were harvested (T1552.001).
3. Discovery: Using the stolen AWS credentials, attackers made API calls (e.g., ListBuckets, ListRoles, ListFunctions) to map out the victim's cloud environment and identify valuable data assets.
4. Privilege Escalation: The attackers created new IAM roles with full administrative privileges (AdministratorAccess) to ensure persistent and unrestricted access to the account, even if the original stolen key was revoked (T1078.004).
5. Persistence and Propagation: Malicious AWS Lambda functions were deployed. These serverless functions were programmed to continue scanning for more credentials from within the compromised AWS environment, effectively using the victim's own infrastructure to fuel the attack's expansion.
6. Exfiltration: The primary goal was data theft. Attackers used their escalated privileges to copy data from the victim's S3 buckets to S3 buckets under their own control (T1537).
7. Impact: After exfiltrating the data, the attackers deleted the data from the victim's buckets and uploaded ransom notes, completing the double-extortion cycle (T1485).

MITRE ATT&CK Mapping

Impact Assessment

The impact of this attack is devastating for the victims. It represents a complete compromise of their cloud environment, leading to a massive data breach, operational disruption from data deletion, and a direct financial demand via ransom. The recovery costs, including forensic investigation, data restoration (if possible), regulatory fines, customer notification, and reputational damage, will be immense. This incident serves as a powerful case study on how a simple misconfiguration—an exposed .env file—can cascade into a catastrophic security failure in the cloud.

IOCs — Directly from Articles

No specific IOCs were provided in the source articles.

Cyber Observables — Hunting Hints

AWS administrators should hunt for the following signs of compromise:

Detection & Response

Detection:

1. AWS GuardDuty: This is AWS's native threat detection service. It is designed to detect many of the activities described in this attack, such as anomalous API activity, unusual S3 access patterns, and reconnaissance from known malicious IPs.
2. CloudTrail Analysis: Ingest CloudTrail logs into a SIEM and create high-priority alerts for the creation of new admin roles, changes to IAM policies, and the creation of Lambda functions by unexpected users or roles.
3. S3 Access Logging: Enable server access logging for all critical S3 buckets. Monitor for GetObject or CopyObject requests from unauthorized or unexpected principals or IP addresses.
4. Cloud Service Monitoring: Continuously monitor for public S3 buckets and other exposed resources using AWS Trusted Advisor or third-party Cloud Security Posture Management (CSPM) tools.

Response:

1. Containment: If a compromise is detected, immediately revoke the stolen credentials and disable the malicious IAM roles created by the attacker.
2. Eradication: Delete the malicious Lambda functions and any other resources created by the attacker.
3. Forensic Analysis: Use CloudTrail logs to conduct a full investigation, determining the scope of the breach, what data was exfiltrated, and the full timeline of attacker activity.

Mitigation

Strategic Mitigation:

• Credential Management: The most critical mitigation is to never hardcode credentials in files like .env. Use a dedicated secrets management service like AWS Secrets Manager or HashiCorp Vault. These services provide secure storage and programmatic, audited access to secrets at runtime.
• Cloud Configuration Hardening: Use CSPM tools to continuously scan your cloud environment for misconfigurations like publicly accessible S3 buckets or exposed .env files on web servers.
• Principle of Least Privilege: Ensure that IAM roles and policies are narrowly scoped. An API key should only have the exact permissions needed for its function, not broad administrative access.

Tactical Mitigation:

1. Web Server Configuration: Configure your web server (e.g., Nginx, Apache) to block all external access to . (dot) files, especially .env.
2. Git Configuration: Use a .gitignore file to ensure that .env and other configuration files containing secrets are never committed to a source code repository.
3. IAM Best Practices: Enable MFA for all IAM users, especially privileged ones. Use temporary credentials via IAM roles wherever possible, instead of long-lived API keys.