AWS environments compromised through exposed .env files News

Attackers have been found collecting Amazon Web Services (AWS) keys and access tokens from environment variables that were insecurely stored in tens of thousands of web applications. This data extortion campaign, uncovered by Unit 42 researchers, involved compromising AWS resources using credentials gathered from exposed environment (.env) files on web servers. These files contained sensitive information such as AWS access keys, database and social media credentials, API keys for SaaS applications and email services, and access tokens for various cloud services.
The operation came to light during an investigation into a compromised AWS environment that was being misused to conduct automated scans against other domains. Researchers discovered that attackers had collected .env files from approximately 110,000 domains, exposing over 90,000 unique environment variables, with 7,000 linked to cloud services used by organizations. Although not all leaks contained user accounts or secrets, they did reveal details about victims’ internal infrastructure or configurations.
Examples of leaked credentials included 1,185 unique AWS access keys, 333 PayPal OAuth tokens, 235 GitHub tokens, 111 HubSpot API keys, 39 Slack webhooks, and 27 DigitalOcean tokens.
Environment Variables Exposed Due to Misconfiguration
Many web development frameworks and applications store critical configuration data in .env files, which can include credentials and API keys necessary for application functionality. Ideally, web servers should be configured to prevent access to these hidden files, but misconfigurations are common. Similar issues have been noted with the exposure of .git folders, which store configuration information for the Git version control system. Attackers often use web crawlers to find such exposed files, and the scale of this operation suggests that these misconfigurations are widespread.
Lateral Movement Inside AWS Environments
Leaked credentials can be extremely dangerous in the hands of skilled hackers. The attackers in this campaign demonstrated advanced knowledge of AWS APIs. After acquiring an AWS access key, they used it to perform a GetCallerIdentity API call to verify the identity or role associated with the credential. They also conducted reconnaissance by calling ListUsers to gather IAM user lists and ListBuckets to identify existing S3 buckets.
In the compromised AWS environment, attackers found that the exposed IAM role lacked administrative privileges but could create new IAM roles and attach policies. They created a new role with administrative access, achieving privilege escalation. They attempted to create infrastructure stacks using Amazon EC2 and AWS Lambda, successfully deploying multiple Lambda functions with the new IAM role.
AWS Lambda, a serverless computing platform, was used by attackers to deploy a bash script that scanned domains for exposed .env files, extracted credentials, and uploaded them to a compromised public S3 bucket. This script targeted credentials for the Mailgun email platform. Researchers, by accessing the attackers’ public S3 bucket, identified over 230 million unique targets being scanned for misconfigured environment files.
Data Exfiltration and Extortion
Upon obtaining S3 bucket credentials, attackers used a tool called S3 Browser to interact with the S3 API and exfiltrate data. After downloading the files, they deleted them and left a ransom note threatening to sell the data unless paid. The attackers accessed AWS accounts and S3 buckets through the Tor network, public VPNs, or from within AWS infrastructure using other compromised accounts. However, two direct connections were traced to IP addresses in Ukraine and Morocco.
Researchers Suggest Remediation
Palo Alto Networks researchers recommend enabling S3 logging or CloudTrail logging for S3 bucket events to facilitate forensic investigations in case of incidents. Although these settings may increase cloud environment costs, they are crucial for assessing compromises. Organizations should enable specific logging for AWS services in use and retain data for at least 90 days. AWS GuardDuty can provide alerts for credential and EC2 resource abuse, and custom alerts for abnormal log activity can be created.
Researchers advise against using long-term IAM access keys in applications, suggesting the use of IAM roles for temporary access instead. The principle of least privilege should guide IAM resource configuration to prevent privilege escalation and lateral movement. Additionally, access to unused AWS regions should be disabled to prevent attackers from deploying resources in other regions.

Reported by
Lucian Constantin
CSO senior Writer