Abuse JWT Assertion in Azure

What this lab covers

You use a compromised user account to enumerate the directory and a key vault, obtain certificate material for a service principal, and authenticate as that application by signing your own assertion.

From there the lab moves through privileged role elevation and into a container registry, which is a good demonstration of why registry contents deserve the same protection as source code.

It is rated intermediate and assumes basic Azure and Microsoft Graph familiarity. It suits anyone administering application identities.

How JWT assertion authentication works

A service principal can authenticate with a client secret or with a certificate. In the certificate case the client builds a JSON Web Token asserting its identity and signs it with the private key, and Entra ID validates that signature against the registered public key.

This is the recommended approach because there is no shared secret transmitted, and it has a specific consequence: possession of the private key is sufficient and complete. There is no user, no second factor and no interactive sign-in, so controls designed around people do not apply.

Key vaults are therefore the target. Certificates are stored there precisely so applications can retrieve them, and an identity with permission to read certificate material can authenticate as every application whose certificate it can reach. Conditional access policies that require multi-factor authentication generally do not constrain this path, because the grant control being satisfied is not the one protecting interactive users.

How to detect this in your own environment

Enable Key Vault diagnostic logging and alert on certificate and key retrieval by identities outside the expected set. This is the moment the credential leaves your control and it is the most valuable single event here.

Separate service principal sign-in monitoring from user sign-in monitoring, and baseline where each application authenticates from. Applications authenticate from predictable infrastructure, so a service principal signing in from a new network is anomalous.

Alert on role activation through Privileged Identity Management, particularly activation by identities that rarely elevate, since elevation is the step that converts application access into administrative access.

How to prevent it

Scope key vault access per certificate rather than per vault, using role-based access control instead of broad access policies. An identity that needs one certificate should not be able to read them all.

Apply conditional access for workload identities where available, so application sign-ins are subject to location and risk conditions rather than being exempt from everything.

Review which principals are eligible for privileged roles and require approval for activation on the most sensitive ones, so obtaining an application identity does not automatically yield an administrative path.

Real-world context

Application identities are a recurring theme in cloud intrusion reporting precisely because they sit outside the controls organizations invest in most heavily. Multi-factor authentication and conditional access are built around people, and a substantial share of access is held by things.

Container registries are a related blind spot. They hold build artifacts, configuration and frequently credentials in image layers, and they are generally protected as infrastructure rather than as source code, despite containing much the same value.

The pattern maps to MITRE ATT&CK T1078.004 Cloud Accounts, T1550.001 Application Access Token and T1552.004 Private Keys.

Applying this at work

• Audit who can read certificates and keys from your key vaults, and scope those permissions per object.
• Enable Key Vault diagnostic logging and alert on certificate retrieval outside the expected set.
• Apply conditional access to workload identities where your licensing supports it.
• Require approval for activation of your most privileged roles.
• Treat container registries as sensitive, and scan image layers for credentials as you would a repository.

Frequently asked questions

What is a JWT assertion in Azure authentication?

A signed token an application builds to assert its own identity, signed with the private key of a certificate registered against its service principal. Entra ID validates the signature, so possession of the private key is sufficient to authenticate.

Does multi-factor authentication protect against this?

No. Certificate-based service principal authentication involves no user and no interactive sign-in, so controls designed around people do not apply. Conditional access for workload identities is the equivalent control.

Why is key vault access so significant here?

Because certificates are stored there for applications to retrieve. An identity able to read certificate material can authenticate as every application whose certificate it can reach, which makes vault scoping the real access boundary.

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.