Resources the malicious pipeline was authorized to access: 50+ (Source: Microsoft Security, DART Cyberattack Series (September 29, 2026))
The pipeline does what it is told
A build pipeline is a company's most obedient employee. It holds permissions to many systems. It runs whatever its instructions say. That makes it a useful target. An attacker who edits the instructions does not need to break anything. The pipeline does the work.
That is the lesson of a case Microsoft's Detection and Response Team (DART) described on September 29, 2026. It is one incident, not a trend. But it shows where the keys to a cloud environment can sit. They can sit in the tools that ship the code, not only in the code.
What Microsoft found
DART investigated a threat actor it tracks as Storm-3068. The actor got into a user account by abusing the company's self-service password reset. Then it locked in control. It did this by adding its own sign-in methods to the account.
Next, the actor turned to Azure DevOps. This is Microsoft's platform for code repositories and build pipelines. The actor used real admin tools and scripts to list the repositories, projects, pipelines and deployment environments. In effect, it drew a map of how the organization ships software.
How the attack worked
Storm-3068 built a malicious pipeline. Its job was to collect Kubernetes credentials in bulk. Kubernetes runs applications in the cloud. A kubeconfig file tells a user or tool how to connect to a cluster and prove who they are. Whoever holds one can act as its owner.
The pipeline ran several jobs to gather those files. It ran with the permissions of the compromised account. Microsoft says it was cleared to reach more than 50 resources and sign in to services.
The actor also edited existing pipeline scripts. One edit installed Atera, a remote management agent. Another downloaded Chisel, a tunneling tool. Microsoft says the aim was to create other ways back in and to expose the Kubernetes API server.
The Chisel commands opened a tunnel that connected out to an outside IP address. Microsoft says this could let the actor interact with the clusters remotely.
To trace what came next, investigators read two records. One was the Azure DevOps audit log. The other was the Git history, which logs every change to the code. Together they showed the actor saving seven stolen kubeconfig files in a repository. Those files held the credentials needed to reach the targeted clusters.
Where the risk really sat
The password reset was the front door. But the damage came from how closely the systems were linked. Microsoft calls Azure DevOps a high-value target. It sits where identity, software development and cloud operations meet.
The reason is simple. Repositories, pipelines, service connections and deployment settings show an intruder how the rest of the environment fits together. They work like a map.
Consider an organization where one team owns identity, another owns developer tools and a third owns cloud infrastructure. This case suggests a gap there. The attacker ignored those lines. The permissions that connect the three are the shared risk, and no single team may own them from end to end. That is our interpretation, not a finding Microsoft states.
The report has limits. Microsoft does not say how the actor completed the password reset. It calls the tunnel a way to enable "potential" remote interaction. So the post does not confirm what happened inside the clusters. The account also comes from the vendor whose team ran the response.
Questions to put to your teams
Microsoft's recommendations make a useful checklist. Turn them into questions with owners and dates.
Can we spot repeated password reset attempts, or resets aimed at many users? Are privileged accounts kept out of self-service reset? Do they require phishing-resistant multifactor authentication? Can anyone commit straight to critical branches, or do changes need approval and branch protection? Who can create, change or run a pipeline? Does any one identity hold access across identity, development and cloud systems? Is that access limited to the minimum it needs?
One more question follows from the case. If an attacker edited a pipeline tonight, which secrets could it read? Trust in the pipeline is only as strong as the account that can change it.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Microsoft Security.
