whoAMI attacks give hackers code execution on Amazon EC2 instances

Security researchers discovered a name confusion attack that allows access to an Amazon Web Services account to anyone that 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 it’s possible for attackers to 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 fail to update the code.

Carrying out the whoAMI attack

AMIs are virtual machines preconfigured 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 AMIs, each with a specific identifier. In the case of public ones, users can search in the AWS catalog for the right 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 misconfigured AMI selection in AWS environments:

1. The retrieval of AMIs by software using the ec2:DescribeImages API without specifying an owner
2. The use of wildcards by scripts instead of specific AMI IDs
3. The practice of some infrastructure-as-code tools like Terraform using “most_recent=true,” automatically picking the latest AMI that matches the filter.

These conditions allow the attackers to insert malicious AMIs in the selection process by naming the resource similarly to a trusted one. Without specifying an 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 marketplace, which may include a malicious one that has a name similar to a legitimate entry.

Basically, all an attacker needs 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 breaching 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 mimics 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 affects thousands of distinct AWS accounts.”

Amazon’s response and defense measures

DataDog researchers notified 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 allow 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 advises customers to 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 started serving warnings to users when “most_recent = true” is used without an owner filter, with stricter enforcement planned for future releases (6.0).

System admins 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 through ‘Allowed AMIs,’ and switch to ‘Enforcement Mode’ to block them.

DataDog has also released a scanner to check AWS account for instances created from untrusted AMIs, available in this GitHub repository.