Seven stolen Kubernetes configuration files appeared in an Azure DevOps repository after Storm-3068 took over a user’s identity and ran a malicious development pipeline. Microsoft’s incident-response account describes an intrusion at one customer that began with a successful self-service password reset, then reached development pipelines and cloud resources. For teams whose build pipelines can reach production clusters, the account behind a reset request can hold much more authority than its job title suggests.
The attacker registered its own authentication methods on the compromised identity and used legitimate administrative tools and scripts to enumerate Azure DevOps projects, repositories, pipelines and deployment environments. Microsoft’s investigators found a pipeline authorized to access more than 50 resources. That number describes the pipeline’s authorized resources; the concrete credential-theft finding is seven stolen kubeconfig files committed to a repository.
A reset account reaches pipelines
Once Storm-3068 controlled the user account, it could operate inside Azure DevOps using that account’s permissions. Microsoft says the attacker built a malicious pipeline to gather Kubernetes credentials. The pipeline deployed a kube agent and ran multiple jobs intended to collect kubeconfig files, which hold cluster connection and authentication details. The attacker then used the compromised account’s permissions to deploy it against resources it was already authorized to reach.
The pipeline carried the account’s authority into connected cloud resources. Code review on a protected branch helps with changes to code, but a user who can create or modify a pipeline and use an existing resource connection may still reach secrets through the build system. Microsoft describes this as abuse of legitimate identity and cloud services rather than a software exploit. Its investigators wrote: “The investigation revealed that Storm-3068 created a malicious pipeline designed to harvest Kubernetes credentials at scale.” The reported theft consists of seven kubeconfig files committed to a repository.
The attacker also modified pipeline scripts to install the Atera remote-management agent and download Chisel. Microsoft says Chisel commands executed to establish a reverse tunnel to an external IP address for potential interaction with Kubernetes clusters. Treat those as separate access attempts while investigating; the case’s confirmed credential finding remains the stolen kubeconfig files.
Git history preserves the credential trail
Microsoft’s responders reconstructed this stage with Azure DevOps audit logs and Git version history. Start with the affected identity: correlate self-service reset activity and registration of new authentication methods with unusual Azure DevOps pipeline creation, edits and executions. Then inspect pipeline definitions and job logs for the kube agent, kubeconfig collection, Atera installation and Chisel execution. Check repository commit history for cluster credentials, including files later removed from the current tree. A credential committed to Git needs rotation even after the working copy is cleaned.
The Azure DevOps auditing guide says auditing for Azure DevOps Services organizations is off by default, requires an organization backed by Microsoft Entra ID, and retains audit events for 90 days. In Organization settings → Security → Policies, turn on Log Audit Events and export or stream events if your investigation window must extend beyond that period. Exports add authentication mechanism, correlation ID and user agent to the actor, IP, time, area, category and details shown in the audit view. Azure DevOps auditing does not track sign-ins, so use Microsoft Entra sign-in and audit logs for the identity side of the sequence, especially changes to authentication methods.
Limit pipeline access to clusters
Microsoft’s Azure Pipelines guidance recommends project-scoped build identities, narrowly scoped service connections and resource approvals and checks for each pipeline run. Map which users can create, edit and execute the pipelines that hold Kubernetes access; remove permissions the deployment does not need. Put code and pipeline definitions behind branch policies and pull-request approvals, and restrict service connections to authorized pipelines and branches. Resource owners can require a manual approval or protected-branch check before a pipeline uses a sensitive connection.
For a suspected intrusion, disable the unauthorized pipeline and revoke the attacker’s registered authentication methods and sessions as part of containment. Rotate any Kubernetes credentials found in pipeline output or repository history, then check cluster access using the replaced credentials and review the cluster’s own records for activity under the old ones. Microsoft says its DART responders worked with the customer on containment and prioritized remediation.
Verify the pipeline permission change
Enable and retain Azure DevOps audit events, then connect suspicious pipeline changes to Entra password-reset and authentication-method events and Git commits. Reduce pipeline creation and execution rights and gate Kubernetes-bearing connections with branch checks or approvals. A useful access test is to run an unapproved pipeline against the protected connection: it should be denied. Separately, confirm a branch-policy change appears in the enabled Azure DevOps audit log. Check the cluster credential itself separately; denying a future pipeline run cannot retract the kubeconfig files already copied from this incident.