Contribution
This post adds original detection content: a four-stage correlation for SaaS vishing that joins helpdesk social engineering, identity-provider changes, OAuth or SSO session expansion, and repository export. The cited sources describe pieces of that chain; the contribution here is a practical join that lets a SOC alert before a stolen SSO session becomes Slack, Drive, SharePoint, Salesforce, or DocuSign data theft.
The pattern
SaaS vishing has moved past the old mental model of a fake login page and a suspicious sign-in. The current pattern is a live intrusion sequence. A caller impersonates IT or a support function, steers the user through a credential or MFA workflow, takes over the SSO session, adds or abuses an access method, then fans out across cloud applications looking for exportable data.
Obsidian Security's March 2026 analysis of ShinyHunters-style voice phishing gives the clearest identity-to-SaaS chain. It describes Okta account compromise, suspicious MFA enrolment through Okta FastPass or Okta Verify, emulated Android devices sometimes named Passkey, bursts of SSO application access, and high-volume file activity in SaaS platforms such as Slack and Google Drive. The useful detail is not one indicator. It is the sequence. A failed or unusual authentication chain becomes successful, a new factor appears, the session touches more SSO apps than normal, and data leaves repositories shortly afterwards.
Google Threat Intelligence's ShinyHunters-branded SaaS reporting shows the same pattern at a broader campaign level. GTIG describes voice phishing and victim-branded credential harvesting sites used to capture SSO credentials and MFA codes, followed by access to platforms such as Microsoft 365, SharePoint, OneDrive, Salesforce, DocuSign, Slack, and Google Workspace. The advisory also notes attacker searches for terms such as confidential, internal, proposal, vpn, and Salesforce-related content. That tells defenders where the data hunt starts after identity compromise: productivity suites and CRM records, not only endpoint files.
Microsoft's May 2026 code-of-conduct phishing report adds the token-theft side. The campaign used polished internal-policy lures, legitimate delivery services, PDFs, CAPTCHA steps, intermediate pages, and an adversary-in-the-middle flow to capture authentication tokens from more than 35,000 users across 13,000 organisations. That matters to SaaS defenders because a captured session token changes the detection problem. A successful login with MFA is no longer reassuring. The attacker may already be riding the completed authentication.
Salesforce's own guidance adds the connected-app angle. It warns about social engineering against Salesforce environments where attackers impersonate IT support, steal credentials and MFA tokens, prompt users towards connected-app setup paths, and convince them to add a malicious connected app. Salesforce notes that a malicious connected app can be used to extract data, and calls out high-risk permissions such as Customize Application, Modify All Data, and Manage Connected Apps.
The pattern across those sources is not malware-led. It is identity-led. The endpoint may never run a payload. The user may complete a real MFA step. The SaaS export may use a normal application, an authorised connected app, or a browser session that looks like work. That is exactly why a single-point alert misses it. The SOC needs to connect the social-engineering start, the identity-provider mutation, the SSO fan-out, and the repository read.
Why it matters to cloud defenders
Cloud defenders own the blast radius even when the first interaction happens over the phone. The data that makes these campaigns damaging sits in SaaS and cloud-backed repositories: CRM tables, support cases, contracts, sales documents, finance exports, legal files, Slack channels, Drive folders, SharePoint libraries, and DocuSign envelopes. Those systems are normally reached through the identity provider, not through a compromised host.
The pace is the hard part. A vishing call can move from first contact to account takeover in minutes. Obsidian's reported sequence includes suspicious authentication activity and MFA persistence before broad SSO access. Google's reporting shows opportunistic movement across whichever SaaS applications the compromised account can reach. Microsoft's AiTM case shows that token theft can turn a polished email campaign into immediate account access. Salesforce's guidance shows how connected apps can become the extraction path once the user or attacker grants access.
Many organisations still split these logs across teams. Identity teams see Okta or Entra events. SaaS administrators see app access. Data teams see Salesforce or SharePoint exports. SOC analysts see phishing reports and mailbox detections. Attackers win when those views stay separate. A suspicious factor enrolment may look like a helpdesk task. A Salesforce export may look like a sales operations job. A SharePoint download may look like a busy employee. Together, after an unusual SSO chain, they look like theft.
This is also a useful correction to a common control story. Phishing-resistant MFA is the right strategic move, but many estates still contain push, OTP, SMS, helpdesk reset, recovery and connected-app paths. The detector should not assume the company is already at a perfect authentication end state. It should watch the messy middle: which users can add factors, which apps can be consented to, which sessions can move across SaaS, and which repositories can export data in bulk.
ATT&CK mapping
T1078.004, Valid Accounts: Cloud Accounts, is the entry point for the cloud portion of the chain. The attacker uses a real identity-provider account or a real SaaS account after vishing, AiTM token capture, helpdesk manipulation, or MFA reset. The signal is not only a new IP address. It is a real account behaving outside its normal authentication and application pattern.
T1528, Steal Application Access Token, covers the session and OAuth side. Microsoft's AiTM reporting is directly relevant: the attack captures authentication tokens so the actor can bypass the comfort of a completed MFA prompt. The Salesforce connected-app path also belongs near T1528 because the attacker seeks durable delegated access to data through an application grant rather than a password alone.
T1213, Data from Information Repositories, is the payoff. Google names SharePoint, OneDrive, Salesforce, DocuSign, Slack, and Google Workspace as target platforms in ShinyHunters-branded activity. Obsidian describes SSO application enumeration followed by SaaS data theft. Once the actor has a valid session or delegated app, the target becomes document libraries, chat history, CRM objects, case attachments, contract stores and other repositories that were designed for business search.
The chain can touch other techniques, including phishing, domain impersonation, account discovery and exfiltration over web services. This article lists the three techniques that make the detection path concrete for cloud defenders: cloud account use, token or app-access abuse, and repository access. The phone call is important context, but the durable log evidence usually begins at the identity provider and the SaaS control plane.
Detection guidance
Build the detector as a four-stage join rather than a pile of separate alerts. Stage one is the helpdesk or social-engineering context. Useful inputs include user-reported phishing or vishing tickets, unusual helpdesk reset requests, recent MFA reset or recovery actions, and inbound emails or PDFs that match internal policy, compliance, conduct, billing, or support themes. This stage may be incomplete. Do not make it mandatory, because many victims never report the call.
Stage two is identity-provider change or authentication drift. In Okta, watch for abnormal sequences around policy.evaluate_sign_on, repeated failed attempts, core.user.factor.attempt_fail, eventual core.user_auth.login_success, user.authentication.auth_via_mfa, user.authentication.verify, OAuth authorisation, and token grant events. Obsidian's emulated Android clue is useful when present: Okta Verify or FastPass user agents with Genymobile or other emulator markers, especially on a new device called Passkey or a similarly generic name.
In Entra ID, the equivalent signals are successful sign-ins after risky or interrupted attempts, sign-in from a new ASN or geography, token replay indicators, unfamiliar device posture, new MFA method registration, security-info changes, app consent, and a shift from browser login to API access. In Salesforce, watch for connected-app authorisation, new or unusual Data Loader-style clients, profile or permission changes involving Customize Application, Modify All Data, or Manage Connected Apps, and logins from locations outside normal ranges.
Stage three is SSO fan-out. After the suspicious identity event, count how many SSO applications the same user touches in a short window. A normal employee may open mail, calendar and one line-of-business app. A compromised session often probes many: Slack, Drive, SharePoint, Salesforce, DocuSign, ticketing, HR, finance, source control and admin portals. Alert when a user crosses a personal baseline for distinct SaaS apps after a factor enrolment, token event, helpdesk reset, or AiTM-themed phishing hit.
Stage four is repository read or export. In Microsoft 365 and SharePoint, watch FileDownloaded, bulk sync, unusual user agents, unmanaged-device context, and access to labelled or sensitive files. In Google Workspace, watch Drive downloads, export actions, sharing changes and access from new OAuth clients. In Salesforce, watch bulk API use, report export, Data Loader patterns, connected-app API calls, and reads of high-value objects such as Accounts, Contacts, Opportunities, Cases, Attachments and custom objects holding personal or commercial data. In Slack or other collaboration tools, watch channel history exports, admin exports and rapid reads across sensitive private channels.
The high-confidence alert is the sequence: suspicious authentication or MFA change, then SSO fan-out, then bulk repository access or connected-app export. Start with a 30 to 180 minute window. Raise severity when the account has not used that app in the last 30 days, the source ASN is new, the device is unmanaged, a new factor was enrolled, a new OAuth or connected app appears, or the data touched carries sensitivity labels.
False positives will come from onboarding, device replacement, incident response, mergers, sales operations exports and admin maintenance. Tune by known helpdesk change tickets, approved IP ranges, device management state, named export jobs, and normal app bundles for each role. Do not tune away the chain itself. A single export may be normal; an export after vishing-shaped identity drift is not normal.
When the alert fires, preserve the identity-provider events, factor-enrolment detail, token or app-consent records, SaaS audit logs, helpdesk tickets, and user-reported call notes. Revoke sessions and refresh tokens, remove suspicious factors, disable malicious connected apps, rotate exposed secrets, and review every SaaS app touched after the first suspicious login. If a connected app was used, treat its grant as compromised until reviewed.
What to do now
First, inventory the paths that let a user or helpdesk process change authentication state. List who can reset MFA, enrol factors, approve recovery, grant connected apps, or relax sign-in controls. Require phishing-resistant factors for privileged users and high-value SaaS users first, but also monitor the fallback routes that remain.
Second, baseline SSO fan-out by role. For each user group, record the normal number of SaaS applications touched in the first hour after sign-in, the normal device posture, and the normal export paths. This does not need a perfect model. A simple per-user and per-role baseline is enough to catch the jump from one or two business apps to seven or eight repositories after a suspicious login.
Third, put Salesforce, Microsoft 365, Google Workspace, Slack, DocuSign and Okta or Entra logs in the same investigation view. The field names will not match cleanly. Build around stable joins: user principal, IdP user ID, session ID, client app, source IP, device ID, user agent, OAuth client ID, connected app ID, target object, file label and event time.
Fourth, rehearse the containment path. A vishing-driven SaaS intrusion is not finished when the password changes. Kill active sessions, revoke refresh tokens, remove new factors, disable suspicious OAuth and connected apps, review downstream SaaS exports, and notify data owners for repositories touched during the window. If the actor reached CRM or document stores, treat the case as data exposure until the export evidence says otherwise.
The defender move is to stop treating vishing, MFA enrolment, SSO enumeration and SaaS export as separate queues. In 2026 reporting, those events are one chain. Join them fast enough, and the incident can be contained while it is still an identity takeover. Miss the join, and the first strong signal may be an extortion email.