Writing
Anatomy of an Identity Incident

A Phone Call Beat Every Control

Anatomy of an Identity Incident — MGM and Caesars, September 2023. No exploit, no malware. Someone called the help desk, and the help desk issued an identity to the wrong person.

Michael AbramovichOctober 10, 20236 min read

Forensic write-ups of public identity breaches, strictly at the identity layer. No vendor is the villain — the point is the structural class of failure, not the logo on it.

The 60-second version

In September 2023, two of the largest casino operators in the world were brought down within days of each other by the same playbook, and the playbook contained no malware at the point of entry and no software vulnerability. The attackers — the social-engineering crew commonly called Scattered Spider, working alongside the ALPHV/BlackCat ransomware operation — looked up an employee on LinkedIn, called the IT help desk pretending to be that person, and talked the help desk into resetting the account's multi-factor authentication. That was the breach. Everything after — privilege escalation, control of the identity directory, data theft, ransomware on the virtualization layer — followed from one reset granted to the wrong caller.

MGM rode out roughly ten days of outages and chose not to pay. Caesars, hit through a similar social-engineering route against an outsourced IT vendor, paid around $15 million. The technical identity stack at both companies was, presumably, modern. It didn't matter, because the attack never touched it.

The identity timeline

Only identity-relevant events.

  • Reconnaissance — The attackers identify an employee from public sources (LinkedIn) and gather enough detail to impersonate them convincingly.
  • The call — Posing as that employee, they contact the IT service desk and request help regaining access — the everyday "I'm locked out" scenario the help desk exists to resolve.
  • The reset — The help desk performs an MFA reset, routing a new factor to the attacker. With reporting describing SIM-swap and SMS-spearphishing techniques in the mix, the recovery path delivered control of the account's second factor to the wrong person.
  • The foothold — The attackers are now an authenticated employee. No exploit was used; the identity was handed to them.
  • The escalation — From that foothold they escalate, ultimately reaching control of the organization's Azure Active Directory — the identity directory itself.
  • The payload — With directory-level control they move laterally, exfiltrate data, and deploy ransomware against ESXi virtualization servers.
  • Sept 2023 — MGM endures about ten days of disruption and does not pay; Caesars, breached via its outsourced IT support, pays roughly $15 million.

The pivot point

The pivot is the instant the help desk reset the factor without being certain who was on the phone.

Every other control in a modern identity stack assumes that authentication is hard to fake. Strong passwords, phishing-resistant MFA, conditional access — they all raise the cost of proving you are someone. The account-recovery path exists to lower that cost back down, on purpose, for the legitimate case where a real employee genuinely can't get in. That is its whole job: to issue identity to someone who currently can't prove it. Which makes it the one door in the building designed to open for people who fail the normal checks — and therefore the door an attacker will always choose.

So the pivot here isn't a weakness in MFA; it's the recovery flow around MFA. The moment a human operator, under the ordinary pressure of a helpful support call, reset a factor for someone they had not strongly verified, every technical control upstream became irrelevant. The identity was issued to the attacker through the front door, with a valid badge, and from that point on the system was not defending against an intruder — it was serving an authenticated user.

What would have caught it

Naming controls, not products.

Strong verification at the help desk — especially for resets. The reset path needs identity proofing that a phone call cannot fake: a live video check against a known photo, a manager approval out-of-band, a one-time code delivered through a separately trusted channel, or in-person verification for the most sensitive accounts. The control that was missing is the only one that mattered.

A separate, harder flow for privileged accounts. A reset for a standard user and a reset for someone who can reach the identity directory should not be the same procedure. Privileged recovery deserves friction: multiple approvers, delays, and senior sign-off.

Holds and alerts on sensitive identity changes. An MFA reset on a privileged account should trigger a delay and an alert, so a fraudulent reset has a chance of being caught before it's used.

Phishing-resistant factors that resist social reset. Hardware-bound credentials raise the bar not only against phishing but against casual "just send me a new code" recovery, because re-binding a hardware factor is a heavier, more verifiable act.

Tiered admin and least privilege, so that one recovered account cannot walk all the way to domain control. The blast radius of a single bad reset should be small by design.

The last mile

This is the incident I point to when someone argues that identity is a product problem. It is the cleanest counterexample I know.

Both companies could have bought every identity product on the market and deployed all of it correctly, and this still happens — because the attack went around the products entirely and through the process that sits beside them. The identity provider's job ends at "we offer strong authentication and a recovery API." It does not, and cannot, verify that the human running your help desk confirms identity before resetting a factor. That verification is operational work: a trained process, applied consistently, every single time, including at 2 a.m. when the caller is friendly and in a hurry. It is exactly the kind of work that has no owner — not the product vendor (out of scope), and too often not the customer either, because the help desk is frequently outsourced, measured on call-resolution speed, and never hardened for the privileged case. Caesars' route ran straight through an outsourced IT vendor; that is the seam made literal.

This is the last mile in its purest form, and it is the one most clearly ownable by an operator rather than a product. Account recovery is a process that lives across people, scripts, and third parties — precisely the span an MSSP standing on it full-time, across many clients, can see and standardize. A provider ships a reset endpoint; someone has to own what it takes to use it safely. The MGM and Caesars intrusions are what it costs when no one does: the best authentication in the world, undone by a polite phone call to the part of the system designed to say yes.

For defenders

Five things you can check this week.

  1. Re-verify your help-desk reset procedure for privileged accounts. If a friendly caller with public information about an employee can get a factor reset, you have the MGM gap.
  2. Add strong, fakeable-by-phone-proof verification to resets — video, manager approval out-of-band, or a separately trusted channel.
  3. Split standard and privileged recovery into different, harder flows with multiple approvers and delays.
  4. Alert on every MFA reset for an admin, and add a hold before the new factor is usable.
  5. Audit your outsourced IT/help-desk contracts for identity verification standards. If recovery is run by a third party measured on speed, the verification bar is probably set where the attacker wants it.

Built from public reporting and the parties' own disclosures; sources below.

Sources

#mgm #scattered-spider #help-desk #mfa-reset #social-engineering #last-mile