The Risks of Exposed AWS Configuration Files: How to implement comprehensive protection with Oasis

The Risks of Exposed AWS Configuration Files: How to implement comprehensive protection with Oasis
Adam Ochayon

Adam Ochayon

Solution Architect

Published on

August 20, 2024

On August 15th, Palo Alto Networks’ Unit 42 uncovered a cloud extortion campaign that successfully compromised and extorted multiple organizations by exploiting configuration files hosted in AWS environments. These files, which typically contain environment variables, also store long-lived credentials for access keys. The leaked keys did not follow the principle of least privilege, making them highly vulnerable to exploitation.

The attackers didn’t need to hack their way in–everything they needed was left out in the open.

The Hidden Danger of Exposed Configuration Files

Configuration files such as .env files are commonly used to store environment variables, which can include anything from application settings, such as name or logging configurations, to API keys, database credentials, and other sensitive information. While this information is essential for keeping your applications running smoothly, improperly secured and exposed configuration files can become a significant attack vector, giving hackers access to your most critical systems.

A typical example of an .env file:

In a large-scale campaign uncovered by researchers at Unit 42, attackers targeted over 110,000 domains and extracted over 90,000 unique variables from exposed .env files. These variables included sensitive credentials. Once these credentials were in the attackers' hands, they could easily escalate privileges and move laterally within the compromised environments, leading to extensive data theft and extortion. 

How the Attack Unfolded

This attack unfolded as a multi-faceted operation:

1. Attackers found access key and secret pairs in .env files and used them to authenticate into various private AWS accounts.

2. Some of these credentials were not properly right-sized, which enabled privilege escalation (in many cases, by creating a new IAM role and attaching admin policies to it).

3. Once privileged access was achieved, it was exploited in various ways:

  1. Further bucket scanning via a newly created Lambda function, allowing the identification of additional credentials initially exposed.
  2. Exploitation of email services credentials (such as Mailgun) to send phishing messages
  3. Attempted provisioning of compute-optimized instances (possibly for cryptojacking)
  4. Listed buckets, pulled their content, and left a ransomware note.

How Oasis Addresses These Challenges

Such attack vectors, directly targeting exposed workload identities, stress the importance of a comprehensive security and management platform designed specifically to handle the complexities of Non-Human Identities (NHIs). 

Here’s how Oasis helps prevent and remediate attacks like the recent AWS environment file exploit:

  1. Discover Exposed Secrets: Oasis’s secret scanning capabilities can proactively search for sensitive information across various environments, including within environment configurations, mitigating the risk of initial access due to credential exposure.
  2. Contextualize Secrets with Identity Mapping: Simply discovering exposed secrets is often not enough; understanding their context is crucial in order to take appropriate action. This includes mapping the secret to specific services, applications, or users, giving security teams a clear understanding of usage and ownership for remediation.
  3. Monitor and Detect Privileged Identity Creation: Oasis's continuous monitoring can detect the creation of new privileged identities, helping security teams quickly identify and respond to unauthorized or unexpected privilege escalations. By alerting your team to new privileged identities as they are created, Oasis allows you to take immediate action to minimize potential risks.
  4. Respond rapidly with safe automated rotation: Once a secret is identified as exposed, it must be promptly rotated to mitigate the risk of unauthorized access.
    This task can often be disruptive, especially when lacking full context, as it might break operational applications. Many organizations need to make the tough choice between leaving NHIs unmanaged and potentially disrupting their business.

    Oasis facilitates the safe rotation of secrets by integrating with identity providers and key management services and ensuring secrets are securely generated and distributed across your environment. Using deep context, secret usage is tracked throughout the entire process to validate that consumers properly migrate to use the newly provisioned secret. This ensures you can confidently delete the old secret without causing any disruptions. For example, if an AWS access key is exposed, Oasis can automate the process of generating a new key, updating the environment variables, and revoking the old key—all without disrupting operations.

    System-wide rotation can also happen on a predetermined schedule driven by company policies. By automatically rotating across your organization and enforcing your company policies, Oasis limits attackers’ window of action and reduces the impact of exposure.
  1. Minimize Risk With Preventative Actions: Beyond remediation, Oasis offers actionable insights to help prevent future incidents. For instance, Oasis can detect AWS environment variables using the default KMS key and prompt security teams to switch to a customer-managed key. These preventative measures enhance control and audit capabilities and are crucial for reducing the attack surface and ensuring that NHIs are securely managed from the start. 

Ready to enhance your AWS security? Contact us today to learn more about our product and how we can help your organization. 

More like this