# The Recovery Trap: Why Your MFA Is Only as Strong as Your Help Desk


The call comes in mid-afternoon. An employee claims they've lost access to their account — phone replaced, authenticator app gone, locked out of everything. The IT help desk worker has seen this a hundred times. They ask a few questions, confirm some basic details, and reset the account. Fourteen minutes later, an attacker is inside the network.


This is not a hypothetical. It is roughly how Scattered Spider walked into MGM Resorts International in September 2023, triggering a breach that cost the company over $100 million. They didn't crack any cryptographic primitives. They didn't need a zero-day. They called the help desk.


## The Front Door Is Locked, So They Came Through the Window


The past decade of security investment has made credential stuffing and phishing significantly harder. FIDO2 hardware keys, push-based MFA, passkeys — the authentication stack for well-resourced organizations is legitimately difficult to abuse directly. Attackers noticed. The pivot was inevitable.


Account recovery exists because humans lose phones, break authenticators, and get locked out of accounts. That's a legitimate operational need. But recovery is, by definition, an exception path — a way to bypass normal authentication when normal authentication fails. And exception paths are almost always where security breaks.


The attacker's playbook is straightforward: call the service desk posing as the target employee, claim a device was lost or replaced, provide enough personally identifiable information to pass basic verification, and request a credential reset. The PII they need — name, employee ID, maybe a manager's name or last four of a Social Security Number — is often scraped from LinkedIn, a prior data breach, or social media. It's not hard to get. The verification question is whether the help desk can tell the difference between a stressed employee and a patient threat actor.


Most of the time, it can't.


## Why This Attack Works So Reliably


Help desk workers are trained to solve problems quickly. Their incentive structure rewards resolution speed, not security skepticism. When someone calls claiming to be a vice president who can't access their email before a board meeting, the social pressure to help is intense and immediate. Threat actors know this, and they exploit it deliberately — often choosing high-pressure scenarios, escalating emotionally if verification is pushed back on, and occasionally claiming to be calling on behalf of a senior executive.


The Scattered Spider group, largely comprising young English-speaking threat actors, ran this play repeatedly across 2022 and 2023 against MGM, Caesars Entertainment, and multiple other hospitality and gaming companies. Caesars reportedly paid $15 million in ransom. MGM did not pay and spent months recovering operational systems. Both breaches traced back to social engineering at the identity layer — not at the technical authentication layer.


What made these attacks particularly damaging wasn't just the initial access. Once attackers had legitimate credentials with MFA reset, they could enroll their own authenticator devices and operate with full authorized access. SIEMs and behavioral analytics tools often struggle to flag this because the account is, technically, behaving like an authenticated user.


## The Verification Gap Nobody Wants to Fix


Identity verification at the service desk is an unglamorous problem. There's no exciting CVE number, no patch to deploy, no vendor dashboard showing you're protected. It requires changing process and culture, which is slower and harder than buying a security tool.


Current verification practices at most organizations are genuinely weak. Knowledge-based authentication — asking for an employee ID, date of birth, or the name of someone's manager — is trivially defeated by attackers who spent 20 minutes on LinkedIn and Have I Been Pwned before picking up the phone. Some organizations use callback verification, calling the employee's number on file, but this also fails if the attacker has already ported the number or if the "employee" claims their phone is what's lost.


Stronger approaches exist. Video identity verification during high-risk recovery workflows can confirm that the person requesting a reset is who they claim to be. Cryptographic identity proofing — where the user must prove possession of a hardware token or complete a step-up verification through a secondary trusted channel — raises the bar substantially. Some organizations now require in-person verification at a physical office before resetting MFA credentials for privileged accounts.


These controls have real friction cost. An executive locked out of their account at 6 a.m. before a flight will not enjoy a video verification flow. Security teams have to make that call explicitly: is the friction worth it? Given the demonstrated cost of getting it wrong, the answer should increasingly be yes, particularly for accounts with elevated access.


## What Defenders Should Actually Change


The technical controls here are less important than the procedural ones, which is unusual and worth sitting with.


A few concrete priorities:


  • Privilege-tiered recovery policies. Not every account needs the same verification bar. A standard employee resetting email access is different from a domain administrator resetting their identity provider credentials. Define these tiers explicitly and enforce different verification requirements.

  • Out-of-band secondary confirmation. For any MFA reset, require an automated notification sent to the employee's personal email or phone on file, requiring them to explicitly confirm the request before it's processed. Attackers will sometimes intercept this, but it blocks unsophisticated attempts and creates an audit trail.

  • Service desk scripts with real teeth. "Can't verify identity" needs to be a complete and acceptable answer, not a failure state that agents are pressured to route around. If a service desk agent can't verify someone, the correct answer is to open a ticket and require the employee to appear in person or complete a video verification — not to guess and reset anyway.

  • Logging and anomaly detection on recovery events. Account recovery events should trigger at minimum a SIEM alert and ideally a brief human review for privileged accounts. Pattern detection — same IP requesting multiple resets, requests outside business hours, requests for accounts of high-value targets — can catch attacker reconnaissance before a full compromise occurs.

  • ## HackWire Analysis


    The framing of "MFA is weak" misses what's actually happening here, and that framing matters because it leads organizations toward the wrong fixes.


    MFA isn't weak. The authentication step is genuinely hard to attack directly. What's weak is the assumption that strong authentication solves the identity problem permanently. Recovery is a moment where the authentication guarantee is deliberately suspended — and that suspension, if not handled carefully, erases everything you built.


    This fits a pattern we've watched accelerate since 2022: attackers moving up the trust stack. When you harden a technical layer, sophisticated adversaries don't keep hammering it. They find the human or process layer above it. We saw this with the collapse of password-based attacks leading to credential stuffing, which led to MFA adoption, which has now led to MFA fatigue attacks and recovery exploitation. The defense keeps improving; the attack surface shifts.


    The Scattered Spider incidents were a stress test that most organizations failed without realizing they were being tested. The uncomfortable truth is that many companies still have no meaningful controls on service desk identity verification for account recovery. They have MFA deployed and feel protected, without recognizing that they've secured the front door while leaving the service entrance unmonitored.


    The investment required isn't enormous, but it requires acknowledging an unflattering reality: your help desk, right now, is probably one confident phone call away from handing over the keys.


    — HackWire Editorial


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)