A compromised Amazon Elastic Container Service (ECS) task could escalate its privileges and compromise other tasks on the same Elastic Compute Cloud (EC2) instance, Sweet Security Senior Software Developer Naor Haziz described in a Wednesday afternoon
briefing at Black Hat USA 2025 in Las Vegas.
Using
an exploit dubbed “ECScape” to abuse the way ESC on EC2 manages task credentials, an attacker in control of a low-privileged task could impersonate the ECS agent and potentially gain access to sensitive data or elevated permissions of other higher-privileged tasks on the instance.
While not a vulnerability in the underlying Amazon ECS and EC2 services, Sweet Security’s research provided insight into potentials risks users of these services should consider and mitigate to prevent unauthorized privilege escalation.
“While AWS often
provides agents to run on customer-controlled EC2 instances to provide service functionality […] in all cases these agents run within the customer’s security boundary, and any and all associated AWS roles (and their credentials and permissions) are understood and designed to be fully accessible to customers,” an Amazon Web Services (AWS) spokesperson said in a statement.
AWS documentation further stated that the EC2 instance is the security boundary, not the container, and further clarified this in an update to its
“Security considerations for running containers on Amazon ECS” blog post following Sweet Security’s report on ECScape.
The ECScape exploit
A task on an Amazon ECS on EC2 instance, even one with low privileges, could impersonate the ECS agent and gain credentials for all running tasks on the instance in five steps, as described by Sweet Security.
First, the compromised container can gain the EC2 instance role credentials that the ECS agent uses for its API calls by querying the instance metadata service (IMDS), which is accessible by default.
Second, the attacker can then leverage these instance role credentials to discover the endpoint the ECS agent uses to connect to the ECS Agent Communication Service (ACS) and communicate with the ECS control plane. This can be done by calling the ECS API ecs:DiscoverPollEndpoint, which returns the endpoint URL.
In the third step, the attacker needs to gather a number of identifiers the agent would need to supply when communicating with the control plane in order to obtain the desired credentials for other tasks on the instance. These include the cluster Amazon Resource Name (ARN), container instance ARN, agent version information, docker version, ACS protocol version and sequence number.
Some of this information is available via the IMDS, but other information, namely the container instance ARN, must be obtained by calling the ECS agent’s introspection API using the credentials already obtained.
Once this information is obtained, the fourth step is to leverage these identifiers from Step 3, the endpoint from Step 2 and the instance role credentials from Step 1 to forge an ACS WebSocket connection request that appears as though it came from the legitimate ECS agent.
This request must be signed with AWS Signature Version 4 (SigV4) using the credentials from Step 1, which is possible in the default configuration, and the parameter sendCredentials=true is included to ensure the control plane returns the desired credentials.
Finally, the attacker leverages the forged WebSocket session to harvest task role credentials for running tasks on the instance, potentially gaining access to higher-privileged tasks, sensitive information leveraged by these tasks, as well as the ability to stop and start tasks, register new container instances in the cluster and more.
Mitigations and detection of Amazon ECS privilege escalation
As the EC2 instance is the only security boundary, AWS customers are responsible for managing risks within their ECS on EC2 environments, including across tasks and containers.
Sweet Security noted that disabling or limiting tasks’ access to IMDS nips this exploit in the bud, as a task cannot impersonate the ECS agent without the instance role credentials that are obtained from the IMDS.
Additionally, it is recommended not to host untrusted or low-privileged tasks on the same EC2 instance as high-privileged or sensitive tasks. If only similarly privileged tasks are hosted together, an attacker would not be able to use ECScape to escalate their privileges beyond what is contained within the same instance.
One of the most effective ways to prevent ECScape exploitation is to launch tasks using AWS Fargate, rather than EC2, as each task is isolated within its own micro-virtual machine (VM) when using the managed AWS Fargate option.
ECScape exploitation could be detected by using CloudTrail alerts to detect unusual identity access management (IAM) role usage, such as low-privileged tasks performing actions they would not normally be expected to.
Additionally, ECScape can be detected due to the compromised container making calls to the ECS API, which should only ever be contacted by the ECS agent itself. Unusual connections by containers to unexpected AWS endpoints should be investigated, as well as unusual behavior patterns, such as actions taken at odd hours or from unrecognized IP addresses.
