Two Retailers, One Attack: What Really Decides Who Survives a Breach

In April 2025, two of Britain's most recognized retailers were hit by the same adversary, using the same attack technique, in the same month. One lost hundreds of millions of dollars. The other noticed within minutes and kept the lights on.

For readers outside the UK: Marks & Spencer (M&S) and the Co-op Group are household names in Britain. M&S — founded in 1884 — operates around 1,400 stores across the country, spanning food, clothing, and homeware, with a major online shopping business. The Co-op Group is one of the largest consumer cooperatives in the world, running thousands of food stores and funeral homes across the UK, serving millions of members. These aren't small businesses. They're institutions woven into daily British life — the kind of organizations where a disruption doesn't just make the tech press; it makes the evening news.

Marks & Spencer lost an estimated $400 million in operating profit. Their online operations went dark for over three weeks. Contactless payments failed across 2,300 food stores. The attack wiped more than $930 million from the company's market value.

The Co-op Group — targeted with the exact same social engineering play — detected the intrusion within minutes. Their security operations center locked the compromised account immediately. Customer-facing services continued uninterrupted. Total business impact: negligible.

Same attacker. Same technique. Same month. Wildly different outcomes.

This isn't a story about social engineering. It's not even really a story about M&S or the Co-op. It's a story about the three questions that separate organizations that survive a breach from those that don't — and why most security spending doesn't move the needle on any of them.

The attack, in brief

The threat group known as Scattered Spider (also tracked as UNC3944, Octo Tempest, and Muddled Libra by various vendors) is a predominantly English-speaking collective — many of them teenagers and young adults — that has compromised over 100 organizations worldwide. Their signature move isn't malware exploitation. It's picking up the phone.

At M&S, they called a third-party IT help desk, impersonated an employee, and convinced the support agent to reset credentials and disable multi-factor authentication. At the Co-op, they did the same thing — called up, answered security questions, got an account reset.

The technique was identical. What happened next was not.

Question 1: Can you detect it?

At M&S, the attackers operated freely for approximately two days before anyone noticed something was wrong. By the time the first anomaly was flagged — late afternoon on April 19 — the adversary had already been inside the network since at least April 17. The first crisis meeting didn't happen until 10 PM that night.

In those 48 hours of undetected access, the attackers had already stolen the NTDS.dit file — the core Active Directory database containing password hashes for every user in the organization. From there, they moved laterally, escalated privileges, and eventually deployed DragonForce ransomware across VMware ESXi infrastructure during the Easter weekend.

Two days of free movement. That's an eternity in incident response terms.

At the Co-op, the SOC detected unusual account behavior within minutes. Behavioral analytics flagged the anomalous activity the moment the attacker started using the reset credentials in ways that didn't match the legitimate user's patterns. The account was immediately restricted.

Rob Elsey, the Co-op's Chief Digital and Information Officer, told the UK Parliament's Business and Trade Sub-Committee:

"Our cyber-defenses kicked in immediately and restricted the activities of that account."

That word — immediately — is doing a lot of work. It's the difference between a contained incident and a catastrophe.

Here's the uncomfortable truth: many organizations have invested heavily in detection tools — SIEM platforms, EDR agents, behavioral analytics engines, threat intelligence feeds — but haven't done the foundational work of understanding what "normal" looks like in their own environment. When you don't know your baseline, your tools generate noise. When they generate noise, your team starts ignoring alerts. When your team ignores alerts, you get M&S's 48-hour detection gap.

The detection problem isn't a tool problem. It's an architecture and awareness problem.

Question 2: When you detect it, how fast and how well do you respond?

Detection without response is a dashboard with flashing lights nobody acts on. What matters is what happens in the minutes and hours after the alert fires.

At M&S, the response was slow and reactive. The crisis meeting on April 19 wasn't a coordinated containment exercise — it was the beginning of a scramble. By the time leadership was fully mobilized, the attackers were already positioning ransomware.

The Co-op's response tells a different story. Within the same day as the detection:

VPN access was locked down across the organization
Remote access was paused
A 12-to-24-hour effort locked down compromised accounts across the environment
Later that week, when the team detected software beaconing to a threat actor's command-and-control server, they proactively paused all communication within the affected network zone

That last point is critical. The Co-op didn't just react to what they could see — they anticipated what they couldn't. They found roughly 40 domain controllers had been touched and decided the right move was to isolate the entire zone rather than play whack-a-mole with individual compromised systems.

This wasn't improvisation. Rob Elsey again, under parliamentary questioning:

"We had actually war-gamed this precise scenario before as a leadership team."

They had rehearsed this. Not in the abstract — they had specifically practiced responding to a social engineering-driven credential compromise. When the real thing happened, the playbook already existed. The decisions were fast because the thinking had already been done.

Question 3: Does your architecture let you respond without destroying your own business?

This is the question I find most organizations haven't even considered. And it's the one that matters most when the pressure is on.

When the Co-op made the decision to isolate a network zone, online retail and payment systems continued operating normally. Why? Because they had invested in network segmentation. The online retail platform, payment processing, and customer-facing services sat on separate, insulated infrastructure. Containing the breach in one zone didn't require taking down the entire business.

M&S didn't have that luxury. Their infrastructure was more tightly coupled — legacy systems intertwined with modern services in ways that made surgical containment nearly impossible. When the ransomware spread, it hit VMware ESXi hosts supporting online shopping, distribution logistics, and in-store systems simultaneously. To stop the bleeding, M&S had to shut down broad swaths of their own operations — including online orders, which stayed suspended for over three weeks.

The result: a company that had tripled its cybersecurity headcount and doubled its security spend in recent years still couldn't contain a breach without crippling itself. The spending was real. The architecture to make that spending effective was not.

The tools trap

I have walked into organizations that own dozens of cybersecurity products — SIEM, SOAR, EDR, XDR, NDR, CSPM, CASB, email security, identity governance, privileged access management, vulnerability scanners. The list goes on. In some cases, the security team themselves couldn't explain what half the tools did, how they interconnected, or what the escalation path looked like when a particular tool flagged something.

They had accumulated a security stack that looked impressive on a procurement spreadsheet but was essentially incoherent in practice.

And here's the deeper problem: in those same organizations, the security team often couldn't accurately describe their own company's system architecture. They didn't fully understand which systems depended on which, where the critical data flows were, what the trust boundaries looked like, or where a lateral movement path would lead once an attacker was inside.

You cannot protect what you don't understand. No amount of tooling compensates for that gap.

The Co-op didn't succeed because they bought better products. They succeeded because they understood their environment deeply enough to design architecture that supported rapid, targeted response — and they had practiced using it.

What actually matters

The M&S and Co-op comparison isn't about one company being smarter or more careful. It's about the fact that the same attack, against two major retailers, produced completely different outcomes — and the deciding factors had almost nothing to do with the attack itself.

Three questions:

Can you detect it? Not "do you have detection tools" — but does your team actually know what normal looks like in your environment, and can they distinguish signal from noise fast enough to matter?

Can you respond effectively? Not "do you have an incident response plan" — but have you rehearsed it? Under realistic conditions? With the people who will actually be in the room when it happens?

Does your architecture allow you to respond without destroying your own business? Not "is your network segmented on paper" — but can you actually isolate a compromised zone while keeping critical services running?

These are architecture questions. Design questions. Understanding questions. They're answered before the breach happens — or not at all.

The harder truth

The M&S breach cost hundreds of millions of dollars. It disrupted millions of customers. It dominated UK headlines for weeks.

And it started with a phone call.

Social engineering works because it exploits the way organizations actually operate — the help desks, the password reset workflows, the third-party support relationships that keep businesses running. You can't eliminate that attack surface entirely without eliminating the business processes themselves.

What you can do is make sure that when that phone call succeeds — and statistically, at some point, it will — your organization isn't betting on the attacker making a mistake. You can limit the blast radius through architecture. You can ensure your team has practiced the response. You can tune your detection to your actual environment, not a generic baseline.

The Co-op proved that preparation works. M&S proved that spending without preparation is expensive in ways the procurement process never accounts for.

This article is written for developers and engineering teams who want to understand why security tooling alone doesn't determine breach outcomes — and what actually does.