A data extortion campaign that compromises AWS resources through credentials collected from environment (.env) files stored insecurely on web servers has been uncovered by Unit 42 researchers. The exposed files contained AWS access keys, credentials for databases and social media accounts, API keys for SaaS applications and email services, as well as access tokens for a variety of cloud services.
The operation was uncovered while researchers investigated a compromised AWS environment that was being abused to launch automated scans against other domains as part of this campaign. The researchers determined that the attackers collected .env files from around 110,000 domains, leading to the exposure of over 90,000 unique environment variables with 7,000 corresponding to cloud services used by organizations.
“Not all the leaks necessarily contained user accounts or secrets, but all of them leaked some details about a victim’s internal infrastructure or its configuration,” the researchers said in the report.
Examples of the 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
Multiple web development frameworks and web applications store important configuration data inside .env files. This could include credentials and API keys to third-party services and resources that the application needs to function.Web servers should be configured to prevent access to . (dot) files by default because these are supposed to be hidden files that are never intended for public access. However, misconfigurations happen all the time. Another example is the .git folder which stores important configuration information for the git source code version control system.
The accidental exposure of .env or .git files is a known issue that other researchers have warned about in the past, so it’s not unusual for attackers to run web crawlers looking for such exposed files in the root folder of domains. However, the scale of the operation uncovered by Palo Alto Networks’ Unit 42 suggests that such misconfigurations remain widespread.
Lateral movement inside AWS environments
In the hands of knowledgeable hackers, leaked secrets can be very powerful and dangerous. For example, the attackers behind this operation exhibited advanced knowledge of AWS APIs.After obtaining an AWS access key the attackers used it to run a GetCallerIdentity API call to verify the identity or role assigned to the exposed credential. They also performed other reconnaissance actions by calling ListUsers to gather a list of IAM users in the AWS account and ListBuckets to identify all the existing S3 buckets.
In the compromised AWS environment investigated, the attackers realized the exposed AWS IAM role they obtained did not have administrative privileges over all resources. However, it had the permission to create new IAM roles and attach IAM policies to existing ones. They then proceed to create a new role called lambda-ex and attach the AdministratorAccess policy to it, achieving privilege escalation.
“Following the successful creation of the privileged IAM role, the threat actor attempted to create two different infrastructure stacks, one using Amazon Elastic Cloud Compute (EC2) resources and the other with AWS Lambda,” the researchers said. “By performing these execution tactics, the actors failed to create a security group, key pair and EC2 instance, but they successfully created multiple lambda functions with the newly created IAM role attached.”
AWS Lambda is a serverless computing platform designed to execute user-supplied application code on demand. It has been abused by attackers before for crypto mining with miners written in Go, but in this case the hackers used it to deploy a bash script that would scan other domains for exposed .env files, extract credentials from them and upload them to a public S3 bucket they previously compromised.
That particular script was looking for credentials for the Mailgun email sending platform, but by accessing the attackers’ publicly exposed S3 storage bucket the researchers were able to understand the full scope of the campaign. “We identified more than 230 million unique targets that the threat actor was scanning for misconfigured and exposed environment files. At the time of access to this public S3 bucket, we estimate that multiple compromised AWS accounts were the target of this malicious scanning as part of a compromise-scan-compromise automated operation.”
Data exfiltration and extortion
Whenever they managed to gain credentials to S3 buckets, a popular data storage option for many web applications, the attackers used a Windows tool called S3 Browser to interact with the S3 API and exfiltrate all the data from them.
After all files were downloaded, the attackers deleted them and left a ransom file behind informing the owner that they now have access to their sensitive information and plan to sell it if they are not paid.
The threat actor accessed AWS accounts and S3 buckets from the Tor anonymity network, public VPNs or from inside the AWS infrastructure itself using other compromised accounts. However, the researchers detected two instances where the attackers connected directly from IP addresses allocated to ISPs in Ukraine and Morocco.
Researchers suggests remediation
Palo Alto Networks researchers advise organizations to have S3 logging or CloudTrail logging on for S3 bucket events to be able to perform forensic investigations if an incident occurs. These settings are not turned on and might increase the cost for the cloud environment because they use resources, but they are worth it to be able to accurately assess what happened in case of a compromise.
“Depending on the AWS services used, organizations will want to ensure they enable the specific logging unique to that service,” the researchers said. “After organizations establish the proper logging and retention of that data (90 days minimum retention recommended), then the focus shifts to monitoring those data sources.”
AWS’s GuardDuty service provides some alerting features for credential and EC2 resources abuse. Organizations can create their own alerts for abnormal activity inside log data.
The researchers strongly advise against using long-term IAM access keys in applications and instead rely on IAM roles which only provide temporary access. The principle of least privilege should be followed when configuring access to IAM resources so that attackers can easily perform privilege escalation or lateral movement. Access to unused AWS regions should also be disabled so attackers can’t deploy resources in additional regions.