230 Million AWS Cloud Environments Campaign 2024: How Exposed .env Files Fed a Cloud Extortion Operation

In August 2024, Palo Alto Networks Unit 42 described an extortion campaign that broke into organisations' Amazon Web Services (AWS) accounts using access keys left in publicly exposed .env files on misconfigured web applications. The attackers turned those keys into administrator-level access, deployed AWS Lambda functions inside victims' accounts and used them to scan the internet for more exposed .env files. Unit 42 says the operation scanned more than 230 million unique targets and copied .env files from at least 110,000 domains, yielding over 90,000 unique environment variables, including AWS access keys, OAuth tokens and API keys. The 230 million figure refers to targets scanned, not to AWS environments compromised. Where the attackers reached S3 storage, they exfiltrated and deleted data and left ransom notes in the emptied buckets. No AWS vulnerability was involved: this was a campaign built entirely on leaked, long-lived non-human credentials and over-privileged IAM identities.

At a glance

What happened

On 15 August 2024, Unit 42 published research titled "Leaked Environment Variables Allow Large-Scale Extortion Operation in Cloud Environments". It said the operation "set up its attack infrastructure within various organizations' Amazon Web Services (AWS) environments and used that groundwork to scan more than 230 million unique targets for sensitive information." Unit 42 did not publish activity dates, name victims or attribute the campaign to a known group.

Many web applications keep configuration in a .env file: database passwords, API keys, cloud credentials. If a web server is misconfigured, that file can be downloaded by anyone who requests it. Unit 42 says "The threat actors located these access keys by scanning and identifying exposed .env files hosted on unsecured web applications." Once they had AWS access keys, they used them to get into the cloud environment behind the application.

Inside an account, the attackers followed a scripted routine. They called GetCallerIdentity to confirm whose credentials they held, then ListUsers and ListBuckets to map IAM users and S3 storage. They also probed Amazon Simple Email Service (SES) with calls such as GetSendQuota and ListVerifiedEmailAddresses, although Unit 42 says they did not go beyond discovery with SES.

The compromised IAM user was not a full administrator, but Unit 42 says it "did have the permissions to both create new IAM roles and attach IAM policies to existing roles." That was enough. The attackers created a role named "lambda-ex" and attached the AWS-managed AdministratorAccess policy to it. They then tried to launch compute: creating a security group, a key pair and a c6g EC2 instance, an instance type Unit 42 notes is often used for cryptojacking. Those calls happened "in under a minute, indicating a pre-scripted, automated activity", and failed because of the limited permissions on the compromised IAM user.

Lambda worked where EC2 did not. The attackers created a Lambda function named "ex" and, according to Unit 42, "automatically deployed that same lambda function into every other enabled region in the account within a second." The function ran a bash script that pulled a list of target domains from a publicly accessible third-party S3 bucket, requested any exposed .env file at each domain with cURL, and stored the cleartext credentials it found in a folder in another attacker-controlled public S3 bucket. Unit 42 says the function "specifically targeted instances where the .env file referenced the string mailgun", and reporting by The Hacker News and Security Affairs linked this to an interest in using Mailgun credentials for phishing. Unit 42 was able to access the attackers' own exposed S3 bucket, which is how it could measure the scale of the harvest.

The final step was extortion. Using the S3 Browser tool over VPN endpoints, the attackers exfiltrated objects from victims' S3 buckets, deleted them and uploaded a ransom note to the now empty bucket. The note, reproduced by Unit 42, claimed the files had been copied to the attackers' server and demanded payment in bitcoin. Unit 42 stresses that the attackers did not encrypt data; they "exfiltrated the data and placed the ransom note in the compromised cloud storage container."

Both Unit 42 and AWS placed the root cause with the victims' configuration. Unit 42 wrote: "None of the listed vendors' applications or services had vulnerabilities or misconfigurations that resulted in this exposure." AWS told CSO Online that "AWS services and infrastructure were not affected" and that .env files "should never be publicly exposed, and even if kept private, should never contain AWS credentials."

Timeline

How it happened: the identity attack path

1. Secrets in a servable file. Victims' web applications exposed .env files containing long-lived AWS IAM access keys and other credentials. Any unauthenticated request to the right path returned them.
2. Keys reused from anywhere. Static access keys carry no binding to a device, network or workload. The attackers used them from Tor, VPN and VPS infrastructure, and AWS accepted them.
3. Discovery through the identity itself. GetCallerIdentity, ListUsers and ListBuckets told the attackers what the stolen identity was and what it could reach.
4. Privilege escalation through IAM. The stolen identity could create roles and attach policies, so the attackers created "lambda-ex" with AdministratorAccess. An identity with those two permissions can effectively grant itself anything.
5. Victim accounts turned into attack infrastructure. The "ex" Lambda function, deployed to every enabled region within a second, scanned for more .env files and fed harvested credentials into attacker-controlled S3 buckets, so each victim helped find the next.
6. Extortion through storage access. Using the stolen keys with S3 Browser, the attackers copied and deleted bucket contents and left ransom notes demanding bitcoin.

Impact

• Scale of scanning: Unit 42 says it "identified more than 230 million unique targets that the threat actor was scanning." These were scan targets, not compromised AWS environments.
• Harvested secrets: according to Unit 42, the campaign copied exposed .env files from at least 110,000 domains and collected over 90,000 unique variables. About 7,000 belonged to cloud services and 1,515 to social media platforms.
• Specific credentials: Unit 42 and CSO Online list 1,185 AWS access keys, 333 PayPal OAuth tokens, 235 GitHub tokens, 111 HubSpot API keys, 39 Slack webhooks and 27 DigitalOcean tokens. Unit 42 also noted that "Not all the leaks necessarily contained user accounts or secrets", but all leaked some internal detail.
• Victims: Unit 42 says multiple organisations were compromised and extorted. It did not publish how many.
• Data loss: in affected accounts, S3 objects were exfiltrated and deleted, leaving only the ransom note.

What this means for NHI governance

This campaign had no human victim to phish and no software flaw to exploit. Every step ran on non-human identities: application secrets stored in configuration files, IAM user access keys, a newly minted IAM role and the Lambda functions that assumed it. Unit 42 summed up the causes as "Exposing environment variables, using long-lived credentials, and absence of least privilege architecture." Each of those is a governance gap, not a technical accident.

The first gap is secret storage. A .env file is a convenient place for developers to keep keys, but it means production credentials live on disk inside the web root of an internet-facing server. One misconfigured rule and the file is public. With more than 110,000 domains affected, this was not a rare mistake. Our guide to the secret sprawl challenge covers why credentials end up in places like this.

The second gap is the credential type. An IAM user access key works until someone rotates or deletes it, and it works from anywhere. The same application could have run with a role that issues short-lived credentials, leaving nothing worth stealing in the file. The third gap is entitlement: an application identity that can create roles and attach policies is, in practice, an administrator.

The campaign also shows how attackers use one organisation's machine identities against others. Compromised AWS accounts became the scanning platform, and the harvested OAuth tokens, API keys and webhooks from one victim became the entry point for the next. Similar patterns appear in the EmeraldWhale operation, which harvested cloud credentials from exposed Git configuration files.

Recommendations

• Keep credentials out of the web root. Block access to .env and other configuration files at the web server, scan your public sites for exposed files, and load secrets from a secrets manager at runtime. See the Secrets Management Guide.
• Replace IAM user access keys with roles. Unit 42 recommends temporary credentials through IAM roles instead of long-term keys. The Cloud Workload Identity Guide explains how workloads can authenticate without static keys.
• Restrict role creation and policy attachment. Unit 42 specifically calls out iam:CreateRole and iam:AttachRolePolicy. Application identities should almost never hold them; use permission boundaries or service control policies to enforce this, as covered in the Cloud PAM and CIEM Guide.
• Disable regions you do not use. The attackers deployed Lambda functions to every enabled region within a second; unused regions are places where activity goes unnoticed.
• Log and alert on identity behaviour. Enable CloudTrail, VPC flow logs and S3 access logging with at least 90 days of retention, and use GuardDuty or equivalent detection to flag calls like GetCallerIdentity from Tor or VPN addresses, new admin roles and cross-region Lambda deployment.
• Rotate and inventory application secrets. Know which keys each application holds, who owns them and when they were last rotated, and rotate every credential in any file that may have been exposed. Challenges of Rotating NHIs explains why this is hard at scale.

Frequently asked questions

Were 230 million AWS cloud environments compromised in 2024?

No. Unit 42 reported that the attackers scanned more than 230 million unique targets for exposed .env files. The confirmed harvest was .env files from at least 110,000 domains and over 90,000 unique variables, and Unit 42 said multiple organisations were compromised and extorted, without giving a number.

How did attackers use exposed .env files to breach AWS accounts?

They found .env files that misconfigured web applications served publicly, took the AWS access keys inside, and used them to enter the victims' AWS accounts. There they created an administrator role, deployed Lambda functions to scan for more .env files, and exfiltrated and deleted S3 data before leaving ransom notes.

Was AWS itself vulnerable in the .env extortion campaign?

No. Unit 42 said no vendor's applications or services had vulnerabilities or misconfigurations that caused the exposure, and AWS said its services and infrastructure were not affected. The root cause was victims exposing .env files and using long-lived, over-privileged credentials.

Related NHI Mgmt Group resources

EmeraldWhale breach · AWS S3 buckets under attack · Hacked AWS accounts fuel crypto mining · Capital One breach 2019 · NHI breaches

How NHI Mgmt Group can help

This campaign ran entirely on leaked access keys, application secrets and an IAM identity with far more permission than it needed. Our NHI Foundation Level Training Course shows teams how to find these non-human identities, move them off static credentials and keep their privileges in check.

References

• Palo Alto Networks Unit 42: Leaked Environment Variables Allow Large-Scale Extortion Operation in Cloud Environments (15 August 2024, updated 3 September 2024)
• CSO Online: AWS environments compromised through exposed .env files (22 August 2024)
• The Hacker News: Attackers Exploit Public .env Files to Breach Cloud Accounts in Extortion Campaign (16 August 2024)
• Security Affairs: Large-scale extortion campaign targets publicly accessible environment variable files (.env) (18 August 2024)
• Security Boulevard: Extortion Group Exploits Cloud Misconfigurations, Targets 110,000 Domains (19 August 2024, updated 22 August 2024)