How ShinyHunters walked into Salesforce accounts without breaking anything

Key points

• Microsoft has tied a year of Salesforce data theft to attackers whose methods match the extortion group ShinyHunters.
• The attackers didn't 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 the victim had already trusted.
• 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 wouldn't have stopped these intrusions, because approved app connections bypass that step once granted.

A group whose fingerprints match ShinyHunters has spent roughly a year quietly pulling data out of corporate Salesforce accounts. No hole in Salesforce was needed. They walked in through a door the victim had already propped open for its own vendors.

That door is OAuth, 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. Click "allow" on one of those prompts and you're giving that outside app a long-lived key to your data.

Microsoft's threat intelligence team mapped the campaign in detail. The Hacker News reported the findings this week. We've been watching this group since late June: our story on the NAIC PeopleSoft incident was the first time ShinyHunters' extortion pattern showed up in our coverage.

How did the hackers actually get in?

They abused connections the victim had already trusted. 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. Separately, stolen tokens, small digital passes issued after a legitimate login, let the attackers act as a real 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 permitted to see.

Think of it like a cleaning company that holds a key to your office. If a criminal cons the cleaning company into handing over a copy, they can walk in at 3am without picking a lock. The alarm on the front door doesn't help.

That's why plain multi-factor authentication, the extra code from your phone, wouldn't have blocked most of this. MFA protects the login. The app connections had already been approved and were running on their own permissions.

What the attackers did with the data

After the theft, the group behaved like a classic extortion crew: they contacted 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 incidents fitting this pattern.

Salesforce itself wasn't breached. 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're a customer of a company that has disclosed a Salesforce-linked incident, the leaked data is likely the sort kept in a sales or support system: name, email, phone number, notes about your account. That's a strong toolkit for a convincing scam call or phishing email in the weeks that follow.

Be extra wary of messages that reference a real recent interaction with the brand. Go to the site directly rather than clicking any login link in those emails.

What companies using Salesforce should do now

Review every connected app in your Salesforce tenant. If nobody remembers approving it, revoke it. Rotate integration tokens on a schedule and limit each app to the smallest set of data it actually needs. Treat your vendors' security as an extension of your own, because in this campaign it was. Our earlier look at the Klue breach showed exactly this risk playing out through legacy OAuth credentials: the attack surface here isn't new, and it hasn't got smaller.