TL;DR - Two members of the Scattered Spider ransomware group pleaded guilty on day one of their UK trial on 23 June 2026, including the man US prosecutors link to the 2023 MGM and Caesars attacks and to a 2022 SMS phishing campaign that stole single sign-on credentials from 130+ companies. The technique they used is the simplest one in the social-engineering playbook: phone a helpdesk, pretend to be an employee who has locked themselves out, ask nicely for an MFA reset. It still works, and your business is in the blast radius whether your helpdesk is in-house or outsourced. What you need to do: ask your IT provider the questions in this article - two if your helpdesk is in-house, four if you outsource to an MSP - and treat the answers as a measure of your actual exposure. If the answer is "we just ask for the employee's date of birth" or "we email the manager", that is your exposure.
By The Numbers
| Thing | Figure |
|---|---|
| When the guilty pleas landed | 23 June 2026, day one of a six-week UK trial |
| Who pleaded guilty | Two men linked to the August 2024 Transport for London attack |
| US indictment details | 120 intrusions, 47 US entities, May 2022 to September 2025 |
| Ransom payments linked to the group | At least $115 million |
| 2022 SMS phishing wave victims | 130+ companies including Twilio, Cloudflare, DoorDash, Mailchimp, Signal |
| Technique that keeps working | Phone the helpdesk, ask for an MFA reset |
The phone call that cost MGM $100 million
I want to tell you a story about a phone call, because it is the kind of story that should change how every Australian business thinks about its IT helpdesk, and most of them are not paying attention yet.
The call happened in September 2023. A man later identified as a member of a loose criminal collective calling itself Scattered Spider phoned the IT helpdesk at MGM Resorts in Las Vegas. He said he was an employee who had lost his phone and could not get into his work account. He knew the employee's name, his employee number, and a few plausible details about his role. The helpdesk agent reset the multi-factor authentication and gave him a new factor tied to a phone number the attacker controlled. From there it took about an hour for the attackers to pivot into MGM's core systems, encrypt the property-management servers that run the casinos, and walk away with the data of roughly 10 million guests.
The cost has been estimated north of $100 million in lost revenue, incident response and remediation. Caesars Entertainment, hit by the same group weeks earlier using the same technique, paid roughly $15 million in ransom to make it stop. US aviation companies, the UK retailer Marks & Spencer, the British retailer Co-op, Harrods, and Transport for London have all been linked to the same playbook in the three years since.
On 23 June 2026, two members of the group pleaded guilty in the UK on day one of what was expected to be a six-week trial. One of them was identified by US prosecutors as the man who gave anonymous media interviews in the days after the MGM attack. The guilty pleas are not the end of the story. They are the part of the story where the technique stops being insider knowledge and starts being on the public record for every other criminal group to learn from.
What the trick actually is
The technique has a name: helpdesk vishing, or just "callback phishing" in some writeups. It is a phone call, not an email. There is no malware. There is no fake login page. The attacker rings your helpdesk, pretends to be one of your staff, and asks for help with one of three things:
- "I lost my phone, can you reset my MFA?"
- "I just got a new phone, can you re-enrol me?"
- "I'm travelling and can't get into my account, can you send me a temporary code?"
The success rate is embarrassing. The reason it works is that most helpdesks are measured on how quickly they close tickets, not on how well they verify identity. An agent who takes five minutes to walk a caller through an MFA reset looks like they are doing their job. An agent who escalates the same call to a callback verification looks like they are being unhelpful. The metrics push in the wrong direction.
What the attacker brings to the call is research. They will know the employee's name. They will often know the employee's manager. They will know roughly when the employee started. Some of that comes from LinkedIn, some from old data breaches, some from social-media stalking. None of it is hard to get. The attackers spend hours preparing for a single call.
The defence is not complicated. It is just enforced.
The two questions to ask your IT provider this week
If your helpdesk is in-house, ask the person who runs it these two questions tomorrow morning:
- "If someone calls in and says they lost their phone, what is your verification process before you reset their MFA?"
- "What is the absolute fastest you would do that reset?"
The right answer to question one is something that involves a callback to a known phone number already on file, not the one the caller is calling from. Some organisations require an in-person visit to a known office for MFA resets. Some require a manager callback on a known number. Some require a video call with a government ID held up to the camera. None of those are perfect. All of them are dramatically better than the default, which is "ask the caller for their date of birth and email it through".
The right answer to question two is "at least 30 minutes, ideally longer". If your helpdesk can reset MFA in under five minutes from a phone call, you have a problem. The attackers are counting on speed.
If your helpdesk is outsourced to a managed service provider (MSP), the same questions apply, but with one extra wrinkle: the attackers know that MSP helpdesks have hundreds of clients, and that the agent on the phone probably does not personally know the employee they are being asked to verify. The social engineering pressure is even higher on an outsourced helpdesk, because the agent wants to be helpful to a customer they do not know well. If your MSP does not have a documented, enforced verification process for MFA resets, that is your exposure, not theirs.
What to ask your MSP specifically
If you outsource IT, here are the four questions that will tell you whether you are protected or exposed. Ask the account manager, not the technician. You want the policy answer, not the technical workaround.
- "Walk me through what happens when one of my staff calls in and says they lost their phone." You want a multi-step verification. If the answer is one step, push back.
- "Has anyone tried to social-engineer your helpdesk in the last 12 months?" Every MSP that takes this seriously will say yes and tell you about it. If they say no, they are not monitoring for it.
- "Do you have a separate verification channel for MFA resets, or do you use the same phone call?" Same call = same attack surface. They need a different channel.
- "What is your average time-to-close on an MFA reset ticket, and how much of that is verification?" Fast reset, slow verification is fine. Fast everything is a red flag.
If the answers make you uncomfortable, this is a good week to bring the conversation up. The Scattered Spider guilty pleas are a free prompt. "I read about Scattered Spider pleading guilty, can you walk me through our helpdesk process?" is a reasonable question for any business owner to ask right now.
What good looks like for an in-house helpdesk
If you run your own IT team, here is the floor. None of it is exotic. All of it works.
- MFA resets require a callback to a phone number on file. Not the one the caller is calling from. A different one.
- High-risk resets (MFA, password, security questions) require a second person to approve. The ticket cannot be closed by the agent who took the call.
- All MFA resets are logged with the reason, the verification steps taken, and the outcome. If you cannot produce that log on demand, you are not actually enforcing the policy.
- Reset requests during unusual hours get extra scrutiny. A 2am call from a senior employee who has never called the helpdesk before is a red flag, not a service opportunity.
- Privileged accounts (admins, finance, executive assistants) require video verification. A selfie with a government ID held next to the face is the bare minimum for these roles.
None of this is expensive. All of it is annoying to legitimate users some of the time. The trade is worth it, because the alternative is the phone call MGM took in 2023.
What the guilty pleas change
Nothing changes technically. The technique has been public for three years. The attackers will adapt, the defenders will catch up, the attackers will adapt again. That is the normal rhythm.
What changes is the social permission to take this seriously. For the last three years, "we might get hit by a helpdesk vishing attack" has been a hypothetical for most Australian businesses. Now it has case law, named defendants, and a public technique. If your board has been pushing back on helpdesk verification policies because they are "too much friction", the 23 June 2026 guilty pleas are the moment to push that conversation back open. The friction is the point.
The Australian Cyber Security Centre has been publishing helpdesk-vishing guidance since at least 2024. Most SMBs have not read it. This is a good week to read it, send it to your IT provider, and ask what they have done with it. The cost of doing nothing just got a named defendant attached to it.
Key Takeaways
- Two Scattered Spider members pleaded guilty on 23 June 2026. The trial was expected to last six weeks. They pleaded on day one. The technique is now public.
- The technique is a phone call. No malware, no fake login page, no exploit. Just a confident caller asking for an MFA reset, with enough background research to sound credible.
- The defence is verification, not technology. Callback to a known phone number, separate-channel approval, manager sign-off, video verification for privileged accounts.
- Ask your IT provider four questions this week. Their answers will tell you whether you are protected or exposed.
- The friction is the feature. Every minute your helpdesk spends verifying an MFA reset is a minute the attacker does not have.
FAQ
Q: I use a password manager and MFA on every account. Am I still exposed to this?
Yes. The attack is not against your password or your MFA app. It is against your helpdesk. The attacker convinces a real human to do a legitimate reset, which the helpdesk then performs correctly. Your personal security setup does not help here. The exposure is in the verification process your IT provider uses, not in your own credentials.
Q: My MSP is great. They are not the weak link.
I hope you are right. Ask them. The MSP industry has been warned about helpdesk-vishing for years. The good ones have policies, verification processes and audit logs. The average ones have a ticket queue and a phone number. You cannot tell which one you have without asking. If they cannot answer the four questions in this article clearly, you have your answer.
Q: Is this really still happening in 2026?
Yes. Every week. The Australian Cyber Security Centre publishes alerts on social-engineering attempts targeting Australian businesses, and helpdesk vishing is one of the most common patterns. The Scattered Spider guilty pleas are a milestone, not a conclusion. The technique is in the public record now, and copycats learn from public records.
Q: What is the minimum verification I should accept from my helpdesk?
A callback to a phone number already on file, plus a second-person approval for the reset itself. Anything less is the helpdesk optimising for ticket close time over your security. If you are a small business with no second person, a video call with a government ID is the next best option.
Q: Should I delay all MFA resets during business hours to slow this down?
No. Legitimate staff need MFA resets to work. The fix is verification, not delay. Make the verification rigorous. Do not make the helpdesk unhelpful. The two are different.
Q: What about passkeys? Would they stop this?
Partly. Passkeys tie authentication to a specific device, so a stolen password alone does not get an attacker in. But passkeys still need to be enrolled, and enrolment is a helpdesk process. If the helpdesk can be talked into re-enrolling a passkey on the attacker's device, the attacker is in. Passkeys make the attack harder. They do not remove the helpdesk from the attack surface.
My Take
I have been writing about Scattered Spider for a couple of years, and the thing that keeps striking me is how un-specialised the technique is. There is no zero-day. There is no exotic malware. There is no nation-state tooling. There is a phone call and a confident voice and a helpdesk that wants to be helpful. That is the whole attack.
The reason it works is that most businesses have spent twenty years optimising their helpdesk for speed and friendliness, and have not updated the verification process to match the threat. The metric your service desk manager reports on is probably average handle time and first-call resolution. Those metrics push the agent to close the ticket. They do not push the agent to verify identity through a separate channel.
The guilty pleas on 23 June 2026 are useful because they take the technique out of the rumour mill and into the public record. The next time a business owner pushes back on helpdesk verification because it slows their staff down, there is a named defendant to point at. That is the social permission I have been waiting for.
The deeper fix is structural. Treat an MFA reset the way a bank treats a wire transfer: callback to a known number, second-person approval, full audit log, mandatory video for high-risk accounts. The cost is friction. The benefit is that the next phone call from a criminal asking nicely for an MFA reset does not turn into a $100 million incident. That trade is not close.
If you take one thing from this article, take this: phone your IT provider this week, ask the four questions, and write down the answers. If the answers make you uncomfortable, change provider. The cost of switching is much lower than the cost of the call you do not want to take.
Mathew Clark Founder, SecureInSeconds Currently: making the helpdesk slower on purpose.
Further Reading
- Scattered Spider Hackers Plead Guilty on Day 1 of Trial (Krebs on Security, 23 June 2026) - the original reporting on the guilty pleas.
- United Kingdom National Charged in Connection with Multiple Cyber Attacks (US Department of Justice, September 2025) - the 120-intrusion, $115 million indictment.
- ACSC guidance: social engineering - the Australian Cyber Security Centre's playbook for this attack class.
- How 1-Time Passcodes Became a Corporate Liability (Krebs, August 2022) - the SMS phishing wave that hit 130+ companies, run by the same group.
- Microsoft Agent 365 and the Defender stack: what the 2025 rollout actually means - related: the Microsoft tooling for catching the post-compromise activity after an MFA reset succeeds.
- Social engineering in 2026: the patterns that keep working - what the aftermath of a successful social engineering attack actually looks like for a small business.
- Zero trust for normal people - the same "never trust the inbound request" thinking, applied to identity.
