What actually happened in the MGM Resorts breach?

Per Okta's own security advisory, attackers ran a social-engineering campaign against IT help desks between July 29 and August 19, 2023: they called in, impersonated a privileged employee, and talked support staff into resetting the MFA factor on a Super Administrator account. Once inside, they used that Super Admin access to weaken authentication policies, escalate further, and configure a second identity provider as a cross-tenant impersonation app — letting them manipulate a username parameter to sign into other applications as any legitimate user in the tenant. No password database was breached and no software vulnerability was exploited; the entire chain ran through the identity-verification process itself.

How much did it actually cost MGM?

MGM's own SEC Form 8-K filing, dated September 12, 2023, put the estimated negative impact at approximately $100 million to Adjusted Property EBITDAR for its Las Vegas Strip and regional properties, plus under $10 million in one-time consulting and legal fees for that quarter. The filing also states MGM does not believe customer payment card numbers or bank account details were obtained — but personal data including names, contact details, dates of birth, and driver's license numbers was accessed for some customers, with Social Security and passport numbers taken for a smaller subset.

Is this the same thing as the 'identity first' point in your casino hardening priority-order post?

No — that post ranks identity ahead of cloud config, server, network, and application hardening for a casino's limited change-window capacity, but only names MFA, conditional access, and session controls as the category's contents in two sentences. It doesn't explain the actual attack mechanism a well-resourced social-engineering crew uses against identity controls, or what specifically breaks when the control that fails is the help desk's verification process rather than a missing MFA policy. This post is the mechanism-level deep dive that sits underneath that one line.

We already require MFA on all admin accounts. Doesn't that cover this?

Not against this specific attack. The attackers in the MGM case didn't need to defeat MFA — they got a help-desk agent to remove it, by phone, using a plausible enough impersonation of a real employee. MFA enrolled on an account is not the same control as a help desk that can't be talked into resetting it. The gap this incident exposed was in the verification process a support team follows before touching a privileged account's authentication factors, not in whether MFA existed.

What does AnySec's identity hardening actually check for this?

The identity-hardening portion of an engagement reviews conditional access and MFA enrollment (as the priority-order post already covers), plus, specifically for privileged and admin-tier accounts: whether standing Super Administrator or domain-admin access exists at all versus scoped, minimal, time-limited roles; whether sensitive admin actions (MFA resets, role changes, new IdP configuration) require a second, harder-to-social-engineer verification step; and whether the help desk or support process has a documented, tested identity-verification procedure for privileged-account requests, not just an informal one. We test the process the way the attack actually worked — by checking whether the verification step could be talked around — rather than only checking whether a policy document exists.

Identity Hardening for an Online Casino: What the MGM Help-Desk Breach Actually Changed

The short answer

MFA on every admin account did not stop the MGM Resorts breach — attackers got a help-desk agent to remove it. Per Okta's own advisory, the attack chain was social engineering against IT support (not a technical exploit), an MFA factor reset on a Super Administrator account, privilege escalation from that access, and a cross-tenant impersonation app used to sign in as any legitimate user. MGM's own SEC filing put the cost at roughly $100 million to Adjusted Property EBITDAR. For an online casino, the identity-hardening question this raises isn't "do we have MFA" — it's whether the process that can reset MFA on a privileged account can be talked around by a phone call.

Who this is for

This is written for a Head of Infrastructure or CISO at an online casino or hospitality-adjacent gaming operator who has already read what comes first in a casino hardening engagement and knows identity sits at the top of that priority order. This post goes one layer deeper into that single category: what a real, well-resourced attack against identity controls actually looks like, and which specific sub-controls a "we have MFA" posture is missing. It's not a general incident-response retainer pitch — for what to do in the first hours of an active breach, see incident response retainers for online casinos; this post is about the hardening work that closes the gap before that call has to happen.

What actually happened, mechanism by mechanism

Okta's security advisory on the cluster of attacks it tracked between July 29 and August 19, 2023 — the campaign publicly associated with the MGM Resorts and Caesars Entertainment incidents — describes a chain that never touches a password hash or a software vulnerability:

Social engineering against the help desk. Attackers called IT support impersonating a real, privileged employee — using publicly available details (LinkedIn, corporate directories, prior data leaks) to sound plausible enough to pass a support agent's informal verification.
MFA factor reset on a Super Administrator account. The ask was simple: "I've lost my phone, can you reset my MFA." A support process built for employee convenience, not attacker resistance, granted it.
Privilege escalation from that single account. Super Administrator access in an identity platform isn't just "one more login" — it can weaken authentication policies platform-wide, create new admin roles, and reconfigure trust relationships.
Cross-tenant impersonation. The attackers configured a second, attacker-controlled identity provider as a federated "impersonation app" inside the compromised tenant, then manipulated a username parameter to authenticate into connected applications as any legitimate user — without needing that user's own credentials at all.

None of the four steps is a technical exploit in the CVE sense. All four are identity-process failures: a verification step that trusted a phone call, and an authorization model that let one compromised support interaction cascade into tenant-wide impersonation.

Why "we have MFA" doesn't cover this

A casino's identity-hardening checklist commonly stops at: MFA enrolled on all accounts, conditional access policies configured, session timeouts set. Those controls are necessary and none of them were the point of failure here. The gap sits in three places most MFA-focused checklists don't reach:

Standing privileged access. If a Super Administrator (or equivalent domain-admin) role exists as a permanent, always-on grant rather than a scoped, time-limited one, a single successful social-engineering call is worth the entire tenant — not one account.
No re-authentication gate on sensitive admin actions. Resetting MFA, creating a new admin role, and configuring a new identity provider are all higher-stakes actions than a normal sign-in. If none of them require a separate, harder-to-bypass verification step beyond the support agent's judgment call, the account's own MFA enrollment is irrelevant the moment that one conversation succeeds.
An informal, untested help-desk verification process. "Ask for an employee ID and date of birth" is not a verification process that resists someone who has already done reconnaissance — it's a checklist that a plausible caller can pass. A verification process that hasn't been tested against a live, scripted social-engineering attempt is a process nobody has actually validated.

Okta's own post-incident guidance names the fixes for exactly these three gaps: enforce phishing-resistant authentication (FIDO2/WebAuthn-class factors that can't be "reset" over the phone the same way a TOTP code can) for sign-in, require a separate re-authentication step for sensitive admin actions specifically, strengthen help-desk identity verification with something closer to visual or out-of-band confirmation, and move privileged accounts to minimal, custom admin roles with just-in-time elevation rather than standing Super Administrator access.

Where this fits inside a hardening engagement

Identity hardening for a casino already means MFA, conditional access, and session controls — the priority-order post covers that layer. This is the layer underneath it, specific to privileged and administrative access:

Inventory standing privileged access. Every account with Super Administrator, Global Administrator, or domain-admin-equivalent rights, and whether that access is permanent or scoped/time-limited.
Test the help-desk verification process against the actual attack. Not a document review — a scripted attempt to get a privileged-account credential or MFA factor reset through the real support channel, the same way a red-team engagement tests a technical control by trying to defeat it.
Require re-authentication for sensitive admin actions. MFA resets, new admin-role creation, and new identity-provider configuration should each demand a fresh, harder-to-bypass authentication step — not inherit the trust of whatever session the support agent or admin already has open.
Move toward minimal, time-limited admin roles. Replace standing Super Administrator grants with custom roles scoped to daily tasks, with just-in-time elevation for anything broader — so a single compromised support interaction can't cascade into full-tenant control.

This sits inside the same hardening methodology AnySec applies to any category — current-state assessment, threat-model the paths most likely to hit the stack, apply changes in change-windowed phases, then retest against the same attack paths — with the retest step here meaning a follow-up attempt at the same help-desk pretext, not just a policy-configuration review. It's part of the same Security Hardening engagement that covers server, network, application, and cloud-configuration hardening alongside identity.

Sources and review

Facts about the MGM Resorts incident are drawn from two primary sources, cross-verified directly: Okta's own security advisory on the cross-tenant impersonation attack cluster (sec.okta.com, describing the July 29–August 19, 2023 observation window, attack mechanism, and recommended mitigations), and MGM Resorts International's own SEC Form 8-K filing dated September 12, 2023, disclosing the estimated financial impact and the scope of customer data affected. No figures in this post are AnySec's own numeric claims — they are third-party-sourced historical incident facts, matching the sourcing standard used for prior incident case studies on this site. AnySec's own hardening methodology and deliverables are described qualitatively, per services.ts, with no new statistical claims introduced.