Passwordless Credentials for Access and Escalation

What this lab covers

You authenticate to a service principal using a certificate rather than a password, use an Azure role that looks narrow to obtain command execution, and move from the compromised application to the managed identity configured on it.

The theme is that identity in Azure is broader than user accounts. Service principals, managed identities and certificates form a parallel population that is larger than the human one and governed far less carefully.

It suits anyone administering Azure identity and assumes no prior experience with service principals.

How non-password credentials work in Azure

A service principal is the identity an application uses. It authenticates with a client secret or a certificate, neither of which involves a user, so conditional access policies aimed at interactive sign-in generally do not apply, and there is no second factor to satisfy.

Azure roles that appear narrow can be broad in effect. Website Contributor is a good example: it grants management of a web application, and managing a web application includes deploying content, which means running code. A role that sounds like configuration management is code execution.

Managed identities complete the chain. Once you have execution inside a resource, the identity assigned to that resource issues tokens on request from a local endpoint. There is no credential to steal because the platform issues one, and its role assignments determine where the chain leads next.

How to detect this in your own environment

Separate service principal sign-ins from user sign-ins in your monitoring. They appear in a different log and are frequently excluded from dashboards built around user behavior, which is how non-human authentication becomes an unmonitored path.

Baseline each service principal's source and behavior. Applications authenticate from predictable infrastructure, so a service principal signing in from a new network or calling APIs it has never used is a strong signal precisely because applications do not improvise.

Watch for credential additions to existing applications. Adding a client secret or certificate to a service principal is a common persistence technique, it is recorded in the audit log, and it is rare enough to alert on individually.

How to prevent it

Inventory and expire application credentials. Client secrets and certificates commonly outlive the projects that created them, and a two year secret on an application nobody owns is a standing risk with no compensating control.

Scope role assignments by capability rather than by name. Ask what a role permits in practice, since several Azure roles that sound administrative include deployment and therefore code execution.

Prefer managed identities and workload identity federation over stored secrets, and apply conditional access for workload identities where available so non-human sign-ins are subject to location and risk conditions too.

Real-world context

Compromise of application identities is a recurring theme in cloud intrusion reporting, and the reason is structural. Organizations apply multi-factor authentication and conditional access to people, then discover that a substantial part of their access is held by identities those controls never covered.

Adding credentials to an existing application is also a favoured persistence mechanism, because the application is already trusted, its permissions are already granted, and the change is a routine-looking administrative event.

The pattern maps to MITRE ATT&CK T1078.004 Cloud Accounts, T1098.001 Additional Cloud Credentials and T1548 Abuse Elevation Control Mechanism.

Applying this at work

• Export a list of your service principals with their credential expiry dates and owners. The ones with no owner are the first problem.
• Review which identities hold roles that permit deployment, since those are code execution in practice.
• Alert on credentials being added to existing applications.
• Separate service principal sign-in monitoring from user sign-in monitoring so non-human authentication is actually watched.
• Replace stored client secrets with managed identities or federated credentials wherever the workload runs in Azure.

Frequently asked questions

Does multi-factor authentication apply to service principals?

No. Service principals authenticate with a secret or certificate and no user is involved, so there is no second factor. Conditional access for workload identities can apply some conditions, but the interactive controls protecting users do not cover them.

Why is Website Contributor considered dangerous?

Because managing a web application includes deploying content to it, which means running code. The role sounds like configuration management and in practice provides execution in the application's context, including access to its managed identity.

What makes managed identities safer than stored secrets?

There is no credential to leak, since tokens are issued by the platform on request. The trade-off is that code execution in the resource is equivalent to holding the identity, so the role assignments need to be scoped tightly.

Do I need my own Azure account to practice this?

No. The lab runs in a live Azure 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.