Overview
A Microsoft incident investigation has demonstrated how a single compromised identity can expand into access across development pipelines, cloud services and Kubernetes infrastructure. The threat actor, tracked as Storm-3068, gained control of an account through a self-service password reset and then registered additional authentication methods to maintain persistent access.
What followed did not depend on malware or a new software vulnerability. Instead, the attacker used legitimate Azure DevOps functionality, existing permissions and trusted connections between development and production environments. The incident demonstrates how identity compromise can become significantly more dangerous when DevOps platforms sit at the intersection of source code, automation, credentials and cloud infrastructure.
From One Account to the Development Environment
After compromising the account, Storm-3068 used legitimate administrative tools and automated scripts to examine Azure DevOps repositories, projects, pipelines and deployment environments. This allowed the attacker to understand how the organisation’s development systems connected to broader cloud resources and identify where useful credentials and service connections could be accessed.
Azure DevOps therefore provided much more than access to source code. Repositories, pipeline configurations, deployment settings and service connections effectively created a map of the organisation’s trusted relationships. Once an attacker understands those relationships, the development platform can become a bridge towards systems that would otherwise be considerably more difficult to reach.
Trusted Pipelines Became the Attack Path
The attacker created a malicious pipeline designed to collect Kubernetes credentials at scale. Microsoft found that the pipeline was authorised to interact with more than 50 resources and services, allowing jobs to search for kubeconfig files containing authentication and cluster connection information.
Investigators ultimately identified seven stolen Kubernetes configuration files that had been placed into an Azure DevOps repository. These credentials could provide access to targeted Kubernetes clusters, demonstrating how development automation can unintentionally become a mechanism for expanding an intrusion into production infrastructure.
Storm-3068 also modified pipeline scripts to deploy the Atera remote-management agent and the Chisel tunnelling utility. These tools were intended to provide alternative remote-access channels and potentially expose Kubernetes API services through reverse tunnels.
Identity Security Must Extend Into DevOps
The incident highlights why identity protection cannot stop at Microsoft Entra ID authentication. Once an identity is successfully compromised, every platform and resource accessible by that identity becomes part of the potential attack path.
Phishing-resistant MFA, stronger controls around password-reset workflows and monitoring for unexpected authentication-method registration can reduce the initial identity risk. Development environments require additional protection through branch controls, change approvals, restricted pipeline permissions and careful management of service connections.
Least privilege should extend across the complete chain from identity to DevOps platform, pipeline and production infrastructure.
Expert in the Cloud Insight
Storm-3068 demonstrates how the modern cloud attack surface is increasingly defined by relationships between trusted systems.
An account may not have direct administrative access to Kubernetes, but access to a development pipeline connected to Kubernetes can provide another route towards the same environment. The risk therefore lies not only in individual permissions, but in what those permissions can trigger through automation.
The security question should no longer be limited to “What can this user access?” It should also consider “What can the systems trusted by this user access on their behalf?”
In tightly integrated cloud environments, one compromised identity can inherit the reach of repositories, pipelines, service connections and deployment platforms.
Identity is no longer simply the front door to the cloud. In modern DevOps environments, it can become the pathway through the entire architecture.
Leave a Reply