Long-lived malicious OAuth apps expose a blind spot in M365 IAM

At a glance

What this is: This is a threat-hunting guide showing that malicious Microsoft 365 OAuth applications can remain trusted, enabled, and unnoticed for years after initial consent.

Why it matters: It matters because application identities often bypass human-centric controls like MFA and continuous review, creating a durable NHI governance gap in M365.

By the numbers:

• Malicious Microsoft 365 applications identified in customer tenants had remained enabled for years in some cases.

👉 Read Cyera's analysis of malicious OAuth applications in Microsoft 365

Context

Microsoft 365 environments are often strongest where user authentication is concerned, but that does not close the risk introduced by application identities. A malicious OAuth app can authenticate legitimately, inherit trust through consent, and operate without the behavioral signals that usually trigger identity investigation. For IAM and NHI governance, that means the problem is not only account compromise. It is also the long-lived permissions granted to software identities that are rarely reviewed like users.

Cyera's analysis shows why this blind spot persists in mature tenants: the application often looks normal because it is using the platform exactly as designed. Once consented, it can stay present far longer than the campaign that introduced it, especially when review processes focus on accounts, endpoints, and sign-ins rather than service principals and delegated access. That starting position is typical for enterprises with hardened human identity controls and weaker application identity governance.

Key questions

Q: How should security teams govern consented Microsoft 365 applications?

A: Security teams should treat consented applications as governed identities with owners, scopes, review dates, and revocation criteria. The key is to inventory service principals, validate business need, limit permissions, and remove apps that lack a current justification. Application identities should never sit outside the same governance discipline used for human access.

Q: Why do malicious OAuth applications bypass so many IAM controls?

A: They bypass many IAM controls because they are not behaving like interactive user logins. Once consented, they can operate through trusted platform tokens and delegated scopes, so MFA and conditional access often do not challenge them. The result is a software identity that can look legitimate while still retaining durable access.

Q: What is the difference between a disabled app and a deleted app in Microsoft 365?

A: A disabled app may stop being used, but it can still exist as an identity object with permissions, metadata, and future reactivation risk. A deleted app removes the object and reduces the chance that dormant access remains in the tenant. For security teams, deletion is the cleaner control when the app has no ongoing business purpose.

Q: When should organisations investigate Microsoft 365 application identities first?

A: Organisations should investigate application identities first when user controls look strong but data exposure, suspicious consent events, or unexplained API activity still appear. That pattern often means the weak point is not the user account but the service principal. In mature tenants, application review can reveal risk that sign-in monitoring will miss.

Technical breakdown

Why OAuth consent creates durable application identity risk

OAuth consent gives an application delegated access that can outlive the user interaction that created it. In Microsoft 365, a service principal is the application identity that receives permissions, and those permissions can remain active even when the originating phishing campaign is old or the operator is gone. Because the app is authenticating as a trusted identity, not as a noisy endpoint process, traditional intrusion signals are weak. The risk increases when scopes such as offline access or broad Graph permissions are approved and never revisited.

Practical implication: treat consented applications as standing NHI entitlements that require lifecycle review, not as one-time setup artifacts.

How malicious M365 apps evade user-centric controls

Malicious applications exploit a structural mismatch between human identity controls and software identity behaviour. MFA, conditional access, and user monitoring are built to challenge interactive logins, but an app can operate through platform-approved tokens and permissions instead. That means the app may never trip the same alerts as a compromised mailbox or a suspicious endpoint. In practice, the attacker uses trust inheritance. The tenant sees normal API activity, legitimate identity objects, and often no obvious escalation event until data access or phishing enablement is already underway.

Practical implication: extend detection logic from sign-ins to service principal creation, consent events, permission changes, and unusual API usage.

Why metadata-first hunting outperforms log-only review

Cyera's method is metadata-first because the important clues are often in the application object itself, not only in logs. Reply URLs, publisher identifiers, naming patterns, and permission combinations can expose malicious intent before any clear abuse appears in telemetry. This is especially true for homoglyph names, impersonation of well-known services, and repeated infrastructure across tenants. Logs still matter, but they usually help confirm risk after the identity object already exists. For hunters, the object model is the starting point, not the end state.

Practical implication: build hunts around application metadata and reputation signals first, then use logs to confirm scope and dwell time.

Threat narrative

Attacker objective: The attacker wants long-lived trusted access to Microsoft 365 data and identity context without needing a live compromise of the user's account.

1. Entry occurs when the victim consents to a malicious Microsoft 365 application that requests OAuth permissions under a trusted identity flow.
2. Escalation happens when the app receives durable delegated access such as offline access or broad Graph scopes that do not depend on repeated user interaction.
3. Impact follows when the application validates identities, harvests tenant context, or redirects users into phishing and credential-harvesting infrastructure while remaining enabled in the tenant.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Application identity is now a primary NHI governance domain, not a side issue. Microsoft 365 apps can hold delegated privileges that remain active long after the consent event, which means the real security object is the service principal, not only the user who approved it. Human-centric identity controls do not adequately govern software identities that persist quietly. Practitioners should treat application identity review as core IAM work.

Persistent OAuth consent creates what we call ephemeral credential trust debt. The credential may be token-based and the initial action may be short-lived, but the resulting access often behaves like standing privilege when no review or expiry is enforced. That debt accumulates across tenants, apps, and publishers until the environment contains dormant but still usable access paths. The control answer is lifecycle governance, not occasional hunting alone.

Metadata signals are often stronger than behavioural signals for malicious app hunting. Reply URLs, homoglyph naming, permission mismatch, publisher reuse, and installation patterns can reveal risk before logs show abuse. This changes the operating model for defenders because the identity object itself becomes the best detection surface. Security teams should prioritise object-level review pipelines for applications.

MFA success against humans can mask failure against applications. An environment can look hardened while malicious OAuth apps still operate through trusted platform workflows with no MFA challenge at all. That creates a false sense of maturity if teams measure only interactive authentication outcomes. The practical conclusion is that M365 security posture must be assessed across both human and non-human identities.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to the same research.
• The 52 NHI breaches Report shows how credentialed non-human access becomes durable when review and revocation are weak.

What this signals

Ephemeral credential trust debt: Microsoft 365 application consent creates access that may start as a single approval but behaves like standing privilege when review and expiry are absent. That pattern is already visible across NHI programmes, and it should push teams to align application governance with the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10.

Cyera's hunt model suggests that tenant-level security programmes should shift left into object-level review, because service principals often reveal risk before logs do. That matters for M365 estates where human identity controls are mature but application identity controls remain uneven. The governance signal is clear: if your review process cannot explain why an app exists, it should not remain trusted.

The practical next step is to connect OAuth consent review with lifecycle controls for credentials, permissions, and ownership. A consented app that has no current owner is an unmanaged NHI, even if it never triggers an alert. Teams that operationalise this distinction will reduce hidden blast radius faster than teams that focus only on sign-in telemetry.

For practitioners

• Review all consented application identities Inventory Microsoft 365 service principals, then flag apps with broad scopes, no business owner, or no recent access review. Prioritise applications with offline access and those installed years ago.
• Hunt for malicious app metadata patterns Search for homoglyph naming, suspicious reply URLs, domain mismatches, and publisher reuse across tenants. Use these object-level signals before relying on log evidence.
• Revoke unused and unjustified OAuth consent Remove applications that no longer have a clear owner, purpose, or current business need. Treat disabled apps as still requiring deletion if they retain usable permissions.
• Extend identity monitoring to service principals Add alerting for new application registrations, consent grants, permission changes, and unusual API access patterns. Tie those events to review workflows so app identities do not sit outside governance.

Key takeaways

• Malicious OAuth applications create a durable NHI risk because they inherit trust through consent and can persist long after the original campaign ends.
• The strongest hunting signals are often in application metadata, not in user-centric authentication logs.
• IAM teams should govern consented applications as first-class identities with ownership, review, and revocation discipline.

Key terms

• Service Principal: An application identity object in Microsoft Entra ID and Microsoft 365 that represents a specific app inside a tenant. It holds permissions, ownership, and configuration data that define what the application can do. In NHI governance, it is a high-value identity that should be reviewed like any other privileged account.
• 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.
• Delegated Access: Access granted to an application to act within the boundaries of a user's or tenant's permission set. It can be legitimate and still risky when the application is malicious, over-privileged, or left enabled without oversight. Delegated access is a core NHI concern because it can look ordinary while remaining highly durable.
• Homoglyph Naming: A naming technique that uses visually similar characters from another alphabet to make a malicious application look legitimate. It is often used to impersonate trusted services and reduce the chance of manual detection. In threat hunting, homoglyphs are a metadata signal that can reveal intent before behavioural telemetry does.

Deepen your knowledge

Microsoft 365 application identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for consented apps and service principals, it is worth exploring.

This post draws on content published by Cyera: The Long-Lived Risk of Malicious OAuth Applications, a practical threat hunting guide for Microsoft 365. Read the original.