TL;DR

• OAuth applications in Microsoft Entra ID are a common persistence and privilege escalation mechanism used by attackers.

• Because OAuth apps are frequently created, modified, and forgotten, malicious applications often blend in with legitimate business integrations.

• By analyzing known OAuth attack campaigns across multiple environments, we developed OAuth Apps Scout - a proactive detection pipeline that automatically surfaces emerging malicious OAuth applications, and has so far helped us identify many malicious apps across dozens of affected organizations.

Would you click "Accept" on this application?

This app looks like a standard Microsoft prompt, but there’s a catch: the name starts with a zero, not the letter O.

After finding this homoglyph attack in the wild, we started investigating. It quickly led to something much larger. The trail ended with over 20 companies impacted across three distinct malicious OAuth App campaigns. It highlights a common gap in how Azure service principals are managed.

What are Oauth Applications and what is Consent?

A Microsoft Entra application starts with a single application object, which lives in the tenant where the app was originally registered (its “home” tenant). That application object acts as a blueprint: whenever the app is used in another tenant, Entra creates a corresponding service principal there.

In other words, you can think of an OAuth application like a third-party contractor you hire to work on your house. You wouldn't give them your master key (your password), instead, you give them a specific badge (set of permissions) that only lets them into the kitchen and the basement.

In the world of Azure, Consent is that badge. When you see a prompt asking for permission to access your profile or files, clicking "Accept" is telling Azure: "I trust this developer enough to give them this specific set of permissions."

From Global App to Local Identity

This is where it gets interesting for security teams. Most of the apps you use, like Microsoft Teams, don’t actually "live" inside your environment. They are hosted inside the developer’s (i.e. Microsoft) Azure environment.

But for Teams to function within your specific company, your Azure tenant needs a way to recognize and manage it locally. This creates a two-part relationship:

1. The Application Object: The global "blueprint" of the app that lives in the developer's home tenant.

2. The Service Principal: Your local "instance" of that app.

As shown in the diagram below, while there is only one global Application ID for Teams, every company that uses it has their own unique Service Principal ID.

The Risk of Azure OAuth Applications

The danger lies in the fact that most of us have "consent fatigue". We see a pop-up, we want to get to work, and we click "Accept" before our brain even registers what we’re looking at. An attacker counts on this. They give their malicious app a legitimate-looking name and wait for an uneducated or rushed user to just open the door for them. Here is how this can be done:

1. Creating the Fake App

First, an attacker creates an application in their own Azure environment. They give it a name that looks legitimate, like "Adobe", to make it look like a trustworthy application. To reinforce the illusion of trust, the actor can configure a familiar logo and specify a homepage URL that looks legitimate.

2. Phishing for a sign-in

The attack’s success depends on a person making a choice, signing in to the app. The attacker sends out a phishing email, perhaps telling the user they need to "update their Adobe settings" or "verify their account". The goal is to get the user to click a link and land on a real Microsoft sign-in page.

3. Getting Consent

After the user signs in, they see a prompt asking for permission to access their data. Because the app name and logo look legitimate, the user often clicks "Accept". By doing this, the user is accidentally "adding" the attacker's app into their company's tenant. As you can see in the diagram, this creates a new Service Principal (a local instance) inside the victim’s tenant, even though the attacker still controls the global application.

4. Capturing Access

Once "Accept" is clicked, the sign-in process is complete. But instead of going to a normal landing page, the access token is sent to the attacker’s Redirect URL. With that token, the attacker now has access to the user's files or emails without ever needing to know their password.

5. Enabling Persistency

As mentioned above, by granting consent, the victim tenant creates a Service Principal for the attacker-controlled application. This Service Principal persists independently of the user’s session and credentials, allowing the application to continue accessing resources as long as the granted permissions remain valid. Unlike traditional credential theft, this access survives password resets, MFA enforcement, and even user offboarding, unless the OAuth grant or Service Principal is explicitly removed.

A Manual Hunt Begins

At this point, it’s clear that malicious OAuth applications represent a real and persistent risk, in part because they closely resemble legitimate SaaS integrations and are difficult to assess in isolation - it’s difficult to know at a glance if an app is malicious or not. With that in mind, we analyzed multiple real-world malicious OAuth applications to understand what distinguishes them from benign ones, and whether those differences could be leveraged to systematically identify other malicious apps. 

One illustrative example is an application that presents itself as a DocuSign integration. Although the application appeared legitimate on its own, evaluating it in a broader context revealed multiple red flags compared to the actual legitimate DocuSign app:

• Application Name - the malicious app’s name closely mimics the well-known SaaS service and looks completely legitimate. However, the application was published by an unverified entity, providing no strong linkage to the brand it claimed to represent

• Publisher verification - the legitimate application is publisher-verified, whereas the malicious application is not.

• Homepage - the malicious app does not specify a homepage, while the legitimate app is configured with the official homepage.

• Unrelated or suspicious reply URL - the redirect URI of the malicious app pointes to infrastructure unrelated to the claimed service and in this case also uses a free hosting subdomain.

• Unusual application owner name and domain - The owning tenant and associated domains did not align with the purported service, further weakening the legitimacy of the application.

• The app prevalence - the real DocuSign app can be found in use by many organizations, whereas the malicious one could only be found in a handful of environments

From Research to Tooling: Operationalizing OAuth App Detection

After manually investigating several malicious applications, we wanted to translate those insights into an automated pipeline capable of proactively detecting future malicious activity. The result is a multi-stage analysis pipeline that incrementally enriches OAuth application data, reduces noise, and enables both newly-observed detection of suspicious applications and cross-environment pivoting to uncover attacker activity.

The pipeline consists of four main stages:

1.Extraction and Establishing the baseline
We start by ingesting OAuth applications observed across environments, focusing on third-party integrations. From this data, we establish a baseline of commonly observed application IDs and names and filter out those that appear broadly across environments, as they are more likely to represent legitimate SaaS services. This baseline is reused in later stages to identify applications that mimic or deviate from known integrations. For the remaining applications, we extract the key characteristics needed for comparative analysis.

2. Enrichment
Each discovered application’s metadata is enriched with additional context to better assess its legitimacy and risk. This enrichment process incorporates multiple signals, including:

• Application name analysis - application names are compared against the baseline of commonly observed names identified in the discovery stage to detect potential masquerading or brand impersonation attempts

• Homepage URL evaluation - homepage URLs are examined to identify empty, placeholder, or suspicious pages, and are cross-referenced with DNS information to assess domain legitimacy

• Reply URL analysis - redirect URIs are analyzed to extract domain ownership and DNS characteristics, helping identify infrastructure that is unrelated to the claimed service

• Ownership and publisher context - publisher names, tenant IDs, and associated domains are enriched to provide insight into the entity operating the application.

• Adoption and permission usage - tenant distribution and the permissions requested by the application are included to understand how the application is used in practice and to highlight anomalous or high-risk behavior.

3. Decision and Prioritization
To prioritize OAuth applications for investigation, we apply a weighted scoring mechanism across the enriched signals. Rather than relying on a single indicator, the model combines multiple weak signals such as unusual permission usage, low tenant prevalence, name similarity to known integrations, and suspicious reply or homepage URLs - to assign a risk score to each application. This scoring approach helps surface applications that warrant closer inspection while reducing noise from benign integrations that may exhibit one anomalous trait in isolation.

4. AI-Assisted Contextual Evaluation
During our analysis, we found that some aspects of OAuth application assessment are inherently contextual. Indicators such as whether a reply URL aligns with the claimed service, or whether an owning domain makes sense for a given application name, are difficult to evaluate using strict rules alone. To address this, we incorporated an AI-assisted evaluation step that considers the application’s metadata holistically. This step helps assess the overall plausibility of the application by reasoning over relationships between signals, rather than evaluating each signal in isolation.

5. Pivoting and Campaign Discovery
Finally, the pipeline enables pivoting across shared indicators such as reply URLs, ownership domains, application metadata, and naming conventions. By correlating these signals across environments, we are able to cluster related OAuth applications and identify coordinated attacker campaigns operating across multiple organizations. This shifts the focus from isolated detections to campaign-level visibility, providing deeper insight into how attackers reuse and adapt OAuth applications in the wild.

Identifying Malicious OAuth Patterns in the Wild

As a concrete example of the malicious OAuth activity we see in the wild, our detection pipeline identified a large-scale campaign active in early 2025. The campaign involved 19 distinct OAuth applications impersonating well-known brands such as Adobe, DocuSign, and OneDrive, and targeted multiple organizations. The same campaign was independently reported by the Proofpoint research team. Across the apps, we observed clear signs of coordination, including infrastructure reuse - most notably shared reply URLs and placeholder or empty home pages.

The attack flow relied on luring users into granting OAuth consent to fake document-sharing applications, allowing attackers to obtain long-term access without triggering MFA or anomalous login alerts. Once consent was granted, the attackers were able to read user emails and files, maintain access through delegated permissions, and exfiltrate data without generating suspicious authentication activity. A list of indicators of compromise (IOCs) associated with this campaign is provided at the end of this blog.

The Evolution of Attacker Stealth: 2019 vs. 2025

While our model surfaced meaningful results from the previous year, we wanted to assess how far back this trend extends. Given that OAuth applications are known to be abused over long periods, we evaluated our model on data from earlier years.

This led us to detect seven additional malicious applications dating back to 2019. These apps utilized Cyrillic homoglyphs, replacing Latin characters with visually identical non-Latin letters, to mimic legitimate Microsoft services.

Commonly Spoofed Apps (2019):

• ОпeDrive for Business (Uses Cyrillic "п")

• Sharеpoiпt Cloud (Uses Cyrillic "п")

• Мicгoѕоft. Сloud App Ѕесuгity (Uses Cyrillic "г")

These homoglyph apps were found in use across more than 50 organizations, highlighting a long-term gap in traditional detection methods.

2025: A Shift in Strategy

When we compare these legacy campaigns to our latest findings in 2025, the evolution in attacker tradecraft is clear. Attackers have moved away from spoofing Microsoft itself and are now leveraging the trust of third-party productivity tools like Adobe and DocuSign.

The modern attacker is significantly stealthier. They have traded "obvious" typosquatting for sophisticated URL structures and legitimate-looking SaaS platforms to host their redirect points.

Comparative Analysis: Tactical Evolution

Key Takeaways for Defenders

Detecting malicious OAuth applications is achievable, and should therefore be a critical pillar of modern identity security. While the transition from 2019’s "Microsoft-cloning" to 2025’s "SaaS-impersonation" shows that attackers are evolving, they are not invisible. They still operate within the constraints of the OAuth protocol, which requires them to leave detectable traces.

The "Breadcrumbs" 

Even the most sophisticated attackers leave identifiable marks across these four vectors:

• Application Metadata: Traditional strategies for detecting phishing are just as applicable to OAuth apps; look for names that imply urgency or mimic trusted tools. 

• Reply URLs: Analyze the redirect URI.  Attackers often hide their landing pages on trusted SaaS platforms like ClickFunnels or GitHub Pages to bypass security filters. Since these platforms are used by many legitimate businesses, security tools can’t easily block them without causing major disruptions. This is a common behavior, previously documented by other security companies, including CheckPoint, Infosecurity and iZOOlogic

• Requested Scopes (Permissions): High-risk permissions like Mail.Read or Files.ReadWrite.All should always trigger an alert, especially when requested by an external, non-verified publisher.

• Infrastructure: Every malicious app is tied to a source tenant and a verified (or unverified) domain. Understanding the Tenant’s details and the reputation of the associated domain is vital.

Actionable Defense Strategies

We believe the detection model discussed in this post can be implemented by any resourceful blue team today. To strengthen your posture, we recommend a multi-layered approach:

1. Restrict User Consent: Limit the ability of non-admin users to grant consent to apps from unverified publishers.

2. Inventory & Audit: Regularly export and review a list of all OAuth grants in your environment. Look for apps that are consented by only 1 or 2 users, these "low-prevalence" apps are often the result of targeted phishing.

3. Monitor "First-Time" Apps: Alert on any app that is seen in your tenant for the first time, especially if the reply URL doesn't match a known enterprise service.

4. Baseline Reply URLs: Use regex or threat intelligence feeds to scan Reply URLs for suspicious strings or known malicious hosting patterns.

Attackers are counting on your trust in familiar names to go unnoticed. This model shifts the power back to the defenders, proving that even the stealthiest application leaves a trail if you know where to look.

IOCs