If you’ve ever used your Microsoft 365 credentials to log in to a third-party app or set up a workflow integration, then congratulations — you’ve interacted with an OAuth application. These apps are everywhere in modern cloud environments, and while they enable powerful integrations and automation, they can also introduce significant risk if left unchecked.
In this post, we’ll break down:
What enterprise/OAuth applications are in Microsoft 365
How attackers are abusing them for persistence and privilege escalation
Real-world examples of attacks
A protection and hunting runbook you can follow to secure your environment
What Are Oauth Applications 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 needing the user’s password. They’re often used to integrate external services or automate tasks across Microsoft 365 apps like Exchange Online, SharePoint, Teams, or Microsoft Graph.
🧭 Types of OAuth Applications in Microsoft 365
1. 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.
2. Application Permissions (App Context)
The app runs without a signed-in user.
It has its own permissions, granted by an admin.
Example: A backup service that reads all mailboxes in Exchange Online.
The Attack Kill Chain: How OAuth Apps Get Abused
Attackers are increasingly using OAuth applications as a stealthy, persistent method to maintain access to compromised environments. Here’s how it typically unfolds:
1. Initial Access
This usually begins with account compromise — often through phishing or more advanced techniques like adversary-in-the-middle attacks, where the attacker captures session tokens even if MFA is enabled.
2. Persistence
To maintain access, attackers might:
Register a new device with Microsoft Authenticator
Set up inbox rules to forward or delete emails
Register a malicious OAuth app, which acts as its own identity, independent of the user
Once the app is registered and granted permissions (often 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
Because the app has its own credentials and permissions, password resets or session expirations won’t kick out the attacker.
Real-World Examples
Attackers have used malicious OAuth apps for years, and the impacts can be massive:
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 using compromised identities.
These apps often look legitimate and in some cases are as you will see later (e.g., mimicking the OneNote icon or naming themselves after Microsoft services), but when inspected closely, they are neither published by Microsoft nor do they require admin consent to gain powerful permissions.
Two Main OAuth App Threat Types
TraderWare Apps: Legitimate apps used in malicious ways. For example, EM Client is a legitimate webmail client, but attackers use it to gain persistent access to a user’s mailbox.
2. Malicious Custom Apps: Purpose-built apps that imitate legitimate ones or use odd naming conventions (e.g., ....., test app, or the username of the compromised user) to avoid suspicion.
Runbook: How to Lock Down Your Tenant and Hunt for Suspicious Apps
✅ 1. Restrict User Consent to Apps
Go to Entra Admin Center>Applications> Enterprise Applications > Consent and Permissions
Set to: Do not allow user consent
Route approval requests to admins or a support ticket system
Set expiration on pending requests (30 days is a solid default)
✅ 2. Prevent Users from Registering Applications
Navigate to the Entra Admin Center>Users>User Settings
Set Users can register applications to No
This prevents users from unknowingly registering apps that could be used maliciously.
🔍 3. Hunt for Suspicious Applications
Look for:
Apps with names like
test,test app sharepoint-api,,or arbitrary strings (e.g.,rrrr,........)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 (though note: some apps run via service principals)
Traitorware apps: RogueApps
🔧 Tools to Help
Huntress Script: Automates detection of suspicious apps using naming patterns and permission scopes
HuskyHacks/cazadora: Simple hunting script for suspicious M365 OAuth Apps
CloudCapsule Playbooks: Our app automates discovery of traitorware, suspicious applications, and misconfigurations — and helps MSPs assess and report risks across tenants. You can run a free assessment to see what this could look like across customers.
