The Backdoor That Survives a Password Reset: OAuth App Abuse in Microsoft 365

Reset the password, revoke the sessions, breathe out. Except the attacker is still reading the mailbox, because three weeks ago they registered an innocuous-looking app in the tenant and consented it into the environment. That is the appeal of OAuth application abuse: the app is its own identity, with its own credentials, and nothing you do to the user account touches it.

OAuth applications are everywhere in Microsoft 365 because they power real integrations and automation. Every time someone signs in to a third-party tool with Microsoft 365 credentials or wires up a workflow, an OAuth app is involved. This post breaks down what these apps are, how attackers use them for persistence and privilege escalation, what real attacks have looked like, and a runbook for locking down and hunting in your own tenants.

What is an OAuth application in Microsoft 365?#

OAuth applications in Microsoft 365 are third-party or custom-built apps that use the OAuth 2.0 protocol to access Microsoft 365 data on behalf of a user or system account, without ever needing the user's password. They commonly integrate external services or automate tasks across workloads like Exchange Online, SharePoint, Teams, and Microsoft Graph.

They come in two permission models, and the difference matters for risk:

Delegated permissions (user context)#

• The app acts on behalf of a signed-in user.
• It inherits the user's permissions.
• Example: a third-party calendar app that reads a user's Outlook calendar.

Application permissions (app context)#

• The app runs without a signed-in user.
• It holds its own permissions, granted by an admin.
• Example: a backup service that reads all mailboxes in Exchange Online.

How does an account compromise become a permanent foothold?#

Attackers increasingly use OAuth applications as a stealthy persistence method after the initial break-in. The chain usually runs:

Initial access. It starts with account compromise, often phishing, or more advanced techniques like adversary-in-the-middle attacks that capture session tokens even when MFA is enabled.

Persistence. To stay in, attackers might:

• Register a new device with Microsoft Authenticator
• Set up inbox rules to forward or delete emails
• Register a malicious OAuth app, which becomes its own identity, independent of the user

Once the app is registered and granted permissions, frequently via social engineering, it can:

• Send emails as the compromised user
• Download mailbox data
• Launch internal or external phishing campaigns
• Move laterally within the organization

Password resets and session expirations will not kick the attacker out, because the app carries its own credentials and permissions.

What has this cost real organizations?#

Malicious OAuth apps are not theoretical, and the documented impacts are large:

• Cryptomining campaigns: attackers used compromised accounts to register apps that spun up VMs and racked up over $1.5 million in compute charges.
• Mass phishing: one attacker created 17,000 multi-tenant OAuth apps and sent nearly 1 million phishing emails through compromised identities. Reference: Threat actors misuse OAuth applications to automate financially driven attacks (opens in new tab) from the Microsoft Security Blog.

These apps often look legitimate, sometimes mimicking the OneNote icon or naming themselves after Microsoft services. Inspected closely, they are neither published by Microsoft nor do they require admin consent to obtain powerful permissions.

Traitorware or purpose-built: the two threat shapes#

1. Traitorware: legitimate apps used in malicious ways. eM Client, for example, is a real webmail client, but attackers use it to gain persistent access to a victim's mailbox.

Real-world analysis and reference lists:

• Deep Dive: Forensic Analysis of eM Client (opens in new tab)
• Huntress rogue app list: RogueApps (opens in new tab)

2. Malicious custom apps: purpose-built apps that imitate legitimate ones or hide behind odd naming conventions, like ....., test app, or the username of the compromised account, to avoid suspicion.

The runbook: lock down consent, then go hunting#

Restrict user consent to apps#

1. Go to Entra Admin Center > Applications > Enterprise Applications > Consent and Permissions.
2. Set consent to Do not allow user consent.
3. Route approval requests to admins or a support ticket system.
4. Set an expiration on pending requests; 30 days is a solid default.

Stop users from registering applications#

1. Navigate to Entra Admin Center > Users > User Settings.
2. Set Users can register applications to No.

This prevents users from unknowingly registering apps that could be used maliciously.

Hunt for the apps already inside#

Work through the enterprise app list looking for:

• Apps with names like test, test app, sharepoint-api, or arbitrary strings such as rrrr or ........
• Apps named after compromised users
• Apps with high-risk permissions: read/write to mail, calendar, contacts
• Unusual or non-Microsoft publishers
• Low or zero interactive sign-ins, with the caveat that some legitimate apps run via service principals
• Known traitorware from the RogueApps (opens in new tab) list

More indicators of compromise are documented in Proofpoint's research: MACT: Malicious Applications in Credible Cloud Tenants (opens in new tab).

Can any of this be automated?#

Two options take the manual sweep off your plate:

The cazadora hunting script automates detection of suspicious apps using naming patterns and permission scopes: HuskyHacks/cazadora on GitHub (opens in new tab).

CloudCapsule playbooks automate discovery of traitorware, suspicious applications, and misconfigurations, and help MSPs assess and report these risks across every tenant they manage rather than one at a time.