Strong passwords and MFA protect a login. They don't protect the process for recovering a login. In the summer and autumn of 2023 a group tracked as Scattered Spider (also known as UNC3944, Octo Tempest and 0ktapus) showed how much damage that gap allows, by calling IT service desks and asking them to reset credentials for accounts the group didn't own.
Two US casino operators were hit within days of each other. Caesars Entertainment told the SEC that suspicious activity resulted from "a social engineering attack on an outsourced IT support vendor" and that the attacker took a copy of its loyalty programme database. MGM Resorts identified an incident on 12 September 2023, shut systems down to contain it, and later estimated a negative impact of about $100 million on Adjusted Property EBITDAR for the quarter.
Step 1: research the target
The group picks an employee, often one with administrative rights, and builds a profile from LinkedIn, social media and data broker sites: name, role, manager, office location and the format of employee IDs. In MGM's case, research group vx-underground reported that the attackers impersonated an employee in a phone call to the help desk. The ransomware operator ALPHV disputed parts of the public reporting, and MGM has not published its own account of initial access, so treat the MGM detail as reported rather than confirmed.
Step 2: the phone call
The attacker calls the service desk posing as that employee. The script is mundane: new phone, lost authenticator, locked out before an urgent meeting. Fluent, confident English, knowledge of internal jargon and correct answers to knowledge-based questions make it convincing. The CISA and FBI advisory on Scattered Spider describes exactly this: posing as company IT or help-desk staff, or as employees, to get IT staff to reset passwords and transfer or reset MFA.
If an agent can reset someone's MFA after hearing facts that are on LinkedIn, MFA is only as strong as that phone call.
Step 3: take over identity itself
Okta warned its customers in August 2023 that between 29 July and 19 August attackers had convinced service desk staff to reset all MFA factors for highly privileged users. With a Super Administrator account, the attackers then:
1. Gave elevated privileges to other accounts and removed MFA requirements from policies.
2. Configured a second identity provider as an "impersonation app" that they controlled.
3. Used it to sign in to applications as other users, without needing their passwords.
ALPHV, whose affiliate carried out the MGM attack, claimed in its own statement to have held super administrator rights in MGM's Okta environment and Global Administrator rights in Azure, and to have encrypted more than 100 ESXi hypervisors on 11 September.
Step 4: tools, data theft and ransomware
CISA's advisory, last updated in July 2025, lists the follow-on pattern: legitimate remote access tools such as AnyDesk, ScreenConnect and TeamViewer; tunnelling with Ngrok or Tailscale; registering attacker-controlled MFA devices; data exfiltration to cloud storage; and ransomware against VMware ESXi, first ALPHV/BlackCat and more recently DragonForce.
How it gets detected
The signals exist, but they sit in different teams:
• Service desk ticket for an MFA reset on a privileged account, followed within minutes by a new device enrolment.
• New identity provider or federation settings added to the SSO tenant.
• Admin role changes, MFA policies relaxed, or new remote access software appearing on servers.
• Sign-ins for a staff member from a location or ASN they have never used.
Okta's guidance is to alert on these events in the identity system's logs, and to correlate them with service desk tickets.
Controls that break each step
Verify identity, not knowledge
• Never reset MFA based on personal details. Use visual verification (live video against an ID or HR photo), a call back to a number already on file, or approval from the user's manager.
• For privileged accounts, require two people to approve any reset, and a delay before the new factor is usable.
• Apply the same rules to outsourced service desks and write them into the contract.
Make the reset worth less
• Enforce phishing-resistant MFA (FIDO2 keys, passkeys) for admins. Okta's "Protected Actions" style re-authentication for sensitive changes means a fresh login can't immediately change identity settings.
• No standing admin privileges: grant admin roles just in time, for a limited period.
• Allowlist remote access tools and block the rest.
Recover fast
• Keep offline, tested backups of hypervisors and identity configuration.
• Have a runbook for revoking all sessions and removing unknown identity providers.
The lesson
Attackers go where verification is weakest, and account recovery is often a person reading a script. Treat the reset path as part of authentication, with the same strength as the login it replaces. For customer-facing apps the same applies: a recovery flow that asks for a date of birth undoes every other control.
osec.one logins use one-time codes and Apple/Google sign-in, so there is no password for a support agent to reset. Free to start.
Add passwordless login