BySecurity researchers discovered a name confusion attack that permits access to an Amazon Web Services account to anyone who publishes an Amazon Machine Image (AMI) with a specific name.
Dubbed “whoAMI,” the attack was crafted by DataDog researchers in August 2024, who demonstrated that attackers can gain code execution within AWS accounts by exploiting how software projects retrieve AMI IDs.
Amazon confirmed the vulnerability and pushed a fix in September but the problem persists on the customer side in environments where organizations failed to update the code.
Carrying out the WHOAMI attack
AMIs are virtual machines preinstalled with the necessary software (operating system, applications) used for creating virtual servers, which are called EC2 (Elastic Compute Cloud) instances in the AWS ecosystem.
There are public and private IMAs, each with a specific identifier. In the case of public ones, users can search in the AWS catalog for the correct ID of the AMI they need.
To make sure that the AMI is from a trusted source in the AWS marketplace, the search needs to include the ‘owners’ attribute, otherwise, the risk of a whoAMI name confusion attack increases.
The whoAMI attack is possible due to misdefined AMI selection in AWS environments:
The extraction of AMIs by software using the ec2:DescribeImages API without specifying an owner
The use of wildcards by scripts rather than specific AMI IDs
The practice of some infrastructure-as-code tools like Terraform using “most_recent=true,” automatically chooses the latest AMI that matches the filter.
These conditions allow the attackers to insert malicious AMIs in the selection process by naming the resource closely to a trusted one. Without specifying an owner, AWS returns all matching AMIs, including the attacker’s.
If the parameter “most_recent” is set to “true,” the victim’s system provides the latest AMIs added to the market, which may include a malicious one that has a name similar to a legitimate entry.
Basically, all an attacker wants to do is publish an AMI with a name that fits the pattern used by trusted owners, making it easy for users to select it and launch an EC2 instance.
The whoAMI attack does not require violating the target’s AWS account. The attacker only needs an AWS account to publish their backdoored AMI to the public Community AMI catalog and strategically choose a name that imitates the AMIs of their targets.
Datadog says that based on their telemetry, about 1% of the organizations the company monitors are vulnerable to whoAMI attacks but “this vulnerability likely impacts thousands of distinct AWS accounts.”
Amazon’s response and protection measures
DataDog researchers informed Amazon about the flaw and the company confirmed that internal non-production systems were vulnerable to the whoAMI attack.
The issue was fixed last year on September 19, and on December 1st AWS introduced a new security control named ‘Allowed AMIs’ allowing customers to create an permitted list of trusted AMI providers.
AWS stated that the vulnerability was not exploited outside of the security researchers’ tests, so no customer data was compromised via WHOAMI attacks.
Amazon recommends customers always specify AMI owners when using the “ec2:DescribeImages” API and enable the ‘Allowed AMIs’ feature for additional protection.
The new feature is available via AWS console → EC2 → Account Attributes → Allowed AMIs.
Starting last November, Terraform 5.77 began serving warnings to users when “most_recent = true” is used without an owner filter, with stricter enforcement planned for future releases (6.0).
System administrators must audit their configuration and update their code on AMI sources (Terraform, AWS CLI, Python Boto3, and Go AWS SDK) for safe AMI retrieval.
To check if untrusted AMIs are currently in use, enable AWS Audit Mode via ‘Allowed AMIs,’ and switch to ‘Enforcement Mode’ to block them.
DataDOG has also released a scanner to check AWS accounts for instances created from untrusted AMIs, available in this GitHub repository.
