One Phone Call to 5.5 Million Records: The ADT Vishing Breach and the SSO Blast-Radius Problem SMBs Share

On April 20, 2026, ADT — one of North America’s largest home-security providers, serving over 6 million customers — detected unauthorized access to a limited set of customer data. By April 24, the company had filed an 8-K and publicly disclosed the incident. By April 27, the extortion group ShinyHunters had told BleepingComputer how they did it: a voice phishing call to an ADT employee, an Okta SSO account handed over, lateral movement into Salesforce, and 11 GB of customer data on the way out the door. Have I Been Pwned ultimately tallied the damage at approximately 5.5 million accounts.

This is ADT’s third confirmed breach in under twelve months — Safestate’s breakdown notes prior incidents in August and October 2024. None of those previous events involved exotic tradecraft either. The pattern that broke ADT is the same pattern that has run through Twilio, MGM, Caesars, Snowflake customers, Salesforce’s 1,000-organization ShinyHunters campaign, and the Medtronic incident disclosed the same week as ADT: an English-speaking caller, a help desk, an SSO account, and a SaaS app full of customer records.

The reason this matters for SMBs is not the size of ADT’s loss. It is that the attack does not scale up — it scales sideways. The same call script that worked at ADT works at a 200-person managed-services firm with Okta in front of HubSpot and Salesforce. If you operate SSO in front of any SaaS that holds your customer or financial data, you have ADT’s threat model. This piece walks through what ShinyHunters actually did, why traditional MFA did not stop them, and the help-desk, identity, and SaaS-side controls every SMB should be running this month.

What ShinyHunters actually did

The most useful single source on the broader 2026 ShinyHunters playbook is Push Security’s analysis of the Instructure breach, published a week before the ADT disclosure. It documents three repeatable attack vectors the group has used through 2025-2026, and ADT’s case is a textbook execution of the first two:

Step 1: Reconnaissance. The group profiles a target organization on LinkedIn and B2B databases, identifying help desk staff, IT operations, and ideally employees who are publicly tagged as “new hire” or recently relocated. The FBI/CISA Scattered Spider advisory from July 2025 documents that this group accurately answers help desk verification questions during the call by harvesting the answers in advance — mother’s maiden name, last four of SSN, and recent ticket numbers are all available cheaply.

Step 2: The vishing call. A live caller, typically a native English speaker, phones the help desk impersonating a real employee. The pretext is almost always urgent: a mandatory passkey rollout, a security compliance update, an MFA reset before a board presentation. The caller wants a password reset, an MFA factor reset, or both. The help desk, working from a script that prioritizes “unblocking the user” over “verifying the user,” complies.

Step 3: SSO compromise. Once the attacker controls the Okta or Entra ID account, the entire SaaS portfolio behind that SSO is reachable. IT Accuracy’s ADT timeline puts the point bluntly: SSO is the blast-radius multiplier. In ADT’s environment, that meant Salesforce. In other 2026 victims it has meant Microsoft 365, Google Workspace, Slack, Zendesk, Dropbox, SAP, Atlassian, and Adobe.

Step 4: SaaS data exfiltration. Inside Salesforce, ShinyHunters operates with the permissions of the compromised user. Push Security notes that the group’s primary tool is a renamed “DataLoader”-style OAuth application that requests full API access and refresh tokens, allowing bulk export that often hides better than UI-driven downloads. ADT’s 11 GB archive was extracted this way.

Step 5: Extortion and leak. ShinyHunters listed ADT on their dark-web leak site on April 23 with a payment deadline. ADT did not pay. The full archive was published shortly after. The public number — 5.5 million accounts — came from Have I Been Pwned’s post-leak analysis, not from ADT’s initial disclosure, which described the loss as “a limited set.”

Notice what is not in this attack chain: no exploits, no malware, no zero-day. CrowdStrike’s mid-2025 Scattered Spider services observation — tracking a closely related cluster — confirmed that help-desk vishing was used in almost every observed 2025 incident to compromise Microsoft Entra ID, SSO, and VDI accounts. The technical sophistication of this entire category is one phone call.

Why standard MFA didn’t save them

Two reasons, both relevant to every SMB.

First, ShinyHunters does not bypass MFA. They reset it. The help desk re-enrolls a new factor on the attacker’s device because the help desk believes the call is legitimate. From that point forward, the attacker satisfies MFA cleanly. There is no “MFA prompt bombing,” no token theft, no novel cryptographic attack — just a procedural failure dressed in a trusted phone voice.

Second, when push notification or SMS MFA is still in use, the group runs adversary-in-the-middle phishing pages branded to look like the victim’s SSO portal (typical patterns are <company>sso.com or <company>internal.com) and relays both credentials and OTP codes in real time through a live operator. Push Security notes the resulting session token grants an authenticated session that survives until manually revoked. Hardware-key MFA does survive this attack class. App-push, SMS, and TOTP do not.

The SMB hardening playbook

Step 1: Vishing-resistant help-desk verification

The single highest-leverage control is procedural, not technical. Every password reset and every MFA reset performed by a human help-desk operator should require at least two of three of the following, with at least one being non-spoofable:

• Manager callback to a number listed in the HRIS, not provided by the caller
• Video confirmation from the employee using a known corporate device, with the agent watching the on-camera employee perform a live action (read a code shown on screen)
• A second factor the attacker cannot harvest from public sources — the employee’s most recent help desk ticket number, the name of the manager who approved last quarter’s laptop refresh, or any rotating shared-secret you maintain outside the HRIS

The mistake we see most often at SMBs is using SSN-last-four or date of birth as the verification token. Both are already in the breach data for most of your employees. Treat any datum that appears in a major US breach as effectively public.

Step 2: Move admins and high-blast-radius accounts to phishing-resistant MFA

The official guidance has been stable for two years and is now non-negotiable: CISA’s phishing-resistant MFA guidance recommends FIDO2/WebAuthn or PIV hardware tokens for any account with privileged access or access to sensitive data. For an SMB that means, at minimum:

• IT, security, and help-desk staff — YubiKey or platform passkey only
• Finance, payroll, and HR — YubiKey or platform passkey only
• Anyone with Salesforce admin, M365 Global Admin, or Okta Super Admin — YubiKey only, with at least two registered keys per user
• Block SMS, voice call, and email MFA on every privileged role group; allow app push only as a transitional state with documented expiry

Step 3: Hunt for the OAuth and session signatures of this attack

If a ShinyHunters-style operator gets in, they will register or use an OAuth app to bulk-export. Run these queries weekly. In Okta, pull System Log events for new OAuth app authorizations granted to user accounts in the last 7 days — particularly any app requesting full or api scope. In Salesforce, run a SAQL or Setup Audit Trail query for new Connected App authorizations and for any user whose data export volume jumps 5x off baseline in a 24-hour window.

For Microsoft 365 customers, this Advanced Hunting KQL surfaces the same pattern in Entra:

AADAuditLogs
| where TimeGenerated > ago(7d)
| where OperationName in ("Consent to application", "Add app role assignment grant to user")
| extend Target = tostring(parse_json(TargetResources)[0].displayName)
| extend ConsentedScopes = tostring(parse_json(AdditionalDetails)[1].value)
| where ConsentedScopes has_any ("full_access", "offline_access", "Mail.Read", "Files.ReadWrite.All", "Sites.ReadWrite.All")
| project TimeGenerated, InitiatedBy=tostring(parse_json(InitiatedBy).user.userPrincipalName), Target, ConsentedScopes
| order by TimeGenerated desc

The output is not zero in most environments we audit. Most of it is benign. The signal you are hunting is a brand-new OAuth app, broad scopes, consented by a non-admin user, followed by API activity from a new IP and a new user agent within minutes. Pair this with the egress visibility we covered in yesterday’s Mexico AI breach playbook and you cover both the human-driven and AI-driven exfiltration patterns.

Step 4: Shrink the SSO blast radius before it is tested

The instinct is to put everything behind SSO for convenience. The discipline is to scope it deliberately:

• Tier SaaS apps by sensitivity. Tier-1 (Salesforce, M365 with customer data, finance systems) requires both SSO and a session-binding policy that revokes if the IP or device posture changes mid-session.
• Require step-up authentication — a second hardware-key tap — for bulk export, admin role assumption, or data download actions in Tier-1 apps.
• Limit Connected Apps and OAuth grants in Salesforce, Google Workspace, and M365 to an admin-approved list. Block user-side OAuth consent for any unverified publisher.
• Set Okta and Entra session lifetimes to the shortest your business can tolerate — 8 hours for standard users, 1 hour for admins. Long-lived refresh tokens are how attackers stay after the help-desk reset is reversed.

Step 5: Rehearse the breach on a quarterly cadence

This is where most SMBs fall down. The vishing playbook does not require a third-party purple team to test. Pick one quarter: brief the security lead, write a script, call your own help desk pretending to be a real employee whose manager has been read into the test, and document what happened. We have run this exercise at SMB clients where the help desk reset MFA in under four minutes with no callback. None of those teams considered themselves under-trained until they listened to the recording.

ADT’s public statement says “protocols performed as designed: the breach was identified quickly, the threat was contained, and the scope was limited.” That is true in the narrow sense and beside the point in the larger one. The protocol that mattered — the one that decides whether a help desk hands over an SSO account in the first place — either exists in your environment or it does not. The SMB version of this attack does not arrive with a public 8-K. It arrives with one missed Salesforce alert, six months later, when a customer asks why their data is in a Telegram channel.

The defenses for this class of attack do not require a new product purchase. They require help-desk procedure that an SMB can actually train and audit, hardware-key MFA on the accounts that matter, and OAuth and session hygiene in the SaaS tier. None of that is expensive. The cost of not doing it is the cost of an ADT-shaped headline.