Full Report
[part 4 in a series of 5 video write-ups from our BlackHat 09 talk, summary here] Goal In the fourth installment of our BlackHat video series, we turned our attention to Amazon’s cloud platform and focused on their Elastic Compute Cloud (EC2) service specifically. Theft of resources is the red-headed step-child of attack classes and doesn’t get much attention, but on cloud platforms where resources are shared amongst many users these attacks can have a very real impact. With this in mind, we wanted to show how EC2 was vulnerable to a number of resource theft attacks and the videos below demonstrate three separate attacks against EC2 that permit an attacker to boot up massive numbers of machines, steal computing time/bandwidth from other users and steal paid-for AMIs.
Analysis Summary
# Tool/Technique: AMIBomb (Recursive EC2 Account Creation and Instance Spawning)
## Overview
The "AMIBomb" technique aimed to create a Denial of Service (DoS) against the Amazon Elastic Compute Cloud (EC2) platform by launching an exponential number of virtual machine instances (AMIs) across numerous accounts. This exploits the lack of stringent controls on the initial account sign-up process.
## Technical Details
- Type: Technique
- Platform: Amazon EC2 (Elastic Compute Cloud)
- Capabilities: Rapid, automated, and exponential scaling of running instances, leading to resource exhaustion and potential DoS.
- First Seen: Prior to BlackHat 2009 (August 2009 presentation).
## MITRE ATT&CK Mapping
This primarily relates to resource exhaustion and service disruption.
- **TA0011 - Command and Control** (Indirectly, through automated requests)
- T1071 - Application Layer Protocol
- T1071.001 - Web Protocols (Used for account creation and AMI instantiation via the web interface/API)
- **TA0040 - Impact**
- T1499 - Network Denial of Service
- T1499.001 - Service Exhaustion (Exhausting the capacity for running new AMIs)
## Functionality
### Core Capabilities
- **Automated Account Registration:** Scripting the web-based sign-up process, which required minimal information (email and credit card).
- **Account Chaining:** Creating new EC2 accounts using the primary account, and then using those new accounts to start the process again (recursive account creation).
- **Instance Spawning:** Booting the maximum allowed number of instances (initially 20 per account) on each newly created account.
### Advanced Features
- **Exponential Growth:** The technique demonstrated exponential growth in running instances across iterations, threatening to overwhelm the system capacity until limited by external factors or detection.
- **Credit Card Abuse:** The testing used a single credit card, but the analysis noted that a malicious actor would use stolen credit card data to bypass basic payment verification checks that might otherwise slow down or halt the process.
## Indicators of Compromise
Since this is an automated technique rather than specific persistent malware, traditional IoCs are less relevant, focusing instead on anomalous account/resource usage patterns.
- File Hashes: N/A
- File Names: N/A
- Registry Keys: N/A
- Network Indicators: High volume of sequential, automated sign-up requests originating from a limited set of IP addresses/CC information directed toward AWS account creation endpoints (defanged: `aws.amazon.com/register`).
- Behavioral Indicators: Rapid creation of numerous EC2 accounts associated with the same payment instrument. Aggressive API/web requests for instance creation/booting, rapidly hitting the per-account limit (e.g., 20 instances).
## Associated Threat Actors
The authors (SensePost researchers) demonstrated this publicly. No specific named threat actor group was associated with this technique at the time of the finding.
## Detection Methods
- Signature-based detection: Not applicable for process abuse unless specific scripting signatures are developed.
- Behavioral detection: Monitoring for patterns indicative of automated registration flows (e.g., high frequency of account creation requests, rapid account establishment followed by immediate instance launching).
- YARA rules: N/A
## Mitigation Strategies
- **Stricter Onboarding Controls:** Implementing more robust verification during account sign-up, especially for payment methods (e.g., real-time verification of new credit cards or limiting the number of accounts per card/IP range).
- **Rate Limiting:** Hard application-level rate limiting on the account creation API/web endpoints.
- **Resource Quotas:** Enforcing stricter default service quotas (which Amazon later did, noting the 20-instance limit tested).
## Related Tools/Techniques
- **Twill:** Specifically mentioned as the tool used to script the browser-based sign-up process for this demonstration.
- General automated abuse of web forms for account creation.
---
# Tool/Technique: Hostile AMI Registration Race (AMI ID Manipulation)
## Overview
This technique exploits the sorting mechanism of the public Amazon Machine Image (AMI) listing page. By repeatedly creating and abandoning AMIs until a favorable, low random AMI ID is generated, an attacker can ensure their malicious or misleading AMI appears at the top of search results, tricking users into launching it.
## Technical Details
- Type: Technique
- Platform: Amazon EC2 (AMI Listing Mechanism)
- Capabilities: Manipulating placement in public listings to enhance visibility and drive user adoption of untrusted images.
- First Seen: Prior to BlackHat 2009 (August 2009 presentation).
## MITRE ATT&CK Mapping
This maps to techniques focused on deception and gaining execution through legitimate channels.
- **TA0005 - Defense Evasion**
- T1210 - Exploitation of Remote Services (Leveraging the AMI infrastructure for distribution)
- **TA0001 - Initial Access**
- T1190 - Exploit Public-Facing Application (Exploiting the AMI directory trust model)
- **TA0003 - Persistence** (If the AMI includes persistent backdoors)
## Functionality
### Core Capabilities
- **AMI Registration Scripting:** Automating the process of baking and registering a new AMI.
- **ID Value Probing:** Repeatedly checking the generated random AMI ID.
- **Listing Position Optimization:** Continuing the script loop until the random ID is low enough (high enough ranking) to appear on the first page of listings (e.g., top 5 spots).
- **Search Optimization:** Using targeted naming conventions (e.g., 'fedora\_core\_11') to ensure the malicious image appears first for users searching specific, trusted operating systems.
### Advanced Features
- **Call-Home Mechanism:** The demonstration AMI included a basic persistence mechanism (`/etc/rc.local` calling back via `wget`) to prove the image was successfully launched by unsuspecting users.
- **Trust Exploitation:** Relying on the assumption that users trust pre-built public AMIs provided by the community.
## Indicators of Compromise
IoCs are related to the distribution phase and the implanted payload.
- File Hashes: N/A (specific hashes depend on the custom AMI created)
- File Names: N/A
- Registry Keys: N/A
- Network Indicators: Outbound "call-home" requests triggered upon instance boot from the compromised AMI (defanged: `[attacker_webserver]/log`).
- Behavioral Indicators: Successful launching of custom, untrusted AMIs by other users; presence of modification to initialization scripts like `/etc/rc.local` on launched instances.
## Associated Threat Actors
Used for demonstration by SensePost researchers. The underlying technique is applicable to any threat actor seeking to distribute code via the Amazon marketplace trust model.
## Detection Methods
- **Content Scanning:** Implementing security scanning of newly registered public AMIs before they reach prominent listing positions.
- **Trust Metric Monitoring:** Monitoring which AMIs are being launched by users (e.g., flagging launches of new, unverified AMIs).
- **Initialization Script Inspection:** Auditing `/etc/rc.local` or equivalent startup scripts for unusual network calls or malicious commands in active instances.
## Mitigation Strategies
- **Ranking Algorithm Review:** Modifying the AMI listing process so that ranking is based on factors other than just the random AMI ID (e.g., creation date, reputation score, or verified source).
- **Reputation/Vetting for Public Images:** Establishing a formal vetting process or reputation system for public AMIs, especially those that appear on the first page of results.
- **User Education:** Warning users about the source and nature of public AMIs.
## Related Tools/Techniques
- **AMI Stealing (Technique 3):** Related in that it involves manipulating the AMI lifecycle.
- SEO/Search Ranking Manipulation: Analogous to manipulating search engine results pages (SERP).
---
# Tool/Technique: AMI Stealing (Paid-for Image License Stripping)
## Overview
This technique demonstrates how an attacker can legally acquire a paid-for Amazon Machine Image (AMI) once, and then cryptographically strip the licensing and ownership metadata from subsequent copies, allowing free, perpetual use of the image without compensating the original creator or Amazon (via DevPay).
## Technical Details
- Type: Technique
- Platform: Amazon EC2 (AMI Bundle/Manifest Handling)
- Capabilities: Circumventing royalty payments for paid AMIs by falsifying authorship metadata.
- First Seen: Prior to BlackHat 2009 (August 2009 presentation).
## MITRE ATT&CK Mapping
This is a financial/licensing fraud technique focused on resource longevity.
- **TA0040 - Impact**
- T1489 - Hijack Execution Flow (Altering the trust flow/manifest validation)
- **TA0006 - Credential Access** (Indirectly, by bypassing payment validation)
## Functionality
### Core Capabilities
- **Purchase and Bundling:** Buying the paid-for AMI and using Amazon tools to create a local bundle, which includes an associated XML manifest file detailing ownership and product codes.
- **Manifest Modification:** Manually editing the downloaded XML manifest to remove the product code and owner information that links back to the original creator.
- **Re-signing:** Using Amazon's tools to cryptographically re-sign the modified manifest, making it appear valid to the registration service.
- **AMI Replacement:** Registering a new AMI using the copied bundle and the edited manifest, effectively creating a 'stolen' copy that executes without further payment obligations.
### Advanced Features
- **Disassociation from Ancestry:** The core advanced feature is the successful removal of ancestry/payment information required for DevPay/licensing enforcement during the registration process.
## Indicators of Compromise
Detection relies on monitoring the lifecycle of paid AMIs and checking manifest integrity.
- File Hashes: N/A
- File Names: N/A
- Registry Keys: N/A
- Network Indicators: N/A
- Behavioral Indicators:
- Rapid creation of multiple, identical AMIs immediately following the purchase of a single paid AMI.
- Disappearance of licensing metadata (product codes) in the manifests of newly registered AMIs derived from a paid source.
- Sudden drop in royalty payments/usage reports for the original AMI creator corresponding with increased usage of a functionally identical, but unlinked, new AMI.
## Associated Threat Actors
Any entity seeking to monetize or freely use proprietary software distributed via the Amazon EC2 Marketplace without adhering to licensing fees.
## Detection Methods
- **Manifest Integrity Checks:** Amazon auditing tools should verify the cryptographic binding between the bundle files and the manifest's licensing details, ensuring removal of necessary payment metadata fails registration or invalidates the registration.
- **Usage Anomaly Detection:** Flagging instances launched from paid AMIs where the associated account/billing mechanism is not the original purchaser's.
## Mitigation Strategies
- **Stronger Manifest Binding:** Tightly coupling the manifest signature to the owning account or billing mechanism so that modification/re-signing without specific authorization invalidates the bundle.
- **DevPay Enforcement:** Ensuring that the registration API strictly enforces the presence and validity of product codes for non-free AMIs.
## Related Tools/Techniques
- **Reverse Engineering/Tampering:** Similar to attempts to bypass DRM or license checks in traditional software.