Microsoft says attackers turned a password reset into a route through cloud infrastructure

A compromised account gave the threat actor Microsoft calls Storm-3068 a route from a self-service password reset into Azure DevOps, development pipelines and Kubernetes resources, according to Microsoft. The company says attackers used a malicious pipeline to collect Kubernetes credentials, showing how a single identity can bridge code and cloud infrastructure.

Microsoft AI Watch analysis

What happened

Microsoft’s Detection and Response Team says Storm-3068 took control of an account by registering its own authentication methods after a self-service password reset. The attackers then used legitimate administrative tools and scripts to map repositories, pipelines and deployment environments in Azure DevOps.

Microsoft says a malicious pipeline was authorised to access more than 50 resources and was used to harvest Kubernetes configuration files. The company also describes attempts to install remote-management and tunnelling tools. It says investigators used audit logs and Git history to reconstruct the activity.

Why it matters

Development platforms can connect identities, source code, deployment pipelines and production infrastructure. If an account with broad permissions is compromised, those trusted links can become an attacker’s route onwards, without the intrusion starting with malware or a software exploit.

Microsoft’s report sets out practical safeguards: use phishing-resistant multifactor authentication for privileged accounts, review password-reset activity, require approval for code changes, protect critical branches, restrict who can create or run pipelines, and apply least-privilege access across connected systems.

Our read

The uncomfortable lesson is that a pipeline can be both a delivery mechanism and a credential cupboard. Organisations should check who can change or run their pipelines, what those pipelines can reach, and whether changes to critical branches need review. These are Microsoft’s findings from its investigation, not an independently established account of the incident.

What to watch

• Whether Microsoft publishes further detail about the affected customer or the incident’s impact.
• Whether organisations review pipeline permissions and credentials exposed to build or deployment jobs.
• Whether account-reset and privileged-access policies are tightened alongside code-review controls.

Discussion spark: Should organisations prioritise tighter identity controls, or restrict what development pipelines can access even when an account is compromised?

not affiliated with or endorsed by Microsoft