In a post published on October 19, Alibaba Cloud's security team says it handled multiple customer incidents over recent months in which Access Keys leaked through public code repositories, frontend JavaScript files and CI/CD variable settings. Once defences were switched on, the team says the activity did not stop but intensified: second-level retries, immediate path switching after a block, enumeration across all regions, and self-adjustment after failures. The write-up breaks the intrusion into eight stages: credential acquisition, identity mapping, cross-domain resource enumeration, privilege escalation and persistence through AssumeRole and freshly created RAM users, command dispatch through the Cloud Assistant API, payload deployment with command-and-control channels, data exfiltration by widening database whitelists and bucket permissions, and anti-forensic cleanup. The team notes that the privilege-escalation and command-channel stages run almost entirely at the cloud API layer, where host and network monitoring, and most SOC rules, do not see them. It also cites a July incident at Hugging Face in which an AI agent made more than 17,600 attempts over 4.5 days, arguing that a single success is enough.
Our takeThe claim worth taking seriously is that the control plane, not the host, is now the attack surface: an AssumeRole call or a batch Cloud Assistant dispatch opens no port and leaves no process tree, so host agents and network segmentation have nothing to match. If ordinary SOC rules rarely cover this, detection has to move to sequences of API calls and the identities behind them. Caveat: the incidents are the vendor's own account, and 17,600 attempts counts tries, not distinct techniques.