Plunder Azure DevOps for Cloud Credentials

What this lab covers

You explore an Azure DevOps organization the way an attacker with developer-level access would, examining repositories, pipeline definitions, variable groups and service connections to find the route into the cloud subscription behind them.

The lesson is about who really holds production access. Cloud permissions are governed carefully while pipeline edit rights are handed out broadly, and the pipeline is what holds the subscription credential.

It suits platform and DevOps engineers as much as testers, and assumes no prior Azure DevOps experience.

How CI/CD becomes a route into the cloud

Azure DevOps deploys into cloud subscriptions through service connections, which hold credentials or a federated trust for a service principal. That principal typically has broad rights over the resources the pipeline manages, because deployment requires them.

Secrets are stored in variable groups and pipeline variables and are masked in log output. Masking prevents accidental disclosure and not deliberate extraction, because a pipeline step runs arbitrary commands and a secret available to a step can be transformed before it is printed.

The access control question is therefore not who can read the secret but who can run a pipeline. Anyone able to modify a pipeline definition, or to open a pull request that triggers one, can potentially execute code in a context holding the service connection's credentials.

How to detect this in your own environment

Alert on service connection creation and modification, and on changes to variable groups. These are infrequent administrative events, so the volume is manageable and the signal is meaningful.

Watch for pipeline definition changes that add steps outside the normal build and deploy pattern, particularly steps that make outbound network requests. This is where extraction happens, and it looks different from ordinary build activity.

On the Azure side, baseline what each deployment service principal does. Deployment identities have repetitive behavior, so enumeration, secret reads or role assignments by a deployment principal are strong indicators.

How to prevent it

Use workload identity federation instead of stored service principal secrets. This removes the long-lived credential entirely, and the trust can be scoped to a specific pipeline and branch so it cannot be exercised from an arbitrary one.

Scope service connections per project and per environment, and require approvals for the ones that reach production. A single connection shared across an organization means the least sensitive pipeline holds production access.

Restrict who can edit pipeline definitions, and require that pipeline changes go through review like any other code. Protect production branches so a pull request cannot trigger a privileged pipeline without approval.

Real-world context

Development infrastructure has been a recurring target in supply chain incidents, because it sits between source code and production while typically being administered with less rigour than either. Compromise of a build system yields both code and credentials.

The structural problem is that CI/CD permissions and cloud permissions are governed by different teams using different models. An organization with careful cloud role assignments can still allow a broad group to modify the pipeline that holds a privileged service connection.

The pattern maps to MITRE ATT&CK T1195 Supply Chain Compromise, T1552.001 Credentials In Files and T1078.004 Cloud Accounts.

Applying this at work

• List your service connections and check the role assignments held by each service principal. Broad Contributor at subscription scope is common and rarely necessary.
• Migrate service connections to workload identity federation to remove stored secrets.
• Review who can edit pipeline definitions in each project, and compare that list against who you would knowingly grant production deployment rights.
• Require approvals and branch protection on pipelines that reach production environments.
• Alert on service connection and variable group modification.

Frequently asked questions

Does masking secrets in pipeline logs protect them?

Only against accidental disclosure. A pipeline step runs arbitrary commands, so a secret available to that step can be encoded or transmitted before it is printed. Masking is a hygiene feature, not an access control.

Why is pipeline edit access equivalent to cloud access?

Because the pipeline executes with the service connection's credentials. Anyone who can change what the pipeline runs can run their own commands in that context, inheriting whatever the service principal is permitted to do.

What is workload identity federation and why is it better?

It lets a pipeline obtain short-lived tokens through a trust relationship rather than holding a stored secret. There is no long-lived credential to steal, and the trust can be scoped to a specific pipeline and branch.

Do I need my own Azure account to practice this?

No. The lab runs in a live environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own tenant.

Which certification covers this in depth?

The Microsoft Cloud Red Team Professional (MCRTP) covers Entra ID, Azure and Microsoft 365 attack paths in full, including token abuse, phishing tradecraft and privilege escalation, and is assessed hands-on in a live tenant.