The Cuffs Don't Fix the Help Desk: Scattered Spider's Arrests and the Salesforce Vishing Wave
On July 1, the DOJ announced that a 19-year-old alleged Scattered Spider member had been extradited from Finland to face U.S. hacking charges — the latest in a run of arrests targeting the crew behind much of last year’s social engineering wave. It’s genuinely good news. It also changes very little about your exposure, because the thing they exploited wasn’t a bug. It was your help desk. When we covered third-party access risk, the closing question was whether you’d done the work to not be the easy target. These arrests are a good moment to answer it — because we now know exactly who was calling.
And in case you missed it, last year I actually sat down with a member of ShinyHunters — the crew that ran much of the Salesforce data-theft campaign alongside Scattered Spider — to walk through precisely how they pulled it off. 😉
What Actually Happened
Peter Stokes, a dual U.S.-Estonian citizen who went by “Bouquet,” was arrested in Finland in April as he tried to board a flight to Japan, and appeared in a Chicago federal court on June 30. Prosecutors tie him to a group accused of more than 100 network intrusions since 2023 and over $100 million in extortion. His charges span wire fraud, computer fraud and abuse, and aggravated identity theft — and notably, his earliest alleged attack, at age 16, was simply convincing an IT support desk to reset an employee’s two-factor authentication.
He’s not alone. Tyler Buchanan admitted to a wave of intrusions earlier this year, and two U.K. defendants pleaded guilty in June to the 2024 Transport for London attack. The arrests are real and they matter. What they don’t do is retire the technique.
Why It Still Matters for Your Org
The Salesforce campaign these groups ran last year didn’t exploit a Salesforce vulnerability. Attackers impersonated IT staff over the phone, walked employees through Salesforce’s own connected-app authorization page, and got them to approve a modified version of Data Loader. From there it was bulk export of CRM data, then lateral movement into Okta, Microsoft 365, and S3. In some cases they even used the victim’s own Salesforce Omni-Channel to vish that company’s customers.
Every step of that used legitimate features working as designed. As Mandiant put it, the playbook has outlived the arrests — other crews are already copying it. The weak point is the help desk, not the firewall.
What to Do This Week
- Lock down connected-app authorization. Move to admin-approved-users-only for OAuth apps so an employee on a phone call can’t self-authorize Data Loader or anything like it.
- Enforce phishing-resistant MFA (FIDO2 keys or passkeys) for privileged users. It’s the one factor a vishing call can’t talk its way past.
- Harden the help desk itself. Require a verifiable identity check before any credential or MFA reset — the reset request is the attack, so that’s where the control belongs.
- Watch for new connected-app authorizations and OAuth token grants in Event Monitoring and the Setup Audit Trail. First authorization of an unfamiliar app is the signal.
Deeper Dive
One Ecosystem, Three Brands
The reason “arrest one member” doesn’t translate to “campaign over” is structural. Scattered Spider (tracked as UNC3944), ShinyHunters (UNC6040), and the remnants of LAPSUS$ aren’t a single org chart — they’re overlapping cells inside a loose English-speaking cybercrime community often called The Com. Over the last year they operated openly under a shared “Scattered LAPSUS$ Hunters” banner with a rough division of labor: Scattered Spider specializes in the initial break-in through social engineering, ShinyHunters handles data theft and the extortion-site publication, and LAPSUS$-aligned members amplify the pressure.
That fluidity is the point. Google’s threat intelligence has described the group as multiple clusters wearing one brand. When you arrest “Bouquet,” you remove a skilled operator, but the technique, the tooling, and the Telegram channels stay in circulation. The lull Mandiant observed after previous arrests was exactly that — a lull, followed by copycats. This is why a defensive posture built around “the named actors are in custody” is a posture with a short shelf life.
The Anatomy of the Salesforce Attack
It’s worth walking the actual kill chain, because understanding it tells you exactly where the controls belong.
It starts with reconnaissance and a phone call. The attacker identifies an employee — often in a non-technical role — and calls posing as internal IT or a help desk agent. The pretext is usually urgent and mundane: a sync problem, a required security update, a password about to expire. The goal of the call isn’t to steal a password directly. It’s to get the employee to authorize a connected app.
Here’s the clever part. The attacker directs the victim to Salesforce’s legitimate connected-app authorization flow — a real Salesforce page, at a real Salesforce URL. The employee is asked to enter a connection code the attacker provides, or to approve an app that looks like Data Loader, Salesforce’s own sanctioned bulk-data tool. Because the page is genuine and the tool is familiar, nothing looks wrong. But approving it grants an attacker-controlled OAuth application standing access to the org’s data — no password reuse, no malware, no exploit.
With that OAuth grant in hand, the attackers used the modified Data Loader to bulk-export CRM records: contacts, accounts, cases, whatever the compromised user could see. Then came lateral movement. Salesforce credentials and connected identity often bridge into Okta, Microsoft 365, and cloud storage like Amazon S3, so a single CRM foothold became an enterprise-wide data theft. In the campaign’s most cynical flourish, some operators used the victim’s own Salesforce Omni-Channel console to contact that company’s customers directly — turning a trusted support channel into an extortion instrument.
Every stage abused a legitimate feature. OAuth connected apps exist so integrations can work without password sharing. Data Loader exists so admins can move data in bulk. Omni-Channel exists so agents can reach customers. The attack is what happens when a human is manipulated into pointing those features at an adversary.
AI Made It Scale
A year ago, vishing had a natural throttle: it took a skilled human to run a convincing call. That throttle is gone. These groups adopted AI voice systems that generate synthetic speech and adapt tone and phrasing mid-conversation to stay credible under pushback. With as little as thirty seconds of reference audio, an operator can spin up a voice convincing enough to get a rushed help desk agent to act. A tactic that used to require one talented social engineer per target can now run across many targets at once. When you’re modeling your exposure, don’t assume the caller has to be good — assume the caller is cheap and infinitely patient.
Where the Controls Actually Belong
Map each defense to the specific step it breaks, and the strategy gets clear.
Phishing-resistant MFA breaks the credential-reset and login step. SMS codes, authenticator apps, and push approvals can all be relayed or fatigued by a live social engineer. FIDO2 hardware keys and passkeys are cryptographically bound to the legitimate site, so there’s nothing for a caller to talk a user into handing over. This is precisely why Salesforce’s summer mandate pushed privileged users onto phishing-resistant factors, and why it’s the single highest-leverage change most orgs can make. We went deep on the assurance and recovery nuances in the phishing-resistant MFA writeup.
Connected-app allowlisting breaks the OAuth-authorization step. In Salesforce, you can set connected apps to be installable and authorizable by admin-approved users only, rather than letting any user consent on their own. Set that as the default posture and the phone-call-to-Data-Loader path simply closes: the employee no longer has the ability to grant the app even if they’re convinced they should. Inventory the connected apps already authorized in your org while you’re at it — the first authorization of an unfamiliar app is one of the cleanest breach signals you have, and it lives in Event Monitoring and the Setup Audit Trail.
Help desk identity verification breaks the pretext itself. The recurring root cause across these incidents is a support process that resets credentials or MFA on the strength of a convincing story. The fix is procedural, not technical: require a verifiable, out-of-band identity proof before any reset — a manager callback, a verified corporate directory check, a step that a stranger with a script can’t satisfy. Make it explicit and non-negotiable that IT will never ask an employee to authorize or install an app over the phone, so that the request itself becomes the red flag.
Guest and Experience Cloud hardening closes an adjacent door. The same actors have pivoted to mass-scanning Experience Cloud sites for over-permissioned guest user profiles and exposed API endpoints. If you run Experience Cloud, audit guest user object and field permissions, tighten Organization-Wide Defaults, and strip any API access a guest profile doesn’t strictly need.
What This Doesn’t Solve
Even with all of the above, you’re reducing likelihood and blast radius, not achieving immunity. Phishing-resistant MFA protects the accounts you’ve enrolled — a legacy service account or a break-glass login left on weaker factors is still a way in. Connected-app allowlisting only helps if you actually audit what’s already authorized; a malicious grant approved before you tightened the policy sits there until someone reviews it. And none of these controls govern data that has already left Salesforce in a prior export. Treat this as defense in depth: the goal is that no single manipulated phone call hands over the whole org, and that when something does slip, it shows up in your logs fast enough to matter.
The Bottom Line
The arrests are a real win, and the people who investigated and extradited these operators deserve the credit. But the campaign that hit Salesforce customers last year was never about a specific person or a specific flaw — it was about a technique that turns legitimate features and helpful employees against the org. That technique is now documented, copied, and AI-accelerated. The operators in custody will be replaced. Your connected-app policy, your MFA factors, and your help desk verification process won’t be — unless you change them. The cuffs don’t fix the help desk. You do.
Book a 15-Minute Security Strategy Call
Reference(s):
https://thehackernews.com/2026/07/19-year-old-scattered-spider-suspect.html
https://www.varonis.com/blog/salesforce-vishing-threat-unc604