Observations

What went wrong, and what to do about it

Real breaches, each put through the same four questions: one control that worked, one that did not, one number worth watching, and what should have been done instead. Every entry cites a primary source, because the point of this section is that you can take it to a meeting.

NO. 05/Hospitality / Gaming/4 September 2026

Ten minutes on the phone to the help desk

MGM Resorts SEC Form 8-K, October 2023, and contemporaneous reporting

Scattered Spider identified an MGM Resorts employee on LinkedIn, called the IT help desk impersonating them, and talked their way into a password reset that yielded administrative access to MGM's Okta tenant. MGM pulled systems offline to contain it; ALPHV still encrypted more than a hundred ESXi hypervisors, and MGM disclosed roughly $100 million of impact to its Las Vegas and regional operations.

What worked

They did not pay. Caesars, hit by the same crew in the same window, reportedly did. MGM took an operational beating instead: slot machines, digital room keys and reservations down, guests queuing at the desk with paper. That is what refusing looks like from the inside, and the fact that they came back without paying is the part worth putting in front of your own executives before an incident, not during one.

What failed

Everything upstream of the phone call. The help desk could reset a privileged account's credentials and its MFA on the strength of a voice and details anyone could read off LinkedIn, and there was no callback, no manager confirmation, no out-of-band check. Then containment came too late to matter: by the time the Okta sync servers were pulled, the operators already held the environment, and the hypervisors were encrypted anyway. Worth being clear about that, because the shutdown is often described as the thing that stopped the encryption. It did not.

The number

10 minutes

the length of the phone call that produced administrator access to MGM's Okta tenant.

What to do instead

Treat identity verification at the help desk as a security control with a written procedure, not as a customer service judgement call. High-privilege resets need a second channel: a callback to the number in the HR record, a manager approval, or an in-person check. Then go and test it, by having someone your desk does not know attempt exactly this call. Most organisations that believe they are covered here have never tried it, and the ones that have usually stop believing it. The technical lesson is smaller than the procedural one: no amount of MFA helps when the help desk will re-enrol the factor for whoever asks.

Named for the doctrine distinction between a lesson observed and a lesson learned: a lesson is not learned until behaviour has changed and somebody has checked. Pretending otherwise is how the same finding turns up in three consecutive post-incident reports.