Azure App-Mirage: Bypassing Application Impersonation Safeguard

Varonis researchers discovered a loophole that made it possible to create malicious applications with deceptive names like "Azure Portal." By bypassing safeguards that prevent the use of reserved names, the vulnerabilities allowed attackers to impersonate Microsoft applications.  

When not properly managed, Azure applications can pose serious security risks, such as enabling initial access, persistence, and privilege escalation within a Microsoft 365 tenant. This can result in data loss and reputation damage for organizations. 

During our investigation, we focused on initial access tactics like illicit consent grants and device code phishing, which trick users into granting permissions and allow attackers to obtain access tokens without stealing passwords. 

This approach creates confusion among users, who might mistake them for legitimate Microsoft services. Warnings about non-Microsoft-owned applications are often ignored, partly due to the lack of signatures on many Microsoft applications.  

To create fake Azure applications that appeared to be real, Varonis Threat Labs added “Azure Portal” between each character in the application name, using hidden Unicode characters. 

We found one character that allowed this initially, and after disclosing it to Microsoft, we found an additional 261 characters. Microsoft patched the first vulnerability  in April 2025 and the second in October 2025, helping prevent future exploitation and emphasizing the need for continuous cybersecurity vigilance. Customers are protected with this fix and do not need to take any action. 

What are Azure applications?

Azure applications are software entities that can interact with Azure services and resources. Users can consent to these applications delegating permissions with two options: allowing the application to act on behalf of the user or application permissions that can give the application service principal its own set of permissions to access resources.

Delegated permissions also give the applications the same permissions the user has, including emails, messages, and access to resources like files. This level of access allows the application to perform tasks on behalf of the user across various platforms, making it a powerful tool and a potential security risk if not managed properly.

Azure applications as an attack vector

At Varonis, we search for new ways to protect our clients from various attack vectors, including malicious Azure applications.

For reference, read Using Malicious Azure Apps to Infiltrate a Microsoft 365 Tenant by Eric Saraga.

Azure applications can be abused in three main ways:

• Initial Access: The attacker gained access after an external message was sent and an organizational user consented, allowing the attacker to access the same resources as the user.
• Persistence: The attacker created the app (either in the attacked tenant or outside the tenant) and used an admin they have a hold over to allow the relevant Service Principal high privileges.
• Privilege Escalation: An attacker has a hold of a user inside the tenant and uses the application to gain higher privileges. 

For this publication, we will focus on Initial Access.

There are two main ways to utilize Azure applications to gain initial access: an Illicit consent grant and device code phishing.

Both require the attacker to pass a URL to the victim, which is commonly done through phishing. They also depend on an attacker creating a malicious Azure application that requires specific permissions from an unsuspecting user. These permissions can vary, depending on the attacker’s goal.

Once the victim consents to the application, the attacker receives an access token and effectively takes over the victim’s account (per the relevant permissions).

1. Illicit consent grant: A common scenario for this attack type is sharing a link to what appears to be a file that redirects to the consent page. Once the user consents, the attacker can show the file or an error. Regardless, the attacker receives a token for the user without physically stealing the password.
2. Device code phishing: An attacker can create an application with the desired permissions and allow public client flow. Once done, they can generate a verification URI and user and device code. The victim must navigate the verification URI and enter the user code. Once that is done, the attacker uses the device code to receive the victim’s access token.

This method doesn’t have to utilize a specific application; instead, it can use the “az login” command. For our purpose, we used an application because it gives us the freedom to choose the application's name that the victim will consent to.

Learn how to protect your environment with our Cloud Security Buyer's Guide.

Download our guide

The vulnerability — impersonating Microsoft applications

During our research, we discovered that Microsoft implemented a safeguard that prevents giving cross-tenant applications specific names. The prohibited names are derived from the following pages:

• Verify first-party Microsoft applications in sign-in reports | Microsoft Learn (The current version of the page no longer holds these names)
• Azure Portal app registration page (requires login to your environment)

This is the complete list of names that we tested that are prohibited:

• ADIbizaUX
• Azure Advanced Threat Protection
• Azure Data Lake
• Azure Portal
• Azure SQL Database
• AzureSupportCenter
• Bing
• CPIM Service
• Enterprise Roaming and Backup
• FindTime
• Microsoft 365 Security and Compliance Center
• Microsoft 365 Support Service
• Microsoft App Access Panel
• Microsoft Approval Management
• Microsoft Authentication Broker
• Microsoft Azure CLI
• Microsoft Azure PowerShell
• MicrosoftAzureActiveAuthn
• Microsoft Bing Search
• Microsoft Bing Search for Microsoft Edge
• Microsoft Bing Default Search Engine
• Microsoft Defender for Cloud Apps
• Microsoft Defender for Identity (formerly Radius Aad Syncer)
• Microsoft Docs
• Microsoft Dynamics ERP
• Microsoft Edge Insider Addons Prod
• Microsoft Exchange ForwardSync
• Microsoft Exchange Online Protection
• Microsoft Exchange ProtectedServiceHost
• Microsoft Exchange REST API Based PowerShell
• Microsoft Exchange Web Services
• Microsoft Exchange Message Tracking Service
• Microsoft Forms
• Microsoft Graph
• Microsoft Intune Web Company Portal
• Microsoft Intune Windows Agent
• Microsoft Office
• Microsoft Office 365 Portal
• Microsoft Office Web Apps Service
• Microsoft Online Syndication Partner Portal
• Microsoft Outlook
• Microsoft password reset service
• Microsoft Power BI
• Microsoft Storefronts
• Microsoft Stream Portal
• Microsoft Substrate Management
• Microsoft Support
• Microsoft Teams
• Microsoft Teams Services
• Microsoft Teams Web Client
• Microsoft Whiteboard Services
• O365 SkypeSpaces Ingestion Service
• O365 Suite UX
• Office 365 Exchange Online
• Office 365 Management
• Office 365 Search Service
• Office 365 SharePoint Online
• Office Delve
• Office Online Client Microsoft Entra ID- Augmentation Loop
• Office Online Client Microsoft Entra ID- Loki
• Office Online Client Microsoft Entra ID- Maker
• com
• Office 365 Shell WCSS-Client
• OfficeClientService
• OfficeShredderWacClient
• OneDrive SyncEngine
• OneNote
• Outlook Mobile
• Power BI Service
• SharePoint Online Web Client Extensibility
• Skype for Business Online
• Sway
• WeveEngine
• Windows Azure Active Directory
• Windows Azure Security Resource Provider
• Windows Azure Service Management API
• Windows Defender ATP Portal
• Windows Spotlight
• Windows Store for Business

When registering an application with the name “Azure Portal,” we encountered an error message, “The name of your application is invalid.”

When using MSGraph, we get the error message, “The display name of your application is invalid.”

To try to bypass this limitation, we used invisible Unicode characters. After a few tries, we found that the Combining Grapheme Joiner ͏character (0x34f) allows us to create “Azure Portal” as the application name by adding it between each character in the name:

	
		
/**
Az$([char]0x34f)ur$([char]0x34f)e Po$([char]0x34f)rtal
 
	

This worked for a total of 262 found characters, including any of the following:

• 0x34f (As seen in the example)
• 0x17b4
• 0x17b5
• 0x180b
• 0x180c
• 0x180d
• range(0xfe00, 0xfe10) # Not including end
• range(0xe0100, 0xe01f0) # Not including end
  

The name “Azure Portal” is visible when sending the victim the application.

Going one step forward and setting an image makes it more reliable:

While safeguards are implemented to protect and notify users that the application they consent to is not actually Microsoft-owned, many Microsoft applications are created by Microsoft but not verified by them.

This can lead to confusion, and in some cases, people will ignore the warning:

Conclusion and recommendations

Although the vulnerabilities have been fixed, there are recommendations to help keep organizations safe from similar attack techniques involving Azure Applications.

Restrict user consent

Use the Entra admin center to restrict users from consenting to applications with two possible settings:

• Do not allow user consent: All apps will require an administrator.
• Allow user consent for apps from verified publishers. For selected permissions: All users can consent to permissions classified as "low impact" for apps from verified publishers or apps registered in this organization.

Implement least privilege principles

Ensure that users and applications have only the minimum permissions necessary to perform their tasks. Regularly review and adjust permissions to prevent unnecessary access that could be exploited.

Monitor Azure Applications

• Deploy robust monitoring solutions to track Azure applications' behavior and access patterns continuously. Look for anomalies, such as unusual access requests or changes in application configurations, that could indicate malicious activity.
• Monitor for non-ASCII characters in application names, as detecting anomalies using variants that retain these characters might be possible.

Educate users

Provide training sessions for users to help them recognize phishing attempts and understand the importance of scrutinizing application permissions before granting them.

Don’t wait for a breach to occur.

This case highlights the importance of continuous vigilance in cloud security. Even well-intentioned safeguards can be bypassed in unexpected ways.

Organizations can better protect themselves from evolving threats by staying informed and proactive. Stay ahead of the evolving threat landscape with more content from Varonis Threat Labs.