ShinyHunters Spent a Year Stealing Salesforce Data Through Trusted App Connections
Microsoft's threat intelligence team has mapped a sustained campaign by a group matching ShinyHunters that pulled corporate data from Salesforce tenants by abusing OAuth tokens, not by exploiting any flaw in Salesforce itself.

A criminal group whose tactics and infrastructure match the extortion crew known as ShinyHunters spent roughly twelve months quietly exfiltrating records from corporate Salesforce environments, Microsoft's threat intelligence team has confirmed. The attackers never touched Salesforce's own code. They used the doors companies had already unlocked for their own vendors.
The Weapon Was OAuth, Not a Vulnerability
OAuth is the widely adopted authorization standard that lets one application act on a user's behalf inside another platform. When a marketing tool asks to read your Salesforce contacts, or a support platform requests access to customer cases, OAuth is what hands over a long-lived token granting that access. The user clicks "allow" once, and that third-party app can operate indefinitely without ever re-entering a password.
Microsoft's researchers found that ShinyHunters focused on harvesting exactly those tokens. In several documented instances, the group targeted staff at third-party vendors connected to the actual target. By tricking a vendor employee into approving a malicious application, the attackers gained a valid OAuth token scoped to that vendor's Salesforce data, which in turn contained records belonging to the vendor's own customers. In other cases they obtained stolen tokens directly and replayed them, presenting themselves to Salesforce's API as a legitimate integration.
Once authenticated, they queried the Salesforce database in bulk, pulling contact lists, open support cases, and any other data the connected app had permission to read.
A useful analogy: imagine a facilities company holds a master key to your building. If an attacker socially engineers that company into handing over a copy, they can enter at any hour without defeating your locks or your alarm. Your perimeter controls were never involved.
Why Standard MFA Did Not Stop This
This is the detail security teams need to internalize. Multi-factor authentication protects a user login. It has no effect on an OAuth token that was already issued and has not expired. The token itself is the credential at that point, and it bypasses the login flow entirely.
The Verizon 2024 Data Breach Investigations Report found that stolen credentials and abuse of valid accounts now account for nearly one third of all breach actions. OAuth token theft is a natural evolution of that pattern, because it gives attackers a credential that is harder to detect and harder to revoke at scale.
Organizations that assumed their Salesforce environment was protected because they had rolled out MFA discovered the hard way that identity hygiene extends well beyond the login page. Reviewing your organization's identity controls against established frameworks is a practical first step toward closing that gap.
Extortion Followed the Theft
After extracting the data, the group behaved like a textbook extortion operation. They contacted victim companies, provided sample records as proof of the theft, and demanded payment to prevent publication on a data leak site. This is a pattern ShinyHunters has followed in multiple previous campaigns targeting cloud-hosted data stores.
Salesforce has consistently stated that its platform was not compromised. The exposures originated in customer-managed configurations and in the ecosystem of third-party integrations built on top of the platform.
The Human Layer That Made This Work
At its root, this campaign succeeded because of failures in two overlapping human processes: vendor security review and employee awareness about OAuth consent requests.
Granting an application access to a business-critical platform is a decision with lasting consequences, yet many organizations treat those consent prompts the same way consumers treat cookie banners, clicking through without scrutiny. Employees at the third-party vendors involved in this campaign were socially engineered into approving malicious apps. That means no amount of technical patching on the Salesforce side would have changed the outcome. The control that failed was human judgment at the moment of the consent prompt.
This is precisely the scenario that well-designed security awareness training addresses. When employees understand what OAuth consent means, what a suspicious app approval looks like, and who to contact before clicking allow on an unfamiliar integration, the attacker loses one of their primary entry vectors. Organizations running regular, scenario-based training programs are measurably better at recognizing these moments. A short pilot is enough to see the difference.
Vendor risk is the second layer. If a third-party tool has read access to your customer records, that vendor's security posture is effectively part of your own attack surface. The companies victimized in this campaign found that out after the fact.
What Salesforce Administrators Should Do Now
The practical response is not complicated, but it requires deliberate effort.
- Open your Salesforce connected apps screen and audit every authorized integration. If you cannot identify who approved an app, when, and why, revoke it.
- Set token expiry policies. Long-lived tokens that never rotate are a persistent liability.
- Apply the principle of least privilege to every integration. A marketing analytics tool does not need access to support case histories.
- Extend your vendor assessment process to include questions about how third parties manage their own OAuth grants and integration credentials.
- Brief staff involved in approving new integrations on what a suspicious consent request looks like.
What Affected Customers Should Watch For
If a company you deal with has disclosed a Salesforce-linked data exposure, assume the leaked information includes the kind of detail kept in a sales or support system: name, email address, phone number, and notes about your account history. That combination makes a highly convincing phishing email or vishing call.
Be especially cautious of messages that reference a real interaction you had with the brand. Do not follow login links in those messages. Navigate directly to the company's website. Report anything suspicious to the brand's fraud team. The stolen records will circulate long after the initial extortion attempt, so elevated caution is warranted for months, not just days.
How this could have been prevented
- Train employees who handle app integrations to scrutinize OAuth consent prompts and escalate unfamiliar requests before approving access.
- Conduct quarterly audits of all third-party connected apps and enforce token expiry policies to limit the lifespan of any stolen credential.
- Extend vendor risk assessments to cover how suppliers manage their own integration credentials and OAuth grants.
Train2Secure's scenario-based modules include social engineering and OAuth abuse simulations designed for the exact human moment this campaign exploited.
Start free, no card requiredSources & further reading
Frequently asked questions
Was Salesforce itself hacked in this campaign?
No. Salesforce's platform was not compromised. The attackers abused OAuth tokens tied to third-party integrations that customers had authorized, exploiting misconfigurations and social engineering rather than any flaw in Salesforce's own code.
Why did multi-factor authentication not prevent these breaches?
MFA protects the user login process. OAuth tokens are issued after login and operate independently. Once an attacker holds a valid token, they can query the platform's API without triggering any MFA challenge.
How should an organization find out whether it has unauthorized OAuth connections in Salesforce?
Salesforce administrators can review all authorized connected apps inside the platform's Setup menu. Any app that cannot be matched to an approved business use case should be revoked and investigated.
What data was typically exposed in these incidents?
Because the attacker's access was scoped to whatever permissions the compromised app held, exposed data commonly included contact records, email addresses, phone numbers, and support case details stored in Salesforce.



