A build pipeline made them an admin

The attacker never had Azure access. They edited a build pipeline, pressed run, and the pipeline made them an admin.

What it is

An Azure DevOps pipeline deploys to Azure through a service connection backed by a service principal or managed identity. Whoever can change the pipeline definition, or trigger it with a pull request that runs the deployment, can execute commands as that connection identity. An attacker edits the pipeline YAML to print the service principal secret, or to use the connection to assign themselves a role or read Key Vault, then runs it. The actions happen as the trusted CI/CD identity, not the attacker. This is T1059 (command execution) with T1552 (unsecured credentials) and T1098 (account manipulation).

Why it works

CI/CD identities are production-privileged, but they are often guarded far less carefully than the production they can reach. A pipeline change plus a service connection’s rights is a quiet path straight into Azure.

How to detect it

Look for a pipeline definition change or a pull-request build that prints secrets or calls Azure unusually, followed immediately by the service connection identity assigning a role or reading Key Vault, in the Azure Activity log.

The fix that holds

Protect pipelines with required reviewers and branch protection, and do not expose secrets to pull-request builds from forks. Restrict who can edit pipelines and service connections, least-privilege the connection identity, require approvals and checks on the connection, and scan for and block secret printing. When you respond, rotate the service principal secret and reverse any role it granted, because deleting the run is not enough.

Practice it

We built an Azure DevOps service-connection abuse scenario in GraphLattice Range so teams learn to treat CI/CD identities as production-privileged and contain them like it.