Cybersecurity researchers have demonstrated an “end-to-end privilege escalation chain” with Amazon Elastic Container Services (ECS). This could be exploited to attackers to access horizontal movements, access sensitive data and seize control of the cloud environment.
The attack technology was called Ecscape by sweet security researcher Naor Haziz.
“We have identified ways to exploit undocumented ECS internal protocols to obtain AWS credentials belonging to other ECS tasks on the same EC2 instance,” Haziz said in a report shared with Hacker News. “Malicious containers with low-minded IAM (ID and Access Management) roles can obtain permission for high-privilaid containers running on the same host.”
Amazon ECS is a fully managed container orchestration service that integrates with Amazon Web Services (AWS) to enable container workloads to run in the cloud.
The vulnerability identified by Sweet Security essentially allows privilege escalation by allowing the modest tasks running on ECS instances to be able to steal and hijack IAM privileges of the same EC2 machine’s IAM privileges.
In other words, malicious apps in ECS clusters may assume the role of a more privileged task. This is facilitated by utilizing a metadata service running on 169.254.170 (.)2 which exposes temporary credentials related to the task’s IAM role.
This approach ensures that each task retrieves IAM role credentials and is delivered at runtime, but leaks of the ECS agent identity could allow an attacker to impersonate an agent and retrieve credentials for any task on the host. The entire sequence is as follows:
- Impersonate an agent to get host IAM role credentials (EC2 instance role)
- Discover the ECS control plane endpoints that the agent speaks
- Collect the required identifiers (cluster name/ARN, container instance ARN, agent version information, Docker version, ACS protocol version, and sequence number) and authenticate as an agent using the task metadata endpoint and ECS introspection API
- Sign the request of Agent Communication Services (ACS) impersonating an agent with AndCredentials parameter set to “true”
- Harvest the credentials for all running tasks on that instance
“The counterfeit agent channel remains stealth too,” Hazes said. “Our malicious sessions mimic the expected behavior of agents: message recognition, sequence number increase, heartbeat sending – nothing is found.”
“Making it as an agent’s upstream connection, Ecscape completely disrupts its trust model. One compromised container can passively collect IAM role credentials for all other tasks on the same EC2 instance and act immediately with those privileges.”
ECSCAPE can have serious consequences when running ECS tasks on a shared EC2 host. This is to open the door to cross-task privilege escalation, secret exposure, and metadata peeling.
Following responsible disclosure, Amazon highlights the need for customers to adopt a stronger separation model as applicable, making it clear in its document that EC2 does not have task separation and that “containers may have access to credentials for other tasks on the same container instance.”
As a mitigation, we recommend avoiding the deployment of high-effective tasks along with unreliable or modest tasks on the same instance. Use AWSFargate for true isolation, disable or restrict Instance Metadata Services (IMDS) access for tasks, restrict permissions for ECS agents, and register CloudTrail Alerts.
“The core lessons mean that each container must be treated as potentially compromised and strictly constrained the radius of that blast,” Hazes said. “While AWS’s handy abstractions (task roles, metadata services, etc.) make life easier for developers, when multiple tasks at different privilege levels share the underlying host, security is only as strong as the mechanisms that separate them.
This development is triggered by several cloud-related security weaknesses reported in recent weeks –
- The race state of Google Cloud Build’s GitHub integration could have allowed an attacker to bypass the maintainer’s review and construct unconsidered code after the “/gcbrun” command was issued by the maintainer.
- Remote code execution vulnerability in the Oracle Cloud Infrastructure (OCI) code editor that attackers can use to hijack a victim’s cloud shell environment. By tricking victims already logged in to Oracle Cloud, it potentially pivots across the OCI service and potentially pivots by accessing malicious HTML pages hosted on the server for a drive-by attack
- For attack techniques called I Spy, which utilizes Microsoft First-Party Application’s Service Principal (SP) with ENTRA IDs, and for privilege escalation via federated authentication.
- Privilege escalation vulnerability in Azure Machine Learning services. Allow attackers with only storage accounts to modify Invoker scripts stored in AML storage accounts, to execute arbitrary code within the AML pipeline, extract secrets from Azure Key Vaults, escalate privileges, and gain broad access to cloud resources
- Legacy scope AmazonguarddutyfullaccessManagedpolicy that may enable full organizational acquisitions from compromised member accounts by registering any delegated administrator
- By leveraging the role of the Azure Connected Machine Resource Administrator, it can be used as an attack technique that abuses Azure Arc for privilege escalation and as a persistent mechanism by setting it up as a command and control (C2).
- The main attractive Azure built-in leader roles and vulnerabilities cases of Azure APIs that can be chained by attackers so that attackers can leak VPN keys and use the key to access both internal cloud assets and on-premises networks
- A supply chain that compromises the Google Gerrit vulnerability, called Google Gerrit, has enabled fraudulent code submissions to at least 18 Google projects, including Chromiumos (CVE-2025-1568, CVSS score: 8.8), Chrom, Dart, and Bazel. Timing of code submission during the code merge process
- The misconception of the Google Cloud Platform, which exposed the subnetwork used for member exchanges at Internet Exchange Points (IXPs), allows attackers to potentially exploit Google’s cloud infrastructure to gain unauthorized access to their internal IXP LANs.
- A vulnerability called the Google Cloud Privilege Extension Vulnerability can be adapted to other cloud platforms such as AWS and Azure, using AWS lambdas and Azure functions, respectively.
“The most effective mitigation strategy to protect your environment from the actions of similar threat actors is to ensure that all SAS (service accounts) within a cloud environment adhere to the principle of least privilege and that legacy cloud SAS is not yet in use,” Talos said. “Make sure all cloud services and dependencies are up to date with the latest security patches. If legacy SAS is present, replace them with minimal SAS.”
