AWS whoAMI Attack: When One Misconfiguration Hands Over Your Cloud
Cloud security isn’t just about blocking attackers—it’s about not inviting them in by accident. The whoAMI attack is a perfect example of how a single misconfiguration in AWS can give an attacker full control over your EC2 instances.
This attack doesn’t rely on a zero-day exploit or AWS bug. Instead, it takes advantage of misconfigured API calls when retrieving Amazon Machine Images (AMIs). If you fetch an AMI using ec2:DescribeImages without specifying an owner, AWS may return any matching AMI, including one uploaded by an attacker. Many automation scripts pick the most recent AMI, so an attacker can publish a malicious version with a newer timestamp and trick your infrastructure into using it.
Once an instance boots from a backdoored AMI, the attacker has full access. They can steal IAM credentials, deploy persistent malware, and pivot into your internal network—all without tripping traditional security alarms.
How to Avoid This Attack
If your automation scripts aren’t filtering images properly, you might be at risk. The best way to prevent this attack is to strictly control which AMIs your infrastructure can use:
- Always use the
ownerfilter inDescribeImagesto restrict results to trusted AWS sources (amazon,aws-marketplace) or your own AWS account. - Whitelist approved AMIs. Many organizations maintain a DynamoDB table with allowed AMIs and terminate any instance that deviates from this list.
- Use AWS Organizations policies to enforce AMI restrictions at scale. AWS now offers declarative policies that let you limit AMI selection to specific accounts.
- Enable AWS GuardDuty to detect unusual instance activity, including unauthorized image launches.
- Leverage IAM policies to enforce the Allowed AMIs setting, preventing instances from launching unauthorized images.
Why This Attack Is a Wake-Up Call
This isn’t just a one-off vulnerability—it’s a reminder of how easy it is to misconfigure cloud security. Many infrastructure teams assume AWS will only return safe AMIs by default, but that isn’t the case.
The whoAMI attack proves that even experienced teams can introduce critical vulnerabilities with small oversights. One missing filter in your infrastructure-as-code pipeline can be the difference between a secure cloud and a total infrastructure compromise.
If you don’t trust every AMI in your environment, you’re doing cloud security right.
Best to use golden images as a starting point instead
