ECScape Flaw in Amazon ECS Allows Credential Theft

Cybersecurity researchers have unveiled an “end-to-end privilege escalation chain” in Amazon Elastic Container Service (ECS) that a malicious actor could exploit to move laterally, access sensitive data, and ultimately seize control of the entire cloud environment.

The attack technique, codenamed ECScape, was presented by Sweet Security researcher Naor Haziz at the Black Hat USA security conference in Las Vegas.

“We identified a way to abuse an undocumented ECS internal protocol to grab AWS credentials belonging to other ECS tasks on the same EC2 instance,” Haziz stated in a report. “A malicious container with a low‑privileged IAM [Identity and Access Management] role can obtain the permissions of a higher‑privileged container running on the same host.”

Understanding the ECScape Vulnerability

Amazon ECS is a fully-managed container orchestration service that simplifies deploying, managing, and scaling containerized applications on AWS. The vulnerability discovered by Sweet Security allows a low-privileged task on an ECS instance to hijack the IAM privileges of a more powerful container on the same EC2 machine by stealing its credentials.

Essentially, a malicious application within an ECS cluster can assume the role of a more privileged task. This is accomplished by exploiting a metadata service running at 169.254.170.2 that exposes temporary credentials tied to a task’s IAM role. While this design is meant to deliver credentials securely to each task at runtime, a leak of the ECS agent’s identity can allow an attacker to impersonate the agent and request credentials for any task on the host.

The Attack Chain Explained

The entire attack sequence unfolds as follows:

• Obtain Host Credentials: The attacker first gets the host’s IAM role credentials (the EC2 Instance Role) to impersonate the ECS agent.
• Discover Endpoint: They discover the ECS control plane endpoint that the agent communicates with.
• Gather Identifiers: Using the Task Metadata endpoint and ECS introspection API, the attacker collects necessary identifiers like cluster name, container instance ARN, agent version, Docker version, and sequence number to authenticate as the agent.
• Forge the Request: The attacker forges and signs an Agent Communication Service (ACS) WebSocket Request, impersonating the agent with the sendCredentials parameter set to “true.”
• Harvest Credentials: Finally, they harvest the credentials for all running tasks on that instance.

“The forged agent channel also remains stealthy,” Haziz explained. “Our malicious session mimics the agent’s expected behavior – acknowledging messages, incrementing sequence numbers, sending heartbeats – so nothing seems amiss. By impersonating the agent’s upstream connection, ECScape completely collapses that trust model: one compromised container can passively collect every other task’s IAM role credentials on the same EC2 instance.”

Impact and Mitigation Strategies

ECScape can lead to severe consequences when running ECS tasks on shared EC2 hosts, opening the door to cross-task privilege escalation, secret exposure, and metadata exfiltration.

Following a responsible disclosure, Amazon updated its documentation to clarify that task isolation does not exist on EC2 and that “containers can potentially access credentials for other tasks on the same container instance.”

To mitigate this risk, it’s advised to:

• Avoid Mixed Privileges: Do not deploy high-privilege tasks alongside untrusted or low-privilege tasks on the same instance.
• Use AWS Fargate: For true task isolation, use AWS Fargate.
• Restrict IMDS: Disable or restrict Instance Metadata Service (IMDS) access for tasks that don’t need it.
• Limit Agent Permissions: Apply the principle of least privilege to ECS agent permissions.
• Set Up Alerts: Configure CloudTrail alerts to detect unusual usage of IAM roles.

A Trend of Cloud Security Weaknesses

This discovery is the latest in a series of significant cloud security flaws reported recently:

• A race condition in Google Cloud Build’s GitHub integration that could allow bypassing maintainer reviews.
• A remote code execution flaw in Oracle Cloud Infrastructure (OCI) Code Editor.
• An attack technique called I SPy that exploits a service principal in Entra ID for privilege escalation.
• A privilege escalation vulnerability in the Azure Machine Learning service.
• A scope vulnerability in the legacy AmazonGuardDutyFullAccess AWS managed policy.
• An attack that abuses Azure Arc for privilege escalation and persistence.
• Over-privileged roles and an API vulnerability in Azure that could leak VPN keys.
• A supply chain vulnerability in Google Gerrit called GerriScary (CVE-2025-1568), affecting projects like ChromiumOS.
• A Google Cloud Platform misconfiguration that exposed internal networks at Internet Exchange Points (IXPs).
• An extension of the ConfusedFunction privilege escalation vulnerability affecting GCP, AWS, and Azure.

“The core lesson is that you should treat each container as potentially compromiseable and rigorously constrain its blast radius,” Haziz concluded. “AWS’s convenient abstractions make life easier for developers, but when multiple tasks with different privilege levels share an underlying host, their security is only as strong as the mechanisms isolating them.”