Exploiting ECS Protocol on EC2 to Exfiltrate Cross-Task IAM and Execution Role Credentials
A sophisticated technique dubbed “ECScape” that allows malicious containers running on Amazon Elastic Container Service (ECS) to steal AWS credentials from other containers sharing the same EC2 instance.
The discovery highlights critical isolation weaknesses in multi-tenant ECS deployments and underscores the security advantages of AWS Fargate’s micro-VM architecture.
The technique, developed by security researcher Naor Haziz, exploits an undocumented internal protocol between ECS agents and AWS’s control plane to exfiltrate IAM credentials across container boundaries.
Unlike traditional container escape methods requiring host-level access, ECScape operates entirely within the container’s namespace while leveraging network manipulation to impersonate the ECS agent.
The attack begins when a compromised container accesses the Instance Metadata Service (IMDS) at 169.254.169.254 to obtain the EC2 instance’s IAM role credentials. These credentials, typically used by the ECS agent for legitimate operations, become the foundation for the subsequent impersonation attack.

Using the stolen instance credentials, attackers can discover the ECS control plane’s polling endpoint through the ecs:DiscoverPollEndpoint
API and gather essential identifiers, including cluster ARNs and container instance ARNs.
The malicious process then establishes a forged WebSocket connection to AWS’s Agent Communication Service (ACS), the internal channel through which ECS delivers task credentials to agents.
ECScape Attack Abuses ECS Protocol
By including the parameter sendCredentials=true
in the WebSocket handshake, attackers can receive all IAM credentials for every task running on the shared EC2 instance.
This includes both application role credentials and task execution role credentials, which often contain sensitive permissions for accessing AWS Secrets Manager, ECR repositories, and CloudWatch Logs.

ECScape demonstrates particularly concerning stealth characteristics, as stolen credentials function identically to legitimate ones. AWS CloudTrail logs attribute API calls to the victim task’s role rather than the attacking container, making initial detection extremely challenging.
The technique breaks fundamental assumptions about container isolation in ECS environments, allowing low-privileged tasks to assume the permissions of high-privileged containers on the same host.
In demonstration environments, researchers showed how a container with deny-all IAM policies could successfully delete S3 buckets using stolen credentials from a neighboring task with S3 full access.
The attack also enabled the extraction of sensitive secrets intended for other containers, effectively compromising the multi-tenant security model.
AWS reviewed the findings through their coordinated disclosure program but classified the behavior as a design consideration rather than a vulnerability. The company emphasized that containers sharing EC2 instances are implicitly part of the same trust domain unless users implement proper isolation measures.
Following the disclosure, AWS updated its documentation to explicitly warn that “tasks running on the same EC2 instance may potentially access credentials belonging to other tasks on that instance”. The company strongly recommends AWS Fargate for scenarios requiring stronger isolation guarantees.
Security experts recommend several mitigation strategies: disabling or restricting IMDS access for containers through network controls or the ECS_AWSVPC_BLOCK_IMDS
setting, avoiding co-location of high-privilege and low-privilege tasks on shared instances, implementing least-privilege IAM policies for all task roles, and deploying comprehensive CloudTrail monitoring to detect unusual credential usage patterns.
Organizations running ECS on EC2 should treat each instance as a potential failure domain and consider migrating sensitive workloads to Fargate’s isolated micro-VM architecture for enhanced security boundaries.
Equip your SOC with full access to the latest threat data from ANY.RUN TI Lookup that can Improve incident response -> Get 14-day Free Trial
Source link