Pierluigi Paganini
August 18, 2024
Palo Alto Unit 42 researchers uncovered a large-scale extortion campaign that successfully compromised and extorted multiple victim organizations by leveraging exposed environment variable files (.env files).
The exposed files contained sensitive variables such as credentials belonging to various applications.
This extortion campaign involved several security failures, including exposing environment variables, using long-lived credentials, and the lack of a least privilege architecture. Threat actors scanned over 230 million targets for sensitive information, seeking misconfigured servers with exposed .env files that contained AWS credentials.. The campaign targeted 110,000 domains, uncovering over 90,000 unique variables in .env files, with 7,000 linked to cloud services and 1,500 traced back to social media accounts. The operation utilized multiple source networks to facilitate these attacks.
Unit 42 researchers states that attackers did not encrypt the data before ransom, but rather they exfiltrated the data and threatened to leak it in a ransom note dropped in the compromised cloud storage container.
“Moreover, the attackers behind this campaign likely leveraged extensive automation techniques to operate successfully and rapidly. This indicates that these threat actor groups are both skilled and knowledgeable in advanced cloud architectural processes and techniques.” reads the analysis published by Palo Alto Unit 42. “Note that the attackers’ success relied on misconfigurations in victim organizations that inadvertently exposed their .env files. It did not result from vulnerabilities or misconfigurations in cloud providers’ services.”
The attackers obtained exposed AWS Identity and Access Management (IAM) access keys that were discovered in publicly accessible .env files. They identified the keys by scanning unsecured web applications. Once obtained, the attackers used the keys to access the hosting cloud environment. The most common entry point for these threats is the inadvertent misconfiguration of servers, leading to the exposure of sensitive files like .env files to the public internet.
Once gained initial access to the cloud environment, the attackers found that the original IAM credential lacked administrator access to all cloud resources. However, they discovered that this IAM role had permissions to create new IAM roles and attach policies to existing roles. The attackers abused these capabilities to escalate their privileges by creating a new IAM role named “lambda-ex” using the CreateRole API request and then attaching the AWS-managed AdministratorAccess policy to it via the AttachRolePolicy API call. This allowed them to gain full administrative control within the victim’s cloud environment.
“The threat actor created a malicious lambda function by leveraging the stolen IAM user credentials.The Unit 42 reverse engineering team analyzed the malicious lambda function, which consisted of a bash script configured to perform internet-wide scanning using a preconfigured set of sources containing millions of domains and IP addresses. Figure 3 displays the complete code of the lambda function.” continues the report. “The script retrieved a list of potential targets from a publicly accessible third-party S3 bucket exploited by the threat actor. We believe the threat actor hosted these third-party S3 buckets within other compromised and legitimate cloud environments, and the threat actor leveraged these resources in this attack. The list of potential targets the malicious lambda function iterated over contained a record of victim domains. For each domain in the list, the code performed a cURL request, targeting any environment variable files exposed at that domain, (i.e., http://<target>/.env).”
The experts noticed that threat actors focused on instances where the exposed .env files contained Mailgun credentials, a circumanstace that suggests adversary aimed at leveraging them for sending phishing emails from legitimate domains and bypass security protections.
The identity of the attackers is still unclear, but researchers were able to identify two IP addresses e tmployed by the attackers: one in Ukraine associated with lambda function activities and another in Morocco used for data exfiltration to S3.
“AWS services and infrastructure are not affected by the findings of these researchers. The issues described in this blog were a result of a bad actor abusing misconfigured web applications—hosted both in the cloud and elsewhere—that allowed public access to environment variable (.env) files. Some of these files contained various kinds of credentials, including AWS credentials which were then used by the bad actor to call AWS APIs. Environment variable files should never be publicly exposed, and even if kept private, should never contain AWS credentials. AWS provides a variety of easy-to-use mechanisms for web applications to access temporary AWS credentials in a secure fashion. We recommend customers follow best practices for AWS Identity and Access Management (IAM) to help secure their AWS resources.” AWS spokesperson told Security Affairs.
The report includes Indicators of Compromise for this campaign along with technical details about the operation.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, environment variable files)
