One account, an entire cloud estate
A single compromised account can be all it takes to open the door to an organization's development platform, its cloud infrastructure, and everything connected in between. A recently documented intrusion shows exactly how far that reach can extend when repositories, automation pipelines, and deployment credentials all sit behind one identity.
What happened
After gaining control of a valid account, the threat actor — tracked as Storm-3068 — didn't need custom malware to get moving. Using legitimate administrative tools and automated scripts, the intruder systematically mapped the organization's Azure DevOps projects, repositories, pipelines, and deployment environments, building a picture of which systems were connected and where valuable credentials were likely to surface.
Azure DevOps made an efficient target precisely because it bridges software development and cloud operations in one place. The attacker built a malicious pipeline authorized to reach more than 50 resources, deployed a kube agent through it, and ran a series of jobs designed to collect Kubernetes cluster configuration files at scale — files that carry both connection details and the authentication material needed to reach live clusters. Investigators later found that seven stolen kubeconfig files had been committed to a repository, each one a usable credential set for a targeted Kubernetes cluster.
The actor then went further, altering pipeline scripts to install the Atera remote-management agent and pull down the Chisel tunneling utility. The apparent goal was to build a backup remote-access channel and expose the Kubernetes API server for possible interaction, with Chisel used to establish a reverse tunnel to an external address. Audit logs and Git version history from Azure DevOps ultimately gave responders the trail needed to reconstruct the intrusion and identify exactly where the stolen credentials had been placed.
The response combined identity, DevOps platform, and cloud infrastructure records to trace how far the attacker had moved, paired with daily containment briefings and coordination with a broader threat-intelligence team to keep the investigation focused as new details emerged.
Why it matters
This wasn't a source-code theft story — it was a lateral-movement story that happened to start in a code repository. A development platform doesn't just hold source; it holds the roadmap to everything that platform is trusted to touch. Repositories, service connections, and deployment settings gave one compromised identity a path into production infrastructure through relationships the organization had already extended trust to. And because the attacker relied on legitimate admin tooling and authorized pipeline permissions rather than exploits, the activity blended into normal DevOps operations until the credential trail gave it away.
What to do
- Watch password-reset activity for patterns — repeated attempts or activity spanning multiple accounts is a signal worth triaging, not ignoring.
- Take privileged accounts off self-service reset flows and require phishing-resistant multi-factor authentication for them.
- Require review and enforce branch protection on code changes, and restrict who can commit directly to critical branches.
- Limit who can create, modify, or execute build and deployment pipelines — pipeline permissions are production permissions.
- Apply least privilege consistently across identities, development platforms, and cloud resources, not just at the infrastructure edge.
- Audit identity, DevOps, and cloud configurations on a regular cadence — the goal is catching the trust relationships an attacker could ride before they're tested.
Treat CI/CD credentials and pipeline permissions with the same scrutiny as production secrets — because in a connected DevOps estate, they effectively are.