Cloud Chaos: New ‘ECScape’ Attack Threatens Amazon’s Container Service

At the Black Hat USA conference in Las Vegas, Naor Haziz, a researcher at Sweet Security, unveiled an attack dubbed ECScape, capable of completely undermining the trust-based security model of Amazon ECS. The vulnerability paves the way for privilege escalation, unauthorized access to other users’ IAM roles, and full takeover of containers in AWS cloud environments.

Amazon ECS is a managed container orchestration service that enables users to deploy and scale applications. However, when operating in EC2 mode—where multiple tasks run on the same virtual machine instance—an opportunity arises for stealthy, host-level attacks. Haziz demonstrated that a container with minimal privileges can acquire the permissions of another, more privileged task, provided both are running on the same EC2 instance.

The attack hinges on the abuse of an undocumented internal ECS protocol. First, the attacker gains access to the IAM role assigned to the EC2 instance itself, allowing them to impersonate an ECS agent. They then identify the cluster control endpoint, collect key metadata (including the cluster name, Docker and agent versions, and unique identifiers), and craft a forged WebSocket request from the impersonated agent to the ACS service. Crucially, this request includes the sendCredentials parameter, which prompts the cloud to return temporary IAM credentials for every task running on the host.

To conceal malicious activity, the fake agent is replicated down to the smallest detail: it responds to messages, sends heartbeat signals, and follows the exact command sequence of a legitimate connection. This creates a convincing illusion of authenticity, while in the background, the malicious container quietly acquires IAM roles belonging to other containers on the same machine.

Haziz emphasized that in Amazon ECS on EC2, there is no inherent task-to-task isolation. This means that even temporary credentials securely issued via the metadata service at 169.254.170.2 can be stolen and abused by an unauthorized container. Such behavior fundamentally shatters the assumption that task roles are isolated and inaccessible to outsiders.

In response to the discovery, Amazon updated its documentation and advised adopting stricter isolation models—specifically, avoiding the co-location of tasks with differing trust levels on the same machine, using Fargate for full isolation, restricting access to the Instance Metadata Service (IMDS), limiting ECS agent privileges, and implementing detection mechanisms for suspicious IAM role usage through CloudTrail.