The recent cyberattack on MGM Resorts International has raised serious concerns about the security of sensitive data and the vulnerabilities organizations face in today’s digital landscape. In this blog post, we will dive into the details of the attack based on the information currently available, analyze its root causes and discuss key takeaways to help organizations strengthen their security posture.
MGM Attack: What We Know (Thus Far)
Allegedly, a criminal gang made up of U.S. and U.K.-based individuals that cybersecurity experts call Scattered Spider (aka Roasted 0ktapus, UNC3944 or Storm-0875) initiated a social engineering attack that led to the near shutdown of MGM Resorts International. MGM Resorts International is a global hospitality and entertainment company, with a portfolio of 29 hotel and resort properties, including iconic brands like Bellagio, MGM Grand and Mandalay Bay.
(Did you attend Black Hat at the Mandalay Convention Center this year? Yes, this could directly affect you.)
A social engineering attack allowed the threat actor to burrow into the MGM environment and establish a foothold. Due to the common mistake of password reuse, CyberArk Labs – as well as many experts in the cybersecurity community – are currently under the impression that the attackers had usernames and passwords from previous data breaches. With additional information collected from a high-value user’s LinkedIn profile, they hoped to dupe the helpdesk into resetting the user’s multi-factor authentication (MFA). They were successful.
Based on available information, as it currently stands, threat actors also were observed creating persistence in MGM’s network by configuring an entirely additional Identity Provider (IdP) in the Okta tenant using a feature called “inbound federation.” The function is intended to allow the fast connection of different Okta tenants during mergers of companies. In this case, though, the threat actors used it to increase their control of the victim’s networks. (As we say in the industry, “It’s not a bug; it’s a feature!”)
It also appears that the attackers gained control not only of Okta but also of the Microsoft Azure cloud environment. This already jeopardized the applications managed by the IAM platform, but now all their cloud assets were also in danger.
Our threat actors were eventually discovered. MGM’s incident response team began by terminating the Okta sync servers, where Scattered Spider had deployed some additional credential harvesting techniques. This ultimately resulted in the complete termination of the Okta platform and the threat actors’ access initial access. HOWEVER, the damage had been done. The threat actors had already exfiltrated unknown terabytes of data and still had access to the cloud platform. It was time to make their presence known.
This was when the BlackCat/ALPHV ransomware group was called in. Using this RaaS service, Scattered Spider encrypted several hundred of their ESXi servers, which hosted thousands of VMs supporting hundreds of systems widely used in the hospitality industry. This caused cascading chaos. As the ESXi hosts became encrypted one after another, the applications running on them crashed … one after another … after another. Hotel room keys no longer worked. Dinner reservation systems were down. Point-of-sale systems were unable to take payments. Guests were unable to check in or out. Slot machines were completely unavailable. At this point, MGM was hemorrhaging money – and potentially its credibility.
Once the threat actors acquired their initial foothold, they could begin to escalate their privileges. They ultimately acquired the privileged access to the accounts running the IAM infrastructure. This allowed them significant access to the MGM network.
What made this attack worse than if MGM’s Okta environment and the applications connected to it had only been compromised, was that the IdP solution granted highly privileged access to Azure, which ultimately allowed the cloud-originated attack into MGM’s brick-and-mortar operations. Scattered Spider deployed BlackCat/ALPHV ransomware, which encrypted several hundred of their ESXi virtual machine infrastructure. This severely impacted MGM’s operations.
The full extent of what systems were compromised and what data was leaked is still unknown. Still, gaming industry analyst David Katz says that MGM Resorts is losing as much as $8.4 million in revenue every day until it fixes the problems caused by the ongoing cyberattack. There is still so much to this story that we won’t know the full extent of the damage for quite some time.
CyberArk Labs’ Critical Initial Takeaways from the MGM Attack
Although it’s still too early to definitively say what exactly happened in the MGM attack, the following initial assessments from our team are as relevant now as they’ll be once the dust settles:
- Attacking IAM platforms is a common tactic that threat actors use. It gives persistent access to an organization and extends attacker privileges into more systems, causing more damage. This isn’t anything new to us either. We discussed this in the aftermath of the SolarWinds breach, along with best practices for configuring and monitoring your IAM platform.
- The worst part of this breach was that MGM’s IdP was configured in a way that allowed Scattered Spider to pivot into their VMware infrastructure. For example, the act of synchronizing credentials between on-prem and cloud resources allowed Scattered Spider to pivot into the VMware infrastructure. This is where we believe that BlackCat/ALPHV became involved.
- BlackCat/ALPHV has been an operator CyberArk Labs has tracked for some time now. We recently released a free and open-source tool called White Phoenix that helps victims to recover from ransomware attacks. (Due to the fact the ESXi files were encrypted and not PDFs, there’s unfortunately not much this tool could do to help MGM.)
- RaaS is big business and part of the larger criminal supply chain. Just as commercial businesses rely on SaaS applications to do their work, so do criminal gangs. BlackCat/ALPHV provides the professional services Scattered Spider lacks. (i.e., malware creation, back-end C2, tor leak-site, malware support, negotiation services).
- The MFA device reset was a significant chokepoint in the attack. If the MFA device reset were not possible or detected in time, the threat actors would have faced limitations in continuing their attack. Hence, limiting the MFA device to a specific phone number associated with the user could have offered an effective mitigation.
- IAM infrastructure, including federation servers, Okta sync servers – and even CyberArk vaults – should be considered Tier 0 assets. Their compromise could lead to paralyzing a significant portion of a network. Securing access to these assets and limiting them to dedicated proxies is extremely important in mitigating future attacks.
Lessons Learned and Mitigation Strategies
To strengthen security measures and mitigate similar attacks, organizations should consider the following strategies:
1. Contain Impact
Minimizing exposure of privileged accounts is vital in mitigating phishing attempts. IT administrators should use privileged access management (PAM) solutions, reducing the risk of compromise through attacks (including vishing). Organizations should also consider implementing zero standing privilege (ZSP) where applicable.
We like to say, “It’s hard to hack a credential when it literally doesn’t exist.” While internal or external compromises may still occur, this contains the attack to a dedicated endpoint, which can help minimize exposure and assist with incident response.
2. Improve MFA Control
Creating visibility into MFA device changes is essential. Implementing specific logs for customers to monitor in their security information and event management (SIEM) systems can help detect and respond to unusual authentication activities. Additionally, implementing a dual control feature can enhance security by requiring multiple authorizations for critical actions.
3. Protect Tier 0 Assets
Tier 0 assets must be protected, including signing keys and access to critical infrastructure. Implementing endpoint privilege security on federation servers can help safeguard signing keys from credential theft attempts. Furthermore, preventing unauthorized access to Tier 0 assets by limiting access to proxies along with dual controls is crucial.
4. Adopt IdP Best Practices:
- Implement MFA controls before allowing users to change/alter their MFA factors (i.e., you must present a current MFA factor before altering one of your MFA factors enrolled).
- Employ helpdesk verification controls (i.e., the helpdesk may only reset a password once the user has verified their identity through a pre-existing enrolled MFA factor).
- Always check a user’s device enrollment/compliance before allowing a user (especially an administrator) access to your IdP.
- Identify secure zones in your network. Understand network traffic to your IdP that does not meet your expectations. Limit actions that can be taken outside of your Secure Zones.
- Manage IdP administrator accounts in the same way database/domain admin accounts are managed (i.e., through privileged access controls such as rotating administrator passwords, monitoring/isolating admin sessions and enforcing dual access controls to access credentials).
- Monitor trust changes, such as identity provider (IdP) modifications – it’s essential for detecting suspicious activities. Organizations should consider implementing specific logs to track and analyze trust changes, providing valuable insights into potential security breaches.
Final Thoughts (For Now)
A series of mistakes ultimately led to one of the most visible and brand-damaging attacks in years. To mitigate similar attacks, organizations should focus on minimizing the exposure of privileged accounts, implementing strong authentication measures such as MFA, protecting Tier 0 assets, monitoring trust changes and staying updated on evolving cyber threats. It’s a lot to do, but it’s crucial for organizations to continuously improve their security measures and follow best practices to protect themselves in today’s digital landscape.
Andy Thompson is CyberArk Labs’ Offensive Research Evangelist.
Editor’s note: For more insights from CyberArk Labs’ Andy Thompson on this subject and beyond, check out his appearance on CyberArk’s Trust Issues podcast episode, “Analyzing the MGM and Okta Breaches: the Identity Connection.” The episode is available in the player below and on most major podcast platforms.
