When Apps Attack: Hunting Traitorware and Rogue Microsoft 365 Apps at Scale

When Apps Attack: Hunting Traitorware and Rogue Microsoft 365 Apps at Scale

Speakers: Matt Kiely (Huntress); Christina Parry (Huntress)

Conference: BSides NYC

YouTube: https://www.youtube.com/watch?v=XSzfsz2zoQQ

Overview

In this compelling talk, "When Apps Attack: Hunting Traitorware and Rogue Microsoft 365 Apps at Scale," Matt Kiely and Christina Parry from Huntress shed light on what they describe as one of the most underappreciated and least understood methods of post-exploitation and initial access in Azure and Microsoft 365 environments: the abuse of OAuth applications. The presentation kicks off with a gripping narrative of Huntress researchers discovering a highly suspicious Microsoft 365 application, named simply with "eight dots" and possessing a credential object named with "five dots," which had delegated access to a specific user's email inbox. This discovery served as the genesis for their extensive research into the prevalence and characteristics of malicious OAuth applications, particularly within the small to medium business (SMB) sector, where such attacks had largely remained theoretical until now.

The core of the talk revolves around understanding how legitimate features of the Azure/M365 ecosystem, designed to enable powerful application integration, can be co-opted by attackers. Kiely and Parry meticulously detail the mechanics of OAuth consent, service principals, and permissions, illustrating how these components form a potent attack surface for persistence and data exfiltration. Their work highlights that these are not zero-day exploits but rather "feature not bug" abuses of the system as intended, making them particularly insidious and difficult to detect without specialized tooling and understanding.

The significance of this research for the cybersecurity community is profound. As cloud adoption accelerates, especially among SMBs that often lack dedicated security teams, the attack surface expands beyond traditional endpoints and network perimeters to include cloud identities and application permissions. Kiely and Parry's findings underscore the urgent need for defenders to grasp this vector, to implement robust auditing, and to leverage data-driven approaches to identify and mitigate rogue applications. Their contribution, including the release of the open-source RogApps project, aims to empower the community to collectively combat this rising threat.

Background

▶ Watch: The mysterious graph that shocked researchers (0:40)

The proliferation of cloud services, particularly Microsoft 365 and Azure, has introduced a new paradigm for application integration and identity management. At the heart of this integration lies OAuth, a standard for delegated authorization. As Matt Kiely aptly puts it, OAuth is "the Kerberos of the cloud," implying its complexity and potential for misuse, much like Kerberos in traditional Active Directory environments. Microsoft's design ethos for Azure is to be developer-friendly, encouraging a vast ecosystem of applications that connect to M365 resources. These applications, whether first-party (built in-house) or third-party, require specific permissions to interact with user data or tenant resources via the Microsoft Graph API.

The fundamental mechanism involves a user consenting to an application accessing resources on their behalf. By default, any user in Azure can install an application and consent to permissions that affect their own assets (e.g., their email inbox), though not necessarily global tenant resources unless they possess higher privileges. When consent is granted, a service principal—an instance of the application—is created within the user's home tenant. This service principal acts as a "little robot account" for the application, authenticated and authorized to access resources using tokens, specifically refresh tokens, which grant persistent access. This process, spanning authentication (AuthN) and authorization (AuthZ), is a standard, built-in feature of Azure.

However, this powerful and flexible system presents a significant attack surface. Attackers can leverage social engineering or compromised credentials to trick users into consenting to malicious applications or to install them directly if they have sufficient access. Because these attacks exploit the legitimate functionality of the system, they are not reliant on CVEs or traditional software vulnerabilities. Instead, they are "feature not bug" exploits, making them stealthy and persistent. The customizability inherent in Azure application development allows attackers to tailor permissions to achieve specific objectives, from accessing emails and calendars to manipulating user accounts or even escalating privileges to global tenant administration.

Kiely and Parry categorize these application-based attacks into two primary tradecraft types:

1. Traitorware: These are legitimate applications, developed for benign purposes by reputable developers, that are co-opted for malicious use. The analogy given is similar to RMM abuse or LOLBINS (Living Off the Land Binaries), where trusted tools are used for nefarious ends. A classic example cited is eM Client, a legitimate email client, which is frequently observed in business email compromise (BEC) and financial fraud attacks within SMBs. An attacker, having gained initial access, installs such an application, consents to its permissions (e.g., to sync all emails), and then uses the generated token to exfiltrate data or manipulate mailboxes.
2. OAuth Consent Grant Attacks: These involve custom-built, "farm-to-table evil applications" designed by attackers with the sole purpose of wreaking havoc. Unlike traitorware, these are purpose-made malware. Attackers register an application, configure it with the necessary permissions (e.g., Directory.ReadWrite.All to modify users, or permissions to stage inbox rules), and then either coerce a user into installing it (for initial access) or install it themselves (for persistence or post-exploitation). A key aspect of persistence is adding a password to the service principal of such an application, effectively creating a single-factor authentication backdoor that survives user password changes. This allows the attacker to authenticate as the application itself and continue to access resources via the Microsoft Graph API.

The problem is particularly acute for SMBs, which often lack the resources and expertise to identify these sophisticated, yet under-the-radar, threats. The research project undertaken by Huntress was specifically designed to quantify and understand the scope of these application attacks in this vulnerable sector.

Key Findings

▶ Watch: Unveiling the rogue 'dot dot dot' M365 app (2:00)

The Huntress research yielded several critical findings that underscore the prevalence and danger of rogue Microsoft 365 applications, particularly in the SMB space:

1. Validation of SMB Exploitation: The initial discovery of the "eight dots" application in a Huntress partner's M365 tenant provided concrete evidence of Azure OAuth application exploitation occurring in SMBs. Up until this point, such attacks were largely theoretical or confined to academic papers and red team exercises, making this a significant real-world validation. The application, despite its innocuous name, had delegated access to a user's email inbox, demonstrating a clear post-exploitation foothold.
2. Widespread Presence of Rogue Apps: Across a sample data set of 2,500 M365 tenants, Huntress enumerated over 6,000 applications and 14,000 service principals. They found numerous tenants with applications that exhibited characteristics of potential exploitation. Alarmingly, some tenants even harbored multiple suspicious applications, with some lurking undetected in environments for extended periods.
3. Prevalence as a Detection Indicator: The research leveraged the concept of "prevalence" to identify unusual applications. While common applications (e.g., Microsoft To Do, SharePoint) naturally fall into the 90-100% prevalence bracket, the vast majority of applications and service principals (99% of apps and >91% of service principals) were found in the "less than 1% prevalence" bucket. This indicates that most applications are unique or highly customized to individual tenants, making low prevalence a key indicator for further investigation into potentially malicious custom-built apps or unique instances of traitorware.
4. Identification of Dangerous Permission Patterns: Specific OAuth permission scopes were identified as high-risk indicators for malicious activity. These include:

• MailboxSettings.ReadWrite.All: Grants an application broad access to read and write all mailbox settings, enabling activities like creating inbox rules for forwarding emails, a common tactic in BEC.
• Directory.ReadWrite.All: Effectively grants global tenant admin permissions, allowing an application to add, modify, or delete users and change passwords, leading to significant privilege escalation and control.
• Files.Read.All: Allows an application to read all files, potentially leading to widespread data exfiltration.

The combination of such powerful permissions with low prevalence or an unknown/unverified publisher domain significantly raises suspicion.

1. The "Needle in a Haystack" Problem: The sheer volume and customizability of applications make hunting for rogue apps a "needle in a haystack" problem. No two custom-built malicious applications are likely to be identical in name or configuration, necessitating a data-driven approach that looks for patterns in permissions, prevalence, and other attributes rather than specific names.
2. Persistence through Service Principal Passwords: A critical finding for post-exploitation is the ability for attackers to add a password to an application's service principal. This grants persistent, single-factor authentication to the application, allowing continued access to resources even if the compromised user's password is changed. This makes OAuth apps a highly effective persistence mechanism.
3. Growing Threat Vector: The talk highlighted that approximately 20% of all categorized threats are related to OAuth apps, and this number is on the rise. While traditional account takeovers remain the most prevalent attack vector, OAuth app exploitation is a "sneakier" way to persist and gain initial access, often with less defensive telemetry compared to token theft or VPN logs.

These findings collectively paint a picture of a significant and evolving threat landscape, urging organizations to prioritize the security of their M365 application ecosystem.

Technical Deep Dive

▶ Watch: First evidence of Azure OAuth app exploitation in SMB (2:40)

The technical foundation for understanding rogue M365 applications lies in the intricate workings of OAuth within Azure Active Directory (now Microsoft Entra ID). At its core, OAuth facilitates delegated authorization, allowing third-party applications to access user data on behalf of a user without requiring the user's credentials.

The process typically begins when an end-user wishes to integrate an application (e.g., a calendar organizer, an email backup tool) with their M365 tenant. The application, which resides in its own developer tenant, requests specific permissions to operate. These permissions define what the application can do (e.g., Mail.Read, User.ReadWrite.All). The user is then presented with a consent prompt, detailing the requested permissions.

Crucially, by default in Azure, any user can consent to an application accessing resources that they themselves control. For instance, a low-privilege user can install an app that accesses their own email inbox, but not necessarily everyone else's. If the user accepts, two key events occur:

1. Authentication (AuthN): The user authenticates with Azure, proving their identity.
2. Authorization (AuthZ): The user explicitly grants the application permission to act on their behalf with the specified scopes.

Upon consent, a service principal is instantiated and created in the user's home tenant. The service principal is a local representation or "instance" of the global application object. It's essentially a non-human identity that the application uses to interact with Azure resources. This service principal is tied to the permissions granted during consent and the identity of the user who installed it. When the application needs to perform an action (e.g., sync emails), it uses the service principal to obtain an access token (and often a refresh token) from Azure. This token is then presented to the Microsoft Graph API, which is the unified endpoint for accessing data and intelligence in Microsoft 365. The Graph API validates the token and the permissions, allowing the application to perform the requested operation.

Attackers exploit this system in several ways:

• Initial Access via Consent Phishing: Attackers can craft malicious applications and then use phishing campaigns to trick users into consenting to them. If a user consents, the attacker gains access to the user's data or tenant resources via the newly created service principal.
• Persistence through Service Principal Credentials: A particularly potent method for persistence involves adding a password or a certificate credential to the service principal object itself. This allows the attacker to authenticate directly as the application, bypassing user accounts. Even if the original user's password is changed or their account is disabled, the attacker can maintain access to the tenant through the application's service principal, making it a highly stealthy and resilient backdoor. Matt Kiely explicitly demonstrated this by showing how an attacker could use az CLI commands to authenticate as the service principal and then enumerate users or manipulate inbox rules.
• Customizable Permissions: The Azure application model allows for granular control over permissions. Attackers can register custom applications ("OAuth Consent Grant Attacks") and request highly privileged permissions such as Directory.ReadWrite.All (for tenant-wide administrative control) or MailboxSettings.ReadWrite.All (for email manipulation). This customizability means no two malicious applications are necessarily alike, complicating detection efforts based on static signatures.
• "Traitorware" Abuse: Legitimate applications often require broad permissions to function. Attackers can leverage these applications (e.g., eM Client) post-compromise. By installing such an app with a compromised user's credentials, they gain access to the user's data and can use the legitimate application's functionality for malicious purposes, such as exfiltrating emails or setting up forwarding rules.

The critical insight is that these are not vulnerabilities but rather the intended functionality of Azure's application model. The danger lies in the lack of visibility and auditing that many organizations, especially SMBs, have over the applications installed in their tenants and the permissions they hold. The system's flexibility, designed for legitimate development, becomes a powerful toolkit for exploitation in the hands of an adversary.

Demo / Proof of Concept

▶ Watch: Talk agenda: Azure apps, tradecraft, and research (4:40)

Huntress's research involved a comprehensive proof of concept (POC) designed to identify rogue Microsoft 365 applications at scale. Christina Parry detailed the methodology and infrastructure used to achieve this:

The core objective was to test the hypothesis that OAuth application attacks were prevalent in SMBs and to identify red flags for detection. The team focused on three main areas for investigation:

1. Prevalence: Identifying the most and least common applications and service principals across tenants.
2. Permission Scope: Pinpointing applications with powerful or suspicious permissions.
3. User Persistence: Understanding how attackers leverage app permissions for persistence.

Data Acquisition:

The primary source of data was the Microsoft Graph API. This API provides a programmatic interface to access M365 data, including information about users, applications, service principals, and their associated permissions. Access tokens were obtained to query this tenant data.

ETL Pipeline and Infrastructure:

Huntress built an Extract, Transform, Load (ETL) pipeline, predominantly using Python, to process the vast amount of data.

• Environment: The entire infrastructure was hosted on AWS.
• Data Collection: A dedicated EC2 instance ran the Python script for collecting tenant data. This script was multi-threaded to handle the volume efficiently.
• Caching: Data for previously seen tenants was cached in S3 buckets, preventing redundant collection and optimizing the process for subsequent runs.
• Data Ingestion:
• Elasticsearch (ELK stack): Data was bulk ingested into Elasticsearch, providing a powerful search and querying engine. This allowed researchers to easily search, pivot, and perform aggregations on various fields (e.g., display name, publisher domain, permissions). Elastic's ES QL language, similar to Splunk's SPL, was used for data wrangling and analysis, particularly for determining prevalence.
• Neo4j: Data was also ingested into Neo4j, a graph database. This was crucial for visualizing and identifying uncommon or unusual relationships between nodes (apps, tenants, users, permissions). While the initial iteration faced bottlenecks with Neo4j ingestion for the full dataset, it was intended to highlight complex interconnections that might indicate malicious activity.
• Output Methods: The processed data was available in Elasticsearch, Neo4j, or as a compressed zip file for ad-hoc analyses and summary scripts.

Data Model Normalization:

To effectively analyze the data in Elasticsearch and Neo4j, the raw JSON output from the Graph API (which could be up to 2MB per tenant) was normalized. This involved breaking down the one-to-many relationships (e.g., one tenant having many users, many applications, many service principals) into distinct, normalized data models for users, applications, and service principals. Each document included a type field (user, app, or service principal), ID fields (user ID, tenant ID, application ID, object ID), and relevant attributes like display name, user principal name, publisher domain, sign-in audience, password credentials, resource accesses, and OAuth permission scopes. This structured approach facilitated efficient querying and relationship mapping.

Findings and Analysis:

Using Elasticsearch, the team performed aggregations to identify the most common applications. Unsurprisingly, these were mostly Microsoft-related services like Microsoft To Do, SharePoint, and Microsoft Graph. However, the true value came from analyzing the low-prevalence apps (less than 1% prevalence). This bucket contained 99% of all analyzed applications and over 91% of service principals, indicating a high degree of customization and uniqueness, making it the prime hunting ground for rogue apps.

They identified suspicious service principals by looking for unknown publishers, low prevalence, and dangerous permission combinations like Directory.ReadWrite.All or MailboxSettings.ReadWrite.All. Examples of suspicious app names like "couch dropper" or "clone" combined with these technical indicators raised red flags.

While the full scale of data ingestion into Neo4j was limited in this first iteration due to time and ETL bottlenecks (taking about a week for the initial 2,500 tenants), the framework successfully proved its ability to identify patterns indicative of OAuth app attacks and traitorware. The POC demonstrated that a data-driven approach, combining prevalence analysis with permission scrutiny, is effective in teasing out malicious applications from the legitimate noise in M365 environments.

Defensive Implications

▶ Watch: Crash course: Azure applications and OAuth explained (5:20)

The research by Matt Kiely and Christina Parry offers crucial, actionable insights for defenders looking to safeguard their Microsoft 365 environments against rogue applications and OAuth consent grant attacks. The core message is that proactive management and auditing of applications are paramount.

1. Enforce Multi-Factor Authentication (MFA) / Two-Factor Authentication (2FA): While not directly preventing app installation, MFA significantly raises the bar for initial account compromise, which is often a prerequisite for an attacker to either install a malicious app or coerce a user into consenting to one. Making it harder for threat actors to gain initial access reduces the likelihood of these downstream app-based attacks.
2. Restrict User Consent for Applications ("No Shadow IT"): By default, users can install applications and grant permissions to their own resources. This "shadow IT" allows unmonitored applications to gain access. Admins should proactively manage user consent settings in M365. Ideally, users should not be allowed to add new applications without administrative review or approval. This can be configured in the Azure Active Directory admin center.
3. Implement the Principle of Least Privilege: When an application is legitimately required, ensure it is granted only the absolute minimum permissions necessary for its function. Avoid granting broad permissions like Directory.ReadWrite.All or MailboxSettings.ReadWrite.All unless explicitly justified and thoroughly vetted. Regularly review existing application permissions to ensure they are still appropriate.
4. Routine Auditing of Applications: This is perhaps the most critical takeaway. Organizations running M365 tenants must regularly audit their applications. This involves going into the Azure dashboard (specifically the Enterprise applications and App registrations sections) and reviewing:

• Application Names: Look for suspicious, generic, or unusually named applications (e.g., the "eight dots" app, "nothing sus lol," "admin app").
• Publisher Domains: Verify the publisher of the application. Unknown or unverified publishers, especially for apps with powerful permissions, are red flags.
• Permissions Granted: Scrutinize the OAuth permission scopes held by each application. Prioritize review of apps with high-risk permissions.
• Creation/Last Used Dates: Identify old, unused applications that might still hold persistent access.
• Service Principal Passwords: Check if any service principals have passwords configured, as this is a prime persistence mechanism for attackers.
• Remove Unused Applications: Any application that is no longer in use should be promptly removed from the tenant to reduce the attack surface.

1. Leverage Threat Intelligence and Community Resources: The talk introduces RogApps, an open-source GitHub repository powered by Huntress. This community-driven project aims to build a library of known malicious applications and their associated tradecraft. Defenders are encouraged to contribute their findings (e.g., observed traitorware like eM Client used maliciously) to this resource. This collective intelligence helps identify common patterns and specific applications known to be abused.
2. Enhance Telemetry and Monitoring: While current telemetry for OAuth app activity might be lacking compared to other attack vectors, organizations should strive to improve their logging and monitoring capabilities around application installations, consent grants, and service principal activity. This can help detect anomalous behavior early.
3. Educate Users: While technical controls are vital, user education on identifying phishing attempts and the implications of consenting to applications remains an important layer of defense.

By implementing these defensive strategies, organizations can significantly reduce their exposure to application-based attacks, moving from a reactive stance to a proactive one in securing their cloud environments.

Key Takeaways

• OAuth Application Exploitation is a Growing, Underappreciated Threat: Rogue Microsoft 365 applications, leveraging legitimate OAuth functionality, are a significant and rising attack vector for initial access and persistence, particularly targeting SMBs.
• "Feature, Not Bug" Exploits are Insidious: These attacks exploit the intended functionality of Azure's application model, making them difficult to detect with traditional vulnerability scanning and often flying under the radar of standard security telemetry.
• Proactive Auditing of Applications is Critical: Regularly review all applications and service principals in your M365 tenant. Pay close attention to app names, publisher domains, and especially the permissions granted. Remove any unused or suspicious applications.
• Implement Principle of Least Privilege for App Permissions: Restrict user consent for applications and ensure that any legitimately installed applications are granted only the minimum necessary permissions. Avoid broad, high-impact scopes.
• Service Principal Passwords Enable Persistent Backdoors: Be aware that attackers can add passwords to service principals, creating persistent access that bypasses user password changes. Monitor for such configurations.
• Contribute to and Utilize Community Threat Intelligence: Leverage resources like the open-source RogApps project to share and gain knowledge about known malicious applications and their tradecraft. Collective intelligence is vital for combating this evolving threat.

About the Speaker(s)

Matt Kiely, known as HuskyHacks in the community, is a video practitioner and works at Huntress. He is also an instructor at TCM Security Academy, demonstrating his commitment to both practical cybersecurity and education. His expertise lies in understanding complex attack vectors and translating them into actionable intelligence for defenders.

Christina Parry is a Staff Product Developer at Huntress, with over two years of experience at the company. Her background is primarily in blue teaming, where she focuses on building end-to-end Proof of Concepts (POCs) and detection capabilities for Huntress's detection engineers, threat intelligence team, and SOC. Her work on this project exemplifies her ability to wrangle and analyze large datasets to uncover novel threats.