One password reset let Storm-3068 run an Azure DevOps pipeline that pulled kubeconfig files

A pipeline in Azure DevOps runs under a service connection that holds the credentials its build steps use to reach cloud resources, so whoever can execute or modify that pipeline inherits the permissions it was given ^[17]. The connection Storm-3068 used was authorized to more than 50 targets ^[4]. Microsoft's Defender Experts, who published the account on 29 September 2026, are careful with that number: it counts authorized targets, not resources actually compromised ^[16][7]. They also note the 50-plus was what they saw at this victim, not a condition the attack required ^[8].

What the credentials allow and what the jobs did are separate questions. Storm-3068 ran jobs named DUMP_CLUSTER_<NAME>, pulled kubeconfig files, and committed seven of them into a kubeconfigs directory in an existing repository ^[5][6]. A kubeconfig carries a ServiceAccount token that authenticates to the Kubernetes API ^[9]. To act on that token, the connecting system needs the API server reachable, a token the server still accepts, and authorization for each requested operation ^[9]. The report says holding a ServiceAccount token does not by itself grant cluster-wide administrative privileges ^[10]. The next move fits that limit: the actor ran the Atera agent and Chisel from the pipeline to relay API traffic through an external tunnel, though how much the tunnel carried has not been disclosed ^[11].

The way in was ordinary. With a valid session from the reset, the actor enumerated the tenant the way an administrator would, walking repositories, projects, pipelines, deployment environments and connected resources through legitimate features and scripts ^[3]. The report does not say what verification information the reset flow accepted ^[14].

Detection is uneven. The account owner might catch the reset, the missing MFA method or the new device, but pipeline activity is quiet to someone who never opens Azure DevOps ^[15].