​​Beyond source code: A path to the keys to the kingdom

1. Executive summary

Microsoft's Detection and Response Team (DART) has published an investigation into an intrusion it attributes to a tracked cluster it calls Storm-3068, in which a self-service password reset (SSPR) on a single user account was converted into control of Azure DevOps, CI/CD pipelines, and Kubernetes clusters. The actor registered its own authentication methods to hold the identity, enumerated repositories and deployment environments with legitimate administrative tooling, then deployed a malicious pipeline that harvested kubeconfig files at scale, installed the Atera remote management agent, and ran Chisel reverse tunnels to expose the Kubernetes API server. No CVE is named in the source and no software vulnerability was exploited; the entire chain ran on valid credentials and native cloud services. For EMEA financial services clients the exposure is structural rather than patchable: wherever identity, source code, pipelines and production are linked, one reset account is a route to the control plane. The actor has no MITRE ATT&CK profile in our reference data, so the attribution is unconfirmed and the TTPs, not the name, are what you should hunt on.

2. Regulatory framing

DORA Art. 17, 18, 19 and 24 and NIS2 Art. 23 are not engaged by anything specific in this item: the source describes an investigation and remediation, not a reportable incident at a named client, and no testing obligation is triggered by the facts given. UK NIS 2018 duties apply only if you are an OES or RDSP; the source gives no basis to assert that.

3. Technical analysis & attack chain

The source is a vendor incident-response narrative. It confirms the sequence below and gives no atomic indicators, no timestamps, no IP addresses, no file hashes and no named CVEs. Everything in this section is single-sourced to Microsoft's 29 September 2026 post and the accompanying Cyberattack Series report; treat the TTPs as actionable and the specifics as unverified until you reproduce them in your own telemetry.

Confirmed steps:

1. Initial access via self-service password reset. Storm-3068 gained access to a user account through the SSPR process. The source does not say whether the reset was social-engineered, whether MFA was bypassed, or whether the account was already reachable; it states only that a successful SSPR was the entry point.
2. Identity takeover by authentication-method registration. After the reset, the actor registered its own authentication methods on the account, converting temporary access into persistent control of the identity. This is the step that survives a password change and is the one most organisations do not alert on.
3. Enumeration of Azure DevOps. With the identity held, the actor used legitimate administrative tools and automated scripts to enumerate repositories, projects, pipelines and deployment environments. Nothing here is malware; it is the platform's own API surface used at speed.
4. Mapping of trusted deployment paths. The actor traced which pipelines could deploy where and which connected resources those pipelines could reach, to find a route out of the initial compromise. Azure DevOps is the pivot because it sits between identity, source code and cloud operations.
5. Malicious pipeline creation and execution. The actor created a pipeline designed to harvest Kubernetes credentials at scale. It deployed a kube agent and ran multiple jobs whose purpose was to collect kubeconfig files, which contain cluster connection details and authentication material.
6. Authorised access to a wide resource set. The pipeline ran under the permissions of the compromised account and was authorised to access more than 50 resources and authenticated services. The blast radius came from the account's existing entitlements, not from privilege escalation.
7. Tooling installation from the pipeline. The actor modified pipeline scripts to install the Atera remote management agent and to download the Chisel tunnelling utility. Both are legitimate tools; Atera gives interactive remote access to the build host, Chisel gives a network path.
8. Reverse tunnelling to the Kubernetes API. Chisel commands were executed to establish a reverse tunnel to an external IP address, with the stated aim of exposing the Kubernetes API server for remote interaction with the clusters.
9. Credential staging in Git. The actor added seven stolen kubeconfig files to a repository. Investigators reconstructed this stage from Azure DevOps audit logs and Git version history, which is also the evidence that the kubeconfigs were the intended key material for the next phase.

What matters to a defender, in order of leverage:

The identity control is the whole intrusion. Registering a new authentication method after an SSPR is a legitimate, expected flow, which is why it does not stand out. Detection has to come from the correlation: a password reset followed within a short window by a new authenticator registration, from a device or location the user has not used, on an account that then touches Azure DevOps. Microsoft's related Storm-2949 reporting describes the same SSPR abuse pattern with the actor impersonating internal IT support and talking the user through MFA prompts; that is a different actor and a different case, so use it as a hypothesis for how your own reset was obtained, not as a confirmed fact about Storm-3068.

The pipeline is the new perimeter. A pipeline that can read a kubeconfig can read every cluster that kubeconfig authenticates to. The actor did not need to escalate: the compromised account's pipeline permissions already reached more than 50 resources. Audit which service connections, variable groups and environments each pipeline definition can touch, and treat a pipeline definition change as a privileged change.

The kubeconfig is a long-lived bearer credential. Seven files were enough to open the targeted clusters. Rotating cluster credentials after any pipeline compromise is not optional, and kubeconfigs committed to a repository are exposed to everyone with read access to that repository, including anyone who clones it before you delete it.

The tooling is dual-use and will not be caught by signature alone. Atera is a commercial RMM agent; Chisel is an open-source tunnelling utility. Both were pulled down by a pipeline script, which means the download and the install are the detectable events, not the binaries.

Unconfirmed and single-sourced: the actor name Storm-3068, the attribution of the activity to that cluster, and the characterisation of the SSPR step as deliberate rather than opportunistic all rest on Microsoft's report alone. Storm-3068 has no MITRE ATT&CK profile in our reference data. Do not build blocking rules on the name. The related sources in our corpus describe Storm-2603 and Storm-2949, which are separate clusters with overlapping tradecraft; do not merge them into a single campaign on the strength of similar SSPR abuse.

4. Mitigation & containment

P1, within 24 hours:

• Hunt for SSPR abuse in your identity logs. Query for password reset events followed by authentication-method registration on the same account within a short window, and for registration from a device or ASN the user has not previously used. Any hit on an account with Azure DevOps or cloud console access is an incident, not a ticket.
• Enumerate Azure DevOps pipeline definitions changed in the last 30 days and diff them against your baseline. Look for added tasks that download executables, added inline scripts, new service connections, and new variable groups. The actor's signature move is a modified pipeline script, so the diff is the detection.
• Search build agents and self-hosted runners for the Atera agent and for Chisel binaries. Check installed programs, service registrations, and the process tree of your build agents. Remove anything not on your approved tooling list and rebuild the agent from a clean image.
• Rotate credentials for every Kubernetes cluster reachable from the affected pipelines, and rotate the service connections and service principals those pipelines use. Rotating the user password alone does not evict an actor who registered their own authenticator.
• Review Git history across all repositories for committed kubeconfig files and for any file matching kubeconfig naming patterns. Seven were added in this case; assume yours may exist from earlier activity. Purge them from history, not just from the current branch.

P2, within 72 hours:

• Restrict who can register authentication methods and require re-authentication for method changes. Where your identity provider supports it, require a conditional access policy that blocks authentication-method registration from unmanaged devices.
• Apply least privilege to pipeline identities. A pipeline that deploys to one cluster should not hold credentials for fifty resources. Split service connections per environment and remove standing access that is not used.
• Block outbound tunnelling from build infrastructure. Chisel's reverse tunnel is an outbound connection to an external IP; egress filtering on build agents and runners should permit only your package registries and deployment targets.
• Enable and centralise Azure DevOps audit logging into your SIEM if it is not already there, with alerting on pipeline creation, pipeline modification, service connection changes and permission grants.

P3, within 7 days:

• Review your RMM tooling inventory. If Atera or an equivalent is not an approved tool, add it to your application control deny list on build and production hosts.
• Test the full chain as a tabletop: SSPR compromise, method registration, DevOps enumeration, pipeline abuse, kubeconfig theft. The point is to find where your detection stops, because in this case the actor never needed malware.
• Review DORA Art. 28 and Art. 30 coverage for the DevOps platform and any RMM provider, per section 2.

5. Indicators of compromise

No atomic indicators of compromise are available in the source material. Microsoft's post names no IP addresses, domains, file hashes, or file paths. The external IP address used for the Chisel reverse tunnel is not published.

The source does describe observable behaviours. These are the machine-pivotable signals available, and they belong in behavioural detection rather than in a blocklist.

6. Detection

The source gives usable artefacts for a Sigma rule: the tooling names, the pipeline-script modification pattern, and the identity sequence. It gives no file hashes, no mutexes, no registry keys and no ransom-note text, so a YARA rule built on file content would have nothing genuine to match on. A rule that greps for "Storm-3068" or "Azure DevOps" would detect reporting about the intrusion, not the intrusion. No YARA rule is emitted for that reason.

The Sigma rule below targets the identity sequence and the tooling installation, which are the two behaviours with the strongest signal-to-noise ratio in this case. Tune the time window and the account scope to your environment before enabling.

title: SSPR Followed by Authentication Method Registration and Build Agent Tooling Install
id: 8f2c1a44-7b6e-4d19-9c3a-2e5f0b7d1a90
status: experimental
description: Detects the Storm-3068 intrusion pattern reported by Microsoft DART, where a self-service password reset is followed by registration of a new authentication method on the same account, and where build infrastructure subsequently installs the Atera remote management agent or the Chisel tunnelling utility.
author: Adverse Trace
date: 2026-09-29
references:

  - https://www.microsoft.com/en-us/security/blog/2026/09/29/beyond-source-code-a-path-to-the-keys-to-the-kingdom/
logsource:
  product: windows
  category: process_creation
detection:
  selection_tooling:
    CommandLine|contains:

      - 'AteraAgent'
      - 'Atera'
      - 'chisel'
  selection_tunnel:
    CommandLine|contains:

      - 'chisel client'
      - 'chisel server'
      - 'R:'
  condition: selection_tooling or selection_tunnel
falsepositives:

  - Legitimate use of Atera where it is an approved remote management tool
  - Legitimate use of Chisel by engineering or red team staff
level: high

The identity half of the chain cannot be expressed in a process-creation rule. Build it as a correlation rule in your SIEM: an SSPR or password-reset event, followed within 60 minutes by an authentication-method registration event for the same principal, followed within 24 hours by Azure DevOps audit events for pipeline creation or modification by that principal. Alert on the full sequence rather than on any single event, because each step on its own is legitimate.

7. Sources

• Microsoft Threat Intelligence, "Beyond source code: A path to the keys to the kingdom", https://www.microsoft.com/en-us/security/blog/2026/09/29/beyond-source-code-a-path-to-the-keys-to-the-kingdom/, 29 September 2026.
• Microsoft Threat Intelligence, "One intrusion, two cyberattackers: Uncovering parallel threat activity", https://www.microsoft.com/en-us/security/blog/2026/06/22/one-intrusion-two-cyberattackers-uncovering-parallel-threat-activity/, 22 June 2026. Related context on Storm-2603; separate cluster, do not merge with this case.
• Microsoft Threat Intelligence, "How Storm-2949 turned a compromised identity into a cloud-wide breach", https://www.microsoft.com/en-us/security/blog/2026/05/18/storm-2949-turned-compromised-identity-into-cloud-wide-breach/, 18 May 2026. Related context on SSPR abuse; separate cluster, use as a hypothesis only.

8. Adverse Trace position

We assess this as a high-impact technique set with a low technical barrier, and we are treating the actor attribution as unconfirmed: Storm-3068 has no MITRE ATT&CK profile in our reference data and the entire case rests on a single vendor's incident-response report, so the TTPs are what we will hunt on and the name is not. The client impact is concentrated in organisations where Azure DevOps or an equivalent pipeline platform holds standing credentials into production Kubernetes, which describes a large share of our EMEA financial services clients; the absence of malware and CVEs means many of those clients will not have a detection for any step of this chain today. We will publish a hunting package for the SSPR-to-authentication-method-registration sequence and the pipeline-definition diff workflow to clients this week, and we will re-issue this advisory if Microsoft publishes the full Cyberattack Series report with atomic indicators or if the actor is assigned a MITRE profile. Clients who run Azure DevOps with self-hosted agents should treat the P1 items in section 4 as this week's work, not next quarter's.

Read the original source →

Published via PulseTrace — Adverse Trace threat intelligence.