AWS Exploited by A New “whoAMI” Attack​

AWS Exploited by A New “whoAMI” Attack

In February 2025, cybersecurity researchers found out attack vector termed “whoAMI” which exploits misconfigurations in the retrieval of Amazon Machine Images (AMIs) within Amazon Web Services (AWS) environments. This attack leverages a name confusion vulnerability Enabling malicious actors to gain unauthorized code execution privileges within targeted AWS accounts. “If executed at scale this attack could be used to gain access to thousands of accounts. The vulnerable pattern can be found in many private and open-source code repositories, and we estimate that 1 percent of organizations using AWS are vulnerable to this attack.” Said Seth

Technical Description

The “whoAMI” attack capitalizes on the process by which AMIs are identified and utilized to launch Elastic Compute Cloud (EC2) instances. Developers and automated systems often employ the “ec2:DescribeImages” API call to search for AMIs based on specific naming conventions. A critical security lapse occurs when this API call omits the “–owners attribute” which is intended to filter AMIs by trusted sources. Without this filter, the search results may include AMIs from unverified or malicious sources.

Attackers can exploit this by publishing a malicious AMI with a name that closely resembles or matches the expected naming pattern. If this rogue AMI is more recent than legitimate ones and if the deployment process selects the “most recent” image without proper owner verification, the malicious AMI can be inadvertently deployed. This results in the execution of unauthorized code within the victim’s AWS environment.

This attack is a type of name confusion exploit, a subset of supply chain attacks, where an attacker creates a deceptive resource to trick misconfigured systems into selecting it over the intended one. It closely resembles dependency confusion attacks, where a malicious software package is used instead of a legitimate dependency. However, in the whoAMI attack, the malicious resource is a virtual machine image (AMI) rather than a software package, leading to unauthorized code execution in AWS environments.

Conclusion

The infostealer malware campaign by the Lazarus Group presents a significant threat, utilizing complex evasion techniques and misleading social engineering approaches to target software developers and IT experts. Its layered obfuscation and advanced data-extraction features make it a powerful cyber risk. Organizations need to remain vigilant and implement robust security measures to combat these threats. An effective defense plan should incorporate endpoint detection and response (EDR) tools, regular security evaluations and thorough employee training on cybersecurity best practices to minimize the chances of a breach.

Impact

The potential impact of the “whoAMI” attack is substantial. Datadog Security Labs reported that during their investigation they identified this vulnerable pattern in numerous private and open-source code repositories. Their research indicated that approximately 1% of organizations utilizing AWS were susceptible to this attack. Even internal non-production systems within AWS were found to be vulnerable underscoring the pervasiveness and severity of the issue.

IOC and Context Details

Table
Topics Details
Tactic Name Initial Access
Technique Name Exploit Public Facing Application
Sub Technique Name Cloud Image Name Confusion
Attack Type Cloud Image Supply Chain Attack
Targeted Applications AWS EC2, AWS AMI
Region Impacted Global
Industry Impacted All
IOC’s NA
CVE NA

Recommended Actions

Mitigation Strategies:
To defend against the “whoAMI” attack AWS, users are advised to implement the following measures:

  1. Specify Trusted AMI Owners
    Always include the –owners attribute in ec2:DescribeImages API calls to filter results by trusted AWS account IDs or recognized aliases (amazon for official AWS AMIs). This practice ensures that only AMIs from verified sources are considered.
  1. Implement Allowed AMIs Feature
    In December 2024, AWS introduced the “Allowed AMIs” feature enabling organizations to create an allow list of trusted AMI provider accounts. By configuring this feature, any attempt to launch instances with unapproved AMIs can be automatically blocked providing a robust defense against such attacks.
  1. Audit Existing Deployments
    Utilize tools like the open-source whoAMI-scanner developed by Datadog to scan existing EC2 instances and identify any that were launched from unverified or potentially malicious AMIs. Regular audits help in maintaining a secure and compliant cloud environment.
  1. Enhance Code Review Processes
    Conduct thorough reviews of Infrastructure-as-Code (IaC) scripts deployment pipelines and automation tools to ensure that AMI retrieval processes include proper owner filters. Incorporating security checks into the development lifecycle can preemptively identify and mitigate vulnerabilities.
  1. Update AWS To Version 0.11.0
    AWS has released version 0.11.0 of this tool which fixes the issue. They have also issued a GitHub Security Advisory for it but rejected the submission for a CVE assignment.

References