A single compromised user account recently served as the entry point for attackers to breach multiple critical cloud systems. An investigation by Microsoft revealed that the adversary employed one identity to escalate access into Azure DevOps, development pipelines, and Kubernetes resources. The breach relied not on novel malware or software vulnerabilities, but on abusing legitimate permissions and cloud services commonly trusted by organizations.
How Attackers Escalated Access
Identified by Microsoft under the name Storm-3068, the attackers gained control of one account via a self-service password reset (SSPR). They then registered their own authentication methods to maintain persistent access. Once inside, the intruders used existing privileges to survey Azure DevOps projects, repositories, and deployment environments. This allowed them to map connected services and see where credentials and infrastructure access were stored across pipelines.
From that vantage point, they established a malicious pipeline designed to harvest Kubernetes credentials at scale. They deployed a kube agent and ran jobs to extract cluster configuration files, then stashed seven such files in a repository—enabling direct access to Kubernetes clusters. The attacker also modified pipeline scripts to deploy a remote management agent (Atera) and a tunneling utility (Chisel), creating alternative remote channels into the infrastructure. One instance of Chisel established a reverse tunnel to an external IP address.
Detection, Response, and Defensive Measures
Forensics were built from a combination of Azure DevOps audit logs, Git version history, and identity system records. This helped track how the malicious pipelines were introduced and how credentials were stolen. Microsoft’s response team, including DART and its Threat Intelligence group, collaborated directly with the impacted organization through daily briefings, containment guidance, and recommendations to reduce risk.
Recommended defense steps include closely monitoring password-reset activity (especially self-service workflows), reducing exposure of privileged accounts to these reset options, and implementing phishing-resistant multifactor authentication. Within DevOps, teams should enforce code‐review policies like branch protection and restrictions on direct commits to sensitive branches. Pipeline permissions need to be carefully scoped so that only authorized personnel can create, modify, or execute workflows. Applying least-privilege across identities, development tools, and cloud resources is crucial, as is regular auditing of linked platforms and access paths.
This incident underscores how developers’ tools and cloud services, often seen simply as productivity utilities, are now prime targets. When one compromised identity can lead to source code and infrastructure credentials, organizations must rethink their security around DevOps and cloud environments.
