Do Apps Have Imposter Syndrome? Unmasking Token Theft Campaigns

Do Apps Have Imposter Syndrome? Unmasking Token Theft Campaigns

Speakers: Shahar Dorfman, Threat Researcher, Whiz; Sapir Federovsky, Threat Researcher, Whiz

Conference: fwd:cloudsec

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

Overview

In an era where identity is the new perimeter, the security of applications and their interactions within cloud environments is paramount. This talk, "Do Apps Have Imposter Syndrome? Unmasking Token Theft Campaigns," by Shahar Dorfman and Sapir Federovsky of Whiz, delves into a critical and often overlooked attack vector: the abuse of OAuth applications in Azure environments. The speakers illuminate how attackers exploit the trust model inherent in multi-tenant applications to conduct sophisticated token theft campaigns, leading to persistence, privilege escalation, and even supply chain compromises.

The presentation provides a comprehensive breakdown of the Azure identity provider, ENTRA (formerly Azure Active Directory), and the intricate relationship between applications and service principles. Dorfman and Federovsky demonstrate how malicious actors craft seemingly legitimate applications to trick users into granting consent, thereby obtaining access tokens and establishing a foothold within victim tenants. The core of their research focuses on a novel, AI-powered pipeline designed to detect these stealthy threats by analyzing application properties and identifying subtle indicators of compromise that blend into legitimate cloud activity.

This research is particularly significant because it addresses a problem that traditional security measures often miss. Unlike malware or exploits, the abuse of OAuth applications leverages legitimate functionalities, making detection challenging. The talk offers a crucial roadmap for defenders, detailing a methodical approach to identifying and mitigating these "imposter" applications, emphasizing the importance of a multi-faceted detection strategy that goes beyond single indicators and leverages contextual analysis to unmask sophisticated campaigns.

Background

▶ Watch: Introduction: Do Apps Have Imposter Syndrome? (0:00)

Azure's identity provider, ENTRA, is the central nervous system for managing identities such as users, applications, service principles, and managed identities. It orchestrates authentication, configures multi-factor authentication (MFA) and conditional access policies, and assigns roles and API permissions. A fundamental concept within ENTRA is the distinction between an application and a service principle. An application is a unique object residing in a single tenant where it was initially created. However, for applications to function across multiple organizations (i.e., be multi-tenant), Microsoft employs service principles. A service principle acts as a local representation of an application within a specific environment. When a user grants consent to an application, they are essentially giving a "visa" for its corresponding service principle to operate within their tenant, creating a one-to-many relationship where one application can have many service principles across different organizations.

The developer of an application controls its properties, including its name, homepage, logo, and the set of permissions it requests during the consent process. Attackers exploit this control by creating malicious multi-tenant applications with deceptive names, logos, and homepages designed to mimic legitimate services like Microsoft Teams or DocuSign. They define a redirect URI (also known as a reply URL) pointing to an attacker-controlled domain, where stolen tokens will be sent after a victim authenticates. The crucial step is the consent page, presented to the user when they attempt to sign in to the attacker's application. This page displays the application's name, requested permissions, and, importantly, indicates if the publisher is "unverified." If a user, unaware of the subtle deception (e.g., a '0' instead of an 'O' in "Microsoft"), clicks "Accept," several critical events unfold: a service principle for the malicious application is created in their tenant with the granted permissions, and their access token is immediately sent to the attacker's defined reply URL. This mechanism allows attackers to achieve various objectives beyond initial token theft, including persistence (the service principle remains in the victim's tenant), privilege escalation (if the consenting user has high privileges), and even supply chain attacks by compromising legitimate multi-tenant applications.

Key Findings

▶ Watch: Understanding ENTRA, Applications, and Service Principles (2:00)

The central discovery of this research is the development and validation of a robust, multi-stage pipeline capable of unmasking sophisticated OAuth token theft campaigns. The speakers identified that while individual indicators of compromise (IOCs) might be weak, their aggregation and contextual analysis can reliably surface malicious applications that would otherwise blend into the noise of legitimate cloud activity. Their model successfully transitions from a manual hunting process to an automated, scalable detection system, capable of identifying "imposter" applications by scrutinizing their underlying properties and behaviors.

A significant finding is the prevalence of these attacks and their organized nature. Dorfman and Federovsky observed the same malicious applications and campaigns across multiple victim environments, underscoring that these are not isolated incidents but often part of broader, coordinated efforts. The ability to pivot on shared indicators, such as app owner tenant IDs or DNS infrastructure, proved crucial in connecting seemingly disparate malicious applications to larger campaigns, allowing for a more comprehensive understanding and mitigation strategy. Furthermore, the integration of Large Language Models (LLMs) into the detection pipeline represents a key innovation, automating the contextual checks that previously required human intervention. This allowed the model to become "completely automatic and independent," significantly improving its scalability and efficiency in alerting customers with high confidence about malicious application consent.

Technical Deep Dive

▶ Watch: Attacker's perspective: Creating a malicious multi-tenant application (4:00)

The core of the Whiz team's solution is a five-step pipeline designed to identify and analyze suspicious OAuth applications. This pipeline systematically processes application data, enriches it with external context, scores potential threats, leverages AI for validation, and finally pivots on shared indicators to uncover broader campaigns.

1. Visibility and Baseline Construction:

The initial step involves ingesting service principle data from numerous organizations. This forms a baseline by identifying the most common app IDs and application names across tenants. Common applications are generally more likely to be legitimate SaaS integrations, providing a reference point for comparison. Beyond app IDs and names, other critical properties like homepage, display name, reply URL, and verified publisher status are also ingested.

1. Enrichment:

Raw JSON data of service principles is insufficient for robust detection. The pipeline enriches key fields to add context. This includes:

• Application Name Analysis: Identifying applications that mimic legitimate brand names but possess different app IDs.
• Commonality & Ownership: Analyzing how frequently an application appears across organizations and how many applications a specific app owner has created.
• External Context Integration: Utilizing external services like Validin to query the domains of the reply URL and homepage URL. This allows for pivoting on DNS properties (e.g., name servers, IP resolutions) and HTTP responses to uncover connections to other hosts controlled by attackers.
• Microsoft Graph Querying: Using Microsoft Graph to retrieve the owner tenant ID and subsequent details like the owner tenant name and its primary domain. This is vital for detecting inconsistencies where an application claims to be a well-known brand, but its owner tenant domain is unrelated. For example, a "DocuSign" application whose owner tenant domain is "myclickfinance.com" immediately raises suspicion.

1. Decision and Weighted Scoring:

A single suspicious indicator, such as an unverified publisher, is rarely sufficient to conclusively identify a malicious application. The model employs a weighted scoring mechanism that combines multiple weak signals into a strong, actionable threat indicator. For instance, an unverified publisher combined with a suspicious reply URL and a common, mimicked application name creates a much higher confidence score. This mechanism prioritizes applications for further investigation. The model aims to surface approximately "50 service principal applications that are suspicious" for deeper analysis.

1. AI for Contextual Evaluation (LLM Integration):

Initially, the contextual checks (e.g., manually Googling suspicious URLs or investigating company names) were performed by human analysts. To overcome the scalability bottleneck, LLMs were integrated into the pipeline. The LLMs are fed specific sets of properties associated with the suspicious applications identified in the scoring phase. Their role is not to creatively discover new threats but to automate and accelerate the human-like contextual evaluation, such as confirming if an owner domain makes sense for a given application name. This integration transformed the model into a "completely automatic and independent" system.

1. Pivoting on Shared Indicators:

Once a suspicious application is identified, the pipeline seeks to determine if it's an isolated incident or part of a larger campaign. This is achieved by pivoting on shared indicators:

• App Owner Tenant: Any other applications created within the same app owner tenant are highly likely to be malicious, as the tenant itself is controlled by the attacker.
• Reply URL and Owner Domain: These can be used to pivot on shared DNS infrastructure (e.g., common name servers, IP addresses) or HTTP infrastructure. These shared infrastructure elements can then lead to other domains, which might serve as reply URLs or homepages for other malicious applications, ultimately revealing additional compromised owner tenants and more malicious OAuth applications.

This pivoting strategy allows the detection of entire campaigns, as demonstrated by an example where a single malicious application led to the discovery of three other distinct, mimicked applications created by the same attacker, subsequently identifying more victims.

The technical distinctions between a legitimate and malicious application are stark. For instance, a legitimate DocuSign application would have a verified publisher, a homepage of "docuign.com," and a reply URL belonging to its official domain. In contrast, a malicious DocuSign imposter would typically have an empty homepage, an unverified publisher, a reply URL pointing to a suspicious domain like "myclickfinance," and an app owner name that is a random company unrelated to DocuSign. The app ID and app owner tenant ID would also be distinctly different, binding the malicious service principle to the attacker's infrastructure.

Demo / Proof of Concept

▶ Watch: Analyzing service principal properties for abuse detection (6:30)

The speakers provided a clear demonstration of the attacker's workflow and the subsequent user experience during an OAuth token theft campaign. The scenario began in the attacker's Azure tenant, where they navigated to "App registrations" to create a new application. For the demo, they named it "for cloud sec demo" and configured it as a multi-tenant application. Crucially, they defined a redirect URI pointing to their own malicious domain, "malicious," ensuring that any tokens issued would be sent there. They also had the option to upload a custom logo and specify a homepage, both of which could be manipulated to enhance legitimacy. Finally, they defined the specific permissions the application would request during consent (e.g., access to various resources in the victim's environment).

The victim's perspective was then shown:

1. Initial Access: The victim, in their own tenant, did not have the malicious application registered. They were lured to the attacker's application UI and clicked "Sign in with Microsoft."
2. Consent Page: The user was redirected to Microsoft's consent page. This is the most critical juncture. The page displayed the application name ("for cloud sec demo"), explicitly stated its owner was unverified, and listed the permissions it was requesting (e.g., "access your data").
3. Consent Grant: Upon the victim clicking "Accept," several key events occurred:

• A service principle for "for cloud sec demo" was immediately created within the victim's tenant.
• The permissions granted by the user were attached to this newly created service principle.
• The victim's access token was sent to the attacker's specified reply URL ("malicious"). In the demo, this was visibly printed to the screen, illustrating the token exfiltration.
• The service principle then used its newly acquired permissions to query for user information, demonstrating its immediate operational capability within the victim's environment.

1. Tenant Verification: Back in the victim's ENTRA ID tenant, the newly created service principle was visible, reflecting the properties defined by the attacker, including the granted permissions. This confirmed the successful establishment of persistence through the malicious application.

This demonstration effectively illustrated how attackers leverage legitimate OAuth flows to gain unauthorized access and persist within an organization, highlighting the subtle cues (like "unverified" publisher) that users often overlook.

Defensive Implications

▶ Watch: How attackers abuse OAuth applications: Phishing (8:00)

Understanding the mechanics of OAuth application abuse provides crucial insights for strengthening an organization's defensive posture against token theft campaigns. The speakers highlighted several key areas for defenders to focus on:

1. User Education is Paramount: Despite technical controls, user awareness remains a critical first line of defense. Organizations must educate users to carefully scrutinize consent prompts. Key indicators to look for include an unverified publisher status, suspicious-looking reply URLs (which may not always be visible on the consent page but can be part of the URL itself), and application names that mimic legitimate services but might contain subtle misspellings (e.g., a '0' for an 'O'). Users should be trained to question requests for excessive permissions from unfamiliar applications.

1. Implement Granular Consent Policies: While educating users is vital, organizations can also implement policies to restrict who can consent to what types of applications and permissions. Azure allows administrators to configure user consent settings, such as allowing consent only for applications from verified publishers or requiring administrator consent for specific high-privilege permissions. This can significantly reduce the attack surface, although it requires careful management to avoid hindering legitimate application usage.

1. Proactive Monitoring of Service Principles: The research emphasizes that detection shifts from identifying malicious applications to monitoring the behavior of legitimate or newly created service principles. Defenders should establish baselines for normal service principle activity and look for shifts in behavior. This includes:

• Unusual sign-in locations (e.g., a service principle suddenly signing in from an unusual IP address or an unexpected geographical region).
• Unusual user agents associated with service principle activity.
• Access to unusual or uncharacteristic resources for a given service principle.
• Creation of new users or modifications to existing configurations by service principles, which could indicate persistence efforts.

1. Focus on Supply Chain Attack Detection: The talk underscored the growing threat of supply chain attacks where legitimate multi-tenant applications are compromised. In these scenarios, the detection challenge is even greater, as the application itself is trusted. Defenders must develop capabilities to identify when a trusted service principle begins to behave in an anomalous way, even if the application itself is legitimate.

1. Indicator Sharing and Collaboration: The observation that the same malicious applications and campaigns are seen across multiple environments highlights the importance of sharing indicators of compromise (IOCs). This extends beyond simple app IDs to include app owner tenant IDs, suspicious reply URLs, owner domains, and associated DNS/HTTP infrastructure. Collaborative efforts among organizations and with security vendors like Microsoft can significantly improve collective defense against these widespread campaigns.

1. Understand Attacker Post-Compromise Actions: Once an attacker gains access via a malicious OAuth application, their actions typically involve:

• Email Exfiltration: In "99% of the cases," attackers immediately read and exfiltrate emails, often leading to Business Email Compromise (BEC).
• Persistence: Creating new users or modifying existing ones to maintain a foothold.
• Data Querying: A new trend noted is attackers authenticating to Copilot (Microsoft's AI assistant), presumably to query and leak information from the organization, though the exact nature of their activities here is still being investigated.

By adopting a comprehensive strategy that combines user education, policy enforcement, advanced behavioral monitoring, and intelligence sharing, organizations can significantly improve their ability to detect and respond to sophisticated OAuth application abuse.

Key Takeaways

• OAuth Application Abuse is a Pervasive Threat: Attackers are actively exploiting the trust model of multi-tenant OAuth applications in Azure to steal tokens, establish persistence, and achieve privilege escalation.
• Deceptive Applications Blend In: Malicious applications mimic legitimate services, leveraging attacker control over properties like names, logos, and redirect URIs to trick users into granting consent.
• Multi-Indicator Detection is Essential: Relying on single indicators (e.g., unverified publisher) is insufficient. Effective detection requires a weighted scoring mechanism that combines multiple weak signals and contextual information.
• AI Enhances Scalability: Integrating LLMs into the detection pipeline automates contextual checks, transforming manual analysis into a scalable, autonomous system for identifying suspicious applications.
• Pivoting Uncovers Campaigns: Analyzing shared indicators such as app owner tenant IDs and DNS/HTTP infrastructure allows defenders to connect isolated malicious applications to broader, organized token theft campaigns.
• User Education and Behavioral Monitoring are Critical: Alongside technical controls, educating users to scrutinize consent prompts and proactively monitoring for anomalous service principle behavior are vital for preventing and detecting these attacks.

About the Speaker(s)

Shahar Dorfman is a Threat Researcher at Whiz. His work focuses on uncovering and analyzing emerging threats within cloud environments, particularly those related to identity and application security. In this talk, he co-presented the detailed methodology and findings of their research into OAuth application abuse.

Sapir Federovsky is also a Threat Researcher at Whiz. She collaborates with Shahar Dorfman on identifying and understanding sophisticated attack vectors in cloud security. Her contributions to the talk included explaining the foundational concepts of Azure ENTRA and demonstrating the attacker's perspective of an OAuth token theft campaign. Together, their research at Whiz aims to develop innovative solutions for detecting and mitigating complex cloud-native threats.