Amazon ECS Internal Protocol Exploited to Steal AWS Credentials from Other Tasks

Security researchers have disclosed a critical vulnerability in Amazon Elastic Container Service (ECS) that allows malicious containers to steal AWS credentials from other tasks running on the same EC2 instance.

The attack, dubbed “ECScape,” exploits an undocumented internal protocol to impersonate the ECS agent and harvest privileged credentials without requiring container breakout.

Vulnerability Overview

The ECScape attack leverages a fundamental design flaw in how ECS manages IAM credentials on shared EC2 instances.

When multiple containers with different privilege levels run on the same host, a compromised low-privileged container can obtain credentials belonging to higher-privileged tasks through the ECS Agent Communication Service (ACS) protocol.

The vulnerability was discovered by security researcher Naor Haziz during development of an eBPF-based monitoring tool.

While investigating how ECS tasks retrieve metadata, Haziz observed that the ECS agent receives task credentials via a WebSocket connection to AWS’s control plane with a suspicious “sendCredentials=true” parameter.

How the Attack Works

ECScape operates through a multi-step process that requires no container escape but does need access to the Instance Metadata Service (IMDS).

First, the attacker steals the EC2 instance’s IAM role credentials through IMDS queries. Next, they discover the ECS control plane endpoint and gather necessary identifiers like cluster ARN and container instance ARN.

The attacker then establishes a forged WebSocket connection to impersonate the ECS agent, using stolen instance credentials for authentication.

Once connected, the malicious session receives IAM credential payloads for all tasks running on the host, including both task roles and execution roles that typically have access to sensitive resources like AWS Secrets Manager.

The vulnerability poses severe risks for multi-tenant ECS environments. A compromised scanning container with read-only permissions could steal credentials from a database backup container with full database access, completely undermining isolation boundaries.

Even more concerning, execution role credentials—supposedly inaccessible to application containers—are also exposed, potentially granting access to private container registries and secrets.

Detection proves particularly challenging because stolen credentials function identically to legitimate ones.

AWS CloudTrail logs attribute API calls to the victim task’s role, making initial detection difficult without correlation to expected task behavior patterns.

AWS recommends several protective measures for ECS users. Primary defenses include avoiding deployment of high-privilege tasks alongside untrusted containers on shared instances, implementing dedicated hosts for critical services, or migrating to AWS Fargate where each task runs in an isolated micro-VM.

Additional protections involve restricting IMDS access through the ECS_AWSVPC_BLOCK_IMDS setting, enforcing IMDSv2, and implementing least-privilege IAM policies.

Organizations should also drop unnecessary Linux capabilities to limit post-compromise activities.

The disclosure highlights fundamental security considerations in container orchestration platforms and underscores the importance of understanding isolation boundaries in cloud environments.

While AWS has not indicated plans to modify the underlying architecture, the research emphasizes why Fargate’s micro-VM isolation provides stronger security guarantees for sensitive workloads.

The Ultimate SOC-as-a-Service Pricing Guide for 2025– Download for Free