Microsoft showed that compromising a single identity can become a broad access path within development and cloud environments, even without using malware or exploiting vulnerabilities. In a new report in the Cyberattack Series, the Microsoft Detection and Response Team (DART) documented Storm-3068’s movement from a compromised account to Azure DevOps, development pipelines, and Kubernetes resources.
The intrusion began through a self-service password-reset process. After gaining access to the user account, the attacker registered their own authentication methods, giving them persistent access to the identity. They then used legitimate administrative tools and automated scripts to inventory repositories, projects, pipelines, and deployment environments in Azure DevOps.
From Identity to Deployment Pipelines
Azure DevOps was a high-value point because it connects identity, software development, and cloud operations. By mapping deployment pipelines and the resources associated with them, Storm-3068 identified ways to move into other parts of the environment.
Investigators discovered a malicious pipeline designed to collect Kubernetes credentials at scale. The pipeline deployed a Kubernetes agent and performed multiple jobs to collect kubeconfig files containing cluster connection details and authentication data. Because of the compromised account’s permissions, the pipeline was authorized to access more than 50 resources and authenticate to various services.
Pipeline scripts were also modified to install the Atera remote-management agent and download the Chisel tunneling tool. Chisel commands were used to create a reverse tunnel to an external IP address, potentially enabling remote interaction with Kubernetes clusters. The investigation team reconstructed the next stage of the attack using Azure DevOps audit logs and the Git version history, where seven stolen kubeconfig files had been added to a repository.
What Does the Case Reveal to Defenders?
The incident’s significance lies in the fact that the initial compromise alone was not sufficient to explain the extent of the final access. The risk arose from the interconnection between identity systems, repositories, build and deployment pipelines, and operational infrastructure. Therefore, securing each layer in isolation does not guarantee containment of a compromised account if its permissions open trusted paths to subsequent layers.
DART responded by analyzing data from identity systems, development platforms, and cloud infrastructure, and worked with the customer through daily briefings and prioritized guidance for containment and remediation. It also collaborated with Microsoft Threat Intelligence to place the activity in its broader context.
Practical Defensive Measures
- Monitor password-reset activity for repeated attempts or patterns targeting multiple users.
- Reduce the exposure of highly privileged accounts to self-service reset paths and enforce phishing-resistant multifactor authentication.
- Require approval for code changes and enable branch protection to prevent unauthorized modifications.
- Restrict direct commits to critical branches and require changes to undergo clear review and approval.
- Control build and deployment pipeline permissions and define who can create, modify, or run them.
- Apply the principle of least privilege to identities, development platforms, and cloud resources to limit the impact of a single account compromise.
Why Does This News Matter?
This case shows that identity, Azure DevOps, Git, and Kubernetes environment logs must be read as an interconnected security picture, not as separate sources. The open questions established by the source concern organizations’ ability to detect the misuse of legitimate tools, review cross-environment permissions, and prevent credential files from leaking into repositories before they are used to access production.