I


n early 2025, a series of cyber security incidents disrupted operations across some of the largest retail brands in the UK: Marks & Spencer, Co-op, and Harrods. In mid-May, threat intelligence vendors claimed similar attacks in the US – though names are unconfirmed.


The attackers are a known group named, variously, Scattered Spider, Octo Tempest, and UNC3944, depending on the intelligence vendor. This native-English- speaking collective – believed to be a loose network of teenagers and young adults across the UK and US – was also behind high-profile attacks on MGM and Caesars casinos.


As usual, the incidents were labelled “sophisticated cyber security attacks”. Yet UNC3944’s methods are well-known, and the full attack narrative is unusually clear.


Scattered Spider act as access brokers for a Ransomware-as-a-Service (RaaS) group called DragonForce. Once access is gained, DragonForce affiliates deploy ransomware. But the breach relies more on psychology than technology: they target IT help desks, using social engineering techniques to bypass security controls.


While the follow-up is carefully planned, it’s a stretch to call an attack that hinges on help desk impersonation “advanced”. Attackers pose as staff, using publicly available information and social cues to trick help desk agents into resetting credentials — a risk larger organisations, ironically, are more prone to. These attacks are preventable with the right processes, but few organisations implement them consistently.


Once inside, attackers aim for domain control. A primary target is NTDS.dit – Active Directory’s core database, which stores all password hashes. Tools like Mimikatz, secretsdump.py, or Volume Shadow Copy manipulation are used to extract it. Weak or reused passwords fall quickly under offline cracking, giving attackers broad lateral movement.


Next: encrypt critical infrastructure. There’s often a focus on virtualisation hosts – especially vulnerable if admin credentials or interfaces are exposed. Ransomware is deployed, virtual machines are encrypted, and business operations halt.


Operation-specific impact


Marks & Spencer took the hardest operational hit. Online orders, mobile apps,


were predictable, preventable. What they reveal isn’t attacker brilliance, but architectural fragility. Which leads to an important question: why are known weaknesses still built into critical systems?


Why the fix isn’t more cyber security RETAIL


REALITY CHECKS


customer services, and possibly logistics were all disrupted. The initial attack struck over the Easter bank holiday. By mid-May, online ordering remained unavailable. Financial losses were estimated at £30 million, with ongoing revenue losses of up to £15 million per week. M&S brought in CrowdStrike, Microsoft, and Fenix24 to support recovery.


Co-op initially denied data loss, but later confirmed personal data had been leaked. Payment processing issues were widespread, and some areas — like the Scottish islands – reported product shortages. Co-op responded quickly, disconnecting systems to avoid ransomware spread, and recovered more rapidly as a result.


Harrods detected the attack early and cut off internet access as a precaution. So far, no significant operational or reputational damage has been confirmed.


Attribution in cyber incidents is always difficult, but UNC3944 were identified through technical indicators, leaked data, and their own communications. Selective data leaks – used to pressure victims into ransom payments – evidenced their claims.


Familiar script


This playbook – social engineering, credential reset, Active Directory compromise, ransomware on hypervisors – isn’t new. It’s well-documented. What’s striking is how effective it remains. Despite years of guidance and public awareness, the same structural flaws persist: help desks without layered verification, weak passwords, and enterprise networks with flat trust models offering all-or-nothing access. These weren’t unprecedented attacks. They


3 © CITY SECURITY MAGAZINE – SUMMER 2025 www.citysecuritymagazine.com


If we judge security by how well we respond to breaches, we’ve already failed. These incidents make it clear: we don’t need more expensive cyber solutions – we need less insecure design.


Too many organisations are pouring money into layered technologies in a desperate attempt to hold broken systems together. Detection, response, and managed services aren’t bad – but they’re compensating for deeper flaws. They’re papering over cracks, and every breach makes those cracks more visible. At the root of these failures is a simple truth: our systems weren’t designed to be secure. They were built for convenience, speed, and scale – then retrofitted with security once the need could no longer be denied.


The identity illusion


Take identity. The bedrock of modern access control, and often the weakest link. For all the talk of zero trust, many organisations are still vulnerable to anyone who knows a few employee names, the help desk number, and how to sound confident.


Help desk impersonation was the first step in these attacks. It shouldn’t have worked – but it did, across multiple large retailers. That’s not a training failure, it’s a process design flaw.


A reset process that accepts scraped LinkedIn details as proof of identity isn’t secure – it’s theatre.


Muti-factor authentication helps, but less so when it’s reset by the same help desk agent who’s just been manipulated. Tying brittle directories into SSO systems only amplifies the fracture radius when something inevitably breaks.


Active Directory: predictable catastrophe


The next failure is just as familiar: Active Directory. Still the foundational pillar of enterprise identity, AD is a single point of total failure and every attacker knows it. Once inside, attackers extract NTDS.dit – the skeleton key to the kingdom. A few cracked hashes later, they’re logged in as privileged users, forgotten service accounts, or administrators. The fact that this vital file is so often accessible is a damning indictment. Domain controllers shouldn’t be this exposed. Service accounts shouldn’t have excessive rights.


Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36