Researchers have uncovered an extortion campaign that targeted more than 100,000 domains by using misconfigured AWS environment variable files (.env files) to ransom data in cloud storage containers.
The sophisticated cloud extortion campaign used 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.
Multiple Security Failures Fueled AWS Cloud Extortion Campaign
The researchers, from Palo Alto Networks’ Unit 42, said 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 include:
- Exposed environment variables
- Use of long-lived credentials
- Absence of a least privilege architecture
The attack campaign set up its infrastructure within organizations’ AWS environments and “used that groundwork to scan more than 230 million unique targets for sensitive information,” the researchers wrote.
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, the researchers said. They didn’t encrypt the data before ransom, but instead exfiltrated it and placed a ransom note in the compromised container (example below).
“The attackers behind this campaign likely leveraged extensive automation techniques to operate successfully and rapidly,” the researchers said. “This indicates that these threat actor groups are both skilled and knowledgeable in advanced cloud architectural processes and techniques.”
They emphasized that the attack “relied on misconfigurations in victim organizations that inadvertently exposed their .env files. It did not result from vulnerabilities or misconfigurations in cloud providers’ services.”
It’s not clear where the threat actors were located or if they were affiliated with any known threat groups, but the researchers found one ISP IP address geolocated in Ukraine that was part of early-stage privilege escalation activity, and a second ISP IP address that was geolocated in Morocco and was associated with S3 access and exfiltration.
“Based on the user-agents and time between API calls, we determined the threat actor manually performed these access operations, which leaked the threat actor’s possible physical location,” they wrote.
Initial Access Came From Leaked AWS IAM Credentials
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.
“The attack pattern of scanning the internet for domains and exploiting credentials obtained from exposed environment variable files follows a larger pattern we believe propagates through other compromised AWS environments,” the researchers said.
The threat actors were able to obtain exposed AWS Identity and Access Management (IAM) access keys by scanning and identifying exposed .env files hosted on unsecured web applications.
“We continue to see a growing trend of attackers targeting cloud IAM credentials leading to initial access of organizations’ cloud environments,” they wrote. “The most common initial access vectors for this particular threat originate from organizations inadvertently misconfiguring servers, subsequently exposing sensitive files to the public internet, with the most frequently exposed files being .env files.”
While the IAM credentials did not have administrator access to all cloud resources, the attackers discovered that the IAM role used for initial access “did have the permissions to both create new IAM roles and attach IAM policies to existing roles. Using these capabilities, the attacker successfully escalated their privileges within victim cloud environments by creating new IAM resources with unlimited access.”
From there, the attackers were able to create new AWS Lambda functions for their automated scanning operation.