In April 2025, UK retailers Marks & Spencer, Co-op and Harrods were hit by a series of cyberattacks. Access to M&S did not run through a sophisticated technical vulnerability, but through a phone call: the attackers — attributed to the group Scattered Spider — impersonated an employee and called the IT service desk (outsourced to a third party), which then carried out a password reset. With that, the front door was open. Estimated damages ran into the hundreds of millions of pounds. This is the international textbook case of help-desk social engineering.
How the attack unfolded
Scattered Spider is known for deploying English-speaking members who convincingly play the role of a colleague or IT staffer. At M&S they called the service desk, posed as an employee who could no longer log in, and obtained a password reset. No malware, no zero-day — just a phone call and a believable story.
With that initial access the attackers worked their way to the heart of the network. They obtained the central Active Directory password database (the NTDS.dit file), cracked the password hashes offline and gained access to a wide range of accounts. Eventually they deployed DragonForce ransomware across the M&S environment.
Notably, the help desk that was called had been outsourced to an external supplier. The weak link sat not only in a process, but in the supply chain — a combination of social engineering and supplier risk.
Why the help desk is such an attractive target
An IT help desk exists to help people who are stuck — often under time pressure and with a certain willingness to make exceptions. That very helpfulness makes the help desk an ideal target. Someone who sounds convincing and applies a little pressure ('I have a presentation in five minutes and I'm locked out') can nudge an agent into a reset.
The problem is structural, not individual. A help-desk agent who performs a hundred legitimate resets a day cannot stay on guard with every caller without a clear procedure. The solution is therefore not 'pay more attention', but a hard verification process that cannot be bypassed with a good story.
Strong identity verification before a reset or MFA change is the crux here: a callback to a registered number, confirmation through a second channel, or approval by a manager. No verification the caller can supply themselves.
MFA and passwords alone are not enough
Many organisations rely on MFA and complex passwords. M&S shows that this is insufficient when the recovery process around it is weak. An attacker need not crack your password if they can get the help desk to reset it — and re-enrol the MFA on their own device.
The reset and recovery process is therefore just as critical as the login security itself. That is a blind spot in many awareness programmes: lots of attention goes to strong passwords and not-clicking, but hardly any to the question 'how does the help desk know for sure it is really you?'
Phishing-resistant MFA (such as hardware keys or passkeys) helps, but only if the exception processes too — a lost key, a new phone — are equally tightly secured. Attackers always look for the exception.
Why this matters for your organisation too
Scattered Spider is not an exotic threat that only hits British retailers. The same technique — call, pretend, ask for a reset — works at almost any organisation with a help desk. The approach is cheap, scalable and requires no technical vulnerability.
Under the GDPR an M&S-style breach is a notifiable incident, and for many sectors the NIS2 directive sharpens the duty of care further. But more important than the compliance question is the operational one: would your help desk have stopped a convincing caller?
That question can be tested. A help-desk-focused social engineering test mercilessly reveals whether your verification process holds up in practice — not on paper, but when someone actually calls.
How to embed this in your awareness programme
The M&S case is ideal for shifting attention from 'don't click' to 'who do you verify, and how'. It also makes tangible for management why process and behaviour must align.
Focus specifically on the IT help desk and on everyone who can reset identities or grant access.
- Audience + cadence: give the IT help desk a dedicated, recurring module on identity verification for resets and MFA changes.
- Set one hard rule: never a reset or MFA change without verification through an independent, registered channel (callback, manager, second factor).
- Actually test it: run a help-desk-focused social engineering test and discuss the outcome without blaming anyone.
- Measure whether the procedure holds: how many reset requests are correctly verified before being carried out?
- Want to go deeper? See how to practise this through phishing and social engineering simulation.
Related articles
- The Odido breach: one phone call, 6 million people
- The ChipSoft attack: supplier risk in your awareness programme
- Ransomware and employee behavior
FAQ
How did Scattered Spider get into Marks & Spencer?
Not through a technical vulnerability, but through social engineering of the IT help desk. The attackers called the (outsourced) service desk, posed as an employee who could not log in and obtained a password reset. With that access they later seized the central Active Directory password database and deployed ransomware.
Why is the IT help desk a favourite target?
A help desk exists to help quickly, often under time pressure and with a willingness to make exceptions. That helpfulness is exactly what attackers exploit. It is a structural problem: without a hard verification process, a convincing caller can force a reset no matter how alert the agent is.
Doesn't MFA protect against this kind of attack?
Not by itself. If the help desk resets a password and re-enrols the MFA on the attacker's device, the MFA is bypassed. The recovery and reset process is therefore as critical as login security. Phishing-resistant MFA only helps if the exception processes are tightly secured too.
Could this happen to my organisation?
Yes. The technique — call, pretend, ask for a reset — works at almost any organisation with a help desk and requires no technical vulnerability. You can test your resilience with a help-desk-focused social engineering test that shows whether your verification process holds up in practice.