Your Help Desk Is an Identity Control

Between April and June, a run of intrusions moved through UK retail, then U.S. retail, then the insurance sector. The activity has been widely attributed to the loose collective tracked as Scattered Spider. Public reporting describes a consistent opening move. Someone calls the IT service desk, claims to be an employee who’s locked out, and persuades the agent to reset a password and register a new MFA device. In some cases the impersonated person was an administrator.

From there the intrusions followed familiar paths: access to identity and virtualization platforms, data theft, and in several cases ransomware. The damage was severe, with weeks of disrupted online sales for at least one major retailer. The entry point was a conversation.

Why the help desk is an attack surface

Organizations spend heavily on authentication, from MFA rollouts to conditional access and device trust. Every one of those controls has a recovery path for when a legitimate user loses a phone or forgets a password. That path almost always runs through the service desk.

The service desk is measured on speed and satisfaction. Agents are trained to help. A caller who sounds stressed, knows a few details about the person they’re impersonating and is in a hurry is exactly the kind of caller the desk exists to help. Attackers with good English, information from social media and data from earlier breaches can pass knowledge-based questions easily.

So the strength of an organization’s authentication is capped by the strength of its account recovery process. In many organizations that process hasn’t been reviewed since before MFA was deployed.

Strengthening the recovery path

Verify identity with something the attacker can’t research. Knowledge-based questions (employee ID, manager’s name, date of hire) are discoverable. Stronger options include:

  • a video call where the agent compares the caller against the badge photo, combined with a second factor
  • a call-back to a number on file in the HR system, not one given by the caller
  • confirmation through the user’s manager, made through a known channel
  • in-person verification for privileged accounts

Tier the process by privilege. A standard user’s password reset and a domain administrator’s MFA re-registration shouldn’t follow the same script. For privileged and executive accounts, require a second approver and a waiting period, and notify the account owner through an existing channel.

Separate password resets from MFA changes. Resetting a password and registering a new MFA device in the same call gives the caller everything they need. Treat MFA device registration as a higher-risk action that needs stronger verification.

Give agents permission to slow down. Make it explicit, in writing and from leadership, that following the verification process takes priority over call time, and that an agent who refuses an unverified request will be backed up. Pressure and urgency are part of the attack.

Watch what happens after a reset. A reset followed within minutes by a new device registration, sign-in from an unfamiliar location, and access to admin consoles is a strong signal. Detection teams should treat help-desk-initiated changes as an event worth correlating.

Reduce what a reset can unlock

Phishing-resistant authentication helps here too. If privileged access requires a hardware security key bound to a known device, a reset over the phone can’t hand that access to a caller. Recovery for those accounts becomes a deliberate, in-person process, which is the right trade-off for the accounts that matter most.

Outsourced service desks deserve attention as well. Several of this year’s incidents reportedly involved third-party help desk providers. Confirm that your provider follows your verification standards, and test it.

Test it the way attackers do

The most useful exercise is a controlled social engineering test against the service desk, run with leadership’s approval and with agents told afterward what happened and why. It shows how the process holds up under pressure.

Organizations that run these tests usually find their procedures are sound but inconsistently followed, especially at night, at weekends and during busy periods. Those are the gaps attackers look for, and they’re fixable with clearer scripts, tiered approvals and support for the people answering the phone.