September 01, 2026
Media reports alleged that Scattered Spider called the IT help desks at Marks & Spencer and Co-op, impersonated employees, and talked staff into resetting passwords.
It was reported that M&S alone lost an estimated $402 million in profit; Co-op had data on 20 million members exposed. The UK’s National Cyber Security Centre responded by telling every retailer to review its help desk’s identity-verification process. The attack vector wasn’t a phone system nobody could monitor. It was a phone line the business already owns.
What Happened
Fraud and security teams have spent a decade building defenses around the calls customers make in: IVR authentication, voice biometrics on banking lines, fraud scoring on contact-center traffic. That investment reflects a correct instinct. But it’s only aimed at half the problem.
In spring 2025, it was reported that Scattered Spider (also tracked as UNC3944, Octo Tempest) ran a short, low-tech campaign against two of the UK’s best-known retailers. The method was consistent across both:
- An attacker called the internal IT help desk.
- They claimed to be a real employee, using a name and enough personal detail to sound credible.
- They said they’d lost access and needed a password reset.
- The help desk agent, working under pressure to resolve tickets quickly, reset the password and handed the attacker a way in.
From there, it is alleged that the attackers moved into deploying DragonForce ransomware at M&S and exfiltrating member data at Co-op. No malware delivered the initial access. No vulnerability was exploited. A person picked up the phone, asked for something routine, and got it.
The Financial and Human Cost
The impact wasn’t abstract. M&S halted online orders for weeks and lost an estimated $402 million in profit. Co-op had to pull systems offline mid-attack to contain the damage, and personal data belonging to a large share of its 20 million members was still exposed. The UK’s National Cyber Security Centre took the unusual step of publicly urging all retailers, not just the two affected, to review their help desk password-reset workflows before the same technique hit them next.
Why This One Is Different From the Last Case Study
It’s worth being precise about scope, because it’s what makes this incident solvable in a way some vishing campaigns aren’t.
The attacks that make headlines every few months take two different shapes. In one, an attacker calls an individual employee directly, on a number that was never set up to be monitored or verified in the first place. That’s a hard problem: the business doesn’t own that call, and there’s no natural chokepoint to secure.
This is the other shape: an inbound call to infrastructure the business already owns, staffs, and controls, not a call nobody could have seen coming.
Allegedly the attacker called into a defined, owned line: the company’s own IT help desk. It’s the same category of call flow fraud teams already monitor at the contact center, just aimed at employees instead of customers. That distinction matters because it’s exactly the kind of call flow that can be verified in real time, the same way a bank already verifies the customer calling in about a locked account.
The Fix Isn’t More Training. It’s Verification at the Point of Contact.
Security teams’ instinct after an incident like this is often “train the help desk to ask better questions.” Well, yes, but that puts the entire burden back on a person under time, and rank, pressure to spot a well-researched impersonation, exactly the failure mode that let this happen twice in one month.
The more durable fix is to verify the caller before the request is ever actioned, using the same logic already applied to inbound customer calls:
- Real human? Is this a live, real caller, not a synthetic or replayed voice?
- Right human? Does this caller’s voice match the identity they’re claiming, against an enrolled voiceprint?
- Right outcome? Is the specific request, in this case a password reset, cryptographically tied to that verified identity in a record that holds up afterward?
None of that requires monitoring an employee’s personal phone or a call the business was never going to see. It requires treating the help desk’s inbound line the way a contact center’s inbound line has been treated for years: as a channel worth securing, not a convenience to route around.
The Takeaway
Scattered Spider didn’t need new tools to hit M&S and Co-op. They needed one thing: an inbound call nobody was verifying. Every retailer, hospital system, and enterprise with a phone-based help desk has that exact same exposure right now, on a line they already own and could already be monitoring.
