The Silent Backdoor: How Hackers Use OAuth Apps in Microsoft Entra ID for Persistence

In the modern cybersecurity landscape, the perimeter has shifted from the corporate firewall to the identity layer. As organisations have fortified their defences with Multi Factor Authentication (MFA) and Conditional Access, threat actors have evolved. 

One of the most sophisticated and increasingly common techniques used by hackers involves exploiting OAuth 2.0 applications within Microsoft Entra ID to establish long-term, stealthy persistence.

Unlike traditional malware, which might be flagged by antivirus software, a malicious OAuth application leverages legitimate cloud protocols. This allows attackers to maintain access to sensitive data, even if a user changes their password, creating a "silent backdoor" that can remain undetected for months.

The Mechanics of the Attack: From Phishing to Persistence

The lifecycle of an OAuth-based attack typically follows a structured path designed to bypass traditional security alerts.

1. Initial Access via Consent Phishing

The attack often begins with "Consent Phishing." Instead of trying to steal a user’s password, the hacker sends an email or a message containing a link to a seemingly legitimate application. These apps often impersonate well-known tools like "Adobe Acrobat," "DocuSign," or even internal company utilities like "Salary Bonus Reports."

When the user clicks the link, they are directed to the official Microsoft Entra ID sign-in page. Because the page itself is legitimate, MFA may be triggered and successfully completed. However, after signing in, the user is presented with a "Permissions Requested" screen. By clicking "Accept," the user grants an OAuth token to the attacker’s application.

2. Weaponising First-Party Applications

A newer, more advanced variant known as ConsentFix involves abusing "first-party" Microsoft applications. Attackers use the Client IDs of trusted tools like Azure CLI or PowerShell. Because these applications are pre-trusted in every Entra ID tenant, they often do not trigger a consent prompt at all. Attackers trick users into completing the authentication and then "fixing" a fake error by pasting the resulting URL (which contains the authorization code) back into a malicious site.

3. Establishing Persistence

Once the attacker has an authorization code, they exchange it for an Access Token and a Refresh Token. The Refresh Token is the key to persistence. In Microsoft Entra ID, these tokens can remain valid for extended periods (often up to 90 days or more) and can be used to generate new access tokens without any further user interaction.

Even if the organization implements a mandatory password reset or enforces MFA after the initial compromise, the OAuth grant remains active. The attacker’s application continues to have the "keys to the kingdom" until the specific application registration or the user's consent is manually revoked.

Key Persistence Techniques Observed in 2024–2025

Security researchers from firms like Proofpoint, Wiz, and Mitiga have documented several specific ways hackers are hardening their foothold:

• Malicious App Registration: If an attacker compromises an account with sufficient privileges (such as an Application Administrator), they can register a new "internal" application directly within the victim's tenant. This application inherits a higher level of implicit trust.

  
  

• Adding Credentials to Existing Apps: Attackers may identify legitimate, "dormant" applications already in the environment and add their own client secrets or certificates to them. This allows them to hide their activity under the guise of a pre-approved service.

  
  

• Device Code Phishing: This technique exploits the OAuth "Device Flow" (intended for smart TVs or IoT devices). The attacker generates a code and tricks a user into entering it at microsoft.com/devicelogin. This links the attacker’s device to the user’s account, bypassing many Conditional Access policies that require a "managed device."

  
  

• Token Transition (RT to PRT): Advanced actors use tools like ROADtx to transition from a stolen Refresh Token to a Primary Refresh Token (PRT). This effectively allows them to register a "virtual device" in the tenant, making their traffic look like it is coming from a trusted, joined corporate laptop.

  
  

The Impact: Data Exfiltration and Shadow Administration

The danger of OAuth persistence is the level of access it provides. Common "scopes" (permissions) requested by hackers include:

• Mail.Read / Mail.Send: Allowing the attacker to monitor conversations, steal sensitive attachments, or launch internal phishing campaigns from a trusted executive’s email.

• Files.ReadWrite.All: Providing full access to the organization's SharePoint and OneDrive repositories.

• Directory.ReadWrite.All: The ultimate goal, allowing the hacker to create new "ghost" admin accounts, modify group memberships, or disable security policies.

Mitigation and Defence: Breaking the Chain

To defend against these "identity-first" attacks, organizations must move beyond simple password management and audit their application landscape.

1. Restrict User Consent: The most effective defence is to disable the ability for non-admin users to grant consent to third-party applications. Organizations should implement an Admin Consent Workflow, where users must request approval for new apps.

   
   

2. Audit Existing Grants: Regularly review the "Enterprise Applications" and "App Registrations" sections in the Entra ID portal. Look for apps with high-privilege permissions, unverified publishers, or those with very few users.

   
   

3. Monitor Sign-in Logs: Watch for unusual OAuth activity, such as sign-ins from the "Azure CLI" client by non-technical staff, or tokens being redeemed from IP addresses in unusual geographic locations.

   
   

4. Implement Conditional Access for Workload Identities: Extend security policies to include not just users, but the applications themselves. This can limit where an

   
   

5. Revocation is Key: In the event of a suspected compromise, simply resetting a password is not enough. Admins must explicitly Revoke Refresh Tokens and delete any suspicious OAuth permission grants or service principals.

   
   

Critical Questions for IT Security Teams

To ensure your environment is resilient against these threats, consider the following questions:

• Visibility: Do we have a complete inventory of every third-party application currently authorized to access our Microsoft 365 data?

• Policy: Is our user consent policy set to "Do not allow user consent," or are we relying on users to spot sophisticated phishing attempts?

• Legacy Flows: Have we blocked the "Device Code Flow" in our Conditional Access policies for users who do not strictly require it?

• Alerting: Does our SOC receive an alert the moment a new client secret or certificate is added to an existing application?

  
  

The shift toward OAuth-based persistence represents a significant evolution in cybercrime. By treating applications with the same level of scrutiny as human users, organizations can close these hidden backdoors and secure their cloud identities.

Anything we missed? Share your thoughts at DCCybertech.com