Malicious AMI detection: Securing Amazon Machine Images (AMIs)

Amazon Machine Images (AMIs) are essential to the AWS computing ecosystem. An Elastic Compute Cloud (EC2) instance without an AMI is like a laptop without any software or hard drive: a digital brick. That's why effective malicious AMI detection is critical to your cloud security strategy. 

Since AMIs are so crucial to AWS computing, they’re a prime target for attackers. One AMI can control several EC2 instances, which means a single malicious AMI could help a hacker penetrate your entire cloud network. 

But here’s the good news: You can use image security practices and governance to reduce your risk of AMI attacks drastically. 

Editor’s note: AWS has transformed the computing landscape, but it can be hard to know how to start using it for your cloud infrastructure. Infosec has a free AWS workshop and lab about how to build and deploy your first cloud infrastructure. 

View Free Course

What are AMIs? 

An Amazon Machine Image (AMI) is a template that launches EC2 instances in AWS. To enable effective EC2 instances, an AMI provides: 

• A root volume: This has an operating system, such as Amazon Linux, and essential applications like Remote Desktop Protocol (RDP). 

• Launch permissions: These determine the AWS accounts that are allowed to use the image. 

• Block device mappings: These are storage blueprints for your EC2. They determine the kind of storage your EC2 will use and important storage behaviors. For instance, a block device mapping may specify that your EC2 uses 30 GB of EBS storage, and the volume gets automatically deleted when someone terminates the EC2 instance. 

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

While building a malicious AMI detection system, it’s also important to know that AMI cloud computing can involve different kinds of AMIs: 

• AMIs owned by AWS: These are maintained and updated by Amazon and are hardened, meaning they’re secured with a minimal attack surface and vulnerabilities. 

• AMIs from the marketplace: These are published by vendors and sold to organizations. 

• Community AMIs: Other users create and share AMIs, oftentimes making them publicly available. 

• Private AMIs: These are typically created by an organization and used internally, but some organizations may choose to outsource their private AMI creation to a developer. 

What are malicious AMIs? 

Malicious AMIs are AMIs that have been altered by someone, introducing security risks to an EC2 instance. Often, the alteration is intentional, but an unintentional configuration could also result in a threat. Regardless of whether someone builds a malicious AMI to compromise systems or it results from a mistake, they can introduce serious vulnerabilities in your AMI cloud computing ecosystem. 

AWS AMI security risks are hazardous because a malevolent AMI may look innocent. For instance, it may consist of trusted distributions or a seemingly innocent operating system.

Recent malicious AMI trends 

Your malicious AMI prevention system should look out for the following threats that have been trending on the attack landscape: 

• Cloned or modified AMIs: Some attackers may clone a legitimate image from trusted AMI sources and then introduce threats, such as malware or backdoors. They then redistribute it and make it look like an authentic AMI. 

• Intentionally malicious AMIs that mimic legitimate AMIs: For instance, it may have a name like “Ubuntu 22.004 LTS,” designed to resemble the legitimate version, Ubuntu 22.04 LTS. This or similar renaming strategies are also used to disguise cloned and modified AMIs. 

• Inadvertent exposure to malicious AMIs: An organization may inadvertently acquire a shared AMI containing secure shell (SSH) keys, outdated software, or other vulnerabilities. 

• Malicious images created as part of cloud supply chain attacks: Hackers may infiltrate a legitimate AMI producer’s process and inject malicious code into the AMIs they provide. These providers may even advertise that they’ve implemented golden image hardening, giving you confidence in their product. However, successful cloud supply chain attacks, such as cloud poisons, can impact any of the provider’s customers. 

Common types of malicious payloads found in AMIs 

Malicious AMI detection must consider a range of private and public AMI risks. As part of an AMI security best practices program, here are some payloads to look out for: 

• SSH key implants, which empower an attacker to access your system undetected for an extended period of time 

• Privilege escalation exploits, which often take the form of backdoors that provide root access to a hacker 

• Legacy or vulnerable packages that attackers have already found ways to exploit 

• Rogue daemons, such as background services that contact external IPs set up by attackers 

• Reverse shells, which enable attackers to control your system remotely 

• Crypto miners, which repurpose your resources for mining crypto, for attackers 

It’s also important to note that these attack methods can be used in other cloud environments. For instance, GCP images and Azure images can also be susceptible to the above attack methods. So while malicious AMI detection should focus on the above techniques, if you have a multi-cloud environment, you can also look for the same threats in your other images. 

The AMI security lifecycle 

Your images are foundational to your infrastructure, so by establishing proper controls, you can safeguard many cloud assets. Your security lifecycle should consist of: 

1. Selecting AMIs. These may have either been hardened by AWS or come from a verified, trusted vendor that can prove they have checked the AMIs they’re sending you. 
2. Internal hardening. Your internal hardening procedure should include applying the Center for Internet Security benchmarks, removing unnecessary services and pre-installed SSH keys, and disabling unused ports. 
3. Vulnerability scanning. You should use scanning tools, which are discussed below, to check for vulnerabilities, malware, embedded APIs, SSH keys, or passwords in the image. 
4. Controlled distribution. Controlling your AMI distribution starts with storing hardened AMIs in secure AWS accounts. Then, you should distribute them using strict identity and access management (IAM) policies. 
5. Monitoring your environment. Your monitoring system should look out for suspicious outbound traffic and configurations that differ from those of the hardened baseline image. Monitoring also involves looking out for unauthorized accounts or SSH keys. 
6. Decommissioning outdated images. You should have a systematic retirement process in place to prevent people from accidentally using old or problematic AMIs. It’s also crucial to revoke access to older AMIs and ensure that any configuration files, such as those in AWS CloudFormation or Terraform, no longer reference them. 

The importance of mapping AMI security to compliance requirements 

Depending on the compliance standards that apply to your organization, certain types of AMI security may be mandatory. 

For instance, NIST 800-53 requires that all deployed systems have known, trusted baselines. If audited, you would also have to provide evidence that you’ve been continuously monitoring your deployment for AMI-based threats. 

The Center for Internet Security (CIS) provides benchmarks that outline configuration guidelines for the operating system images you should use, such as an authentic Amazon Linux or Ubuntu OS. 

To determine the compliance ramifications for your AMI security, you can consult the guidelines of the relevant regulatory body with which your organization must comply. 

How to identify suspicious AMIs before using them 

Even though AMI vulnerability scanning, AMI backdoor detection, and container image security can prevent many image-based threats, it’s still essential to systematically: 

• Use explicit “owner” filters in your development processes: For instance, suppose the Canonical AWS account ID for a trusted Ubuntu 22.04 LTS operating system is “099720109477.” You can input “--owners 099720109477 \” in your code to make sure AWS only returns images owned by Canonical. 

• Always double-check the AMI owner: Checking the owner is crucial for verifying the base image. Before implementing an AMI, ensure it’s from a trusted source. 

• Check each AMI’s creation date: If the date is suspiciously recent, the AMI may be malicious. For instance, if the supposed producer hasn’t released a new AMI for several months, and the date on the AMI you’re considering is from two days ago, it could be malicious. 

• Check the cryptographic checksums and metadata against those from the supposed provider: This is one of the most straightforward malicious AMI detection strategies. Any changes to an AMI’s contents will produce a different checksum, and differences in the producer’s name, the publication date, or type of virtualization can also indicate a malicious image. 

• Check the vendor’s reputation in the AWS marketplace: If the AMI’s vendor has victimized other users, they may have reported their experiences in the market. 

AMI scanning tools 

Several security tools can reduce AWS AMI security risks. These can be helpful to weapons in an AWS security testing portfolio because they automate elements of malicious AMI prevention while boosting your overall container image security. Some effective image scanning automation tools include: 

• AWS Inspector: This is an essential component of AWS Marketplace security, and it’s included in the AWS ecosystem. Inspector scans AMIs and EC2s for common vulnerabilities and exposures (CVEs). 

• Aqua Security: Aqua plays a key role in AWS security controls because it scans container images for malware and vulnerabilities. It also checks for compliance issues. 

• Palo Alto Networks Prisma Cloud (fka Twistlock): By scanning virtual machine images and containers, Prisma Cloud can detect outdated packages and malware. 

Learn Cloud Security

Get hands-on experience with cloud service provider security, cloud penetration testing, cloud security architecture and management, and more.

Start Learning

Harden your AWS infrastructure against malicious AMIs 

Attaining immutable infrastructure security in AWS should start with safeguarding your AMI environment. A single compromised AMI can result in vulnerabilities across your system, or even in it being hijacked and used for an attacker’s bidding. By applying the tips above, you can safeguard your infrastructure against a wide range of malicious AMIs, ensuring uninterrupted and secure cloud operations. 

If you’re ready to take the next step in building your cloud and security expertise, explore Infosec Institute’s free cybersecurity career paths ebook to map your next move in the field.