How Public AMIs Are Leaking Credentials at Scale

TLDR: Researchers at DEF CON 2024 demonstrated that thousands of public Amazon Machine Images (AMIs) contain hardcoded secrets, including AWS credentials and private keys. By automating the process of spawning instances and mounting their EBS volumes to a dedicated searcher, they successfully extracted valid credentials from over 120 accounts. This research highlights a critical failure in cloud hygiene where developers inadvertently bake sensitive data into images that are then made globally accessible.

Cloud security often focuses on complex IAM policies or misconfigured S3 buckets, but sometimes the simplest path to compromise is just sitting in the public marketplace. The research presented at DEF CON 2024 by Eduard Agavriloae and Matei Josephs serves as a stark reminder that developers are still treating machine images like local development environments. When you build an AMI, you are capturing the entire state of that virtual machine. If you forget to scrub your .ssh directory, your .env files, or your .aws/credentials file before creating that image, you are essentially handing over the keys to your kingdom to anyone with an AWS account.

The Mechanics of the AMI Harvest

The researchers did not just look for a few needles in a haystack. They built a pipeline to systematically scan millions of public AMIs. The core of their technique relies on the fact that an AMI is essentially a snapshot of a virtual machine. If an image is marked as public, any AWS user can launch an instance from it.

The automated workflow they developed is straightforward but highly effective. First, they used the AWS CLI to list public AMIs, filtering out official vendor images and those owned by AWS to focus on third-party, potentially misconfigured assets. Once they identified a target, their script would:

1. Launch an EC2 instance using the target public AMI.
2. Stop the instance to allow for volume manipulation.
3. Detach the EBS volume from the newly created instance.
4. Attach that volume to a "secret-searcher" instance they controlled.
5. Mount the volume and run a search for sensitive files.

This approach bypasses the need to actually log into the target instance, which might have SSH keys or other authentication mechanisms that would block an attacker. By treating the EBS volume as a raw data source, they could bypass OS-level security controls entirely.

Searching for Secrets

Once the volume was mounted, the researchers used standard Unix utilities to find the goods. They specifically targeted directories and files known to contain high-value data. The command they used is a masterclass in efficiency:

find $mount_point \( ! -path "$mount_point/Windows/*" -a ! -path "$mount_point/Program Files/*" \) -size -25M \
\( -name ".aws" -o -name ".ssh" -o -name "credentials.xml" \
-o -name "Secrets.yml" -o -name "config.php" -o -name ".history" \
-o -name "autologin.conf" -o -name "web.config" -o -name ".env" \
-o -name ".git" \) -not -empty

This command ignores system directories like Windows or Program Files to save time and focuses on the high-probability targets. For secret detection, they integrated tools like TruffleHog and GitLeaks to identify actual keys within the files they found. They also used KeyHacks to validate the credentials they discovered, ensuring they weren't wasting time on expired or revoked tokens.

The results were staggering. They found over two million generic API keys, thousands of private keys, and, most importantly, over 120 valid AWS credentials. Some of these were root-level keys, granting them full control over the victim's AWS environment.

Why This Matters for Pentesters

If you are performing a cloud penetration test, this technique should be part of your reconnaissance phase. Checking for public AMIs owned by your target organization is a low-effort, high-reward activity. Even if the organization has a mature security program, a single developer who pushed an image to the public registry months ago can provide a persistent backdoor into the production environment.

The impact of this vulnerability falls squarely under OWASP A05:2021 – Security Misconfiguration. When an AMI is public, it is not just a configuration error; it is a data leak. The fact that the researchers were able to find root-level credentials demonstrates that this is not just a theoretical risk. It is a direct path to T1552: Unsecured Credentials and T1530: Data from Cloud Storage.

Defensive Hygiene

Defending against this is simple but requires discipline. First, audit your AWS environment to ensure that "Block Public Access" settings are enabled for both AMIs and EBS snapshots. This is a global setting that prevents accidental exposure. Second, implement a pre-build script in your CI/CD pipeline that scans images for sensitive files before they are ever registered as AMIs. If you are using tools like Packer, integrate a scanner that runs before the final image is exported.

Finally, rotate your keys. Even if you think your images are clean, the risk of a leaked key is never zero. If you find yourself in a situation where you must use a public AMI, treat it as untrusted. Never store long-lived credentials on a machine that might be snapshotted. Use IAM roles for EC2 instances instead of hardcoded keys, and ensure that your secrets management strategy does not rely on local files.

The cloud is a powerful tool, but it is also a massive, distributed attack surface. Every time you push a configuration or an image, you are making a security decision. Make sure you are not making that decision for an attacker.