ShinyHunters-Style Vishing Tricks Staff Into OAuth Access

How the attack worked

Attackers linked to ShinyHunters-style activity spent an extended period gaining access to corporate Salesforce data without exploiting any platform vulnerability. One of the primary methods involved vishing calls in which attackers impersonated internal IT support. During these calls, employees were talked through Salesforce's OAuth consent screen and guided to authorize a connected app disguised as the legitimate Data Loader tool. Once approval was granted, the malicious app could make API calls as that user, giving attackers persistent, password-free access to CRM records and a foothold for hunting credentials tied to other SaaS platforms.

Why it succeeded

This approach worked because it relied entirely on social engineering rather than technical exploitation. There was no malware and no stolen password to replay, only a phone call and a consent click. The attack also exploited a structural blind spot: when access originates from a real user who approved a connected app, or from an integration the organization already trusts, the resulting API traffic looks like ordinary business activity. Standard sign-in and authentication monitoring is built to catch anomalous logins, not authorized-looking app behavior, so this kind of access can persist without triggering alerts.

Other paths observed in the same campaign

Microsoft's reporting also describes two additional real-world intrusion paths used alongside vishing. Stolen OAuth tokens from compromised vendor integrations allowed attackers to reuse already-approved access so it blended into normal automation. Separately, misconfigured Salesforce Experience Cloud guest access allowed unauthenticated data pulling from Aura endpoints, with pagination used to exceed standard query limits. Together, these paths show that trust in connected apps, tokens, and guest configurations can be leveraged without ever touching a core platform flaw.

What to watch for

• Unsolicited calls pressuring immediate approval of a Salesforce or connected app
• Requests to approve an app you did not initiate through an official change process
• Consent prompts referencing familiar tools, such as Data Loader, arriving via phone guidance rather than internal IT tickets

Building resistance

Help desk and general staff should treat unexpected IT support calls with suspicion, hanging up and calling back through a known official number before acting. Training should emphasize that approving a connected app can be functionally equivalent to handing over account access. On the technical side, security teams should inventory connected apps regularly, remove unused ones, scope remaining apps to least privilege, and monitor post-access behavior such as API volume and query patterns rather than relying solely on sign-in alerts.

What is the ShinyHunters-style vishing attack against Salesforce users?

Attackers posed as IT support in phone calls and walked employees through Salesforce's OAuth consent screen, convincing them to authorize a malicious connected app disguised as the Data Loader tool.

Did the attackers exploit a Salesforce vulnerability?

No. According to the findings, attackers entered environments without exploiting a single flaw in the platform, instead abusing trust in OAuth connected apps and integrations.

Why didn't security monitoring catch this activity?

Because the access came from a real user who had approved a connected app or from an already-trusted integration, the resulting traffic looked like ordinary use and largely evaded sign-in and authentication alerts.

How can organizations reduce risk from malicious connected apps?

Regularly inventory connected apps, remove ones that are no longer used, and scope remaining apps to least privilege access.