How one password reset gave hackers the keys to a company's cloud

Key points

• Microsoft's Detection and Response Team says a group it tracks as Storm-3068 broke into a company by abusing a self-service password reset, then pivoted into Azure DevOps and Kubernetes clusters.
• The attackers built a malicious build pipeline that used the hijacked account's rights to reach more than 50 connected resources and harvest cluster credentials at scale.
• Seven stolen kubeconfig files, small text files that hold the keys to a Kubernetes cluster, were checked into a code repository during the intrusion.
• The intruders installed the legitimate Atera remote management tool and the Chisel tunnelling utility to keep a way back in, rather than dropping custom malware.
• Microsoft's investigators reconstructed the attack from Azure DevOps audit logs and Git version history, working with the customer through daily briefings.

A single forgotten password. That was the whole opening.

Microsoft's incident responders have published a case study of an intrusion they attribute to a cluster they track as Storm-3068, in Microsoft's weather-themed threat actor naming system. The "Storm" prefix means Microsoft hasn't yet linked the activity to a known criminal or state-backed group with high confidence. Treat the attribution as a working label, not a verdict.

What matters is the path the intruders took, because it didn't involve a single piece of malware or a software flaw.

How did the attackers get in?

They got in through a self-service password reset, the same online form that lets a normal employee recover a forgotten password without calling the help desk. We covered this vector on 17 September, when criminals were already pivoting to the humans who manage authentication rather than the technology itself. Once inside the account, Storm-3068 registered their own multifactor authentication method, the second login step meant to prove you are who you say you are, and locked the real user out of that control.

From there, the account looked legitimate to every system it touched.

What did they do with that access?

The hijacked identity had access to Azure DevOps, Microsoft's platform for storing source code and running the automated pipelines that build and deploy software. Storm-3068 used ordinary administrative tools and scripts to list every repository, project and deployment target the account could see.

Then they built a pipeline of their own.

That malicious pipeline deployed a small program called a kube agent and ran jobs designed to collect kubeconfig files. A kubeconfig is the file a developer uses to authenticate to a Kubernetes cluster, the system many companies use to run their production applications. Because the compromised account was trusted, the pipeline was allowed to talk to more than 50 resources and services. Seven stolen kubeconfig files were then committed into a repository, giving the attackers a tidy stash of cluster keys.

Did they plant malware?

Not really, and that's the point. The pipeline was modified to install Atera, a commercial remote management tool used by IT support firms, and to download Chisel, a free tunnelling utility that can punch a connection back out through a firewall. Chisel was then used to open a reverse tunnel to an outside IP address, exposing the Kubernetes API server to the attackers.

Both tools are legal, unlikely to trip a basic antivirus scan, and built for purposes most IT teams would recognise. That's why intruders reach for them.

Should you worry?

My read, after a lot of these DevOps intrusions: the interesting target was never the code. It was the trust the code platform holds on behalf of everything downstream.

Microsoft's hardening advice is worth reading in full, but the short version is practical. Watch password reset activity for odd patterns. Keep privileged accounts out of self-service reset flows and require phishing-resistant multifactor authentication for them. Require review and approval for code changes, and lock down who can create or run build pipelines. Give every identity only the access it actually needs, whether that identity belongs to a person or a machine.

None of that is new. This case is a reminder of what happens when it's skipped.