A single password reset was enough. According to the Microsoft Security Blog DART Cyberattack Series write-up on 29 September 2026, Storm-3068 abused self-service password reset on a workforce user account, registered its own authentication methods, removed the legitimate user's MFA methods, and then used that owned identity inside Azure DevOps. Malicious pipelines harvested kubeconfig files from more than 50 resources. Seven of those kubeconfigs landed in a repository. No malware was required for the opening move. Legitimate identity recovery and legitimate DevOps features did the work.
Public reporting does not name the victim organization. Public reporting does not establish the exact prior knowledge or social-engineering step used to start the SSPR flow. What Microsoft did document is enough to map the chain: recovery first, MFA lifecycle second, development platform third, Kubernetes credentials last.
How SSPR turned into full identity ownership
Storm-3068's initial access was not a malware drop and not a software exploit. According to Microsoft, the actor gained access through a successful self-service password reset on a user account. That reset changed the password and transferred practical ownership of the identity to whoever completed the recovery path.
SSPR exists so employees can recover without a ticket queue. That convenience is also an attack surface. Once the reset succeeded, the attacker held the new password and could sign in as the user. Authentication after that point was authentic for the platform and fraudulent for the organization.
Microsoft's investigators framed the lesson bluntly. "What began as a single compromised identity quickly expanded into an organization's development and cloud environments." The expansion did not need a second break-in. It needed the rights already attached to that identity and the systems that trusted it.
Public reporting does not establish whether the actor already knew enough personal data to pass SSPR challenges, whether a helpdesk path fed the reset, or whether another recovery weakness was involved. The documented fact is simpler and worse: the recovery workflow completed, and identity control moved.
That is a credential-phase failure at recovery. The password the attacker set was a transferable secret. Nothing about the subsequent MFA prompts fixed the fact that the account password now belonged to Storm-3068.
When MFA started protecting the attacker
Password ownership was only the first half of persistence. After the SSPR success, Storm-3068 registered its own authentication methods and removed the legitimate user's MFA methods. From that moment, MFA still "worked." It worked for the wrong principal.
Every later sign-in could look clean in logs that only check whether a second factor completed. The factor that completed was the attacker's. The real user was locked out of their own methods. Microsoft's summary is explicit that the actor established persistent control of the identity this way, without needing malware for that stage either.
This is the recovery and enrollment gap that password-plus-OTP or password-plus-push deployments leave open. If a reset path can hand someone a new password, and if that someone can then add authenticators and delete the old ones, MFA becomes a lock on a door the attacker already re-keyed. The cryptography of the second factor never gets a fair fight because the lifecycle step before login was weak.
| Control | What happened here | Why it failed |
|---|---|---|
| SSPR / recovery | Password reset completed for attacker | Reset path did not bind to unphishable user proof |
| Existing MFA methods | Removed after takeover | Enrollment allowed attacker-controlled replacement |
| New MFA methods | Registered by Storm-3068 | MFA then guarded attacker identity, not the employee |
| Azure DevOps access | Used with owned identity | Platform trusted the compromised account |
Microsoft recommended monitoring anomalous SSPR activity and requiring phishing-resistant MFA especially for privileged accounts, plus limiting privileged exposure to SSPR workflows. Those recommendations sit on top of a design problem: recovery that can mint a new password and new factors without strong binding is identity transfer, not user assistance.
Related workforce recovery failures keep showing the same class of problem. The M&S helpdesk password-reset social engineering case also started with identity recovery abuse rather than a clever exploit against login crypto. Different industry, same lesson: if IT or self-service can be steered into handing over a reset, the rest of the stack follows the new owner.
Azure DevOps pipelines and the kubeconfig harvest
With the identity under attacker control, Storm-3068 moved into Azure DevOps using legitimate tools and scripts. According to Microsoft, the actor enumerated repositories, projects, pipelines, and deployment environments. Then it created a malicious pipeline that deployed a kube agent and harvested kubeconfig files from more than 50 resources.
Those kubeconfigs are post-authentication artifacts. They hold Kubernetes credentials. Once the pipeline ran under the compromised identity's authority, no extra MFA prompt at the cluster edge undid the harvest. Seven stolen kubeconfig files were added to a repository. Pipeline scripts were modified to install Atera RMM and download Chisel. Chisel supported a reverse tunnel aimed at exposing Kubernetes API access.
Microsoft put the technique in plain language: "Rather than deploying malware, the threat actor modified development pipelines to collect Kubernetes credentials and expand access into cloud infrastructure." The same post notes that a single compromised identity can reach development platforms, cloud resources, and production environments when those systems are tightly connected. The callout line is shorter still: "Identities are the new attack path."
DART investigated with identity, DevOps, and cloud telemetry, disrupted access, and published hardening guidance with the 29 September 2026 disclosure. Public reporting does not establish how many people or records were affected beyond the technical counts Microsoft gave for resources and kubeconfigs. Public reporting does not establish a ransom demand.
The SSPR abuse and the MFA method swap are credential and lifecycle failures. Closing weak recovery and attacker re-enrollment stops those phases. The kubeconfig theft and pipeline misuse are what happens after the identity is already attacker-owned. No login ceremony reverses a pipeline that already ran with legitimate permissions. Revocation, pipeline review, least privilege on service connections, and credential rotation are containment for that stage, not a rewrite of the opening.
If you want to skip the attack details and go straight to what can stop the recovery and enrollment path, read the related article on mfa2point0.com: how hardened SSPR and phishing-proof enrollment block Storm-3068-style identity takeover.
FAQ
How did Storm-3068 get into the environment in the first place?
Storm-3068 got in by successfully abusing self-service password reset on a workforce user account, according to Microsoft's DART Cyberattack Series disclosure on 29 September 2026. The reset let the actor set a new password and take ownership of the identity. Public reporting does not establish the exact social-engineering or prior-knowledge step that started SSPR. No malware was required for that initial access.
Did MFA fail during the Storm-3068 Azure DevOps intrusion?
MFA failed at the lifecycle layer after SSPR, not as a mysterious cryptographic break. Storm-3068 registered its own authentication methods and removed the legitimate user's MFA methods. After that swap, MFA prompts protected the attacker's enrollment. The real user was no longer the principal behind the second factor. Later Azure DevOps and Kubernetes access ran under that already-owned identity.
Why did Azure DevOps pipelines matter so much in this attack?
Azure DevOps pipelines mattered because they turned one compromised workforce identity into automated reach across development and cloud resources. Microsoft reported that a malicious pipeline harvested kubeconfig files from more than 50 resources and that seven kubeconfigs were stored in a repository. The actor also tried Atera and Chisel for further remote access toward Kubernetes. Those steps used legitimate platform features after identity takeover, not a separate initial exploit.
Would stopping the SSPR abuse have stopped the kubeconfig theft?
Stopping the SSPR abuse and the MFA method replacement would have blocked the identity-takeover phases that made the DevOps activity possible. The kubeconfig harvest itself was post-authentication work under permissions the owned account already had. Once pipelines ran and kubeconfigs were copied, containment needed revoke, rotation, and DevOps hardening. Prevention value sits upstream at recovery and enrollment, where the identity first changed hands.
What does public reporting still not establish about Storm-3068?
Public reporting does not name the victim organization. Public reporting does not establish the exact method used to initiate SSPR, the number of affected records, or a ransom figure. Microsoft's blog summary and linked full report PDF document the identity takeover, MFA method replacement, pipeline abuse, resource counts above fifty, seven stolen kubeconfigs, and the Atera and Chisel follow-on attempts. Those are the facts defenders can work from without guessing.
