Atlas ApexAtlasApex

Incident

ADT: Vishing → Okta SSO → Salesforce, 5.5M Records

Back to Thinking
IncidentADT 8-K filing / BleepingComputer reporting · Apr 2026
5.5M

Voice phishing of a help-desk operator compromised Okta SSO credentials. The attacker walked into Salesforce as a legitimate user and exfiltrated 5.5 million customer records. No malware, no zero-day, no credential stuffing — just a phone call.

Key Finding

Identity-aware controls at the IdP did not stop the attack because the attacker authenticated successfully. The control that would have caught it (session anomaly, browser-layer DLP, just-in-time scope reduction) sat outside the identity stack.

On 20 April 2026, ADT detected unauthorised access to customer and prospective-customer data inside its Salesforce instance. The breach disclosure confirmed that the entry vector was a voice-phishing campaign attributed to the threat actor ShinyHunters, who tricked an employee with Salesforce-connected access into approving a fraudulent authentication request against the corporate Okta SSO. From there the attacker queried Salesforce as a legitimate user and exfiltrated personal information belonging to roughly 5.5 million individuals.

There was no exploit. There was no malware. The Okta tenant was correctly configured. MFA was enrolled. The attacker authenticated through the same SSO path the legitimate user used every day — because the legitimate user approved the push notification at the wrong moment.

From an architecture perspective, three properties of the attack are worth naming:

The identity stack was not the failing layer. The IdP did exactly what it was supposed to do: it authenticated a user against a known factor with a valid approval. Anything downstream that depended on "the user is authenticated, therefore the request is legitimate" inherited the failure.

The blast radius was set by Salesforce, not by the IdP. Once inside, the attacker had query access to the entire customer record set because the compromised role had broad Salesforce permissions. A least-privilege model with per-record-type scoping and rate-limited bulk export would have reduced the loss by orders of magnitude.

The detection signal was post-exfiltration. The first sign of the attack was the leak-site post, not a behavioural alert. Browser-layer controls (session recording on the Salesforce app, anomaly detection on bulk-data actions, last-mile DLP on large-result queries) would have produced a real-time signal that the SSO + MFA combination could not.

ShinyHunters' 2026 campaign has reportedly hit 100+ organisations through the same playbook (vishing → SSO → SaaS). The conclusion for architecture is uncomfortable: identity authentication is solved; identity-aware authorisation, session-layer controls, and post-authentication defence are not.

Need help with your identity architecture?

Every incident on this page was preventable with the right architecture. Let's talk about yours.

Book a Conversation