MGM Resorts Hack September 2023 — How a 10-Minute Phone Call to the Help Desk Cost $100M: Scattered Spider Anatomy

Manish Garg
Manish Garg Associate of (ISC)² · RingSafe
Apr 23, 2026
15 min read
Read as
On 10 September 2023, the threat group tracked variously as Scattered Spider, UNC3944, Star Fraud, and 0ktapus initiated a now-famous attack against MGM Resorts International, parent of multiple major Las Vegas hotel and casino properties. The initial access vector was strikingly simple: a member of the group identified an MGM employee on LinkedIn, called MGM’s IT help desk, impersonated the employee, and convinced the help-desk operator to reset the employee’s password and MFA factors. The 10-minute phone call gave the attackers privileged Okta access. They then escalated to MGM’s Azure tenant and ultimately to the company’s VMware ESXi hypervisor infrastructure, deploying ALPHV/BlackCat ransomware that encrypted virtualised infrastructure underlying hotel check-in systems, slot machines, room keys, restaurant POS, and corporate networks. MGM made the controversial decision not to pay the ransom; recovery took 10+ days; total cost approached $100 million in direct response and revenue loss; share price dropped 6%. Caesars Entertainment, attacked by the same group days earlier, paid approximately $15 million ransom and avoided the catastrophic operational impact MGM suffered. The contrast between the two responses became a foundational case study in ransomware response strategy.

The MGM hack is the canonical modern social-engineering attack. No zero-days, no exotic tradecraft, no nation-state resources. A young person on a phone call talking their way into corporate access and from there to systemic destruction. This post reconstructs the technical chain, contrasts MGM’s and Caesars’ responses, and draws the lessons that every IT and security operation must internalise about the human layer of corporate identity.

What happened — the help-desk call that broke MGM

On the morning of 10 September 2023, a member of Scattered Spider — a loosely-organised collective of English-speaking, mostly young threat actors operating from the US, UK, and Canada — researched MGM employees on LinkedIn, identified a target with apparent privileged IT access, and called MGM’s IT help desk. Posing as the employee, the caller requested a password reset and MFA factor reset. MGM’s help-desk procedures at the time did not require strict identity verification beyond information that could be obtained from public sources (employee ID, manager name, recent department info). The help-desk operator complied with the request, issuing a new password and resetting MFA. Within minutes the attackers had Okta access at the level of the impersonated employee. From there, the standard Scattered Spider playbook began: enumerate Okta to identify highest-value applications and accounts, phish or social-engineer additional users to expand access, identify path to crown-jewel infrastructure (Azure tenant, ESXi hypervisor, network management), and ultimately deploy ransomware to maximise leverage. The end-to-end attack from initial call to ESXi deployment took less than 24 hours.

The ESXi compromise — why hypervisor-level encryption is catastrophic

Once Scattered Spider had administrative access to MGM’s VMware vCenter, they could deploy ransomware at the hypervisor level. ESXi-targeting ransomware (the ALPHV/BlackCat ESXi variant, plus several other families) encrypts virtual machine disk files (.vmdk) directly on the hypervisor storage rather than encrypting individual VMs from inside. This is operationally devastating because: (1) Speed. Encrypting hundreds of VM disk files in a single hypervisor scope is faster than encrypting them individually inside each VM. (2) Bypass of in-VM defences. Endpoint protection running inside guest VMs has no visibility to encryption operations happening at the hypervisor layer. (3) Comprehensive impact. Every VM hosted on the hypervisor is affected simultaneously; a single ransomware deployment cripples large swathes of infrastructure. (4) Recovery complexity. Restoring at the VM level requires recovering individual disk files; if multiple VMs share storage, partial recovery is often impossible. For MGM specifically: the ESXi infrastructure underpinned hotel property management systems, slot machine networks, electronic key card systems, restaurant POS, corporate email, and many other operational systems. Encryption simultaneously affected all of these. The recovery process required restoring ESXi infrastructure from backups (where available), rebuilding VMs, and re-establishing network connectivity — a process that took days for partial restoration and weeks for full normalcy.

The Caesars contrast — why paying may have been the rational choice

Caesars Entertainment, MGM’s major competitor in the Las Vegas market, was attacked by the same Scattered Spider operation a few days before MGM. Caesars’ attack also began with a social-engineering compromise — reportedly through a third-party IT services vendor rather than directly through the help desk. The contrast in response is instructive. Caesars: negotiated, paid approximately $15 million in ransom (reportedly a $30M demand negotiated down), received decryption keys and (claimed) deletion of exfiltrated data, restored operations relatively quickly with minimal disruption to customer-facing services. MGM: declined to pay (reportedly the demand was around $30M); endured 10+ days of operational disruption; faced approximately $100M in direct cost; suffered class-action lawsuits from affected customers; had executive-level reputational and operational damage. The strategic question: was Caesars’ decision rational? Strictly financially, paying $15M to avoid $100M is rational arithmetic. But the calculation extends beyond direct cost: paying signals continued vulnerability, encourages future attacks, may violate US OFAC sanctions if the recipient is sanctioned, and provides no enforceable guarantee. The lesson is not that paying is right or wrong but that ransomware response decisions depend critically on factors specific to the victim — backup maturity, operational dependencies, customer impact, regulatory exposure. Make the decision deliberately with executive leadership and legal counsel; do not let it default to either extreme by inattention.

Scattered Spider — the loose collective behind MGM and many others

Scattered Spider (also UNC3944 per Mandiant’s designation, Star Fraud per CrowdStrike, 0ktapus per Group-IB) is unusual among prominent threat groups in that it operates from English-speaking countries. Members are primarily young (teens to early twenties), recruited through Discord and Telegram channels, and operate with a hybrid criminal/lulz culture that combines financial motivation with status-seeking among peers. Notable Scattered Spider campaigns: 2022 attacks on Twilio, MailChimp, and Cloudflare via SMS-based phishing of employees (the original “0ktapus” campaign). 2022-2023 attacks on dozens of US, UK, and Australian organisations through similar techniques. 2023 attacks on Caesars and MGM as the most prominent examples. 2024-2025 continued operations though with several arrests of identified members in the US and UK. Operational characteristics: Scattered Spider is operationally sophisticated despite the youth of members. They invest in social-engineering preparation (LinkedIn research, organisational mapping, employee profiling); they have working knowledge of corporate IT (Active Directory, Okta, Azure, AWS, ESXi) at a level far above script-kiddie; they use commercial tooling (RMM tools like Anydesk, ConnectWise; legitimate frameworks like Rclone for exfiltration). They are also distinguished by communication: they often actively engage with defenders during incidents, taunt executives via email, and maintain a public-ish persona that traditional Russian-speaking groups avoid. For defenders: Scattered Spider’s threat profile differs from nation-state APTs in that they exploit human-process vulnerabilities rather than software vulnerabilities. Defending against them requires investment in identity, help-desk procedures, and user awareness — not in software patching alone.

Timeline — 24 hours from phone call to systemic ransomware

Days/weeks before 10 Sep 2023: Scattered Spider conducts reconnaissance on MGM employees via LinkedIn; identifies target with apparent privileged access. Morning, 10 September 2023: Phone call to MGM IT help desk; impersonation; password reset granted; MFA reset. 10 September, mid-day: Attackers authenticate as compromised employee; begin Okta enumeration. Evening 10 September: Lateral movement; access to Azure tenant; identification of ESXi infrastructure. Early hours 11 September: Privileged access to vCenter; deployment of ALPHV/BlackCat ESXi ransomware variant. Encryption of hundreds of VMs across MGM properties. Morning 11 September: MGM IT discovers operational impact. Hotel check-in systems offline. Slot machines unable to process cashless transactions. Electronic key card systems failed. Email infrastructure encrypted. 11-13 September: Public disclosure; Las Vegas Strip operations dramatically disrupted; manual workflows for hotel operations; cash-only at many points; staff overwhelmed. 14-19 September: Progressive recovery as backups are restored; some systems remain offline. 20 September – 30 September: Most customer-facing systems restored. Backend reconciliation continues. October 2023 – January 2024: Class-action lawsuits filed. SEC disclosure required (8-K filing). Insurance claims processed. Long-tail customer impact (loyalty program data exposure, potential identity issues for affected guests). 2024: US authorities arrest several alleged Scattered Spider members in the US and UK. Ongoing prosecution proceeds.

Help-desk security — the structural reform required

The MGM attack made one specific operational reform mandatory across enterprise IT: rigorous help-desk identity verification. The historical pattern of help desks accepting “I am [employee name]” plus easily-discoverable details (employee ID, recent project info, manager name) as authentication is dead. Modern help-desk procedures must include: (1) Out-of-band verification. Help-desk callers requesting password or MFA reset must be verified via a separate channel — typically a callback to a phone number on file (not the number the caller supplies), a video call confirming face match against employee badge photo, or a confirmation message via the employee’s registered email or messaging account. (2) Manager confirmation. For high-risk requests (password reset for privileged accounts, MFA reset, account creation), require positive confirmation from the employee’s manager via known communication channel. (3) Authentication factors not derivable from public sources. Employee ID, manager name, department info — all derivable from LinkedIn or open-source research. Authentication should require something the caller would not know unless they are the employee — a personal security question with a non-obvious answer, a one-time code sent to a registered device, biometric verification. (4) Recording of all calls. Help-desk calls should be recorded for forensic review; authentication failures and refusals should be logged for pattern detection. (5) Privileged-access protection. The help desk should not be able to reset passwords or MFA for the highest-privilege accounts (domain admins, security team, executives) without additional approval workflow. (6) Awareness training. Help-desk staff need ongoing training on social engineering tactics; periodic simulated attack exercises; reward systems that incentivise refusal of suspicious requests. The MGM and Caesars attacks both relied on help-desk procedures that have since been substantially hardened across the industry — but smaller and less-mature organisations remain vulnerable.

Indicators of compromise and detection

Concrete detection signals for Scattered-Spider-style attacks. (1) Help-desk pattern monitoring. Aggregate help-desk activities by user; alert on rapid sequences (password reset, then MFA reset, then login from new geography) for any single user. (2) Okta authentication anomalies. Logins from new geographies, new device fingerprints, after recent credential changes — all signals worth aggregating. (3) Azure / cloud admin activity. Privileged actions in cloud tenants outside business hours, by users not normally performing admin actions, from non-corporate IPs. (4) RMM tool usage. Anydesk, ConnectWise, Atera, NinjaOne — all legitimate remote-management tools but unusual usage patterns from Scattered Spider operations. Alert on installation events, sustained sessions to non-corporate destinations. (5) Reconnaissance of high-value targets. User-account browsing of vCenter consoles, ESXi management interfaces, backup systems by users without operational reason — the precursor to ESXi-targeted attacks. (6) Outbound exfiltration patterns. Use of Rclone, Mega.nz, transfer.sh, or anonfile from corporate hosts. Block outbound to file-hosting services that aren’t business-required. (7) Hypervisor activity. Detect creation of VMs, modification of VM disk files, snapshot operations — all should align with operational change control; deviations are alerts. For mature organisations these signals are aggregated by SIEM and SOAR platforms; for mid-tier, build alerts incrementally on the highest-value patterns first.

Mitigations — defending against social engineering and ESXi attacks

Concrete defensive measures categorised by attack stage. Initial access prevention: hardened help-desk procedures (above); phishing-resistant MFA (FIDO2/WebAuthn for privileged users); annual mandatory user training on social engineering; user awareness campaigns highlighting recent attack patterns. Lateral movement prevention: network segmentation between user workstations and infrastructure management; privileged access workstations (PAWs) for administrative tasks; just-in-time privileged access management; logging and alerting on privileged-account usage. Hypervisor protection: dedicated management network for vCenter and ESXi; restrict ESXi/vCenter access to specific source IPs; multi-factor authentication mandatory for vCenter; ESXi shell access disabled or strictly controlled; ESXi-specific logging to external SIEM. Backup defence: backup infrastructure isolated from production network; immutable backups (S3 Object Lock, write-once tape, cloud-immutable storage); offline copies of critical backups; tested restore procedures. Incident response: ransomware-specific runbook; pre-arranged forensics-vendor relationship; pre-arranged crisis-communications support; tabletop exercises quarterly; relationship with law enforcement (FBI, NCRB, state cyber crime units). Cyber insurance: review coverage specifically for ransomware response, business interruption, and regulatory fines; understand sub-limits and exclusions; confirm pre-approved response vendors are covered.

India context — Scattered Spider, Indian help desks, and the operational lesson

Scattered Spider has not specifically been attributed in publicly-known attacks against major Indian enterprises (as of mid-2025), but the technique is highly portable and applicable. India has multiple high-target sectors with comparable operational characteristics: large hotel chains, ITES/BPO operators serving global clients, large IT services firms with extensive customer remote-access, large hospitals, and government IT operations. Specific Indian risk areas: (1) ITES/BPO help desks. Indian ITES providers operate help desks on behalf of multiple Western clients; the structural pattern (large help-desk teams, many client environments, high call volumes) is exactly the environment where social engineering thrives. (2) Hotel chain ITES integration. Indian hotel chains running modern property-management systems on virtualised infrastructure share MGM’s structural exposure. (3) Public-sector IT. Public-sector IT staffing patterns, with limited security training and multiple vendor relationships, create help-desk targets for attackers willing to invest in research. For Indian organisations: assume Scattered-Spider-style attacks will occur. Strengthen help-desk procedures now. Mandate phishing-resistant MFA for privileged accounts. Implement ESXi-specific protections. Test incident response. The cost of these measures is materially less than the cost of an MGM-class operational disruption.

Lessons learned — five durable takeaways

(1) Identity is the new perimeter. The MGM attack started and ended with identity compromise. Network-layer defences and software-vulnerability patching matter, but they did not prevent and could not detect this attack. Identity controls — strong authentication, careful authorisation, comprehensive logging — are the dominant defensive priority for 2025-2026. (2) Help-desk procedures are security-critical. Treat the help desk as an attack surface comparable to your edge VPN or your authentication system. Procedures, training, monitoring, and escalation paths all need rigor. (3) Hypervisor protection is non-negotiable for virtualised environments. Most enterprises run substantial workload on virtualised infrastructure; the hypervisor is a single point of catastrophic failure. Treat ESXi and equivalent (Hyper-V, KVM, Nutanix AHV) as crown jewels with appropriate access controls. (4) Ransomware response is a business decision, not a technical one. The decision to pay or not depends on operational dependencies, backup maturity, regulatory exposure, customer impact — a decision the CISO informs but the CEO and Board own. Pre-decide your principles before incident; do not negotiate them under crisis pressure. (5) Backup architecture matters more than backup existence. Backups exist almost everywhere; backups that survive a sophisticated attacker who has compromised privileged credentials are rare. Immutable backups, offline copies, network-isolated backup infrastructure — these are differentiators. Audit and improve.

What every IT leader should review this quarter

A 90-day program based on MGM lessons. Month 1 — Identity and help desk. Audit help-desk procedures end-to-end. Implement out-of-band verification for password and MFA resets. Mandate phishing-resistant MFA for privileged accounts. Review Okta/Azure AD audit log monitoring. Training for help-desk staff on social engineering. Month 2 — Hypervisor and infrastructure. Inventory ESXi/Hyper-V infrastructure. Implement management-network isolation. Restrict source IPs for management access. Confirm MFA mandatory on vCenter. Audit privileged accounts; revoke unused. Implement just-in-time elevation for vCenter administration. Month 3 — Backup and incident response. Audit backup architecture; identify single points of failure. Implement immutable backups for critical data. Test restore procedures end-to-end. Update incident response runbook with ransomware-specific scenarios. Conduct tabletop exercise simulating MGM-pattern attack. Identify and pre-engage forensics and crisis-communications vendors. The cost of this program is materially less than the cost of inaction.

Wider implications — Scattered Spider as a model and the response to it

The MGM/Caesars episode shapes ongoing cybersecurity practice in several specific ways. (1) Help-desk industry transformation. Major IT services firms have implemented standardised help-desk verification procedures across client engagements; ITSM tools (ServiceNow, BMC, Atlassian) have built more rigorous identity verification into help-desk workflows. (2) FIDO2 adoption acceleration. Phishing-resistant MFA (FIDO2/WebAuthn, hardware tokens) is now the table-stakes expectation for privileged accounts; prior tolerance of TOTP and push-notification MFA for high-privilege accounts is eroding. (3) ESXi hardening at vendor level. VMware (Broadcom) released improved security defaults for ESXi; competing hypervisor vendors followed; cloud-equivalent IaaS providers strengthened analogous protections. (4) Cyber insurance underwriting. Insurance applications now ask specifically about help-desk procedures, identity controls, and hypervisor protection; pricing and coverage reflect maturity. (5) Law enforcement engagement. The arrest of Scattered Spider members demonstrates that even diffuse, geographically-distributed criminal collectives are reachable by determined law-enforcement effort. This shapes risk-reward calculations for would-be attackers and signals durable enforcement attention. (6) Academic and curriculum response. The MGM case is now standard material in cybersecurity education programs; case studies in graduate security curricula; CISO peer learning materials. The lessons will continue to shape security practice for the rest of the decade.

FAQ

How much did the MGM attack cost in total?

MGM disclosed in SEC filings approximately $100 million in direct impact — recovery costs, forensics, legal expenses, and lost revenue from operational disruption. This excludes ongoing class-action settlement costs and reputational damage. The total may exceed $200 million when all costs settle.

Did MGM eventually pay the ransom?

No public confirmation that MGM paid. Multiple media reports indicate MGM declined to pay; recovery proceeded through backup restoration. Caesars, attacked by the same group days earlier, did pay (~$15M).

Were Scattered Spider members caught?

Several alleged members have been arrested in the US, UK, and Spain through 2024-2025. Prosecutions are ongoing. The collective itself has continued operations with new members despite the arrests.

What's the difference between Scattered Spider and ALPHV/BlackCat?

Scattered Spider is the initial-access and lateral-movement operator; ALPHV/BlackCat (now defunct after a March 2024 exit-scam) was the ransomware-as-a-service provider whose malware Scattered Spider deployed in some campaigns. Scattered Spider has used multiple ransomware brands.

How can I tell if my company is vulnerable to similar attacks?

Run a tabletop exercise: have someone call your help desk pretending to be a senior employee and request password/MFA reset. If they succeed without out-of-band verification, you are vulnerable. This kind of internal “purple-team” testing is invaluable.

Is FIDO2 hardware token mandatory now?

Not legally mandatory in most jurisdictions but rapidly becoming the de-facto requirement for privileged accounts in mature security postures. Insurance underwriting and regulatory expectations are moving in this direction. For executives, IT admins, and security team members, FIDO2 hardware tokens are now standard expectation.


📰 Note: This analysis is compiled from public reporting (Reuters, Bloomberg, court filings, threat-intel firm publications) and is intended for security education. Some technical details remain disputed in ongoing legal proceedings; we have attributed claims where the source is established and noted where matters remain contested.

Worried about your exposure?

Get a free attack-surface review

We check what an attacker would see about your business — leaked credentials, exposed services, dark-web mentions. 30 minutes, no obligation.

Book exposure review Replies in 4 working hrs · India-only · Senior consultants