Notifications
Clear all
Topic starter
23/06/2026 9:22 pm
TL;DR: Help desk scams let attackers reset credentials, bypass MFA, and take over privileged accounts, with Scattered Spider-linked campaigns tied to major retail and insurance disruptions according to Push Security. The core problem is that many help desk workflows still assume identity proofing can survive social engineering and high-pressure impersonation.
NHIMG editorial — based on content published by Push Security: Scattered Spider help desk scams and how to protect your organization
By the numbers:
- M&S felt the pain of £300m in lost profits and a share value hit approaching £1b.
- Scattered Spider has heavily relied on identity-based TTPs since they first emerged in 2022.
Questions worth separating out
Q: How should security teams stop help desk scams from bypassing MFA resets?
A: Make MFA resets a high-risk identity event, not a routine service task.
Q: Why do help desk scams work so well against privileged accounts?
A: They work because many organisations use one reset process for everyone, even though a privileged account carries far more blast radius.
Q: What do security teams get wrong about identity verification for support requests?
A: They often rely on static personal data, a return call, or a quick manager check as if that were enough to defeat social engineering.
Practitioner guidance
- Separate admin resets from routine help desk flows Create a distinct approval path for high-privilege account resets, including extra escalation steps and logging for every administrative identity change.
- Require out-of-band verification for risky requests Use a call-back to a known number, device-bound codes, or in-person validation when the reset affects MFA, passwordless access, or privileged roles.
- Freeze self-service when social engineering indicators appear Define triggers that pause automated resets if a user reports a new device, an urgent access problem, or unusual contact from the help desk workflow.
What's in the full article
Push Security's full blog post covers the operational detail this post intentionally leaves for the source:
- A practical walkthrough of how help desk scams are staged against MFA reset workflows.
- Examples of the social engineering patterns used in Scattered Spider-linked campaigns.
- More detail on browser-based verification codes and how they fit into support operations.
- Push Security's own demonstration of identity attack detection and response capabilities.
👉 Read Push Security's analysis of help desk scams and identity takeover tactics →
Help desk scams and MFA resets: are your controls keeping up?
Explore further
25/06/2026 2:39 am
Help desk identity proofing is now a front-line security control, not an administrative courtesy. The article shows that the attacker does not need to break MFA when they can persuade support staff to reset it. That shifts the control boundary into IAM operations, where verification quality, escalation discipline, and fraud-resistant support workflows matter as much as authentication technology. Practitioners should treat every support-mediated identity change as a security event.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
A question worth separating out:
Q: Who is accountable when a help desk reset leads to account takeover?
A: Accountability sits across support operations, IAM governance, and the business owners of privileged access. If a reset process can alter MFA or passwords without strong proofing, then the control design is part of the incident. Governance teams should assign explicit ownership for risky reset approvals and audit them regularly.
👉 Read our full editorial: Help desk scams are the gateway to privileged account takeover
