Haziz originally set out to build an eBPF-based real-time monitoring tool for ECS workloads. While doing so, he intercepted communication between the ECS agent and AWS backend as part of his debugging process, which is when he noticed the undocumented WebSocket channel.
From lowly tasks to privileged IAM roles
Thanks to the default availability of IMDS, any container (with low-level access) on an EC2-based ECS instance can read the instance role credentials intended for the ECS agent.
“No container breakout (no hostroot access) was required – however IMDS access was required via clever network and system trickery from within the container’s own namespace,” Haziz noted, adding that accessing IMDS lets any container impersonate an ECS agent. AWS has documentation on how to prevent or limit access to IMDS.
Armed with those instance role credentials, the attacker can forge communication over the ACS WebSocket. This allows them to intercept or request IAM credentials of other running tasks, even if those tasks are supposed to be isolated by IAM roles. Essentially, the compromised container escalates by masquerading as the orchestrator ECS agent responsible for managing and orchestrating tasks.
“The stolen keys (IAM credentials) work exactly like the real task’s keys,” Haziz said. “AWS CloudTrail will attribute API calls to the victim task’s role, so initial detection is tough – it appears as if the victim task is performing the actions.” This lets attackers be invisible in the logs because AWS thinks the victim is doing everything.