AWS Credential Exfiltration via Amazon ECS Internal Protocol Abuse

A technique dubbed “ECScape” that allows malicious containers running on Amazon Elastic Container Service (ECS) to steal AWS credentials from other tasks sharing the same EC2 instance.

The attack exploits an undocumented internal protocol between the ECS agent and AWS control plane, enabling privilege escalation without requiring container breakout or host-level access.

The vulnerability was discovered during development of an eBPF-based monitoring tool for ECS workloads.

Researcher Naor Haziz noticed that the ECS agent possessed service information not available through standard EC2 instance IAM roles, leading to investigation of the agent’s communication channels.

Through packet capture analysis, Haziz observed that the ECS agent establishes WebSocket connections to AWS endpoints with a critical parameter: ?sendCredentials=true.

This connection receives cleartext JSON payloads containing IAM credentials for all tasks running on the host, including Access Key IDs, Secret Keys, and Session Tokens.

The attack works by first stealing EC2 instance role credentials via the Instance Metadata Service (IMDS), then using these credentials to impersonate the ECS agent.

Attackers call ecs:DiscoverPollEndpoint to identify the correct AWS endpoint, gather required identifiers including cluster and container instance ARNs, and establish a forged WebSocket connection that mimics legitimate agent communications.

“The ECS control plane was actively pushing task credentials down to the agent over this WebSocket channel,” Haziz explained. “If I could somehow tap into that channel, I might capture credentials that weren’t meant for my container”.

AWS Credential Exfiltration

ECScape fundamentally undermines the assumption that containerized workloads remain isolated from each other on shared infrastructure.

A compromised low-privilege container can instantly escalate to any higher-privilege task on the same EC2 instance by stealing its IAM credentials.

The attack also exposes task execution role credentials, which AWS documentation states should not be accessible to task containers.

These credentials often include sensitive permissions for pulling secrets from AWS Secrets Manager, accessing private container registries, or writing to CloudWatch Logs.

Particularly concerning is the attack’s stealth factor. Stolen credentials function identically to legitimate ones, with AWS CloudTrail attributing API calls to the victim task’s role rather than the attacker.

“Initial detection is tough – it appears as if the victim task is performing the actions,” researchers noted.

The technique was demonstrated with three tasks sharing an EC2 instance: a low-privilege attacker container with deny-all policies successfully obtained S3 full access from another task and retrieved database secrets from a third task’s execution role.

AWS Maintains “Working as Designed” Stance

When reported through coordinated disclosure, AWS classified ECScape as a design consideration rather than a vulnerability, stating that containers sharing EC2 instances are implicitly in the same trust domain.

AWS updated their documentation to explicitly warn that “tasks running on the same EC2 instance may potentially access credentials belonging to other tasks on that instance” and recommended AWS Fargate for stronger isolation guarantees.

Key mitigation strategies include disabling or restricting IMDS access for containers, isolating high-privilege tasks on dedicated instances, implementing least-privilege IAM policies, and using Fargate where each task runs in its own micro-VM.

Organizations can also deploy monitoring to detect unusual IAM role usage patterns through CloudTrail analysis.

The research underscores the critical importance of treating EC2 instances as security boundaries and carefully considering workload placement in multi-tenant container environments.

Find this Story Interesting! Follow us on LinkedIn and X to Get More Instant Updates.