How ShinyHunters walked into Salesforce accounts without breaking anything
Microsoft says a year of data theft from Salesforce tenants leaned on trusted app connections, not a platform bug.

Key points
- Microsoft has tied a year of Salesforce data theft to attackers whose methods match the extortion group ShinyHunters.
- The attackers did not exploit any flaw in Salesforce itself, according to Microsoft's write-up.
- The way in was OAuth, the standard that lets one app connect to another on a user's behalf, usually through third-party tools already trusted by the victim.
- Stolen data has been used to pressure companies into paying to keep customer records off leak sites.
- Turning on multi-factor authentication on the user account alone would not have stopped these intrusions, because the app connections bypass that step once granted.
A group of criminals whose fingerprints match ShinyHunters has spent roughly a year quietly pulling data out of corporate Salesforce accounts. They did not find a hole in Salesforce. They walked in through the front door the company had already propped open for its own vendors.
That door is called OAuth. OAuth is the plumbing that lets one online service talk to another on your behalf, so a marketing tool can read your Salesforce contacts without you handing over your password. When you click "allow" on one of those prompts, you are giving that outside app a long-lived key to your data.
Microsoft's threat intelligence team, which first mapped the campaign in detail, says the attackers focused on those keys rather than on Salesforce's own code. The Hacker News reported the findings this week.
How did the hackers actually get in?
They abused connections the victim had already trusted. In several cases the criminals tricked staff at a third-party vendor into approving a malicious app, and that app then had permission to read the vendor's customers' Salesforce data. In others they used stolen tokens, small digital passes issued after login, to act as a legitimate integration without ever seeing a password.
Once inside, they queried the Salesforce database directly and pulled down records in bulk. Contact lists. Support cases. Whatever the connected app was allowed to see.
Think of it like a cleaning company that has a key to your office. If a criminal cons the cleaning company into handing over a copy of that key, they can walk in at 3am without ever picking a lock. Your alarm system on the front door does not help.
That is why plain multi-factor authentication, the extra code from your phone, would not have blocked most of this. MFA protects the login. The app connections had already been approved and were operating with their own permissions.
What the attackers did with the data
After the theft, the group behaved like a classic extortion crew. They contacted the victims, showed proof of the stolen records, and demanded payment to keep the files off a public leak site. Several well-known brands have been named in recent months in incidents that fit this pattern.
Salesforce itself was not breached. The company has repeatedly said the exposures came from customer configurations and the third-party apps around its platform, not from its core service.
What ordinary customers should watch for
If you are a customer of a company that has disclosed a Salesforce-linked incident, expect the leaked data to be the sort of thing kept in a sales or support system: name, email, phone number, notes about your account. That is a strong toolkit for a convincing scam email or phone call in the weeks that follow.
Be extra wary of messages that refer to a real recent interaction with the brand. Do not click login links in those emails. Go to the site directly.
What companies using Salesforce should do now
Review every connected app in your Salesforce tenant. If you do not recognise it, or nobody remembers approving it, revoke it. Rotate integration tokens on a schedule. Limit each app to the smallest set of data it actually needs. And treat your vendors' security as an extension of your own, because in this campaign it was.



