ADT Confirms Breach: One Vishing Call → Okta SSO → 10M Salesforce Records — The ShinyHunters Playbook in Action

Introduction

ADT — the largest residential security brand in the United States — confirmed in an SEC Form 8-K filed April 24 that an attacker accessed parts of its cloud environment on April 20, 2026. ShinyHunters, the extortion crew behind the breach, posted a "Pay or Leak" notice claiming over 10 million records of customer PII, set a ransom deadline of April 27, and told BleepingComputer they got in by calling one ADT employee, social-engineering them into giving up Okta SSO credentials, and pivoting straight into the company's Salesforce tenant. No malware. No zero-day. Just a phone call, a federated identity, and a CRM full of personal data. This is the same playbook ShinyHunters has used against Canada Life, McGraw Hill, Hims & Hers, Wynn Resorts, Crunchbase, and Udemy in 2026 alone — and it's the breach pattern most enterprises are still wide open to.

What Happened

On Monday April 20, 2026, ADT detected unauthorized activity in its cloud-based environments. Forensic analysts traced it to a single compromised employee account at ADT's Okta SSO portal. The attackers used the resulting session to authenticate to ADT's Salesforce instance and exfiltrate customer data over a period of several hours before ADT's incident response team severed the session.

ShinyHunters told BleepingComputer the initial access came from a vishing (voice-phishing) call. An operator phoned the targeted employee, posed as IT support, and walked them through a "verification" flow that captured both the Okta password and a live MFA push approval. With the SSO session in hand, every Salesforce object the user could see was reachable — names, phone numbers, addresses, and in a "small percentage of cases" dates of birth plus the last four digits of Social Security or Tax IDs. ADT publicly disputes the 10M-record figure ShinyHunters posted but confirms PII was taken.

The pattern is identical to what ShinyHunters has been running against major Salesforce tenants for the past 12 months:

  1. Pick a target with a public-facing employee directory or LinkedIn presence
  2. Call a help-desk or junior employee, impersonate IT, claim there's a "session issue"
  3. Ask them to read a code from their MFA app, or push-bomb until they accept
  4. Authenticate to the company's Okta/Entra/Workspace IdP, harvest a session token
  5. Pivot to whatever SaaS app is connected — Salesforce, Microsoft 365, Workspace, SAP, Slack, Zendesk, Dropbox, Atlassian — and bulk-export
  6. Post on the leak site, set a one-week deadline, demand ransom

ADT has had three confirmed breaches in 12 months (August 2024, October 2024, and now April 2026). The April incident is the cleanest demonstration of why traditional perimeter and endpoint controls don't help: there is no perimeter to defend when the attacker authenticates through your own IdP using your own employee's hands.

Why It Matters

Vishing-driven SSO compromise is now the most prolific initial-access vector against mid-to-large US enterprises. It bypasses every email security control, every URL sandbox, every EDR rule. The MFA "phishing-resistance" bar most companies set in 2022 — TOTP codes and push notifications — was already broken by 2024 and is comprehensively defeated by 2026 attackers running social-engineering scripts at industrial scale. The attacker doesn't need to defeat MFA cryptographically; they just need to convince a human to approve the prompt.

The second-order problem is SSO blast radius. When one Okta account compromise hands an attacker access to Salesforce, M365, Slack, Confluence, GitHub, AWS, and Snowflake, the data-exfiltration ceiling is whatever the most-trusted user role can read. ShinyHunters' targeting of Salesforce specifically is rational: the CRM holds the consolidated customer record that drives both the most-valuable extortion data and the most-effective downstream phishing lists.

Who Is Affected

  • ADT customers and prospective customers (PII may be leaked April 27 if no payment)
  • Any organization using Okta, Microsoft Entra, or Google Workspace as its IdP with broad SaaS federation — particularly to Salesforce, M365, Workspace, SAP, Slack, Zendesk, Dropbox, Atlassian, Adobe — and without phishing-resistant MFA enforced
  • BPO/help-desk teams handling password resets and MFA re-enrollments — the prime ShinyHunters target population
  • Companies that have not implemented device trust as a session requirement, allowing attacker-controlled devices to reuse harvested SSO tokens

How to Protect Yourself

Step 1: Move the entire workforce to phishing-resistant MFA. TOTP and push are no longer adequate. Enforce FIDO2/WebAuthn (security keys or platform passkeys) for SSO, and turn off all weaker factors as a fallback. In Okta:

# Authenticator enrollment policy → Required factor types
- WebAuthn (Required)
- Okta Verify with FastPass + biometric (Allowed only with phishing-resistant proof of possession)
- Disable: SMS, Voice Call, Security Questions, Password (as sole factor)

In Microsoft Entra, set the Authentication Strength policy to Phishing-resistant MFA and apply to a Conditional Access rule that targets all users:

New-MgIdentityConditionalAccessPolicy -DisplayName "Phishing-resistant MFA all users" `
    -State enabled -Conditions @{Users=@{IncludeUsers="all"}; Applications=@{IncludeApplications="all"}} `
    -GrantControls @{Operator="OR"; AuthenticationStrength=@{Id="00000000-0000-0000-0000-000000000004"}}

Step 2: Lock the help-desk reset flow. This is where vishing actually lands. Require:

  • A ticket pre-created by the user from a known device
  • Verification via a secondary channel (manager callback, in-person, or pre-enrolled second-factor possession)
  • A delay before sensitive resets (e.g., MFA re-enrollment) that triggers a notification to the user's manager
  • Recording of all help-desk calls and a verbal challenge-response policy

ServiceNow and Okta Workflows both support this pattern. Document it. Tabletop it monthly.

Step 3: Require device trust on every SaaS session. A session token harvested by vishing is useless if the SaaS app refuses to accept it from a non-managed device. In Okta:

# Sign-on policy → Conditions → Device State
- Device must be: Registered, Managed (per Workspace ONE / Intune / JAMF integration)
- Reject sessions where device state cannot be verified

In Entra, enforce Require compliant device and Require Hybrid Azure AD joined device on all critical applications. Salesforce, M365, and Workspace all support this directly.

Step 4: Tighten Salesforce. Salesforce is ShinyHunters' favorite exfil target because the default permissions are wide. Audit and restrict:

# Via SFDX CLI — pull and review object access for each profile
sf data export tree --query "SELECT Profile.Name, PermissionsModifyAllData, PermissionsViewAllData, \
    PermissionsExportReport, PermissionsAPIEnabled FROM PermissionSet" \
    --target-org production --output-dir audit/

# Find profiles with unrestricted Account/Contact read
sf data query --query "SELECT Profile.Name FROM PermissionSet WHERE PermissionsViewAllData = true" \
    --target-org production

Then:

  • Disable Modify All Data and View All Data for everyone except a tiny break-glass admin group
  • Enforce IP login ranges per profile
  • Cap the daily API export volume per user
  • Enable Salesforce Shield Event Monitoring and forward ApiEvent, LoginEvent, BulkApiResultEvent to your SIEM
  • Enable Transaction Security Policies that block bulk exports outside business hours

Step 5: Hunt for the ShinyHunters TTPs in your own logs. Pull last 90 days of Okta/Entra logs and look for:

# Okta system log — vishing TTP indicators
eventType eq "user.authentication.auth_via_mfa"
  AND outcome.result eq "SUCCESS"
  AND client.userAgent.os ne "<expected-OS-for-user>"
  AND client.geographicalContext.country ne "<expected-country>"

Patterns to flag:

  • MFA enrollment changes followed within minutes by a successful SSO from a new IP/UA
  • SSO sessions where client.device ≠ the user's normal device
  • Salesforce BulkApiResultEvent records with RowsProcessed > 50000 outside business hours
  • Sequential LoginEvent from one user across Salesforce, M365, Slack, Workspace within minutes (the ShinyHunters multi-SaaS sweep)

Step 6: Train the workforce on vishing specifically. Email-phishing training does not transfer. Run quarterly tabletop drills where a vendor places real calls to your help-desk and front-line staff. Track the metric. The single biggest control you can implement today is:

"We will never ask you to read your MFA code or approve a push during a phone call. If anyone does, hang up and call security."

Step 7: If you've been hit by ShinyHunters and are within their payment window — invoke counsel, FBI/IC3 (1-800-CALL-FBI), CISA reporting (1-844-Say-CISA), and your cyber-insurance carrier before engaging the threat actor. Pre-coordinated playbooks exist with most large IR firms (Mandiant, CrowdStrike Services, Unit 42, Kroll, Coveware) for ShinyHunters specifically.

Source