Azure consent injection and app backdooring expose tenant control

At a glance

What this is: This analysis shows how attackers can turn OAuth consent, app manifests, and long-lived secrets into a persistent tenant backdoor in Entra ID.

Why it matters: IAM, PAM, and NHI teams need to treat consent grants and enterprise applications as governed identities, because standing write access can become durable administrative control.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging and over-privileged accounts at 37% each.

👉 Read SlashID's analysis of Entra ID consent injection and app backdooring

Context

In Entra ID, the governance failure is not a password reset problem. It is a consent and application control problem, where OAuth grants, app manifests, and client secrets can be used to create durable non-human identity authority inside the tenant.

That matters because the attacker does not need to stay inside a single user session. If a malicious app can obtain write access to consent settings or application configuration, it can convert temporary access into persistent control that survives ordinary revocation and user turnover.

This pattern is common wherever identity controls assume humans are the only actors making authorization decisions. In cloud tenants, service principals and application permissions can be abused as quietly as any credential, but with far broader blast radius.

Key questions

Q: What breaks when OAuth consent is writable by too many identities?

A: Consent becomes a privilege-escalation path instead of an administrative exception. If too many identities can grant or modify permissions, one compromised account can create organisation-wide delegated access, hide persistence inside a legitimate application, and bypass ordinary revocation workflows. That is why consent write access must be governed like privileged control, not routine app management.

Q: Why do service principals with app-only permissions increase tenant risk?

A: Because app-only permissions let the application act as itself, not as a user. Once an attacker adds high-privilege app permissions, the app can read and modify directory objects, create new service principals, and keep working even if the original human account is disabled. The access surface is broader and more durable than a user token.

Q: How do security teams know if app secret governance is failing?

A: Look for secrets with unusually long expiry dates, repeated re-creation of credentials, and application records that still authenticate after the original human owner has changed. If credential rotation happens but the entitlement itself remains untouched, the backdoor may survive in a different secret. Effective governance means tracking both the secret and the identity state behind it.

Q: Who is accountable when a malicious enterprise application persists after revocation?

A: Accountability sits with the team that owns application governance, directory privileges, and privileged role approvals, not just the incident response team. If consent writes, manifest edits, and secret creation were not separately controlled, the breach reflects a lifecycle governance failure across IAM and PAM. The relevant benchmark is whether privileged changes were traceable before the compromise matured.

Technical breakdown

How consent injection becomes tenant-wide access

OAuth consent injection works by abusing permission grants that let an application act on behalf of users or the tenant. In Entra ID, an attacker with write access to consent objects can create or modify OAuth2PermissionGrant records, including AllPrincipals grants that apply across the organisation. That turns a single compromised identity into a tenant-wide delegated backdoor. The real danger is that consent appears administrative and routine, so it often escapes the scrutiny applied to traditional privileged accounts.

Practical implication: treat consent-grant creation and modification as privileged events, not ordinary app administration.

Why app manifest tampering creates durable non-human privilege

Application manifests define what an app can request and how it behaves as a service principal. By adding app-only permissions such as Directory.ReadWrite.All and then granting them, an attacker shifts from delegated access to application-level authority. That means the malicious app can call Microsoft Graph as itself, without a user token. Once that happens, the attacker no longer depends on the original compromised user or session, because the app has become the control point.

Practical implication: monitor manifest changes and app permission grants as part of privileged identity change management.

How long-lived client secrets make revocation ineffective

A planted client secret turns a compromised application into a persistent identity. If the attacker adds a passwordCredential with a distant expiry date, revoking the original token or removing the compromised user does not remove the backdoor. The secret remains a valid authenticator for the service principal, which is why secret hygiene and lifecycle governance are inseparable from access governance. This is a classic NHI persistence pattern, not a one-time intrusion artifact.

Practical implication: enforce secret expiry, rotation, and removal checks on every enterprise application and service principal.

Threat narrative

Attacker objective: The attacker wants durable administrative control over the tenant, with the ability to read, modify, and persist access across Entra ID.

1. Entry begins with phishing, OAuth pharming, or SSRF against managed identity endpoints to obtain a valid token or consent path.
2. Escalation occurs when the attacker injects blanket consent grants or modifies the application manifest to add app-only permissions.
3. Impact follows through persistent Graph API access, tenant-wide data exfiltration, and shadow administration that survives ordinary revocation.

Breaches seen in the wild

• Mastra npm Supply Chain Attack — Sapphire Sleet — North Korean Sapphire Sleet backdoors 144 AI npm packages in 88 minutes via supply chain attack on Mastra ecosystem.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Consent governance is now NHI governance. Once an application can receive or modify tenant-wide OAuth grants, it is no longer a simple integration. It becomes a governed identity with delegated authority, persistence potential, and audit requirements that look far closer to PAM than to ordinary app registration. IAM teams need to stop treating consent as a user-experience setting and start treating it as a privileged access decision.

Tenant-wide consent creates a hidden privilege blast radius. The AllPrincipals model collapses the distinction between one compromised application and organisation-wide exposure. A single malicious grant can impersonate normal business use while quietly expanding access across the directory, which is why app consent reviews must be tied to data access scope and administrative delegation. The practical conclusion is that directory permissions need lifecycle governance, not point-in-time approval.

Long-lived app secrets are standing privilege in disguise. A client secret with an expiry pushed out to 2299 is not a credential management edge case. It is a standing administrative entitlement that survives user offboarding, credential rotation routines, and many routine audits. Secret rotation without entitlement review simply preserves the backdoor in a new form, so practitioners must manage secrets as identity state, not as isolated tokens.

Identity blast radius is determined by write access, not just read access. The dangerous threshold in this pattern is the ability to rewrite grants, manifests, and secrets. Those capabilities let an attacker reshape the tenant’s trust fabric rather than merely consume exposed data. That means governance should prioritise the identities that can authorise others, because those are the actors that can turn a foothold into a durable control plane.

Privilege review cadences assume access is stable long enough to inspect. This assumption breaks when attackers can chain consent injection, manifest tampering, and secret planting into a few API calls. The implication is that review-driven governance alone will always lag behind abuse unless it is paired with runtime change detection on consent objects and application credentials.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% having no or low visibility and 47% having only partial visibility, according to The State of Non-Human Identity Security.
• Only 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• If consent grants and app secrets are part of the attack surface, start with 52 NHI Breaches Analysis to compare recurring failure patterns and control gaps.

What this signals

Consent objects are now part of the identity control plane. Once attackers can modify grants and manifests, the question is no longer whether an app is legitimate, but whether it can rewrite the trust relationship behind the scenes. Teams that still classify application permissions as lower-risk than human admin roles will keep missing the real escalation path.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the governance gap is already established, and this attack pattern shows how quickly that blind spot becomes persistent control. Practitioners should expect consent review to move closer to PAM-style oversight, with stronger change detection on app identities and delegated permissions.

Ephemeral consent debt: when short-lived access decisions accumulate into long-lived app authority, revocation stops being a cleanup step and becomes a race against persistence. That means directory teams need to watch for permission drift, not just expired credentials, because the backdoor often survives in the authorisation layer even after the secret is removed.

For practitioners

• Lock down OAuth consent pathways Restrict consent approval to a small trusted admin group, and separate ordinary app onboarding from any permission that can write grants or modify tenant-wide access.
• Treat app registrations as privileged identities Require PIM for roles that can create, update, or approve enterprise applications, service principals, and application permissions.
• Alert on consent and manifest changes Monitor Add servicePrincipalOAuth2PermissionGrant, Update application, and Add passwordCredential events, and correlate them with identities that do not normally perform admin tasks.
• Shorten secret lifetimes and verify removal Enforce expiry limits on client secrets, then verify that revoked apps no longer have any valid passwordCredential entries or residual Graph permissions.
• Audit third-party OAuth exposure continuously Run scheduled reviews of connected apps, delegated scopes, and high-risk enterprise applications so blanket consent does not remain invisible for long periods.

Key takeaways

• Consent injection turns a cloud integration into a tenant-wide privilege boundary problem, which is why OAuth governance belongs in privileged access management discussions.
• The evidence in this attack is the persistence mechanism itself: manifest tampering, blanket grants, and long-lived secrets can survive ordinary revocation.
• The control that matters most is lifecycle governance over who can write consent, who can change app permissions, and how quickly those changes are detected.

Key terms

• OAuth Consent: The approval that allows an application to access resources on behalf of a user or tenant. In practice, consent can create durable access paths that outlive the original interaction if permissions are broad, unmanaged, or never reviewed. For security teams, it is both an access decision and a lifecycle event.
• Enterprise Application Backdooring: Enterprise application backdooring is the act of modifying an app registration or service principal so it can keep authenticating after the original foothold is detected. The backdoor usually lives in permissions, secrets, or delegated scopes rather than in malware on an endpoint.
• AllPrincipals Consent: AllPrincipals consent is a tenant-wide grant that allows an application to act across all users in an organisation. It is powerful because one approval can replace many individual decisions, which makes it a high-risk control point when consent is writable by compromised identities.
• Standing Application Privilege: Standing application privilege is persistent non-human access that remains available until someone explicitly removes it. Unlike time-bound access, it does not depend on a live approval window, so revocation, rotation, and audit must all be tied to the same lifecycle state.

What's in the full article

SlashID's full blog post covers the operational detail this post intentionally leaves for the source:

• HTTP request examples for /oauth2PermissionGrants and /applications/{id} changes that show exactly how the backdoor is planted.
• Python and Azure CLI snippets for tampering with manifests, permissions, and long-lived client secrets.
• MITRE ATT&CK mapping for each phase of the attack chain, useful for detection engineering and threat modelling.
• Detection and hardening guidance tied to specific Graph audit events and consent controls.

👉 SlashID's full post covers the attack flow, code snippets, detection logic, and hardening steps in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.