AWS Attack Made Simple: whoAMI 💀
You definitely need to learn about this...
⚠️ Educational Purposes Only ⚠️ I do not show anything even slightly malicious in this newsletter. My goal is to raise awareness and help the security community protect themselves against these types of cloud misconfigurations.
This is not sponsored, but a huge shoutout to the folks over at Datadog Security Labs for first disclosing this attack. I’m 100% taking inspiration from their walkthrough for this and have linked them at the end.
Start Here 👉
To understand this topic, we need to cover three key things: AMIs, AWS CLI and Terraform - Heads up, this post may not fit in your inbox.
AMIs
What is an AMI in the context of the cloud and specifically AWS?
What are all the parts under the hood that make up an AMI Image?
Broken down that’s:
- Root volume: Operating System and pre-installed software
- Launch permissions: Who can use it
- Block device mappings: Attached storage configuration
I find it helps to visualize it like this - It all goes in to make up a Cloud Instance.
We have three types of AMI’s
Ultimately, it’s really good practice to use AMI’s but why?
There are hundreds of AMIs, so to keep things simple, we reference them by their AMI ID.
For example, the Ubuntu AMI ID might be: ami-0861e7f40fe2da51
AWS CLI
You’ve heard of the AWS CLI, right? Simply put, it allows you to interact with AWS services directly from the terminal using commands.
Why use it?
For example the following command:
aws s3 ls
Lists all S3 buckets in your AWS account.
Last concept I promise, then we can get onto the fun stuff
Terraform
What is it? - It’s an Infrastructure as Code tool that lets you define and manage cloud resources using configuration files.
Why would we want to use an IAC tool?
I find it helps to think of it as a blueprint that allows you to describe what kind of infrastructure you want - such as servers, databases, and networks - using a straightforward, readable language. Once you've outlined what you need, IaC automates the process of building and updating your setup, ensuring everything is configured exactly as specified without the need to set up each component manually.
If you like the images above, check out TechOneTwenty, my eBook!
You are now equipped to understand this AWS attack!
By the way, in my opinion, that’s ultimately what cybersecurity actually is, having deep enough knowledge in a certain technical domain to understand how it can be taken advantage of.
The attack? 💀
Here you can see I’m using Terraform to launch a new EC2
Notice one thing with the filters:
- We are searching for architecture - that's fine.
- Virtualization type - that's also fine.
Now, look at the name, it returns the latest version, which is exactly what we want to ensure we get the most up to date, patched version of Ubuntu. I've even set most_recent = true to make sure of it.
If you’re still trying to transition into Cloud Security - I have a sneaky feeling being up to date with attacks like this is going to really help you stand out. For more breakdowns like this, I highly encourage you to subscribe - It’s free!
This gets crazy 🤯
An attacker first creates a malicious AMI containing a Command and Control (C2) binary - I want to actually show this here but honestly, I’m not sure on the Substack policy. I’m going to find out for future reads. Basically it’s a malicious executable used by attackers to establish a communication channel between a compromised system (such as an infected AWS instance) and the attacker's remote server.
The attacker then shares it publicly but uses the exact same name as a popular, legitimate image.
When the target searches for the AMI, Terraform selects the most recent match by default. Since AWS doesn’t verify ownership in this process (and neither have here!) a newer malicious AMI with the same name can take priority, leading to a compromised deployment.
It will return the most recent AWS AMI ID. However, if we check closely, we can see that the owner's ID is different, which can help identify the malicious AMI.
The ID is there, but let's be honest, who's really going to double check that? That's exactly why this attack works.
#official AWS account for Ubuntu AMIs
owners = ["099720109477"] Once the instance is booted up, it initiates a callback to the attacker's account, giving them control.
The attacker now receives the connection and gains Remote Code Execution on the compromised instance. (We’ll dive deeper into how this is typically done another time.)
What can they do now?
Worryingly simply right?
That’s the thing with most modern cloud attacks - they often stem from a simple misconfiguration, but the impact can be devastating! A small oversight, like trusting the wrong AMI, can lead to full system compromise, data exfiltration, and even complete cloud account takeover 🔥
Prevention
Use the allowed AMIs feature. This feature allows you to specify criteria that AMIs must meet to be visible and available within your account. Use trusted AMIs and scan for malware before launching instances. Restrict outbound connections using security groups and network ACLs.
Thank you for reading: Keep it secure, keep it light-hearted!
WJPearce - CyberBrew
Sources:
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html#enable-allowed-amis-audit-mode
https://www.bleepingcomputer.com/news/security/whoami-attacks-give-hackers-code-execution-on-amazon-ec2-instances/
https://securitylabs.datadoghq.com/articles/whoami-a-cloud-image-name-confusion-attack/
That’s well deep. I’ve been hacked a few times and it’s invariably because I mistake what I’m looking at for something familiar and especially when I’m off guard so easy to see how this one would work.