The dashboard did not fail first. The phone did.
That is the uncomfortable part of the current wave of identity attacks. We keep talking about MFA, SSO, conditional access, risk scoring, device posture, and shiny admin consoles like identity security is something that lives entirely inside a browser tab. Then an attacker calls the help desk, sounds convincing, claims they got a new phone, and asks for a reset.
Suddenly the whole expensive stack is balanced on one rushed support interaction.
This is not an argument against MFA or identity platforms. Use them. Configure them well. Turn on the boring protections. The point is simpler and more annoying: attackers do not have to beat your normal login flow if your recovery process politely opens a side door.
And right now, that side door is getting a lot of attention.
The attack moved to the seam
Google Cloud’s Mandiant team has written extensively about UNC3944, a financially motivated threat group that overlaps with public reporting on Scattered Spider, 0ktapus, Octo Tempest, and similar clusters. In Mandiant investigations, the group used social engineering against corporate help desks to gain access to privileged accounts. One recurring story was painfully ordinary: the caller claimed they were getting a new phone and needed MFA reset.
That is not cinematic. Nobody is typing furiously in a dark room while green text rains down the wall. It is a support request.
Mandiant says the attackers sometimes already had enough personal information to pass weak verification checks: last four digits of Social Security numbers, dates of birth, manager names, job titles, coworker details. In other words, the “secret” questions were not secret. They were trivia with a breach history.
Once inside, the attackers did not stop at email. Mandiant observed abuse of SaaS and SSO access, including Okta permissions abuse and access to applications such as Salesforce, Azure, CrowdStrike, AWS, GCP, vCenter, and CyberArk. That is the nightmare shape of modern identity compromise: one believable reset turns into a tour of every important cloud tile the account can reach.
Okta has reported similar patterns. In one 2025 advisory, Okta Threat Intelligence described financially motivated activity where attackers impersonated legitimate employees, contacted IT help desks, requested password resets, and then enrolled their own MFA authenticators. The campaign targeted HR and payroll paths, including systems like Workday, Dayforce, ADP, CRM platforms, ITSM platforms, Office 365, and Google Workspace.
That should make every operator sit up a little straighter. The blast radius is not just “someone got into email.” It can become payroll manipulation, customer data exposure, service desk abuse, internal reconnaissance, and persistence through attacker-owned authentication methods.
The identity dashboard may show a successful login. The real failure happened earlier, when the system decided a phone call plus obtainable personal details was enough to rebuild trust.
Vishing is not just a phone scam anymore
It is tempting to file voice phishing under old-school social engineering. Someone calls. Someone lies. Someone falls for it. Put up another awareness slide and call it a day.
That framing is too small.
Okta Threat Intelligence has analyzed phishing kits designed specifically for voice-based social engineers. These kits let the attacker on the phone control what the target sees in the browser in real time. The caller’s script and the fake authentication flow move together. If the attacker needs the user to approve a push, enter a code, or respond to an MFA challenge, the page can be adjusted live to make that request feel normal.
That is not just “please click my bad link.” It is a synchronized performance: browser, phone call, credentials, MFA prompt, and human pressure all working together.
Okta notes that this kind of hybrid attack can defeat MFA methods that are not phishing-resistant, including push notifications with number matching. That point matters because number matching often gets treated like the grown-up version of push MFA. It is better than blind approval spam, absolutely. But if a caller is live on the phone telling the victim exactly what number to enter, it is not the same thing as phishing-resistant authentication.
Phishing-resistant means the authentication method is bound to the legitimate site or device in a way the attacker cannot simply talk someone through. That is why CISA keeps pushing methods like FIDO/WebAuthn and PKI-based authentication for stronger protection. It is also why Microsoft keeps steering organizations toward passkeys, conditional access, device registration controls, and tighter handling of token and OAuth abuse.
The practical lesson is not “MFA failed.” The lesson is “MFA has types, and some of them are much easier to socially engineer than others.”
That distinction matters in real environments, especially the messy ones.
Schools. Small businesses. Local governments. Nonprofits. Lean IT teams. Places where one person owns twelve systems, the help desk is also the project team, and everybody knows there is always one urgent exception because somebody has a board meeting, payroll deadline, grade submission, audit file, or broken phone.
Attackers love urgency because urgency makes bad procedure feel like customer service.
The help desk is not the problem. The procedure is.
There is a lazy version of this article that blames help desk staff. That version is useless.
Most help desk people are doing exactly what the organization trained and incentivized them to do: solve the user’s problem quickly, reduce friction, be helpful, keep work moving, and avoid being the person who says no to someone who sounds important. If the procedure says “verify DOB and manager name,” and both of those are findable, the staff member is not the weak point. The procedure is.
Bad identity recovery asks a human to make a high-risk trust decision with low-quality evidence while someone is applying pressure.
That is a design failure.
A better recovery process does not rely on vibes. It narrows who can perform risky actions, defines what proof is acceptable, logs exceptions, and makes the safe path easier than improvising.
Start with the ugly questions:
- Who can reset passwords?
- Who can reset or enroll MFA factors?
- Who can issue temporary access codes?
- Who can change recovery email addresses or phone numbers?
- Who can approve exceptions for privileged users?
- Who can modify payroll or banking details after an account recovery?
- Who can change admin access in your IdP, MDM, SIS, HRIS, DNS registrar, cloud console, password manager, or ticketing system?
If the answer is “more people than we thought,” congratulations, you found the actual perimeter. It was wearing a headset.
Google/Mandiant’s hardening guidance for UNC3944 emphasizes positive identity verification, out-of-band confirmation for high-risk changes, stronger controls around MFA registration and modification, and avoiding publicly available personal data as verification. Okta recommends standardized identity validation for remote support, strong authenticators, constrained service-desk roles, and temporary access methods that are time-bound and limited by policy.
Translated out of vendor dialect: stop letting routine support tools perform emergency surgery.
For privileged accounts, recovery should be annoying on purpose. Not impossible. Not bureaucratic theater. Just serious enough that one convincing call cannot rewrite identity trust.
A high-risk reset might require an out-of-band callback to a number already on file, manager confirmation through a known channel, on-camera verification, in-person verification, a second approver, or a temporary access code that expires quickly and only works under specific conditions. The exact answer depends on the environment. The principle does not: the caller should not get to define the proof.
What to fix before the next call
If you run identity for anything larger than a personal hobby project, audit the recovery path like it is production infrastructure. Because it is.
Do the boring work:
- Separate normal help desk work from high-risk identity changes. Front-line support does not need unlimited power to reset factors for everyone, especially admins.
- Require stronger verification for privileged and sensitive roles. Admins, finance, HR, executive accounts, domain/DNS owners, identity admins, and payroll-capable accounts should not follow the same reset flow as a low-risk account.
- Stop using public personal data as proof. Birth dates, last four SSN digits, titles, manager names, and phone numbers are not secrets. They are breadcrumbs.
- Constrain temporary access. If you use temporary codes, make them short-lived, scoped, logged, and blocked from sensitive apps unless stronger checks happen afterward.
- Watch for suspicious sequences. Password reset followed by MFA enrollment followed by access from a new device or unusual network is not three unrelated events. It is a sentence.
- Make callback and escalation rules explicit. If a caller is angry, rushed, important, or weirdly informed, that is exactly when staff need a procedure they can point to.
- Practice the failure mode. Do a tabletop where someone tries to socially engineer an MFA reset. If the room gets awkward, good. Awkward is where the real work lives.
This applies outside the enterprise too. Homelabbers and solo operators should look at password manager recovery, registrar access, cloud consoles, GitHub org ownership, email admin accounts, and backup codes. If one lost phone turns into “support can reset everything after a chat,” that is not resilience. That is a trap with a friendly UI.
Identity security is an operating procedure
Buying the identity platform was the easy part. The harder part is deciding what humans are allowed to do when the normal path breaks.
That is where a lot of organizations get soft. They protect the front door, then leave recovery, exceptions, and support escalation half-documented because everyone is busy and the edge cases are annoying. Attackers noticed. Of course they noticed. Attackers are basically professional edge-case enthusiasts with worse morals.
The fix is not panic. It is not another poster. It is not yelling at staff to be more suspicious while leaving them with the same squishy process.
The fix is to treat identity recovery like part of the identity system.
Because it is.
If someone can call your help desk and convince them to reset MFA, enroll a new authenticator, or issue temporary access to a privileged account, then that phone call is part of your authentication flow. Pretending otherwise just gives the attacker better odds.
The dashboard matters. The policy matters. The MFA method matters.
But when the call comes in, the procedure matters more than the slide deck.