Your Help Desk Is a Backdoor: The Password Reset Attack That Cost M&S $5.1M Per Day

The Marks & Spencer breach in April 2025 didn't start with a zero-day exploit or a sophisticated piece of malware. It started with a phone call.

A threat actor — believed to be affiliated with Scattered Spider — called M&S's third-party helpdesk, pretended to be an employee, and asked for a password reset. That single social engineering move unlocked a chain of events that shut down online sales for five days and cost the retailer $5.1 million per day.

At Gerus-lab, we build security-conscious backend systems and have seen this pattern repeat itself across enterprises. The Forrester research that surfaced this week makes it official: regular password resets aren't just expensive ($70 per reset operation) — they're actively dangerous. Here's why, and what the engineering fix actually looks like.

The Attack Chain Nobody Talks About

Most post-mortems focus on the ransomware. The real story is what happened before the encryption:

1. Social engineer calls helpdesk → password reset approved via voice verification
2. Attacker gains initial access to an account
3. Active Directory exploit used to extract NTDS.dit — the database storing all domain user password hashes
4. Hashes cracked offline at leisure
5. Privilege escalation using legitimate credentials over weeks — completely invisible to standard monitoring
6. Ransomware deployed targeting payment, e-commerce, and logistics systems

This is the Scattered Spider playbook. They didn't need to break encryption. They needed one sleepy helpdesk agent and a convincing story.

The $70 Problem Is Actually a $5.1M Problem

Forrester's data shows each password reset costs organizations ~$70 in support time. That's why SSPR (Self-Service Password Reset) tools became popular — reduce ticket volume, reduce cost.

But here's what the data misses: SSPR doesn't eliminate the social engineering surface, it just shifts it. If an attacker can't convince the tool, they convince the agent who overrides the tool. And agents override tools constantly — because their job is to unblock people, not to be security gatekeepers.

The M&S breach is a textbook example of this. The SSPR tools existed. The breach happened anyway.

What Actually Fixes This (Engineering Perspective)

We've helped clients redesign their identity verification flows. The principles that actually work:

1. Kill Voice-Based Identity Verification

Voice is not a secure channel for identity. Deepfakes are table stakes now. Any system that allows "the caller knows their employee ID" as authentication for a password reset is one convincing voice away from compromise.

Replace it with: OTP pushed to a pre-registered trusted device. The device is the second factor, not knowledge.

# Bad: Agent asks "what's your employee ID?"
# Good: System sends OTP to registered device, agent only proceeds after code confirmed

def initiate_password_reset(employee_id: str) -> ResetSession:
    employee = get_employee(employee_id)
    session = create_reset_session(employee)

    # Push notification to registered device, NOT email/SMS
    push_otp_to_device(
        device_id=employee.primary_device_id,
        session_token=session.token,
        expires_in=300  # 5 minutes
    )

    return session  # Agent cannot proceed until OTP confirmed

2. Anomaly-Detect Reset Patterns

Helpdesk agents can't notice patterns — they're handling individual tickets. Systems can. Build monitoring that flags:

• Multiple reset requests for the same account within 24h
• Reset requests immediately followed by after-hours logins
• Reset requests for accounts with elevated privileges
• Resets correlated with concurrent failed MFA attempts on the same account

def check_reset_risk_score(employee_id: str) -> RiskAssessment:
    recent_resets = get_resets_last_24h(employee_id)
    recent_failed_mfa = get_failed_mfa_attempts(employee_id, hours=1)
    account_privilege_level = get_privilege_level(employee_id)

    risk_score = 0
    if len(recent_resets) > 1: risk_score += 40
    if recent_failed_mfa > 3: risk_score += 35
    if account_privilege_level == 'admin': risk_score += 25

    return RiskAssessment(
        score=risk_score,
        requires_escalation=(risk_score >= 50),
        requires_security_team=(risk_score >= 75)
    )

3. Protect NTDS.dit Like It's Your Crown Jewels

The M&S attackers knew exactly what to look for. NTDS.dit — the Active Directory database — is a goldmine of password hashes. Once you have it, you don't need to brute-force the network: you brute-force offline at GPU speed.

Hardening checklist:

• Restrict ntdsutil and VSS snapshot access to specific break-glass accounts only
• Alert on any process touching NTDS.dit that isn't LSASS or replication
• Implement Credential Guard to prevent hash extraction even with admin access
• Audit who can perform DCSync operations — attackers love this too

4. Segment Helpdesk from Privilege Operations

The architectural mistake in most orgs: helpdesk agents have the ability to reset passwords for any account, including domain admins. That's insane.

A junior support agent should have zero visibility into privileged accounts. PAM (Privileged Access Management) systems exist for exactly this reason. Admin password resets should require a separate approval workflow, ideally with a 15-minute delay and security team notification.

The Deeper Lesson: Your Attack Surface is Human

At Gerus-lab, we've learned that the hardest security problems to solve aren't technical — they're organizational. The M&S breach succeeded because:

• Trust was granted based on claimed identity, not verified identity
• The helpdesk process had no risk-based escalation
• Monitoring treated password resets as routine events, not potential indicators of compromise
• Privileged account management was not isolated from general support operations

The technology to prevent this exists. The discipline to implement it consistently is the hard part.

What We Actually Recommend

If you're auditing your organization's password reset process today, run through this checklist:

• [ ] No voice-only identity verification for any account type
• [ ] Device-bound OTP required for all agent-initiated resets
• [ ] Risk scoring on every reset request, with automatic escalation
• [ ] Privileged account resets isolated from general helpdesk workflows
• [ ] NTDS.dit access audited with alerting on anomalous access
• [ ] VSS snapshots monitored — attackers use this to copy the database
• [ ] Helpdesk agent training at least quarterly on social engineering scenarios
• [ ] Incident response playbook specifically for suspected credential compromise events

The $70 Reset That Became $25M

M&S's five-day outage cost an estimated $25.5 million in lost revenue alone, not counting remediation, reputational damage, and regulatory scrutiny. The entry point was a $70 password reset.

Security ROI is notoriously hard to quantify — until you're the example everyone else uses in their blog posts.

If you're building B2B SaaS or enterprise systems and need a security review of your identity and access management architecture, we at Gerus-lab do exactly this kind of work. We've helped teams across Web3, fintech, and enterprise SaaS close the gaps that matter.

Don't wait for your own breach to become the case study.

---

Building something that needs to actually stay secure? Talk to us at Gerus-lab — we engineer systems that hold up under real-world attack conditions.