Storm-3068: Account Takeover via SSPR Leads to Kubernetes Credential Theft Through Azure DevOps

1. Basic Information

• Article Title: How a password reset became a pathway to the cloud
• Publisher: Microsoft Defender Experts Cybersecurity Incident Response
• Publication Date: 2026-09-29
• Source: Microsoft Defender Experts Cybersecurity Incident Response
• Related Sources: Microsoft Security Blog, Microsoft Learn: Azure Resource Manager service connection, Kubernetes: ServiceAccount token management, MITRE ATT&CK: T1219, MITRE ATT&CK: T1090
• Related Malware, Threat Groups, CVEs, and Products: Storm-3068, Microsoft Entra ID, Azure DevOps, Microsoft Intune, Kubernetes, AWS CloudTrail, Atera, Chisel
• Severity: Critical (In an actual breach, a single identity chained into Azure DevOps administrative functions, a pipeline authorized to access over 50 resources, and Kubernetes service account tokens. The figure of 50+ represents the number of authorized targets, not the number of resources actually compromised.)

2. Executive Summary

Storm-3068 leveraged a successful self-service password reset (SSPR) on a user identity to gain access to Azure DevOps, where it retrieved kubeconfig files via a pipeline. The threat actor also attempted persistent remote access using Atera and Chisel, although the scope of successful tunnel-based connections has not been publicly disclosed.

3. Attack Flow

Chain from SSPR to DevOps and Kubernetes in an Actual Breach

1. Storm-3068 successfully executed a self-service password reset (SSPR) on a user account, registered an attacker-controlled device following the initial sign-in, and onboarded it to Microsoft Intune.
2. Using valid credentials, the actor accessed Azure DevOps, enumerating repositories, projects, pipelines, deployment environments, and connected resource information through legitimate administrative features and automated scripts.
3. The attacker registered their own MFA method while removing the legitimate user's MFA method, establishing persistent control over the account.
4. The attacker executed a pipeline authorized to access more than 50 resources, retrieved kubeconfig files via DUMP_CLUSTER_<NAME> style jobs, and committed/added them to the kubeconfigs directory of an existing repository (Microsoft's supplemental blog reported that seven kubeconfig files were added).
5. The acquired ServiceAccount tokens serve as credentials to authenticate to the Kubernetes API. Subsequent API operations require token validity, API reachability, and ServiceAccount operation permissions. Furthermore, the actor deployed the Atera remote management agent and executed Chisel from the pipeline in an attempt to relay API traffic and establish an external reverse proxy/tunnel (while command execution was confirmed, the extent to which persistent connections via the tunnel were established has not been publicly disclosed).

Attack / Operational Layer	Attacker's Specific Activities	Observed Facts / System Impact	Prerequisites and Unconfirmed Aspects
Identity & Intune	Completed SSPR, performed initial sign-in, registered attacker device in Intune. Registered a new MFA method and removed the legitimate user's MFA method	Account takeover confirmed in Entra ID, along with the registration of the attacker device and enrollment in Intune	Specific prior methods used to accomplish SSPR (such as phishing) or the acquisition path for identity verification info remain undisclosed
Development Platform (Azure DevOps)	Logged in with valid credentials; enumerated repositories, projects, pipelines, deployment environments, and connected resources	Collected project configurations, source code locations, deployment paths, and cloud connection details. Does not confirm understanding of the entire environment	Prerequisite that the user account possesses permissions to view and enumerate target Azure DevOps information
CI/CD Pipelines	Executed a pipeline authorized to access over 50 resources, retrieved kubeconfig files using DUMP_CLUSTER_<NAME> jobs, and committed them	Supplemental blog indicates 7 kubeconfig files added to the repository. Includes API endpoints, CA data, and ServiceAccount tokens	The actor needed the relevant pipeline permissions, and the pipeline needed access to the target kubeconfigs. More than 50 is an authorization count; seven is a file count. Neither is a count of confirmed cluster compromises
Infrastructure & Remote Control (Kubernetes & C2)	Acquired tokens serve as credentials for Kubernetes API auth. Modified pipeline definition to deploy Atera and attempted a reverse proxy via Chisel	Tool deployment and command execution confirmed via pipeline. Intended to establish a tunnel to external infrastructure and relay API traffic	API operations require token validity, network reachability, and authorization. The extent of sustained tunnel access, and whether in-cluster data theft or workload modification occurred, remain unconfirmed in public reporting

4. Attacker Position and Execution Location

• The attacker seized the user identity from an external position capable of completing SSPR and utilized legitimate cloud authentication.
• Confirmed command and tool executions occurred via the Azure DevOps pipeline. A distinction must be made between the scope of reach enabled by the acquired credentials and the scope of operations actually executed within Kubernetes.

5. Victim and Administrator Perspective

Victims

• The legitimate user may notice a password reset, removal of MFA methods, or registration of a new device. Subsequent pipeline activity may be less visible to a user who does not normally work in Azure DevOps.

Administrators

• Correlate available records across Entra SSPR, authentication-method changes, device registration, Azure DevOps auditing, Git history, and pipeline logs. Kubernetes audit logs can help investigate subsequent API activity where available. The public report specifically describes using Azure DevOps audit data and Git history to reconstruct the intrusion.

6. Success and Failure Conditions

Success Conditions

• The attacker successfully completes SSPR and signs in using the target identity. Information used for identity verification and specific prior methods are not publicly disclosed.
• The target identity has permissions to register devices/MFA methods and perform Azure DevOps administrative operations.
• The pipeline that the compromised identity can execute or modify has permissions to retrieve the target kubeconfig. The authorized count of over 50 is an observed value in this incident and is not a prerequisite for the attack.
• Subsequent Kubernetes API operations require a token accepted by the target API server, network reachability from the connecting system, and authorization for the requested operation. Possession of a ServiceAccount token does not automatically confer cluster-wide administrative privileges.

Failure Conditions and Risk Mitigation

• Prohibit or strictly restrict SSPR for privileged identities, and employ phishing-resistant MFA alongside additional verification for authentication method changes.
• Segregate changes to Azure DevOps repositories, pipelines, and service connections, enforcing PR reviews, protected branches, execution approvals, and least privilege.
• Inference: Reduce the storage and reuse of long-lived tokens; consider workload identity federation for corresponding Azure Resource Manager service connections, and short-lived tokens for Kubernetes. Short-lived tokens alone do not prevent exploitation from authorized pipelines, so combine them with per-pipeline usage permissions, change approvals, and restricted connection target privileges.

7. What Happens Upon Success

• Source code, project structures, and deployment paths were enumerated, and kubeconfig files and service account tokens were retrieved.
• Atera deployment and Chisel execution supported attempts to maintain remote access and relay Kubernetes API traffic. Command execution was confirmed, but the extent of sustained access from external infrastructure was not disclosed.
• Public reporting does not establish whether data theft or workload modification occurred within the Kubernetes clusters, or what the scope of such activity would have been.

8. Observable Logs

• Email: It has not been publicized whether email was the initial entry vector. Verify the delivery and viewing of SSPR notifications or MFA method change alerts.
• Proxy / SWG / DNS: Review connections to Atera infrastructure and Chisel tunnel destinations, together with unexpected downloads and outbound reverse-tunnel activity from pipeline agents.
• Endpoint / EDR: Investigate third-party script downloads, the Atera agent, Chisel, shell execution, and parent-child process relationships on pipeline agents or connected hosts.
• Identity / IdP: Chronologically review SSPR, initial sign-ins, MFA method additions/deletions, device registrations, and Intune enrollments.
• SaaS / Cloud: Check Azure DevOps audit logs, pipeline creation/deletion/editing, repository commits, service connection usage, AWS CloudTrail requests, and Kubernetes audits.
• Network: Inspect pipelines or clusters for external reverse tunnels and abnormal connections to the Kubernetes API.

9. Attack Success Assessment

• Subsequent Compromise Confirmed: Public Info: Microsoft DART confirmed identity control following a successful SSPR, Azure DevOps enumeration, kubeconfig acquisition, and the deployment of Atera/Chisel in an actual victim environment. This classification refers to DevOps compromise and credential theft following the initial account takeover. It does not establish sustained access through reverse tunnels or confirm data theft or workload modification within Kubernetes. (Target: Victim environment investigated by Microsoft DART)

10. Investigation Playbook

• Investigation Starting Point: Begin with suspicious SSPR events, MFA method changes, device registrations, and Azure DevOps administrative operations.
• Initial Verification: Preserve the SSPR success timestamp, sign-ins, authentication methods, devices, privileges, and Azure DevOps memberships for the target identity.
• Device and Server Investigation: Investigate downloads, Atera, Chisel, shells, and persistence mechanisms on pipeline agents and connected hosts.
• Authentication and Cloud Investigation: Reconstruct repository enumeration, pipeline creation/deletion, kubeconfig commits, and service connection usage from Azure DevOps audit logs and Git history, then pivot to Kubernetes and AWS logs.
• Tracking Subsequent Operations: Trace cluster API operations, secret/workload/namespace access, internal reconnaissance, and external tunnels.
• Containment: Terminate compromised identities/sessions and unauthorized pipelines, and delete any MFA methods or devices registered by the attacker. Revoke and reissue leaked credentials at the issuer, and update service connections and kubeconfigs. Replacing kubeconfigs alone does not revoke old tokens. Select token revocation methods appropriate to the Kubernetes token type, and verify the impact that deleting Secrets or ServiceAccounts may have on other workloads.
• Assessment Classification: Record SSPR success, identity persistence, DevOps compromise, credential acquisition, cluster access, and subsequent operations separately.

11. Defense and Detection Ideas

• Single Events: Prioritize MFA method deletions immediately following SSPR, unknown device registrations, and kubeconfig generation/commits from pipelines.
• Chronological Correlation: Correlate events along the PDF timeline: SSPR -> sign-in -> device enrollment -> Azure DevOps enumeration -> MFA changes -> AWS CloudTrail requests -> pipeline creation/deletion -> Atera/Chisel execution. Do not treat this specific sequence as a mandatory detection condition.
• Threat Hunting: Search all projects for jobs matching the DUMP_CLUSTER_ pattern, additions to the kubeconfigs directory, service connections with excessive permissions, and Atera or Chisel execution.
• Log Limitations: If retention of Azure DevOps audit logs, pipeline logs, Git history, and Kubernetes audit logs is fragmented, the intrusion path cannot be reconstructed.
• Priority Mitigations: Prioritize phishing-resistant MFA, restricted privileged SSPR, pipeline change approvals, reduced reliance on long-lived credentials, short-lived tokens where supported, and least-privilege service connections.

12. Facts / Inference / Hypothesis

Facts

• Microsoft DART investigated a breach where Storm-3068 successfully executed a self-service password reset (SSPR) on a user account, registered its own authentication method, and removed the legitimate user's MFA method.
• The attacker registered a device to join Intune and enumerated Azure DevOps repositories, projects, pipelines, and deployment environments using legitimate administrative features and automated scripts.
• The pipeline executed by the attacker was authorized to access over 50 resources, retrieved kubeconfig files via jobs formatted as DUMP_CLUSTER_<NAME>, and added them to the kubeconfigs directory of an existing repository. A supplemental blog reported the addition of 7 files, which does not indicate compromise of all 50+ resources.
• The kubeconfigs contained Kubernetes API endpoints, certificate authority data, cluster identifiers, and authentication tokens associated with dedicated service accounts.
• The attacker modified the pipeline to deploy the Atera remote management agent and execute Chisel. Microsoft explained this as an attempt at proxying Kubernetes API traffic and maintaining persistent access via an external reverse tunnel, without stating the extent of sustained access achieved.
• Combining Azure DevOps audit logs and Git history allowed the chronological reconstruction of pipeline creation and deletion, kubeconfig additions, and tool deployments.

Inference

• The chaining of SSPR, identity, device registration, DevOps administrative privileges, service connections, and pipeline permissions turned a single account compromise into a pathway to production cloud environments.
• Monitoring that treats pipeline execution entities as equivalent to legitimate developers may overlook credential harvesting and remote tool deployment executed via legitimate features.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "14. Unresolved Items & Further Investigation".

13. MITRE ATT&CK Mapping

ID	Technique	Confidence	Basis
T1098	Account Manipulation	high	Addition/removal of MFA methods and device registration were confirmed.
T1552.001	Unsecured Credentials: Credentials In Files	high	Kubeconfigs were retrieved via pipeline and saved to the repository.
T1219	Remote Access Tools	high	Deployment of the Atera agent was confirmed.
T1090	Proxy	high	The Microsoft PDF describes Chisel being used to relay Kubernetes API traffic and attempt a reverse tunnel. Because internal relay destinations and paths are not detailed, it is mapped to the parent technique T1090.

14. Unresolved Items & Further Investigation

• The specific prior methods used to accomplish SSPR and the identity verification information obtained by the attacker.
• Whether additional commands ran within the Kubernetes clusters, whether workloads or data were accessed or modified, and the scope of any such activity.
• The target accounts/resources and success results of AWS CloudTrail requests.

15. Impact on SOCs and Organizations

Organizations that connect identity platforms, Azure DevOps, CI/CD pipelines, and Kubernetes through operational accounts or service connections should examine how permissions extend across those systems. An SSPR event or MFA-method change should be correlated with subsequent device registration, DevOps administration, pipeline changes, credential retrieval, and possible cluster access. Investigators should verify the evidence for each stage rather than assume the entire chain succeeded. Inventory the service connections and cluster credentials available to pipelines. Apply independent approval to changes in pipeline definitions, variables, and service connections, and limit the permissions available at each connection.

16. Summary by Target Audience

• For SOCs: Cross-correlate SSPR success, MFA method changes, device registrations, Azure DevOps enumeration/pipeline modifications, kubeconfig commits, and Atera/Chisel execution.
• For Administrators: Review conditions for privileged identity SSPR, phishing-resistant MFA, pipeline administrative permissions, and the principle of least privilege for service connections and cluster tokens.
• For Users: If you receive unexpected notifications of password resets, MFA method deletions, or device registrations, immediately contact administrators through an out-of-band channel.