Hackers Turn One Compromised Account Into Access to Azure DevOps and Kubernetes

A single compromised account can open the door to an entire cloud estate. A recent investigation shows how an attacker used one compromised identity to move from password recovery into Azure DevOps, development pipelines, and Kubernetes resources.

The incident did not rely on a software flaw or custom malware. Instead, the intruder abused trusted services that organizations use every day, turning ordinary access rights into a route toward source code, deployment settings, and infrastructure credentials.

Microsoft analysts identified the activity as Storm-3068 and found that the actor took over an account through a self-service password reset.

Microsoft said in a report shared with Cyber Security News (CSN) that registering its own authentication methods gave the attacker persistent access.

The case illustrates why development systems have become attractive targets. Earlier attacks against Microsoft Entra ID accounts similarly abused legitimate cloud features, although they involved a different actor.

Here, connected repositories, automation pipelines, and cloud resources amplified the impact of one compromised identity.

Hackers Turn One Compromised Account Into Access

After gaining control of the account, Storm-3068 used legitimate administrative tools and automated scripts to examine Azure DevOps projects, repositories, pipelines, and deployment environments.

This discovery helped the intruder understand which systems were connected and where valuable credentials might be available. Azure DevOps was useful because it brought together software development and cloud operations.

A separate Azure DevOps MCP flaw highlighted another way to misuse authorized access, but this intrusion instead exploited an account’s existing permissions to map trusted deployment paths and connected resources.

The actor then created a malicious pipeline aimed at collecting Kubernetes credentials at scale. It deployed a kube agent and ran multiple jobs intended to collect cluster configuration files containing connection details and authentication information needed to access Kubernetes resources.

Microsoft said the attacker deployed a pipeline authorized to access more than 50 resources and authenticate to services. Investigators later found that seven stolen cluster configuration files had been added to a repository, providing credentials needed to access targeted Kubernetes clusters.

That sequence shows how a development platform can reveal more than source code. Repositories, service connections, and deployment settings can provide a roadmap into an organization’s broader environment, allowing an attacker to extend access through relationships already trusted by the business.

Cloud Access

Storm-3068 also altered pipeline scripts to install the Atera remote management agent and download the Chisel tunneling utility.

Investigators said these changes were intended to create alternative remote-access paths and expose the Kubernetes API server for possible interaction with the clusters.

Chisel commands established a reverse tunnel to an external IP address, although the supplied source did not disclose that address.

Azure DevOps audit logs and Git version history helped investigators reconstruct the intrusion and identify the stolen credentials placed in the repository.

Microsoft’s response team analyzed records across identity systems, development platforms, and cloud infrastructure to determine how far the attacker had moved.

It worked with the affected organization through daily briefings, prioritized containment guidance, and recommendations intended to reduce opportunities for another compromise.

DART also collaborated with Microsoft Threat Intelligence to place the activity in a broader threat context. That coordination helped refine the investigation and focus response efforts across affected environments as new details emerged.

Organizations should monitor password-reset activity for repeated attempts or patterns involving multiple users. They should reduce privileged accounts’ exposure to self-service reset workflows and require phishing-resistant multifactor authentication, measures relevant to the separate password reset portal exposure reported earlier this month.

Development teams should require approvals for code changes, enforce branch protection, and restrict direct commits to critical branches so updates follow established review processes.

Pipeline permissions should also limit who can create, modify, or execute build and deployment workflows, reducing opportunities for unauthorized changes. Finally, least-privilege access should apply across identities, development platforms, and cloud resources.

Regular reviews of identity, DevOps, and cloud controls can reduce the chance that one compromised account becomes a pathway into production environments through the organization’s own trusted connections.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC