What breaks when attackers create malicious OAuth applications in a compromised tenant?

Why This Matters for Security Teams

Malicious OAuth applications break the usual incident response assumption that the user account is the center of gravity. Once an app is consented in a compromised tenant, the attacker may retain access through the application itself, independent of the password, MFA status, or active user session. That makes app registrations, delegated scopes, and secrets first-class attack assets, not background configuration.

This pattern is especially dangerous because OAuth often looks legitimate in logs. Security teams may see a trusted app name, a valid token exchange, and normal API activity while the app quietly accesses mail, files, or directories. NHIMG research on The State of Non-Human Identity Security shows how widespread this visibility gap is: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. That aligns with broader guidance from CISA cyber threat advisories, which repeatedly show that persistence is often created through legitimate-looking identity paths.

In practice, many security teams encounter OAuth persistence only after mailbox forwarding, data export, or API abuse has already occurred, rather than through intentional app governance.

How It Works in Practice

A malicious OAuth app typically enters through consent phishing, abused admin consent, or an app already trusted in the tenant. After consent, the attacker does not need to keep reusing the victim’s password. The app receives scopes that define what it can read, write, or delegate, and those permissions can outlive the original compromise unless the tenant revokes them.

For responders, the practical sequence is: identify the app registration, review delegated and application permissions, revoke consent, invalidate any app secrets or certificates, and check for secondary persistence such as inbox rules, forwarding, or service principal abuse. Use MITRE ATT&CK Enterprise Matrix to map the abuse chain, and pair it with NHIMG examples such as the Salesloft OAuth token breach and the CoPhish OAuth Token Theft via Copilot Studio, both of which show how identity-based access can be repurposed after initial compromise.

Operationally, the best control is not just stronger user authentication. It is consent governance, least-privilege scope design, and continuous review of service principals and app secrets. The OAuth app should be treated as its own non-human identity with its own lifecycle, ownership, and revocation path. Current guidance suggests this is where many environments fail: they monitor user accounts but not app grants, which leaves a durable access path in place even after the user is remediated. These controls tend to break down in large tenants with weak app inventory, because admins cannot reliably distinguish sanctioned integrations from attacker-created persistence.

Common Variations and Edge Cases

Tighter app control often increases operational overhead, requiring organisations to balance user self-service against consent risk. That tradeoff becomes sharper in environments that rely heavily on SaaS integrations, partner automation, or low-code tools.

There is no universal standard for this yet, but current guidance suggests three common edge cases deserve special handling. First, delegated permissions can be less visible than application permissions, yet still allow broad data access if the user account remains active. Second, multi-tenant apps can reappear through new consent even after one service principal is removed. Third, emergency response can miss app secrets stored outside the identity platform, which means revocation must extend to token caches, certificates, and automation pipelines.

NHIMG’s Top 10 NHI Issues and the 52 NHI Breaches Analysis both reinforce the same lesson: once a non-human identity is established, it can become a long-lived foothold unless inventory, scope review, and revocation are treated as continuous controls, not one-time cleanup.

Related resources from NHI Mgmt Group

• What actions should I take if my OAuth tokens are compromised?
• How do attackers operationalise stolen OAuth tokens at scale?
• What breaks when attackers abuse compromised mailboxes and OAuth redirects in phishing campaigns?
• Why do non-human identities create more risk than many human accounts?