Hide yo environment files! Or risk getting your cloud-stored data stolen and held for ransom

Cybercriminals are breaking into organizations’ cloud storage containers, exfiltrating their sensitive data and, in several cases, have been paid off by the victim organizations to not leak or sell the stolen data.

“The attackers behind this campaign likely leveraged extensive automation techniques to operate successfully and rapidly,” according to Palo Alto Networks researchers.

Exposed environment files hold keys to hosting cloud environments

The attackers gained access to the cloud storage containers by scanning for and leveraging exposed environment files (.env) within the victim organization’s web applications. (Publicly accessible .env files are the result of server misconfiguration.)

“These files often contain secrets such as hard-coded cloud provider [Identity and Access Management (IAM)] keys, software-as-a-service (SaaS) API keys and database login information then used by the threat actor for initial access,” the researchers noted.

“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.”

Once in, the attackers explored the victim organization’s cloud environment to:

• Verify the the identity of the user or role assigned to the IAM credential they use
• Create a list of other IAM users on the AWS account and a list of existing S3 buckets
• Locate services in use, e.g., Simple Storage Service, Security Token Service, Simple Email Service.

Then they used the original IAM role to create new roles that will have administrative permissions within the compromised AWS account (i.e., unlimited access).

This allowed them to (try to) create Amazon Elastic Cloud Compute (EC2) resources for cryptomining, and to create AWS Lambda functions to perform automated internet-wide scanning for environment variable files exposed at various domains.

“Upon successfully retrieving the domain’s exposed environment file, the lambda function uncovered and identified cleartext credentials contained within the file. Once the lambda function identified the credentials, it stored them in a newly created folder within another threat-actor-controlled public S3 bucket,” the researchers shared.

“The malicious lambda function specifically targeted instances where the .env file referenced the string mailgun. With these compromised Mailgun credentials, threat actors can send large-scale phishing attacks against organizations from legitimate domains, making their attacks more likely to bypass security protections.”

The ransom note (Source: Palo Alto Networks, Unit 42)

Finally, they exfiltrated data and objects from the victims’ S3 buckets by using the S3 Browser tool, and uploaded a ransom note. Occasionally, they would also send the same ransom note to the victim company’s stakeholders.

Could your organization end up a victim?

Interestingly enough, the S3 bucket the attackers used to store and view the stolen .env files was also publicly exposed, so the researchers managed to glimpse what type of credentials the files contained.

“We identified over 90,000 unique combinations of leaked environment variables that contained access keys or IAM credentials, with 7,000 access keys directly associated with various cloud services [AWS, PayPal, GitHub, Slack, etc.]. Most concerningly, 1,515 of the leaked variables were associated with social media platforms; some of them included account names and authentication secret keys,” they shared.

Exposed environmental variables were just one of the things allowing attackers to be so successful. Another is the fact that the permissions associated with IAM resources were too broad.

The researchers have outlined several actions organizations can take to prevent their data from being ransomed in this way:

• Configure servers properly to prevent the exposure of environmental and other files
• Use IAM roles instead of IAM keys, as the former are temporary
• Use principle of least privilege when provisioning permissions
• Disable all unused regions within an AWS account (so the attackers have less “space” to hide)
• Enable logging and monitoring to get alerts for abnormal activities