Cybersecurity researchers have demonstrated an “end-to-end privilege escalation chain” in Amazon Elastic Container Service (ECS) that could be exploited by an attacker to conduct lateral movement, access sensitive data, and seize control of the cloud environment.
The attack technique has been codenamed ECScape by Sweet Security researcher Naor Haziz, who presented the findings today at the Black Hat USA security conference that’s being held 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 said in a report shared with The Hacker News. “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.”
Amazon ECS is a fully-managed container orchestration service that allows users to deploy, manage, and scale containerized applications, while integrating with Amazon Web Services (AWS) to run container workloads in the cloud.
The vulnerability identified by Sweet Security essentially allows for privilege escalation by allowing a low-privileged task running on an ECS instance to hijack the IAM privileges of a higher-privileged container on the same EC2 machine by stealing its credentials.
In other words, a malicious app in an ECS cluster could assume the role of a more privileged task. This is facilitated by taking advantage of a metadata service running at 169.254.170[.]2 that exposes the temporary credentials associated with the task’s IAM role.
While this approach ensures that each task gets credentials for its IAM role and they are delivered at runtime, a leak of the ECS agent’s identity could permit an attacker to impersonate the agent and obtain credentials for any task on the host. The entire sequence is as follows –
- Obtain the host’s IAM role credentials (EC2 Instance Role) so as to impersonate the agent
- Discover the ECS control plane endpoint that the agent talks to
- Gather the necessary identifiers (cluster name/ARN, container instance ARN, Agent version information, Docker version, ACS protocol version, and Sequence number) to authenticate as the agent using the Task Metadata endpoint and ECS introspection API
- Forge and sign the Agent Communication Service (ACS) WebSocket Request impersonating the agent with the sendCredentials parameter set to “true”
- Harvest credentials for all running tasks on that instance
“The forged agent channel also remains stealthy,” Haziz said. “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 and immediately act with those privileges.”
ECScape can have severe consequences when running ECS tasks on shared EC2 hosts, as it opens the door to cross-task privilege escalation, secrets exposure, and metadata exfiltration.
Following responsible disclosure, Amazon has emphasized the need for customers to adopt stronger isolation models where applicable, and make it clear in its documentation that there is no task isolation in EC2 and that “containers can potentially access credentials for other tasks on the same container instance.”
As mitigations, it’s advised to avoid deploying high-privilege tasks alongside untrusted or low-privilege tasks on the same instance, use AWS Fargate for true isolation, disable or restrict the instance metadata service (IMDS) access for tasks, limit ECS agent permissions, and set up CloudTrail alerts to detect unusual usage of IAM roles.
“The core lesson is that you should treat each container as potentially compromiseable and rigorously constrain its blast radius,” Haziz said. “AWS’s convenient abstractions (task roles, metadata service, etc.) 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 – mechanisms which can have subtle weaknesses.”
The development comes in the wake of several cloud-related security weaknesses that have been reported in recent weeks –
- A race condition in Google Cloud Build’s GitHub integration that could have allowed an attacker to bypass maintainer review and build un-reviewed code after a “/gcbrun” command is issued by the maintainer
- A remote code execution vulnerability in Oracle Cloud Infrastructure (OCI) Code Editor that an attacker could use to hijack a victim’s Cloud Shell environment and potentially pivot across OCI services by tricking a victim, already logged into Oracle Cloud, to visit a malicious HTML page hosted on a server by means of a drive-by attack
- An attack technique called I SPy that exploits a Microsoft first-party application’s Service principal (SP) in Entra ID for persistence and privilege escalation via federated authentication
- A privilege escalation vulnerability in the Azure Machine Learning service that allows an attacker with only Storage Account access to modify invoker scripts stored in the AML storage account and execute arbitrary code within an AML pipeline, enabling them to extract secrets from Azure Key Vaults, escalate privileges, and gain broader access to cloud resources
- A scope vulnerability in the legacy AmazonGuardDutyFullAccess AWS managed policy that could allow a full organizational takeover from a compromised member account by registering an arbitrary delegated administrator
- An attack technique that abuses Azure Arc for privilege escalation by leveraging the Azure Connected Machine Resource Administrator role and as a persistence mechanism by setting up as command-and-control (C2)
- A case of over-privileged Azure built-in Reader roles and a vulnerability in Azure API that could be chained by an attacker to leak VPN keys and then use the key to gain access to both internal cloud assets and on-premises networks
- A supply chain compromise vulnerability in Google Gerrit called GerriScary that enabled unauthorized code submissions to at least 18 Google projects, including ChromiumOS (CVE-2025-1568, CVSS score: 8.8), Chromium, Dart, and Bazel, by exploiting misconfigurations in the default “addPatchSet” permission, the voting system’s label handling, and a race condition with bot code-submission timings during the code merge process
- A Google Cloud Platform misconfiguration that exposed the subnetworks used for member exchanges at Internet Exchange Points (IXPs), thereby allowing attackers to potentially abuse Google’s cloud infrastructure to gain unauthorized access to internal IXP LANs.
- An extension of a Google Cloud privilege escalation vulnerability called ConfusedFunction that can be adapted to other cloud platforms like AWS and Azure using AWS Lambda and Azure Functions, respectively, in addition to extending it to perform environment enumeration
“The most effective mitigation strategy to protect your environment from similar threat actor behavior is to ensure that all SAs [Service Account] within your cloud environment adhere to the principle of least privilege and that no legacy cloud SAs are still in use,” Talos said. “Ensure that all cloud services and dependencies are up to date with the latest security patches. If legacy SAs are present, replace them with least-privilege SAs.”
About The Author
Original post here
