Summary
- Storm-3068 took control of a user identity following a successful self-service password reset and registered new authentication methods.
- The actor enumerated Azure DevOps resources and created a malicious pipeline designed to collect Kubernetes credentials.
- The pipeline had access to more than 50 resources and authenticated services, showing how automation can amplify one identity compromise.
A single compromised user identity expanded into access across development pipelines and Kubernetes infrastructure after an attacker abused legitimate cloud services rather than malware or a software exploit, according to Microsoft.
The incident began when the actor tracked as Storm-3068 gained access to a user account following a successful self-service password reset. The attacker then registered its own authentication methods, establishing persistent control over the identity.
From there, Storm-3068 moved into Azure DevOps and used legitimate administrative tools and automated scripts to enumerate repositories, projects, pipelines, and deployment environments.
Microsoft’s investigation found that the attacker created a malicious development pipeline designed to harvest Kubernetes credentials at scale. The pipeline deployed a Kubernetes agent and ran jobs intended to collect kubeconfig files containing cluster connection details and authentication information.
The pipeline was authorised to access more than 50 resources and authenticated services.
The attacker also modified pipeline scripts to install the Atera remote-management agent and download the Chisel tunnelling utility.
No novel software vulnerability was required. The intrusion relied on a valid identity, legitimate recovery mechanisms, an authorised development platform, and permissions already attached to automation inside the environment.
That combination exposes an important structural risk in cloud estates. Source-code platforms and continuous integration systems are no longer isolated developer tools. They routinely hold deployment credentials, cloud identities, service connections, secrets, and automated paths into production.
A pipeline can therefore operate as a privileged machine identity. A job authorised to deploy applications into Kubernetes may be able to retrieve credentials or reach services that no individual developer normally accesses directly.
That can make the effective privilege of a compromised account much greater than its visible user permissions. If the account can modify or launch trusted automation, the attacker may inherit everything that automation is allowed to do.
The password-reset element also places account recovery inside the authentication boundary. Multi-factor authentication can provide strong protection during normal sign-in but still be undermined if an attacker can seize an account through a recovery process and then register replacement authentication methods.
The relevant control question is therefore broader than whether MFA is enabled. Organisations need to understand who can initiate recovery, what evidence is required, how new authentication methods are monitored, and whether development identities with production reach are subject to stronger recovery rules.
Development platforms require the same scrutiny. Rights to edit pipelines, approve deployments, use service connections, or retrieve secrets can carry production-level consequences even where the account itself is labelled as a development identity.
Microsoft’s case does not establish that every Azure DevOps environment exposes the same path. It demonstrates how tightly connected identity, source code, deployment automation, and cloud infrastructure can allow one compromised account to cross layers without exploiting a vulnerability in any of them.
The incident ultimately reflects accumulated trust. Once Storm-3068 controlled an identity capable of manipulating automation, the organisation’s own development machinery provided the route towards Kubernetes and the resources behind it.
