Security1 publisher2 min readPublished
Storm-3068 turned a self-service password reset into a Kubernetes credential harvest
Storm-3068 hijacked one account via self-service password reset and ran an Azure DevOps pipeline authorized for 50-plus resources, Microsoft says. No exploit was involved, so the fix sits in the reset flow and in what one account's pipelines can reach.
The Watch · Security desk
What happened
- After the reset, Storm-3068 registered its own authentication methods on the account, taking full control of the identity and keeping access.
- The malicious pipeline deployed a kube agent and ran jobs to collect kubeconfig files holding cluster connection and authentication details.
- The actor committed seven stolen kubeconfig files to a repository, giving it the credentials for the targeted Kubernetes clusters.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure Accounts that can be reset through SSPR and can also create Azure DevOps pipelines are the exposed population, since a pipeline they deploy inherits what that identity is authorized to touch.
- constraint Detection built around malicious binaries had little to see at entry and reconnaissance; the usable evidence here lived in identity events and DevOps audit records.
- decision Defenders now have to choose whether SSPR should cover accounts with pipeline or DevOps admin rights, and whether a reset followed by new method registration holds access until reviewed.
- cost Recovery extends past the hijacked account to rotating credentials for every cluster whose kubeconfig was collected and removing Atera and Chisel wherever the pipeline installed them.
Storm-3068 needed two things, and one account supplied both. The actor had to complete a self-service reset on it [1]. The account then had to hold enough Azure DevOps permission to deploy a pipeline, because the later stages ran on that account's own rights [7].
Microsoft ties persistence to the step after the reset, when the actor registered its own authentication methods on the identity [2]. Enumeration of repositories, projects, pipelines and deployment environments came next, run with legitimate administrative tools and automated scripts [4]. That order put two identity events ahead of any DevOps activity: a reset, then new methods on the same account [2]. The first defence on Microsoft's list is monitoring password reset activity for unusual patterns [12].
Azure DevOps was the high-value target, Microsoft wrote, because it sat at the intersection of identity, software development and cloud operations [5]. The malicious pipeline's authorization came from the hijacked account's own permissions [7]. Scoping those permissions is the second place this chain can be cut. A narrower grant limits what kube agent jobs like these can collect [6].
According to Microsoft, the actor relied on legitimate identity and cloud services instead of malware or software exploits [3]. That description fits entry and reconnaissance. The later stage brought in outside tools, the Atera remote management agent and the Chisel tunneling utility, through modified pipeline scripts [8]. Chisel then opened a reverse tunnel to an external IP address, aimed at the Kubernetes clusters [9]. That tunnel needed outbound network access from wherever the pipeline executed [9].
DART, the team behind Microsoft Defender Experts incident response [15], rebuilt the kubeconfig stage from Azure DevOps audit logs and Git version history [11]. The stolen kubeconfigs had been committed to a repository [10], so the record of the theft and the credentials themselves sat in the same Git history [10][11].
Microsoft calls this a growing challenge wherever identities, source code, pipelines and production environments are tightly linked [13]. DART worked with Microsoft Threat Intelligence to place the activity in a broader threat context [14]. Microsoft did not publish that context: its account does not identify the customer, date the intrusion, explain how the reset was obtained, or link Storm-3068 to other victims [1]. On the public record, this is one intrusion by one actor [1].
What to watch
- Whether Microsoft's full report or a later Threat Intelligence post ties Storm-3068 to other organizations or gives a timeline for this intrusion.
- How Storm-3068 got through the self-service reset; the method would show whether the weak step was the verification factor or the reset policy itself.
- The rest of Microsoft's recommendations beyond password-reset monitoring, especially any guidance on pipeline permission scope.