OAuth consent phishing: how attackers steal your Salesforce data while MFA is switched on

Multi-factor authentication has become the standard for most organisations. It effectively protects the moment of sign-in: without the second factor, an attacker gets no further. But there is an attack vector that operates outside that sign-in moment. OAuth consent phishing does not bypass MFA by cracking it — it bypasses MFA by making it entirely irrelevant.

Threat group ShinyHunters, known for major data breaches at international consumer and business platforms, has spent the past twelve months compromising Salesforce environments at scale via three attack paths that all rely on OAuth consent. Microsoft published a detailed analysis of this earlier this week, alongside an update to the Salesforce connector in Defender for Cloud Apps to better detect these attacks.

What OAuth consent is and why it is a risk

OAuth is the protocol that grants applications access to a platform on behalf of a user. When an employee connects an app to Salesforce, they click 'Allow' on a consent screen showing which data the app may read or modify. After that click, the app receives an access token that remains valid for an extended period, sometimes weeks or months, even after the employee has logged out.

That is the attack surface. If an attacker can persuade an employee to authorise a malicious app, that attacker gains API access to everything the employee can see. The platform, Salesforce, Microsoft 365, or any other SaaS system, records a legitimate authorisation granted by the user. There is no stolen password, no intercepted MFA token, no suspicious login from an unknown IP address.

The three attack paths ShinyHunters uses

Microsoft mapped three attack paths that ShinyHunters has deployed over the past period. They sometimes overlap, but each path also works independently.

The first path is vishing combined with a fake consent screen. An employee receives a call from someone posing as IT support or a Salesforce partner. The caller walks the employee through an OAuth consent screen for an application disguised as the official Salesforce Data Loader. After clicking 'Allow', the attacker gains full API access to that employee's CRM account, including all customer data, opportunities, and contacts.

The second path runs through supply chain integrations. Platforms like Salesloft and Gainsight are legitimate applications already connected to Salesforce at many organisations. Attackers compromise an account at such an integration vendor or abuse shared service accounts with broad permissions. Because the connection already exists and is trusted, an expanded permission request attracts less attention. The existing trust status is used as leverage to obtain additional scopes.

The third path exploits misconfigured guest access in Microsoft Entra. Organisations that allow external partners or freelancers as guest users with overly broad permissions create a bridge to connected SaaS applications. Through an Entra guest account with unnecessarily high permissions, attackers can move laterally to Salesforce and other connected platforms linked via the Microsoft identity.

Why MFA does not stop these attacks

This is the point that surprises many organisations. With classic phishing, an attacker steals a password and then tries to log in, at which point MFA stops the attack. With OAuth consent attacks, it is the employee who logs in, with their own account including MFA, and then grants permission to an app. The platform records a legitimate action by an authenticated user.

The result is an access token that is completely separate from the session and the MFA verification. That token operates via the API, not via the sign-in screen. The attacker never logs in as the user. They use the API as if they were the application the employee authorised.

What Microsoft Defender for Cloud Apps now detects

Microsoft has expanded the Salesforce connector for Defender for Cloud Apps with enhanced detection capabilities. The updated connector provides richer context about connected apps: which OAuth applications are authorised, by whom, with which permissions, and when last active. This enables anomaly detection based on consent behaviour.

Defender for Cloud Apps now generates alerts when a user authorises an unknown app outside working hours, when an app requests scopes far outside the organisation's norm, or when a connected app suddenly queries more data than expected. The Salesforce connector links these signals to the identity context from Microsoft Entra, making the complete attack path visible in Microsoft Sentinel or the Defender portal.

Five measures that protect your organisation

No single measure eliminates the risk entirely, but the combination of the following five steps significantly reduces the attack surface.

Restrict user consent in Microsoft Entra. Configure end users so they cannot grant OAuth consent to apps outside an approved list. Apps without approval then require an admin consent request, which an administrator reviews before access is granted. This setting is in Entra under Enterprise Applications, User Settings.

Activate the Salesforce connector in Defender for Cloud Apps. If your organisation has Defender for Cloud Apps but the Salesforce integration is not active, that is a blind spot. The connector gives an overview of all connected apps, active tokens, and abnormal API behaviour. Then revoke tokens for apps that are not actively used.

Audit external application integrations. Periodically check what permissions Salesloft, Gainsight, HubSpot, and other connected platforms have in your Salesforce environment. Service accounts used for these integrations should not have more rights than strictly necessary. Remove integrations for applications your organisation no longer actively uses.

Tighten guest access in Microsoft Entra. Review the External Collaboration settings and restrict what guest users can do. Guests should by default not be able to browse the user directory, join teams without an invitation, or authorise apps on behalf of the organisation.

Train employees on OAuth consent screens. Phishing awareness traditionally focuses on suspicious emails with links. OAuth consent attacks happen via phone calls and look like a normal authorisation step. A short awareness session on what IT support would never ask over the phone and how to recognise a legitimate versus suspicious consent screen makes a concrete difference.

What you can do this week

Start with an inventory of the OAuth applications that currently have active tokens in your Salesforce environment and your Microsoft 365 tenant. Most IT teams know how many users they have, but not how many apps have active API access. That blind spot is precisely what ShinyHunters exploits.

Then check the user consent settings in Entra. If users can currently freely authorise applications without administrator approval, that is a low-effort change with immediate effect. The setting can be modified in under five minutes.

OAuth consent attacks illustrate that security extends beyond the sign-in screen. It encompasses which apps have access to your data, how long that access remains valid, and who monitors that. Want help inventorying connected applications, setting up Defender for Cloud Apps, or tightening your Entra policy for external app authorisation? Contact Zarioh.