ECS-cape – Hijacking IAM Privileges in Amazon ECS

ECS-cape -- Hijacking IAM Privileges in Amazon ECS

Speakers: Naor Haziz

Conference: fwd:cloudsec North America 2025

YouTube: https://www.youtube.com/watch?v=WXdB-9pTqAU

Overview

Naor Haziz, a software developer and security researcher at Sweet Security, presented a vulnerability he discovered in Amazon ECS (Elastic Container Service) that allows any container running on an EC2 instance to hijack the IAM role credentials of every other container on the same host. Dubbed ECScape (a play on ECS + escape), the attack exploits the internal Agent Communication Service (ACS) protocol to impersonate the ECS agent and receive all task role credentials over a WebSocket connection. The vulnerability requires no misconfigurations -- IMDS is enabled by default for ECS tasks, and the ECS instance role has the necessary permissions out of the box. AWS acknowledged the issue, updated their documentation, and stated that hundreds of millions of containers are potentially affected, but classified it as not presenting a security concern for AWS and declined to change the default behavior.

Background

▶ Watch: The premise: one container hijacking credentials of another via internal AWS ... (1:30)

Amazon ECS is one of the most widely adopted container orchestration platforms, with approximately one-third of developers using orchestration technologies relying on it. ECS runs in two launch modes: Fargate (fully serverless) and EC2 (customer-managed instances). In EC2 launch mode, each EC2 instance runs a Docker daemon and an ECS agent that communicates with the AWS control plane. The ECS agent authenticates using the EC2 instance role and receives task assignments, metadata, and critically, IAM role credentials for all running tasks on that instance.

A core security promise of ECS is task role isolation: each task receives its own IAM role, and AWS documentation explicitly stated that "a container never has access to credentials that are intended for another container that belongs to another task." ECScape proves this promise false in EC2 launch mode.

Haziz discovered the vulnerability organically while building an EC2 sensor for Sweet Security's detection and response product. His manager asked him to monitor ECS tasks, and while hunting for the service name metadata, he stumbled upon the ECS agent's WebSocket communication and noticed it was passing task role credentials over the wire.

Key Findings

▶ Watch: Deep dive into ECS agent authentication flow and SIGv4 signing (10:00)

The ECScape vulnerability enables cross-task IAM role hijacking -- any task running on an EC2 instance can steal the IAM role credentials of every other task on the same host. This constitutes a clear privilege escalation path: a low-privilege container can obtain administrator-level credentials from a co-located high-privilege container.

The attack chain requires no misconfiguration. IMDS (Instance Metadata Service) is enabled by default for ECS tasks, and the ECS instance role ships with the ecs:Poll and ecs:DiscoverPollEndpoint permissions by default. These are the only two ingredients needed.

AWS's response was to update their documentation to state that "tasks running on the same EC2 instance may potentially access the credentials belonging to other tasks on that instance" -- replacing the previous promise of isolation. AWS told Haziz they would "consider long-term defense and in-depth changes" but explicitly stated the behavior would not change for now. AWS also confirmed that hundreds of millions of containers are accessible to this vulnerability. Fargate is not affected because it already implements better isolation defaults.

Technical Deep Dive

▶ Watch: Container introspection endpoint reveals the missing container instance ARN (18:00)

The attack exploits the Agent Communication Service (ACS), an undocumented WebSocket-based internal protocol used by the ECS agent to communicate with the AWS control plane. The ACS protocol carries task metadata, agent directives, and IAM credentials for all running tasks on a container instance.

The ECS agent authenticates to ACS through a multi-step process. First, it calls the DiscoverPollEndpoint API using the instance role, which returns a poll URL. The agent then constructs a WebSocket request using this URL plus several identifiers (agent version, cluster ARN, container instance ARN) and signs it using SIGv4 with the ecs:Poll permission. AWS validates the signature and grants access to the WebSocket, which then streams all task credentials.

To impersonate the agent from within a task, Haziz had to solve several challenges:

1. Obtaining the poll URL: Tasks lack the DiscoverPollEndpoint permission, but Haziz discovered the URL structure is predictable -- only the region and a backend server number vary. The region is known, and the server number can be brute-forced.

1. Getting the instance role credentials: IMDS is accessible from every ECS task by default, providing the EC2 instance role credentials needed for SIGv4 signing.

1. Finding the container instance ARN: This was the hardest piece. The instance role lacks ListContainerInstances permission, and other approaches (mounting host filesystem via Bolt DB, registering a new container instance) had drawbacks. The breakthrough came from discovering the container introspection endpoint, another ECS agent endpoint exposed to every task, which returns the cluster name, container instance ARN, and agent version.

1. Constructing and signing the WebSocket: With all identifiers gathered, the task signs the request using SIGv4 with the instance role's ecs:Poll permission and connects to ACS, receiving credentials for all co-located tasks.

The entire attack works identically with IMDSv2 -- the token-based protection adds no meaningful barrier since the task can simply request the IMDSv2 token first.

Demo / Proof of Concept

▶ Watch: Live demo: zero-permission container deletes S3 bucket using stolen admin cre... (22:00)

Haziz performed a live demonstration using a cluster with two tasks: Hyper (with an administrator access policy -- full AWS permissions) and ECScape (with a deny-everything policy -- zero AWS permissions). An S3 bucket named "forward-cloud-sec-25" was created as a target. From within the ECScape container (which had zero permissions), Haziz ran his ecscape CLI tool written in Rust. The tool retrieved the Hyper task's full administrator credentials, then used those credentials to successfully delete the S3 bucket, demonstrating complete privilege escalation from a zero-permission container to full administrator access. The tool is open-source and available on GitHub.

Defensive Implications

▶ Watch: AWS response: hundreds of millions of containers affected, behavior won't change (30:00)

The primary mitigation is to disable IMDS access for individual ECS tasks. AWS provides documentation on how to do this based on network mode. Critically, IMDS must not be disabled at the instance level, as this would break the ECS agent itself. Disabling IMDS for tasks prevents them from obtaining the instance role credentials needed to initiate the attack.

Additional mitigations include:

• Never grant tasks the ecs:Poll or ecs:DiscoverPollEndpoint permissions, as these allow the same attack without IMDS
• **Avoid ecs:* wildcard permissions** on task roles, as they include the dangerous permissions
• Separate high-privilege and low-privilege tasks onto different EC2 instances -- sensitive workloads should never share a host with untrusted containers
• Isolate tenants in multi-tenant systems -- never share clusters or instances between tenants
• Minimize task role permissions following the principle of least privilege
• Consider migrating to Fargate, which is not vulnerable to this attack and has better isolation defaults

AWS has signaled that task-level hardening is the customer's responsibility and the default behavior will not change. IAM role isolation is the last line of defense in ECS EC2 mode.

Key Takeaways

• ECScape allows any ECS task on an EC2 instance to hijack IAM credentials from every other task on the same host, breaking AWS's documented promise of task role isolation
• The attack requires zero misconfigurations -- IMDS and the necessary ECS instance role permissions are enabled by default
• AWS confirmed hundreds of millions of containers are potentially affected but classified it as expected behavior rather than a security vulnerability
• The primary defense is disabling IMDS access per-task, which must be explicitly configured by the customer
• Fargate is not vulnerable and provides better isolation defaults, which AWS appears to be encouraging as the preferred launch mode
• The open-source ecscape tool on GitHub implements the full attack chain in Rust

About the Speaker(s)

Naor Haziz is a software developer and security researcher at Sweet Security, based in Israel. He specializes in container security and cloud-native detection and response. This was his first conference speaking engagement. Outside of security research, he is a DJ and an enthusiast of the Rust programming language.