whoAMI: Discovering and exploiting a large-scale AMI name confusion attack

whoAMI: Discovering and exploiting a large-scale AMI name confusion attack

Speakers: Seth Art

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=2mxMW6dw-Fs

Overview

Seth Art, a security researcher at Datadog with 15 years of penetration testing experience, presents a comprehensive examination of the whoAMI attack, a name confusion vulnerability affecting Amazon Machine Images (AMIs) in AWS. The attack allows an adversary to publish a malicious AMI that matches a victim's search criteria, causing the victim's infrastructure-as-code to unknowingly deploy the attacker's image instead of the legitimate one. The result is remote code execution in the victim's AWS account. Art estimates that if launched today, this attack could compromise thousands of AWS accounts. The talk covers the vulnerability's history dating back to 2009, a live demonstration of the attack chain, real-world findings including a vulnerability in Cirrus CI's self-hosted runner infrastructure, and the new AWS Allowed AMIs feature that serves as the primary defense.

Background

▶ Watch: Introduction to name confusion attacks and AMI vulnerability (1:00)

AMIs are the base operating system images used to create EC2 instances in AWS. When deploying infrastructure using tools like Terraform, developers commonly use data sources that perform dynamic lookups to find AMIs matching specific name patterns, selecting the most recent match. The critical issue arises when these lookups do not filter by owner, meaning any publicly published AMI that matches the name pattern could be returned.

This is not a new problem. The first AMI name confusion attack was demonstrated in 2009 by Haroonir and Marco Slavierro, who exploited the fact that community AMIs in the AWS console were sorted by AMI ID in ascending order. By scripting the creation and deletion of AMIs to obtain low AMI IDs, they achieved top-five search results for Fedora Core 11 within two hours and saw real users deploying their images.

In 2018, HashiCorp's security team identified the same class of issue in Packer, and a user reported receiving a Monero miner instead of a legitimate Ubuntu AMI. A CVE was filed against the AWS CLI (though AWS treated it as a won't-fix), and both Terraform and Packer made the owner parameter required. However, in 2022, a well-intentioned pull request to the Terraform AWS provider successfully argued for making the owner optional again. The maintainers, likely lacking context on the four-year-old CVE, agreed. This reopened the vulnerability window that Art discovered in 2024.

Key Findings

▶ Watch: Sliver C2 callback and post-exploitation: S3 bucket exfiltration (7:30)

Art's research produced three significant findings:

1. Prevalence in production environments: When Datadog deployed a SIEM correlation rule looking for EC2 DescribeImages events followed by RunInstances events within 10 minutes by the same principal, they found that 2-4% of their customers in any given month were vulnerable to this pattern. Extrapolated globally, this represents a substantial number of AWS accounts currently at risk.

1. AWS internal systems were affected. Working through the AWS Vulnerability Disclosure Program, Art and his team published benign doppelganger AMIs and monitored for usage. They discovered 70,000 shared snapshot volume creation events from AWS backend services. AWS traced this to two internal non-production systems that were consuming the research AMIs, confirming that even AWS's own infrastructure was susceptible.

1. Cirrus CI self-hosted runners were vulnerable. Art found that Cirrus CI's documentation for self-hosted EC2 runners used a name filter without an owner constraint. He created a Cirrus CI account, configured a C2-enabled AMI matching their naming pattern, and successfully obtained a reverse shell on the runner instance. From there, he extracted decrypted secrets including AWS secret access keys and Docker passwords from the process environment variables. Cirrus CI resolved the issue within 12 hours of notification.

Technical Deep Dive

▶ Watch: Detection with CloudTrail SIEM correlation: DescribeImages followed by RunIns... (16:00)

The attack chain works as follows: the attacker identifies a target's AMI name filter pattern (e.g., amazon-linux-2023-*), creates a malicious AMI with a matching name, and optionally shares it only with specific target accounts to avoid detection. Because the victim's Terraform code uses most_recent = true without an owner filter, the next terraform apply will select the attacker's AMI since it has the most recent creation timestamp.

The malicious AMI contains a command and control (C2) callback that executes at startup. Art demonstrated using Sliver as the C2 framework. Once the EC2 instance boots with the attacker's image, it phones home, giving the attacker an interactive shell. From there, any IAM instance profile attached to the EC2 instance is immediately accessible, enabling the attacker to enumerate S3 buckets, list objects, and exfiltrate data.

Art demonstrated that the vulnerability extends beyond Terraform. Vulnerable patterns exist in Go, Python, shell scripts, and CloudFormation map population scripts. The attack can also be delayed through launch templates, launch configurations, and Auto Scaling groups, where the malicious AMI ID is stored and not executed until a scaling event triggers instance creation.

For detection, Art recommends two approaches. Static analysis using tools like Semgrep can identify vulnerable Terraform files and code in other languages. Runtime detection through CloudTrail correlation, looking for DescribeImages events followed by RunInstances events within a 10-minute window by the same principal, provides the definitive source of truth.

The Terraform AWS provider team was informed and, as of version 5.77, produces a warning when most_recent = true is used without an owner filter. Version 6.0 makes this a blocking error.

Demo / Proof of Concept

▶ Watch: 70,000 events: AWS internal systems found consuming research AMIs (18:00)

Art demonstrated the full attack chain in two controlled AWS accounts. The demo showed the victim performing a terraform apply that initially selected the correct AMI, then after the attacker staged a doppelganger AMI, the same terraform apply (with no code changes) selected the attacker's AMI instead. The Sliver C2 framework received a callback, and Art demonstrated post-exploitation including checking for instance profiles, listing S3 buckets, listing objects, and exfiltrating sensitive data.

A second demonstration targeted Cirrus CI, showing the full flow from committing code to trigger a CI job, through the CI runner deploying the attacker's AMI, to extracting decrypted secrets from the runner's process environment.

Defensive Implications

▶ Watch: AWS Allowed AMIs feature and Declarative Policies as primary defense (23:30)

The primary defense is AWS's Allowed AMIs feature, released in 2024. This creates an allow list of trusted AWS accounts at the organization level. When enabled in blocking mode, any AMI from an account not on the list is rejected, completely preventing the whoAMI attack. Art strongly recommends deploying this using Declarative Policies for EC2 at the AWS Organization level, which functions similarly to SCPs. It can be run in audit mode first before switching to enforcement.

Defense in depth measures include:

• Deploy SIEM correlation rules matching DescribeImages followed by RunInstances within 10 minutes by the same principal.
• Use Semgrep or equivalent static analysis to scan infrastructure-as-code repositories for missing owner filters.
• Apply the principle of least privilege to all EC2 instances, not just public-facing ones, since any workload could be compromised through this supply chain vector.
• Upgrade the Terraform AWS provider to version 6.0 or later, which blocks the vulnerable pattern.

Art also released the Cloud Image Investigator (investigator.cloud), a tool analogous to VirusTotal for cloud images. It allows users to look up AMI account IDs, view publication history, trace parent-child AMI lineage using AWS's new source_image_id and source_image_region fields, and compare file-level changes between AMIs using hash-based analysis.

Key Takeaways

• The whoAMI name confusion attack can give an attacker remote code execution in any AWS account that performs AMI lookups without filtering by owner, and it is exploitable today against thousands of accounts.
• The vulnerability has a 16-year history dating to 2009, was "fixed" in 2018 by making the owner required in Terraform, but was silently reintroduced in 2022 when the requirement was relaxed.
• Between 2-4% of Datadog's monitored AWS customers showed vulnerable AMI lookup patterns in any given month.
• AWS's Allowed AMIs feature, deployed via Declarative Policies for EC2 at the organization level, is the single most effective defense.
• The attack extends beyond Terraform to any language or tool that performs EC2 DescribeImages without owner filtering, including Go, Python, shell scripts, and CloudFormation.
• The Cloud Image Investigator (investigator.cloud) provides VirusTotal-like analysis capabilities for AMIs, including lineage tracing and file-level diffing.

About the Speaker(s)

Seth Art is a security researcher at Datadog focused on cloud security research and advocacy. Before joining Datadog, he spent 15 years as a penetration tester, with his last four years at Bishop Fox where he started their cloud penetration testing practice. He is the creator of Cloud Foxable, an open-source gamified learning environment for cloud penetration testing that he debuted at fwd:cloudsec two years prior. He also created the Cloud Image Investigator tool (investigator.cloud) as part of his AMI security research.