Marks & Spencer and the UK retail wave: when the provider helpdesk is the shortest way in

On 25 April 2025, Marks & Spencer suspends all online sales on its website and mobile app. The statement from CEO Stuart Machin describes a “cyber incident”, with no detail on the vector. Four days earlier, over the Easter weekend (19–21 April), contactless payments and Click & Collect had started failing intermittently in stores; on 23 April, Machin received a message from a compromised corporate M&S email account — already controlled by the attackers — confirming the network was encrypted. M&S doesn’t use the word “ransomware” publicly until 27 April.

The vector goes public between 1 and 5 May: social engineering of the Tata Consultancy Services (TCS) IT helpdesk, M&S’s outsourced provider, to obtain credential and MFA reset for internal employees. Access is attributed to Scattered Spider as initial access broker; the deployed ransomware to DragonForce, in its new affiliate cartel model. Microsoft tracks the group as Octo Tempest. Three weeks later, Co-op confirms the same vector (29 April), and Harrods contains an attempt (1 May). Three UK retailers, same playbook, two weeks.

Lab: this post’s PoC focuses on the compensating control, not the offence. Minimal Active Directory in a VM, simulation of the helpdesk call with a PowerShell reset script, and demonstration of: (a) the “standard” flow that works against Scattered Spider, (b) three compensating controls that break the playbook. All in a closed VM.

The vector — already known since MGM 2023

The playbook isn’t new. In September 2023, MGM Resorts and Caesars Entertainment fell with the same method: call to the IT helpdesk, employee impersonation, password and MFA token reset. Attributed at the time to Scattered Spider (UNC3944 per Mandiant). MGM loses ~$100M operationally in a week. Caesars pays a documented $15M ransom.

What changes in 2025 isn’t the technique, it’s the industrial scale:

• Three known victims in two weeks in the same geographic sector (UK retail), all with the same initial vector. The group operates by sector — concentrates force, saturates media, then rotates.
• Helpdesk outsourcing as multiplier. M&S, like many large UK retailers, doesn’t run its tier-1 IT in-house. It subcontracts it to TCS. The helpdesk operator isn’t an M&S employee — they’re a TCS contractor with access to M&S tools. The identity verification of the “employee” calling depends on processes defined contractually between two organisations, not on the operator’s personal relationship with the requester.
• DragonForce as affiliate cartel, not single operator. DragonForce’s 2025 rebrand offers 80% payout to its affiliates, no operation of its own. Scattered Spider builds the initial access; DragonForce supplies the encryptor and the extortion portal. Specialisation divides the chain.

The outsourcing factor is what turns the pattern systemic. In 2023 with MGM, the attacked helpdesk was internal. In 2025 with M&S and Co-op, the helpdesk is TCS’s — the same provider for both. A single set of verification procedures, a single set of operators trained with the same manuals, a single reusable vector against any of the provider’s clients.

The documented timeline

What’s verifiable as of incident closure (May 2025), aggregating public sources:

• 22 April 2025 — Suspicious activity detected on M&S networks: anomalous logins, escalation attempts. M&S CSIRT begins internal investigation.
• 23 April — CEO Stuart Machin receives the message from the extortion group, sent from a compromised @marksandspencer.com account, signed by DragonForce. The account had been leveraged via the helpdesk-obtained MFA reset.
• 25 April — Click & Collect disabled nationally. Brief public statement, no attribution.
• 27 April — Machin confirms “ransomware” in leaked internal communication. Internal network is partially encrypted.
• 29 April — Co-op Group announces detection of a similar compromise and that it has “taken systems offline” preventively. Co-op’s detection speed (24–48 hours after the initial intrusion) limits damage to back-office and call-centre.
• 1 May — Harrods announces a contained intrusion attempt with no operational disruption. Same vector reported, early containment.
• 2 May — M&S still has online suspended. Loss estimate: £3.8M online revenue per day.
• 8 May — NCSC UK publishes a blog post with specific guidance on helpdesk impersonation, without directly naming the affected retailers.
• Mid-May — Partial recovery of M&S ecommerce. Full recovery announced for July.
• 21 May — M&S guides operational impact estimate: ~£300M in operating profit for the fiscal year.
• 6 July — Public confirmation of Scattered Spider + DragonForce attribution via Cyber Monitoring Centre (CMC) investigation, which classifies the M&S + Co-op set as a “single combined cyber event” with aggregate impact between £270M and £440M.

What the later M&S annual report adds: the initial intrusion penetrates around 17 April, roughly 8 days before the online suspension. The window between initial access and exfiltration + encryption is where containment is decided — where the incident is won or lost.

The technical playbook — step by step

The Scattered Spider flow documented by Microsoft (Octo Tempest), Mandiant (UNC3944) and NCSC, reconstructed for M&S:

1. Reconnaissance — LinkedIn + breach data

The operator identifies a real M&S employee with a target profile: ideally IT, finance, or a privileged user. LinkedIn is the primary source — name, role, team, manager. Aggregated breach data (Have I Been Pwned, dehashed.com, telegrams like “cocoricos”) provides personal info: employee’s private phone number, alternative personal email, approximate date of birth. In more careful playbook versions, the operator calls the target ahead of time with a pretext (survey, fake delivery) to confirm voice and availability.

2. Call to the helpdesk

The operator calls the helpdesk’s public number (TCS Service Desk in M&S’s case). They impersonate the identified employee. The standard script — captured in recordings of prior incidents and reported by defenders who’ve worked the blue side:

> Helpdesk: TCS Service Desk, how can I help you?
> Operator: Hi, this is [Name] from [Team]. I'm trying to log in
            from home and my password isn't working. I think I locked
            it after too many attempts.
> Helpdesk: Sure, can I verify your employee ID?
> Operator: It's [4-digit ID estimated or pulled from LinkedIn URL].
> Helpdesk: And your date of birth?
> Operator: [DOB from breach data].
> Helpdesk: Last thing, your manager?
> Operator: [Manager from LinkedIn].
> Helpdesk: OK, I'm resetting your password. New temporary password
            is [...]. You'll need to change it on first login.
> Operator: Great, thanks! Oh, and I lost my phone yesterday — can
            you also reset my MFA? I haven't had time to enrol a new
            device.
> Helpdesk: Sure, MFA reset. You'll see the enrollment flow next login.
> Operator: Perfect, thank you!

Three minutes. No cross-verification over an alternative channel. No manager checkpoint. No biometric verification (voiceprint, something some tier-1 vendors offer but few organisations implement).

3. Login + persistence

With password and MFA reset, the operator logs in via corporate VPN or Citrix gateway. Configures their own MFA (Microsoft Authenticator or YubiKey, depending on policy). From that moment on, they are the employee from the system’s point of view. What follows is the standard post-exploitation playbook:

• Active Directory mapping (BloodHound, SharpHound).
• Enumeration of privileged accounts, admin groups, GPOs.
• Pivot to another more privileged account via Kerberoasting, delegation abuse, or repeating the same helpdesk trick with a more senior employee.
• Loading C2 implants (Cobalt Strike, Sliver, or Brute Ratel in recent operations).
• ESXi detection on the network — Scattered Spider has documented preference for encrypting hypervisors (bulletin and technical news from 2024).

4. Exfil + encryption

Before encryption, exfiltration to attacker infrastructure. In the M&S case the reported figure is 150 GB of corporate data via MEGA and other file-sharing services. After that, deployment of the DragonForce binary against hosts and ESXi. M&S reports tens of thousands of affected hosts.

The compensating control that works

The operationally interesting part: the bug isn’t the reset itself, it’s the requester’s identity verification process. Any helpdesk at a company with >500 employees resets credentials every day, legitimate operation. The question is: how does the operator know the person on the other end is who they say they are?

Standard security questions (employee ID, DOB, manager) are public knowledge in 2025: LinkedIn + aggregated breach data covers all three fields for 90% of the employees of any multinational. Verification based on that isn’t verification.

Three compensating controls that break the playbook, in order of increasing friction:

Control 1 — Out-of-band verification

The helpdesk operator doesn’t reset based on the information the caller gives. They initiate a challenge on an independent channel only the real employee can answer. Minimal lab implementation:

# helpdesk-verify-oob.ps1 — out-of-band compensating control
param(
    [Parameter(Mandatory=$true)][string]$EmployeeId,
    [Parameter(Mandatory=$true)][string]$RequestType  # "password" | "mfa" | "both"
)

# 1) Resolve email and Teams ID from AD (not from what the caller says)
$user = Get-ADUser -Filter "EmployeeID -eq '$EmployeeId'" `
    -Properties Mail, Title, Manager, OfficePhone

if (-not $user) {
    Write-Error "Employee not found in AD"
    exit 1
}

# 2) Generate 6-digit challenge code
$challenge = (Get-Random -Minimum 100000 -Maximum 999999).ToString()

# 3) Send it to the corporate channel registered in AD — not the one the caller says
# Simulated with Send-MailMessage; in production, Teams DM via Graph API
Send-TeamsDirectMessage -UserPrincipalName $user.UserPrincipalName `
    -Message "Helpdesk verification code: $challenge. " +
             "If you did NOT request a reset, ignore this message and report " +
             "to security@company.com."

# 4) Wait for the caller to read back the code
Write-Host "Waiting for verification code..."
$caller_code = Read-Host "Code dictated by caller"

if ($caller_code -ne $challenge) {
    Write-Error "Incorrect code. Reset DENIED. Logging attempt."
    Add-Content -Path "C:\Security\HelpdeskAttempts.log" `
        -Value "$(Get-Date -Format o) | DENIED | $EmployeeId | $RequestType"
    exit 1
}

# 5) If we get here, proceed with the reset
Write-Host "Verification OK. Proceeding with $RequestType reset..."
# ... actual reset ...

The helpdesk operator doesn’t decide whose Teams DM it is — AD decides. If the attacker has also got access to the real employee’s Teams, the control fails — but we’ve moved up a step. The bar is no longer “know the employee ID”; it’s “have access to the employee’s corporate Teams”.

Control 2 — Manager checkpoint for privileged resets

Reset of normal user credentials: control 1 is enough. Reset of privileged credentials (AD admin, production access, service accounts): a second human factor. The helpdesk operator cannot self-approve the reset; they must escalate to the requester’s direct manager.

# helpdesk-privileged-reset.ps1 — additional checkpoint
param(
    [Parameter(Mandatory=$true)][string]$EmployeeId,
    [Parameter(Mandatory=$true)][string]$Reason
)

$user = Get-ADUser -Filter "EmployeeID -eq '$EmployeeId'" `
    -Properties Mail, Manager, MemberOf

# Privileged?
$is_privileged = $user.MemberOf | Where-Object {
    $_ -match "Domain Admins|Enterprise Admins|Privileged Users"
}

if ($is_privileged) {
    Write-Host "Privileged account. Requiring manager approval."

    $manager = Get-ADUser -Identity $user.Manager -Properties Mail
    $approval_token = New-Guid

    Send-TeamsDirectMessage -UserPrincipalName $manager.UserPrincipalName `
        -Message ("Reset of PRIVILEGED account requested for " +
                  "$($user.Name). Reason: $Reason. " +
                  "Approve: https://helpdesk.internal/approve/$approval_token. " +
                  "If you do NOT expect this request, deny + alert security@.")

    # Poll until manager approves or 30 min timeout
    Write-Host "Waiting for manager approval (30 min timeout)..."
    # ... polling with Wait-ApprovalToken ...
}

Control 3 — Automatic time-delay for tier-2+ resets

Configurable: any reset affecting privileged accounts or requested outside business hours waits 45 minutes between request and activation. During those 45 minutes, the real employee receives notification via email + Teams + SMS. If the request is legitimate, they wait; if not, they trigger cancellation + alert.

Simple implementation: queue the reset in a table, scheduled task that processes every 5 minutes checking whether it was cancelled. If the attacker depends on speed (and they do — the window between reset and detection by the real user is where they win), 45 minutes is lethal for the playbook.

What NCSC asks of UK retailers

The NCSC blog post on 8 May lists three actions any company with an outsourced helpdesk needs to review:

1. Audit the helpdesk identity verification process. How the requester is authenticated. If verification relies on public or semi-public information (employee ID, DOB, manager name), it’s vulnerable by default. Implement out-of-band challenge.
2. Review who can reset privileged accounts. In many setups tier-1 helpdesk has the same permissions for every account. Differentiation: tier-1 resets normal users with out-of-band; tier-2 + manager checkpoint resets privileged ones; critical accounts (Domain Admins, prod root) require ticket approved by security + physical presence.
3. Logging and alerting on reset patterns. Multiple resets in a short window for related accounts (same manager, same team) should trigger automatic review. The Scattered Spider playbook leaves a signature — it shares temporal patterns.

NCSC adds a fourth operational point: review contracts with outsourced IT providers so the provider’s helpdesk verification processes meet the customer’s standard, not the provider’s. Verification good enough to reset @small-customer.com isn’t good enough for @marks-and-spencer.com.

What comes next

Consequences play out across the year:

• July 2025 — UK arrests of four individuals linked to the operation. Three in their twenties, one a minor. Charges related to conspiracy, fraud, money laundering. UK NCA + FBI cooperate.
• August 2025 — M&S confirms termination of the TCS contract for the helpdesk. Migrates the service to a different provider with renegotiated SLA.
• September–December 2025 — Civil litigation starting: affected customers, shareholders, regulatory probes from the FCA. ICO investigates personal data handling.

The latest operational impact, not quantifiable yet: the Scattered Spider + DragonForce affiliate pattern replicates in other sectors through summer 2025 — Coca-Cola European, Allianz Life, multiple hospitality and aviation. Octo Tempest expands its targeting to aviation. The helpdesk playbook isn’t UK-retail-exclusive; it’s available for any sector with outsourced tier-1 IT.

What to take away

Four points for a CISO who wants to get through the year without falling into the same trap:

1. The helpdesk is identity perimeter. More than the firewall, more than the WAF. It’s the control regulating who can be whom inside the directory. Treating it as service ops (meeting resets-per-hour SLA) instead of security ops (verifying identity properly) is the decision that gets paid later.
2. IT outsourcing requires specific contractual hardening. The provider doesn’t implement security controls for free. If you want out-of-band verification, manager checkpoint, time-delay — write it into the contract with measurable SLAs, and audit compliance.
3. Public knowledge ≠ verification. Any “secret question” derived from information any breach data aggregator can sell has been broken since 2023. Your helpdesk can’t verify identity with data you can buy online.
4. Detection latency is what separates M&S from Co-op. Co-op detected in 24–48 hours and contained. M&S detected in 5+ days and lost £300M. The operational difference isn’t in initial prevention but in how fast the blue team recognises the post-access pattern.

References

• M&S Group, Stuart Machin public statement (25 Apr 2025): https://corporate.marksandspencer.com/media/press-releases/2025/cyber-incident
• NCSC UK, Incidents impacting retailers — recommendations from the NCSC (8 May 2025): https://www.ncsc.gov.uk/blog-post/incidents-impacting-retailers
• Microsoft Threat Intelligence, Octo Tempest (operational reference): https://www.microsoft.com/en-us/security/blog/2023/10/25/octo-tempest-crosses-boundaries-to-facilitate-extortion-encryption-and-destruction/
• Mandiant, UNC3944 / Scattered Spider profile (updated 2025): https://cloud.google.com/blog/topics/threat-intelligence/unc3944-targets-saas-applications
• Cyber Monitoring Centre, M&S + Co-op classified as single combined cyber event (July 2025): https://cybermonitoring.org/cmc-reports/2025-uk-retail-event
• BleepingComputer, Deep dive into DragonForce ransomware and its Scattered Spider connection: https://www.bleepingcomputer.com/news/security/deep-dive-into-dragonforce-ransomware-and-its-scattered-spider-connection/
• BBC News, M&S incident coverage with detail on the helpdesk vector (May 2025): https://www.bbc.co.uk/news/business-cyber
• Computer Weekly, M&S suspends all online sales as cyber attack worsens (25 Apr 2025): https://www.computerweekly.com/news/366623085/MS-suspends-all-online-sales-as-cyber-attack-worsens
• The Hacker News, Scattered Spider Behind Cyberattacks on M&S and Co-op (June 2025): https://thehackernews.com/2025/06/scattered-spider-behind-cyberattacks-on.html
• CISA, Scattered Spider Joint Advisory AA23-320A (2025 update): https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-320a