The Breaches That Hit Major Companies in August Were Actually One Script

Hi there, Basestone subscriber! 👋

Up until now, we've used this newsletter to give you a broad sweep of the month's security incidents. Starting this month, we're going to dig deeper into one topic instead. In August, healthcare distributor McKesson, telecom provider RingCentral, and nine Fortune 500 companies including McDonald's and Gap all had their SSO accounts compromised. At a glance, these look like separate incidents at unrelated companies, but when you break down the attack method, they're strikingly identical. Each one started with a phone call impersonating the help desk, moved through an expertly cloned login page, and ended with MFA itself intercepted in real time, the same six-step script, almost beat for beat. Today we're walking through exactly how this playbook works, why it's succeeding so often right now, and what set the one company that stopped it apart from the rest 🔐

📌 Quick summary of today's issue

• McKesson (Aug 25), RingCentral (discovered late July), and nine Fortune 500 companies (August) weren't separate incidents — they were the same six-step vishing script, run over and over
• The playbook is built as a real-time adversary-in-the-middle (AiTM) attack that intercepts even "number matching" MFA, which standard push-based MFA can't stop
• Phishing-resistant authentication like passkeys and security keys, which are cryptographically bound to a domain, is structurally immune to this attack
• The group behind it, Scattered Spider, ShinyHunters, and LAPSUS$, merged into one collective in August 2025, and that merger is exactly why the same script is now hitting so many companies at once

🔍 Here's exactly how this playbook works

Step 1: A call built on urgency

The attacker calls an employee posing as IT, HR, or a help desk staffer. They lead with something that feels urgent, "your benefits enrollment deadline is closing," "we're migrating the claims system," "we need to re-verify your security settings," and stay on the line while directing the target, by text or voice, to a specific link.

Step 2: A fake address that looks real

The domain they send you to isn't a typo-squat like most phishing links. It's registered to sound like it naturally belongs to the company and its industry, something like mckesson.claims, which is exactly why it's hard to spot as suspicious at a glance.

Step 3: A meticulously cloned login screen

Opening the link brings up an Okta login page reproduced down to the company logo, a "Connecting to..." banner, and the exact real layout. The address bar even displays a convincing-looking SSO URL, making it nearly impossible to distinguish from the real thing by eye.

Step 4: Credentials relayed in real time

When the employee enters their username and password, that data isn't stored for later, it's relayed to the attacker the instant it's typed.

Step 5: Number-matching MFA relayed in real time too

This is the heart of the attack. "Number matching" was designed specifically to stop what's called an "MFA fatigue attack," where an attacker blindly spams push approvals hoping the victim taps yes. The logic is simple: since approval requires matching a number shown on screen with one in the authenticator app, an attacker who can't see the victim's screen shouldn't be able to get through. But this attack kit isn't stealing and replaying static data, it's built as an adversary-in-the-middle (AiTM) relay operating in real time between the victim and the attacker. The moment the victim submits their credentials, the attacker uses them to attempt a real Okta login, and the real backend's real challenge number gets piped straight back onto the victim's fake screen. The victim sees the number on the fake page match the one in their own authenticator app, feels reassured, and approves it, unknowingly approving the attacker's login instead.

Step 6: A quiet takeover behind an approval screen

The victim sees a brief "approved" screen while the attacker finishes authenticating on the real backend behind the scenes. With the SSO session this hands them, the McKesson attackers reached Salesforce and Snowflake; in the other incidents, they reached whatever internal systems that session unlocked.

🧭 Why this script is working so often right now

The fact that passkeys aren't defeated actually exposes this attack's limits

Here's what's interesting: this attack kit actually disables passkeys on purpose, showing them on the selection screen as "currently unavailable in this region." It doesn't do this because passkeys are hard to break, it does this because they can't be broken at all. A passkey is cryptographically bound to the exact domain where the login attempt happens, so a passkey registered to yourcompany.okta.com will simply refuse to sign for a fake domain like yourcompany.claims. No matter how perfectly the screen is cloned, this structural check can't be routed around. In other words, this attack's sophistication only gets it past number-matching MFA, not every authentication method out there.

The reason this script is hitting so many targets comes down to a merger

In August 2025, Scattered Spider (strong in sophisticated social engineering), ShinyHunters (strong in automated mass data exfiltration), and LAPSUS$ (strong in psychological pressure and media exposure) merged into a single collective. Since then, they've operated through a network of Telegram channels in a structure that functions less like a hacking crew and more like a franchised "attack-as-a-service" operation, similar to how ransomware groups run affiliate programs. That's why August's incidents, which looked like they happened at unrelated companies, actually trace back to the same tools, the same script, and the same group behind the curtain.

What separated the company that stopped this from the ones that didn't comes down to what they actually detected

Security firm ReliaQuest faced the exact same style of attack but managed to block access before any data was actually stolen. The company hasn't disclosed the specific signal that tipped it off, but it credited "monitoring of identity telemetry" and "a response process that escalates quickly" as the factors behind its success. This attack leaves behind no malware and exploits no vulnerability, so antivirus tools and patches can't stop it. Behavioral detection and human judgment are the only line of defense left.

✅ Check these about your own help desk first

• Before your help desk approves a password reset or MFA removal, does it verify identity through a second channel beyond the phone call itself (a registered manager's approval, an internal app notification, etc.)
• Have you moved at least your admin and other high-value accounts to passkey or security key (FIDO2/YubiKey) authentication, and closed off any fallback path that lets them drop back to number matching or SMS
• Do your help desk staff have a standard procedure to hang up on any urgency-driven request and call back on a registered number, rather than continuing the call as-is
• Does behavioral anomaly detection on SSO login attempts (unusual location, a new device, repeated attempts in a short window) trigger a real-time alert, and does that alert reach the right person quickly

⚠️ What teams often miss

The false comfort of "we use number matching, so we're safe"

Number-matching MFA stops blind push-approval attacks, but it's helpless against a real-time relay attack like this one. Rather than judging safety by which type of MFA you use, the better question is whether that MFA actually verifies the login page's authenticity itself, in other words, whether it's bound to the origin domain.

Help desk training often stops at "how to spot a phishing email"

A lot of security training is so focused on email phishing that training for phone-based social engineering gets comparatively little attention. Help desk staff hold the keys to account recovery, which makes them one of the most sophisticated targets out there, and that calls for training of its own.

"There's no technical flaw in this attack. The only vulnerability was a person who had to trust the voice on the other end of the phone." — Basestone Security Research Team

🚀 How to start small

A good first step is moving your smallest, highest-risk group, admin accounts or IT staff accounts, the ones that do the most damage if compromised, to passkey or security key authentication. If rolling it out to every employee at once isn't realistic, starting with your riskiest accounts alone is enough to cut off this attack's core pathway.

If you'd like to look back at last month's Foreign Ministry hack and KDDI leak as well, we'd also recommend reading From the Foreign Ministry Hack to KDDI's Massive Leak, a Roundup of July 2026's Security Incidents.