Key Takeaways

• A sophisticated cloud extortion campaign used misconfigured AWS .env files to target 110,000 domains, steal credentials and ransom cloud storage data.
• The threat actors obtained AWS Identity and Access Management (IAM) access keys by scanning for exposed .env files hosted on unsecured web applications. These environment variable files (.env files) define configuration variables within applications and platforms and often contain secrets.
• Cyble’s threat intelligence platform suggests that .env exposures [PS1] may be more common than even this largescale attack suggests.
• The IAM credentials uncovered by the attackers had permissions to create new IAM roles and attach IAM policies to existing roles, which they used to create new IAM resources with unlimited access.

Overview

An extortion campaign targeted more than 100,000 domains by using misconfigured AWS environment variable files (.env files) to ransom data stored in S3 containers.

The sophisticated campaign employed automation techniques and extensive knowledge of cloud architecture to increase the speed and success of the campaign, underscoring the need for cloud security best practices such as robust authentication and access controls, data encryption, secure configuration management, and monitoring and logging.

The attackers were able to leverage .env files that contained sensitive information such as credentials from numerous applications because of multiple security failures on the part of cloud users. These insecure practices include:

• Exposed environment variables
• Use of long-lived credentials
• Absence of a least privilege architecture

After achieving initial access, the attack campaign set up its infrastructure within organizations’ AWS environments and from there scanned more than 230 million unique targets for sensitive information.

The campaign targeted 110,000 domains, resulting in more than 90,000 unique variables in the .env files. Of those variables, 7,000 belonged to organizations’ cloud services and 1,500 variables were traced back to social media accounts.

Attackers used multiple networks and tools in their operation, such as virtual private server (VPS) endpoints, the onion router (Tor) network for reconnaissance and initial access operations, and VPNs for lateral movement and data exfiltration.

Attackers successfully ransomed data hosted within cloud storage containers. They did not encrypt the data before ransom, but instead exfiltrated it and placed a ransom note in the compromised container.

Technical Analysis

Environment files let users define configuration variables used within applications and platforms, and often contain secrets such as hard-coded cloud access keys, SaaS API keys and database login information, which the threat actors used for initial access.

By scanning for exposed .env files hosted on unsecured web applications, the threat actors were able to obtain exposed AWS Identity and Access Management (IAM) access keys.

How common are .env file exposures? Perhaps much greater than even this campaign would suggest – Cyble’s threat intelligence platform has detected 1,472,925 .env files since 1 Jan 2024 that have been exposed publicly.

The IAM credentials uncovered by the attackers in this case did not have administrator access to all cloud resources, but the attackers discovered that the IAM role used for initial access had permissions to create new IAM roles and attach IAM policies to existing roles. Using these capabilities, the attackers successfully escalated their privileges within victim cloud environments by creating new IAM resources with unlimited access.

In the discovery phase of this campaign, the attackers ran the GetCallerIdentity API call to verify the identity of the user or role assigned to the exposed IAM credential, including UserID, AWS account number and Amazon Resource Name (ARN).

The attackers also used the AWS API request ListUsers to obtain a list of IAM users in the AWS account, and the API request ListBuckets to identify all existing S3 buckets.

To elevate privileges, the attackers created an IAM role named lambda-ex with the API request CreateRole, then used the API call AttachRolePolicy to attach the AWS-managed policy AdministratorAccess to the newly created lambda-ex role.

In the execution phase, the attackers initially failed to create an EC2 infrastructure stack, but using the CreateFunction20150331 API call, they were able to create new AWS Lambda functions for their automated scanning operation. From there, they were able to launch a bash script to scan for targets.

Conclusion

The shared responsibility model of cloud security places responsibility for secure configuration squarely on the service’s users. This cloud extortion campaign reveals the dangers that arise when cloud service users fail to follow best practices such as robust authentication and access controls, data encryption, secure configuration management, and monitoring and logging.

Exposed .env files may contain API keys and secrets, database credentials, encryption keys, and sensitive environment configurations, so the following best practices are recommended:

• Don’t commit .env files to version control: Adding .env files to .gitignore or similar mechanisms in version control systems will help prevent inadvertent exposure.
• Use environment variables: Use environment variables directly in the deployment environment to avoid relying on .env files.
• Access control: Access to .env files should be limited to those who require it.
• Audits: Regularly audit repositories and environment configurations to make sure that .env files and their contents are not exposed.
• Secrets management tools: Secrets management tools can help you store and manage sensitive information securely instead of relying on plain text files like .env.

Indicators of Compromise

Here are indicators of compromise identified in the campaign:

URL

• https[:]//github[.]com/brentp/gargs/releases/download/v0.3.9/gargs_linux (not malicious; used by the lambda function)

IPv4

Tor Exit Nodes

• 109.70.100[.]71
• 144.172.118[.]62
• 176.123.8[.]245
• 185.100.85[.]25
• 185.100.87[.]41
• 185.220.101[.]190
• 185.220.101[.]19
• 185.220.101[.]21
• 185.220.101[.]29
• 185.220.101[.]30
• 185.220.101[.]86
• 185.220.103[.]113
• 192.42.116[.]181
• 192.42.116[.]187
• 192.42.116[.]18
• 192.42.116[.]192
• 192.42.116[.]199
• 192.42.116[.]201
• 192.42.116[.]208
• 192.42.116[.]218
• 198.251.88[.]142
• 199.249.230[.]161
• 45.83.104[.]137
• 62.171.137[.]169
• 80.67.167[.]81
• 89.234.157[.]254
• 94.142.241[.]194
• 95.214.234[.]103

VPS Endpoints

• 125.20.131[.]190
• 196.112.184[.]14
• 46.150.66[.]226
• 49.37.170[.]97

VPN Endpoints

• 139.99.68[.]203
• 141.95.89[.]92
• 146.70.184[.]10
• 178.132.108[.]124
• 193.42.98[.]65
• 193.42.99[.]169
• 193.42.99[.]50
• 193.42.99[.]58
• 195.158.248[.]220
• 195.158.248[.]60
• 45.137.126[.]12
• 45.137.126[.]16
• 45.137.126[.]18
• 45.137.126[.]41
• 45.94.208[.]42
• 45.94.208[.]63
• 45.94.208[.]76
• 45.94.208[.]85
• 72.55.136[.]154
• 95.214.216[.]158
• 95.214.217[.]173
• 95.214.217[.]224
• 95.214.217[.]242
• 95.214.217[.]33

Hash

SHA256 for Lambda.sh – 64e6ce23db74aed7c923268e953688fa5cc909cc9d1e84dd46063b62bd649bf6

Related