ADT got popped because someone called the help desk. 5.5 million records out the door.

# ADT got popped because someone called the help desk. 5.5 million records out the door.

On April 25, 2026, ADT confirmed a data breach affecting 5.5 million customers. ShinyHunters claimed responsibility on their leak site within hours. The personal data exposed includes names, addresses, phone numbers, email addresses, and — for a smaller subset — dates of birth and the last four digits of Social Security numbers.

The attack chain, per ShinyHunters' own statements to *BleepingComputer* and corroborated by ADT's disclosure: an attacker placed a vishing call to ADT's help desk pretending to be an employee, talked the agent into resetting the employee's Okta single sign-on, used the reset SSO session to access the employee's authorized applications, and dumped data out of ADT's Salesforce instance.

That is the entire story. No zero-day. No clever exploit. No nation-state tradecraft. A phone call to a help desk. Which is to say — exactly the same playbook that worked on MGM, Caesars, Snowflake, and a long list of other 2024 and 2025 victims attributed to Scattered Spider / UNC3944. And exactly the playbook we have been writing about all year.

This post walks through what is publicly known about the ADT incident, why this attack pattern has become the dominant threat for any company with a help desk and an SSO, and the specific help-desk procedural changes that actually break the chain.

#What ADT confirmed

From the disclosure and public reporting:

• The breach was detected on April 20, 2026.
• The intrusion was traced to "an unauthorized third party who gained access to certain internal systems."
• Customer security systems were not affected — the attacker did not access live alarm or monitoring infrastructure. The exposed data is from customer-relationship and account-management systems.
• ADT contacted all 5.5 million affected customers individually.

ShinyHunters' separate statements add the technical color the disclosure does not. The voice phishing target was an ADT employee. The Okta reset gave the attacker the same access the employee had. From there, the attacker authenticated to ADT's Salesforce instance and exported the customer object.

Salesforce export is not subtle. A bulk customer-data export from a sales user generates audit logs. The fact that the attacker was able to complete that export and exfiltrate the data before being detected — five days passed between intrusion and detection — points to gaps in the SOC's detection coverage on Salesforce, not to clever evasion by the attacker.

#The Scattered Spider playbook, in five steps

The vishing-Okta-Salesforce chain is so consistent across 2024-2026 victims that it is worth writing out as the canonical playbook:

Step 1: Reconnaissance. Identify the target's IT help desk number. Scrape LinkedIn for an employee with enough seniority that the help desk treats their request as a priority but not so much seniority that the help desk knows them personally. Mid-level managers, regional sales leads, recent hires in technical roles. Pull their voice from any public recording — earnings call, conference talk, podcast — to clone if a callback challenge is posed.

Step 2: Vishing. Call the help desk. Use the target's name. Provide enough context that the help desk treats the call as legitimate (employee ID, manager's name, business unit). Frame the situation as urgent — locked out of an account, traveling, stuck on a deadline.

Step 3: SSO reset. Ask for an MFA reset on the target's primary SSO. The help desk's standard procedure may include identity verification questions, but those questions are typically answerable from public data, LinkedIn, or material the attacker harvested earlier in the recon step. If the help desk insists on a callback to a registered phone number, the attacker either has already SIM-swapped that number (occasionally), or routes the callback through their own infrastructure (more commonly).

Step 4: Privilege walk. Once authenticated to SSO, enumerate accessible applications. Salesforce is almost always one of them in any company that has a sales operation. Workday, Slack, GitHub, Jira, ServiceNow, internal admin panels — same enumeration.

Step 5: Exfiltration. Use whatever bulk-export feature each accessible app provides. Salesforce's report builder. Workday's report exports. Snowflake's COPY INTO. The data flows out the front door under the user's permissions.

The whole chain typically takes less than two hours from first call to first exfiltrated record.

#What breaks the chain

The defenses that work all live in step 3. Once the attacker has SSO, they will find data. Detection on the export step is necessary but reactive. The help desk is the choke point.

Phishing-resistant identity proofing. The help desk should never accept identity verification answers that are knowable from public data. Birthdays, employee IDs, manager names — all in scope for an attacker. The verification needs to be something the attacker cannot have: a one-time code sent to the registered hardware token, an in-person presence at a designated office, a callback to a phone number the help desk pulls from a separate authoritative source (HR system, not the attacker-claimed number).

Out-of-band verification for sensitive resets. MFA resets, account unlocks, and SSO password changes are all sensitive. The help desk should not perform any of these on the basis of a single channel (phone call) alone. The protocol should require the user to acknowledge through a second channel — a confirmation in their work email, a response in their Slack, a Teams notification — before the reset takes effect. If the attacker has compromised one channel, they probably do not have all of them.

Rate-limit the help desk's reset capacity. A help desk agent who performs MFA resets at scale during a single shift is a red flag. Most companies do not realize how rare these requests actually are in normal operation. A real employee gets locked out maybe once a quarter. An agent who handles 15 reset requests in a single shift is either being phished or is rubber-stamping a process that should require more friction.

Detection on SSO reset events. Every Okta MFA reset, every Azure AD password reset, every Google Workspace recovery action should generate a SOC alert. A burst of resets from a single agent, or a reset followed within minutes by an unusual login from a new device or geography, is a high-fidelity tell.

Salesforce-specific controls. ADT's bulk export was the actual exfil mechanism. Salesforce's Event Monitoring and Shield platform encryption add detection coverage for exactly this — Bulk API exports, Report Export events, large SELECT queries via the API. If you run Salesforce and have not enabled Event Monitoring, this incident is the case for the line item in your next budget cycle.

#The pattern across the 2024-2026 victim list

ADT is the latest entry in a list that includes:

• MGM Resorts (September 2023) — vishing into help desk → Okta → multiple ERP and POS systems offline → an estimated $100M of revenue impact
• Caesars Entertainment (August 2023) — same pattern, $15M ransom paid to keep the data quiet
• Twilio (August 2022) — vishing-targeted credential phishing → access to Authy customer data
• Cloudflare (August 2022) — same vishing campaign, hardware-key MFA prevented the compromise (the only major vendor in the wave that survived)
• Reddit (February 2023) — phishing → SSO → internal documents
• Coinbase (May 2025) — vishing of overseas help-desk contractors → customer data exposure
• Snowflake-customer wave (2024) — credential stuffing into Snowflake tenants without MFA → 165 customer breaches including AT&T, Ticketmaster, Santander, Advance Auto Parts
• Marks & Spencer (April 2025) — same Scattered Spider playbook, UK retail
• Co-op Group (May 2025) — same playbook, UK retail
• Harrods (May 2025) — same playbook again

The common thread is the help desk's verification process plus a high-trust SSO that grants broad access once authenticated. Every company on this list had a help desk that performed the reset. Every one of them had an SSO that, once compromised, opened the door to enough applications to exfiltrate data of value. Every one of them paid the consequence in the public news cycle.

#What changes after ADT

The lesson the public narrative will draw is *home security companies are vulnerable too* — which is true and miss-scoped. The actual lesson is the vishing-into-help-desk attack model is now industry-standard against any organization with an SSO, and most help-desk procedures have not been updated since the model went mainstream in 2023.

Every CISO reading the ADT incident should be running the following exercise this week:

1. Have someone on the security team call your own help desk pretending to be a real employee, and try to get an MFA reset. Document what verification the help desk performed and whether it would have stopped a determined attacker.
2. Pull the SSO reset logs from the last 90 days. Categorize each reset by the channel of the request and the verification performed. Look for patterns of "phone call → reset" without out-of-band confirmation.
3. Pull the Salesforce / Workday / Snowflake / Snowflake-equivalent bulk-export audit logs for the same period. If your SOC does not currently alert on bulk exports from a user account that has not historically performed bulk exports, that is your detection gap.
4. Schedule a help-desk procedure update that requires multi-channel verification for any reset of an SSO credential or MFA factor.

The attack is repeatable. The defenders' posture has not been updated. The cost of standing pat is the next ADT-style headline with your company's name on it.

#How Valtik helps

We red-team help desks, audit SSO and identity-provider configurations, and run tabletop exercises on the vishing-into-Salesforce chain specifically. If you have an SSO, a help desk, and a CRM, you have the pattern. We map your exposure to the attack chain that has hit a dozen named companies in two years, and we identify the specific procedural gaps that need to close. Free external check at valtikstudios.com/free-check. Direct: contact@valtikstudios.com.