Mallory Mooney
Amazon Machine Images (AMIs) are templates for launching and scaling Amazon Elastic Compute Cloud (EC2) instances. Because Amazon EC2 AMIs are reused across environments and automation pipelines, decisions about how you build, source, manage, and share them directly affect your cloud attack surface.
You can source AMIs for your EC2 instances in three ways: create and privately share base images (golden images) within your accounts, use public images from a trusted publisher, or use community images from another AWS account. Each option reflects a different trust boundary and introduces distinct risks. For example, Datadog’s security researchers recently noted a scenario where retrieving the newest and potentially unvetted AMIs from a public repository can increase an environment’s exposure to certain types of supply chain attacks.
This post looks at how image sourcing and life cycle management can impact your cloud attack surface, along with best practices to mitigate that risk in the following areas:
- Reduce insecure configurations, vulnerabilities, and version drift in private AMIs
- Prevent sensitive data leakage when sharing Amazon EC2 AMIs
- Detect and block untrusted or malicious public AMIs
Reduce insecure configurations, vulnerabilities, and version drift in private AMIs
Many teams maintain golden images so that they can standardize the process for configuring and provisioning instances. However, the trade-off is that decisions around how you manage an image’s patch levels, installed packages, security guardrails, and other configurations need to be replicated with every launched instance. In addition, golden images are often built on top of public or community AMIs, which means any associated risks become embedded in the internal image. For example, if one of these AMIs includes a remotely exploitable weakness, such as a network-accessible service running with weak or default credentials, every instance launched from it inherits the same initial access path.
You can mitigate this risk in how you build and update images. For images you build from scratch, the Center for Internet Security (CIS) benchmarks can help you standardize secure defaults. If you create images from other AMIs, treat the base image and any dependencies as part of your supply chain. This means retrieving images from trusted sources and scanning them routinely to catch vulnerable packages before distribution.
For handling updates, you have two options: apply patches at instance boot time, or regularly rebuild and publish new AMIs. Applying patches at boot time enables you to keep a stable golden image while ensuring every instance applies security updates during initialization. Rebuilding AMIs regularly gives you the ability to automatically apply any necessary updates and speed up initial boot times.
In order to apply these recommendations reliably, it’s helpful to maintain an inventory of your AMIs and launched instances by considering the following questions:
- Which private AMIs exist across your accounts and regions?
- How many instances running in production were launched from each private AMI?
- Which workloads will be affected if an image is found vulnerable?
Having adequate context for AMI usage enables you to map the relationships between images and other assets, such as instances, attached storage, and owning accounts. With the ability to visualize these connections, you can evaluate the impact to your environment when you discover a vulnerable AMI and confirm when it is decommissioned. Approaches like this help reduce version drift and misconfigurations in your internal AMI distribution pipeline.
Prevent sensitive data leakage when sharing Amazon EC2 AMIs
There are valid use cases for sharing AMIs publicly, but this practice can create a data exposure risk. It’s not uncommon for public AMIs to include embedded secrets and other sensitive data. So even when an image is published intentionally, the publisher sometimes does not thoroughly review it for hardcoded credentials. In other cases, the image is published unintentionally, possibly due to a misclick in the AWS console or a misconfigured deployment script.
If you publicly share AMIs, you can apply the same security practices that you would to any other distributed artifact. AWS recommends the following controls for public AMIs:
- Do not use fixed root passwords, and disable direct root logins.
- As an alternative to root logins, require users to generate public key credentials when launching new instances.
- Delete shell history, which could contain valuable data such as access keys.
- Remove any existing SSH host key pairs in the image’s
/etc/sshfolder. - Exclude any directories and subdirectories that you would not want to include in your bundled image, such as any SSH-related data.
Prioritizing secret management with steps like these helps reduce the chance of publishing AMIs with exploitable secrets and data.
Detect and block untrusted or malicious public AMIs
Beyond data exposure and misconfigurations, attackers can exploit the trust and familiarity associated with public AMIs. In one straightforward example, an attacker published a community image with an embedded crypto miner. When deployed, the image could consume compute resources and increase AWS costs without the user’s knowledge.
Malicious AMIs can also be a part of supply chain attacks that specifically target workflows sourcing public images. For example, Datadog researchers identified a name confusion technique in which an attacker publishes a public AMI with a name designed to match common AMI search patterns. If users or automation tools search for images by a particular name or pattern without also including the publisher or enforcing an allowlist, they could accidentally retrieve the malicious image instead of the intended one.
When a compromised or malicious image is unknowingly introduced into the environment and then reused through legitimate deployment pipelines, it expands the attack surface in ways that you may not immediately discover. Enforcing controls such as Allowed AMIs enables you to restrict and audit AMI usage in these cases. You can also apply the following best practices when sourcing public images to further reduce the risk of retrieving malicious ones:
- Restrict searches by publisher or owner.
- Create and enforce an allowlist of approved images.
- Alert on launches from unapproved or unverified images.
Together, these guardrails enable you to identify the affected instances, replace them with a known-good version, and investigate your environment for further compromise.
How Datadog can help reduce your cloud attack surface
Name confusion attacks and other untrusted or misconfigured AMI scenarios spread through typical day-to-day workflows, so the goal is to turn AMI alerts into a prioritized remediation list. You can use Datadog’s whoAMI-scanner to scan your environment for unverified community AMIs and quickly see which ones to address first.
Datadog Security will also automatically flag any publicly shared AMIs, in addition to any EC2 instances created via risky AMI discovery patterns. Since these risks can escalate rapidly, Datadog Security signals enable you to efficiently determine their scope of impact for your environment, such as which user launched the vulnerable instance and what other resources they have access to.
With this visibility, you can then group instances that use those AMIs alongside other high-risk resources, such as EC2 instances with overly permissive IAM roles. Datadog Security Graph automatically creates a visualization of AMIs and their direct relationships so that you can easily review how a particular vulnerability will affect downstream resources, and respond accordingly.
For example, if images are routinely made public, or you can’t reliably justify why they are shared, it’s a strong indicator you should enforce a control such as blocking public sharing at the account level. This step blocks new public sharing of AMIs (unless they are already public).
Minimize risks in Amazon EC2 AMI usage
Amazon EC2 AMIs enable you to quickly launch instances with repeatable configurations for services, but that convenience creates risk for your environment. By focusing on how you manage private AMIs, prevent data leakage in shared images, and enforce guardrails for sourcing public AMIs, you can reduce both traditional misconfiguration risk and exposure from supply chain attacks.
For a technical deep dive on how public AMI name confusion works, read our research on the whoAMI attack. You can also review our documentation for more information about how Datadog helps you inventory your Amazon EC2 instances. If you’re new to Datadog, sign up for a free 14-day trial.
Acknowledgements
We’d like to thank Seth Art of the Datadog Security Research team for his invaluable assistance with research and feedback on this article.
