Uncover Malicious OAuth Apps in Microsoft 365 with Cazadora

For any organization relying on Microsoft 365, conducting a thorough audit of your OAuth applications is no longer a suggestion, it’s an urgent necessity. The likelihood of a malicious app operating within your environment is statistically significant, posing a serious threat to your security posture.

An open-source script is available to assist with this critical task. You can find it on GitHub. When performing your audit, pay particular attention to several key indicators within your Enterprise Applications and Application Registrations.

Be on the lookout for applications that mimic user account names or are simply labeled “Test” or something similar. Apps named after your own tenant domain or those using nonsensical, non-alphanumeric strings like “……..” should also raise immediate red flags. Another major warning sign is the presence of anomalous reply URLs, especially those pointing to a local loopback address on port 7823.

If you manage a Microsoft 365 tenant, you should conduct this audit immediately. The rest of this article will be here when you return.

For those fascinated by the technical details of cyber threats, let’s explore further.

Imagine a peaceful Sunday morning. You’re enjoying a quiet moment, coffee in hand, feeling relaxed after a demanding week. The sun is warm, birds are singing, and a gentle breeze flows through your window. Everything feels perfect.

Then, you spot a single termite on your windowsill.

Your first thought might be to dismiss it as an isolated insect. But a moment later, a chilling realization sets in: you never find just one termite. Your hope for a restful day vanishes, replaced by the urgent need to investigate the potential infestation lurking beneath the surface.

This scenario closely mirrors the discovery process at Huntress when we began analyzing data on Azure applications and their malicious use within partner environments. We decided to tear up the proverbial floorboards to see just how extensive the problem truly is.

Understanding OAuth Application Attacks

Since launching our Unwanted Access detection capability, the Huntress security team has successfully thwarted a massive number of identity-based attacks. This system was designed to target critical initial access vectors, including credential theft, token theft, adversary-in-the-middle (AitM) attacks, and suspicious location-based logins.

The data shows this capability has significantly disrupted threat actor operations, with our team now neutralizing between three and six thousand initial access attempts every single month.

However, in cybersecurity, resting on your achievements is not an option. Threat actors constantly adapt, evolving their methods to bypass existing defenses. This relentless pressure drives our continuous research into new ways to identify and dismantle their attack sequences.

Our current focus involves investigating Rogue Apps. Cloud applications are integral to the modern user experience, providing developers with powerful tools for building and scaling services. Unfortunately, the very features that make these apps so valuable for legitimate purposes also make them incredibly attractive to cybercriminals.

This area appeared to be the next logical frontier for finding attacks that had slipped past our other security measures.

Our research team formulated several key questions. How do OAuth applications function within Azure? In what ways can they be weaponized during an attack? What makes them so potent for malicious actors? How can we most effectively track down these rogue applications? And finally, the most daunting question of all: just how many are already out there?

In our search for answers, we uncovered far more than we initially expected.

The Mechanics of OAuth Applications

Let’s dive into a primer on Azure applications. It’s important to acknowledge that this system is complex and can be counterintuitive.

For a comprehensive understanding, John Savill’s technical training on Azure App Registrations is an excellent resource. It’s worth noting that John is a recognized Azure expert, and the video’s thumbnail features him looking genuinely concerned about explaining these concepts.

You don’t need to grasp every minute detail. For our purposes, we’ll focus on the concepts directly relevant to malicious app usage.

Cloud applications are similar to the apps on your phone or computer. They are modular programs designed to perform specific functions. Azure applications integrate with Entra ID, allowing your Microsoft 365 account, for instance, to interact with a desktop client that manages your cloud emails.

Azure categorizes applications into two types: Enterprise Applications and Application Registrations. This naming can be confusing, but the core distinction is straightforward: did you build the app yourself, or are you using an app built by someone else?

Enterprise Applications are apps developed, maintained, and published by an external party in a different tenant, which you are now utilizing within your own tenant.

Application Registrations are apps that you are actively building, maintaining, and publishing within your own tenant for others to use. Think of an Application Registration as a blueprint for an app, while an Enterprise Application is a live instance of an app in use.

A developer typically writes the app’s code and then creates an Application Registration in their tenant before publishing it for internal or public consumption.

Now, suppose an administrator wants to install your app in their tenant. Applications cannot install themselves arbitrarily; a system of authentication (authN) and authorization (authZ) is required. The process generally unfolds as follows:

The user requests to install the app, authenticating with their username, password, and multi-factor authentication (MFA) to verify their identity.

If you skimmed the technical details, the key takeaways are these:

• Apps can be built in-house (Application Registrations) or installed from external sources (Enterprise Applications).
• Apps can be granted delegated access to act on behalf of users within a tenant.
• Azure apps rely on the platform’s built-in authentication and authorization systems.
• Installing an app creates a service principal in the tenant, which functions as the app’s operational account.
• Crucially, Azure’s default configuration permits any user to install any application and consent to permissions affecting their own resources, without requiring any administrative review.

This creates a powerful set of primitives ripe for exploitation.

Security professionals who manage complex authentication systems will confirm that attackers relentlessly search for unpatchable system flaws. Any red teamer experienced with Kerberoasting will attest that the most potent exploitation techniques often leverage system features, not software bugs, making them impossible to simply patch away.

Azure applications fit this pattern perfectly. They are a fundamental part of the ecosystem. Their inherent customizability provides attackers with a versatile toolkit, and their operations often go unnoticed due to the system’s overall complexity. When malicious actors use Azure apps, they are operating within the legitimate framework designed for application functionality. For threat actors, this represents an incredibly powerful playground. Let’s examine precisely how they leverage it.

Traitorware: When Legitimate Apps Turn Rogue

Consider a crowbar. It’s a fundamentally useful tool for prying open crates or freeing stuck doors. The tool itself is neutral; its context defines its morality. While not all crowbars are evil, they are frequently found in the hands of burglars.

In the Azure app landscape, we hunt for a category of applications we call “Traitorware.” These are apps not explicitly designed for malicious purposes but have become exceptionally useful to hackers and cybercriminals. We target apps that are overwhelmingly utilized in attacks, even if their original intent was benign.

This attack method is analogous to “Living Off the Land” or “Bring Your Own” tools on endpoints. It’s similar to when a threat actor installs legitimate Remote Monitoring and Management (RMM) software during an intrusion, they are leveraging a lawful tool for illicit purposes.

Currently, our data identifies five such apps as major red flags. Based on a sample of approximately 1,500 reported instances and an average false positive rate of just 1.8%, detecting these specific apps is far more likely to uncover malicious activity than legitimate use.

A complete list of these Traitorware apps, along with details on their common misuse, is available in our open-source Rogue Apps repository. We encourage contributions to this knowledge base to help the community better define and monitor this emerging attack surface.

Stealthware: Bespoke Malicious Applications

Conversely, the Azure app ecosystem also allows threat actors to build malicious applications from scratch. These are custom-crafted, artisanal evil apps, designed specifically for havoc and delivered directly to a target tenant.

The technical term for these attacks is “OAuth Illicit Consent Grant Attacks,” but we refer to them as “Stealthware.” The challenge in hunting Stealthware is that each app is unique. You cannot search for them by a specific name, as each is tailored to the hacker’s specific exploitation goals.

The Hunt for Malicious Apps

With our threat model defined, we proceeded to analyze the data and answer the pressing question: “How widespread is this problem?” Our data collection involved enumerating over 8,000 tenants across various industries, collecting all their Enterprise Applications and App Registrations, and performing extensive analysis.

The findings were clear:

• We discovered evidence of both Traitorware and Stealthware in the surveyed tenants.
• Roughly 10% of the surveyed tenants had at least one Traitorware app installed.
• Hunting for Stealthware proved effective by combining global rarity, the number of assigned users per app, and the permissions granted. Apps with less than 1% global prevalence that were delegated to a single user were more likely to be Stealthware. This hit rate increased significantly when these rare apps also possessed powerful, high-risk permissions.

After presenting these findings, we expanded our data collection across all Huntress partner tenants. The finding regarding Traitorware applications remained consistent at about 10%. Furthermore, using this new telemetry, our security team identified over 500 confirmed instances of Stealthware applications. The names of these malicious apps were all unique, underscoring the point that you cannot hunt for them by name alone.

The conclusion is undeniable: OAuth App Attacks are not just a theoretical threat; they are prevalent and often go undetected for years. The most important takeaway is this: statistically, there is a strong probability that your own tenant harbors one of these malicious applications.

Introducing Cazadora

If you’re now convinced of the need to audit your apps, that’s excellent. To help the community and give Azure administrators a practical tool for this task, I developed and released an open-source script.

This tool, named Cazadora, is a straightforward Azure app hunting script. It uses your user authentication to call the Microsoft Graph API, collects data on your tenant’s Enterprise Applications and App Registrations, and runs hunting logic against the results based on commonly observed malicious tradecraft.

While the script is not a silver bullet and cannot guarantee to find every malicious app, it provides Azure admins with a powerful starting point to identify obvious threats and begin securing their environment. Instructions for its use are available in the script’s repository. It is a crucial first step toward identifying and eliminating these hidden dangers from your Microsoft 365 tenant.

(Source: Bleeping Computer)