ShinyHunters-Linked Vishing Tricks Users into OAuth Consent

How the Attack Worked

Microsoft documented a series of real-world campaigns, running from mid-2025 into mid-2026, sharing tradecraft linked to ShinyHunters. The core technique relied on vishing calls in which attackers impersonated internal IT support personnel and asked employees to authorize a connected app inside their Salesforce tenant. In several confirmed cases, the caller guided the victim step by step through the OAuth consent workflow, presenting the malicious application as a legitimate tool such as a Salesforce Data Loader.

Once a user approved the request, the attacker-controlled OAuth application inherited that user's permissions. This allowed threat actors to make API calls on behalf of the victim, enabling enumeration, persistence, and large-scale data exfiltration from the CRM environment.

Why It Succeeded

The attack worked because it exploited trust rather than a technical flaw. A phone call from someone claiming to be IT support carries built-in credibility, and OAuth consent prompts are a normal, expected part of many workplace workflows. Because the resulting access came through an authorized integration rather than a suspicious login, the activity often appeared indistinguishable from legitimate integration behavior. This made it harder for standard sign-in monitoring to catch.

The pattern also escalated beyond direct vishing into supply-chain style compromise. Attackers targeted third-party SaaS vendors that integrate with Salesforce, using connection secrets and OAuth tokens to reach downstream customers without any direct contact.

What to Watch For

• An unexpected phone call from someone claiming to be IT support who asks you to approve an app or connected integration.
• Pressure during the call to complete OAuth consent prompts quickly.
• A connected app name or branding that looks generic or mimics a known legitimate tool.
• Sudden appearance of new, highly privileged connected apps in the Salesforce environment.
• Unusual guest-user activity, particularly queries against Salesforce Aura endpoints tied to misconfigured guest permissions.

How to Build Resistance

• Never approve an OAuth or connected-app consent request based solely on an unsolicited phone call. Verify the request through a known internal channel first.
• Treat any newly authorized connected app, especially one with broad privileges, as a priority item for review and revoke access quickly if it is unexpected.
• Maintain visibility and governance over third-party SaaS integrations, since attackers can ride trusted connections to move data at scale.
• Regularly audit guest-user permissions in Salesforce and monitor for unusual guest activity that could indicate unauthorized data access.
• Train sales operations, CRM administrators, and helpdesk staff specifically on OAuth consent risks, since these roles are frequent targets for this type of pretext.

How did attackers gain access without triggering login alerts?

They socially engineered employees into authorizing attacker-controlled connected apps through the OAuth consent workflow, which let them make API calls on behalf of the victim user without typical sign-in anomalies.

What pretext did the attackers use on the phone?

They impersonated internal IT support personnel and asked employees to approve a connected app, sometimes disguised as a legitimate Salesforce Data Loader tool.

Were third-party integrations involved in these campaigns?

Yes, the campaigns escalated into supply-chain style attacks targeting third-party SaaS vendors like Salesloft, Drift, and Gainsight that integrate with Salesforce, often using OAuth tokens.

What should organizations check for after this type of attack?

Review newly authorized connected apps for excessive privileges, verify OAuth consent requests through known internal channels, and audit Salesforce guest-user permissions for unusual activity.