The MGM Breach and the Role of IdP in Modern Cyber Attacks

A deep dive into the recent MGM breach and our insights into the actor behind the attack and possible mitigations.

The recent security breach at MGM Resorts highlights the rising risk of cyberattacks and how easily attackers can assume and misuse someone's identity. Regardless of size, every business should enhance its identity security by implementing additional protective measures.

According to details released to the public, the attackers disrupted casino operations and may have accessed MGM's sensitive data. Reports indicate the breach disrupted critical operation infrastructure. As a precaution, the company temporarily halted some systems for investigation and risk mitigation. This situation could pose challenges to MGM's reputation and financial standing, and there are concerns about potential data misuse.

In this post, we will present an outline of the MGM breach and our insights into the actor behind the attack. Additionally, we will demonstrate how attackers could abuse your identity provider (IdP), such as Okta, to gain access to your network and bypass multi-factor authentication (MFA). Finally, we will suggest solutions to this issue, specifically just-in-time access (JIT) and FIDO2, and how they could have helped MGM mitigate the disruption and possible damage caused by the breach, or even avoid it completely. 

The MGM breach

Last Monday, MGM announced on their official X (formerly Twitter) account that they had "recently identified a cybersecurity issue affecting some of the company's systems." MGM initiated an investigation immediately after detecting the issue. Even after attempts to contain and mitigate the threat — including shutting down systems and servers — attackers claimed they still had control within the network.

In a statement released a few days ago, the attackers claimed to have dumped MGM's domain controller hashes and exfiltrated more than 6 TB of organizational and customer data. They stated that they had initially tried to get in touch with MGM using a victim chat and emails. They claim that after receiving no response from MGM, they deployed ransomware and encrypted more than 100 ESXi servers. Such damage has not been officially confirmed by MGM or any other authorities.

As is common in cybersecurity breaches, many details about the breach remain unclear. One such unknown is how the attackers initially gained access to the MGM network. It appears that the hackers obtained an employee's information through social network reconnaissance techniques and then impersonated that employee in a call to MGM's IT help desk. It is unknown whether the attacker turned off or bypassed the MFA, or if it was disabled in the first place. In any case, getting beyond MFA allowed them to acquire credentials to access and subsequently infect the systems.

Breach timeline

Drawing from details publicly revealed so far, we understand the MGM breach likely occurred in early September 2023. Below is a comprehensive timeline based on information from public sources.

• Sometime prior to September 11, 2023: Attackers gained access to the MGM Resorts network.
• September 11: MGM Resorts experiences outages in its systems. The company initially reported the outages are due to a technical issue and that they were “working diligently to determine the nature and scope of the matter.”
• September 12: MGM Resorts issued a second statement reporting that all of its “resorts, including dining, entertainment, and gaming,” were “still operational.” Customers reported several issues with hotel facilities including problems with the online booking systems and non-functioning slot machines. The main MGM website was reported to be down.
• September 14: Reuters reported that the hacking group Scattered Spider was behind the attack. The group claims to have stolen data from the MGM loyalty program database, including driver's license and social security numbers. MGM Resorts confirmed the breach in a statement. The company said they would continue to work to resolve the cybersecurity issue. 
• Sometime between September 11 and September 17: Attackers deployed ransomware on the MGM network. 
• September 20: MGM Resorts announced that it had restored service to all of its systems.

The threat actor

The threat actor behind this disruptive attack is probably Scattered Spider, also known as Roasted 0ktapus and UNC3944, a relatively new hacking group that rose to prominence in 2022. They quickly gained a reputation for being a skilled and sophisticated group, and were able to successfully breach numerous enterprise organizations. Scattered Spider is known for using social engineering techniques to gain access to corporate networks and is believed to be a transnational group, with members from multiple countries. They have been linked to a number of other high-profile cyber attacks including attacks on Caesars Entertainment, Colonial Pipeline, Twilio, Cloudflare and more.

According to a message published on a dark web forum, Scattered Spider is an affiliate of the BlackCat/ALPHV ransomware group, which means that they have access to BlackCat/ALPHV ransomware and infrastructure. In return, Scattered Spider is likely paid a commission for each victim they successfully compromise. Another way to think about this collaboration is the pay-per-install model — for every installation (aka victim), Scattered Spider receives a commission, with the rest of the money flowing to APLHV. 

Scattered Spider is highly skilled in cloud operations, particularly within AWS and Azure, showcasing deep expertise in cloud technologies and modern IdPs. In a previous attack reported by Group-IB, the group targeted employees of companies that are Okta customers. For example, they sent text messages with links to phishing sites that mimic Okta authentication pages of the targeted organizations in order to bypass the MFA mechanism and get direct access to the victim’s environment. Once they gained access to these servers, they were able to escalate their credentials and acquire admin accounts. 

In another example reported by Mandiant, the attackers gained access to an Azure admin account using phishing techniques similar to those used before. They used built-in Azure diagnostic extensions for information gathering and exploited the serial console functionality to obtain an administrative command prompt within an Azure VM. From this point, the attacker could deploy any kind of attack from within the organization.

Given that Scattered Spider is highly familiar with bypassing IdP and MFA and has exploited these mechanisms for their cloud-based attacks, we've decided to focus on an in-depth analysis of methods that leverage IdP takeover for an attack, from bypassing the entry MFA to pivoting to other parts of the organization.

IdP takeover

Although the specifics are not entirely clear, it seems likely from the evidence that Okta was breached. In addition, from past behavior in breaches attributed to this group and the attacker’s statements, it is plausible that Okta was used to pivot and laterally move to other services and parts of the organization.

In this section, we’ll examine the known techniques that attackers use to do this, and which ones may have been leveraged in this case.

Evidence and context

As with every breach, exact details are scant, but we can look at the breadth of available research, reports on similar cases, and the available information regarding this breach to highlight approaches attackers could have (and may have) taken to breach the victim’s Okta environment. We stress that our analysis is speculative — we highlight possible courses of action rather than actions known to have definitely taken place.

The MGM breach did not happen in a vacuum. As Okta’s chief security officer David Bradbury said to Reuters in an interview following the breach, "We've seen consistently over the past six to 12 months, a ramp up in these types of attacks,” referencing the attacks by ALPHV and Scattered Spider. This references the August 31 alert that Okta issued on cross-tenant impersonation techniques and is similar to what we’ve seen in the attacks experienced by Twilio, Cloudflare (which blocked the attack) and others. We applaud the thoroughness and transparency of these companies in sharing extensive technical information, which enables us to learn much more about the behaviors of such groups and make informed speculations about the possible techniques used in the MGM breach.

Bypassing MFA, once and for all

The first step in gaining access is to reach the stage where MFA is required. This is done either by having passwords to privileged accounts (from password leaks, for example) or by manipulating the delegated authentication flow via Active Directory (AD). In the case of MGM, attackers allegedly found an employee on LinkedIn and called the help desk (phishing via voice is sometimes referred to as “Vishing”).

Getting past the entry MFA

Once initial login is achieved, the attackers face the challenge of MFA, a central part of good identity security. But as these attacks show, it is not impenetrable. In this case, the attackers may have bypassed MFA in the same voice call by getting an MFA code or resetting an MFA device. In other cases, we’ve seen attackers bypass MFAs in other ways, including phishing sites. A report by Global-IB and the disclosure by Cloudflare detail one such way: by using a targeted phishing site and sending time-based one-time password (TOTP) codes back to the attacker.

Once they bypass the entry MFA, attackers receive access to the Okta console; if the user is an administrator, the attackers gain access to the administrator console.

Bypassing MFA persistently

From the administrator console, if they have super administrator privileges, an attacker can easily turn off MFA requirements, add additional MFA devices or reset MFA devices, effectively bypassing all IdP-based MFA protections.

• Turning off MFA requirements or making them optional circumvents login protection for the attacker. To avoid detection, the attacker can even set up conditions that enable them to bypass MFA while still giving innocent users an MFA-based login flow.
• Resetting MFA devices enables the attacker to register their own MFA device once they access a user’s console, either with the plaintext password or by leveraging techniques that we’ll describe later.
• Adding an additional MFA method allows attackers to register their own devices with that method (after they log in with a password or otherwise).

Sometimes an attacker will log in with their own MFA rather than fully bypass it, as the authentication method can be configured to appear in the claim and then be verified by an application.

From the "Multifactor" page in the Okta administrator console – the attacker can remove or modify the policy that requires MFA

Pivoting with a malicious identity provider

To access other users’ Okta accounts, the attacker can exploit some known techniques. One of these, highlighted in the aforementioned alert notice from Okta, uses the Org2Org functionality in Okta.

The threat actor was observed configuring a second Identity Provider to act as an "impersonation app" to access applications within the compromised Org on behalf of other users. This second Identity Provider, also controlled by the attacker, would act as a “source” IdP in an inbound federation relationship (sometimes called “Org2Org”) with the target.

(Okta Website)

This technique requires super administrator or org administrator permissions, the highest permissions in an Okta organization. The attacker sets up their own IdP with shadow users mapped to the victim Okta’s users and sets up their malicious organization as a SAML 2.0 IdP provider to the victim Okta. This technique can be used with any SAML provider, but Okta is convenient.

Tenable Cloud Security research team described this technique in a vulnerability report to Okta, submitted in March 2023. The vulnerability enabled the attacker to reveal plaintext passwords, which we’ll explain in the next section. This was marked as a duplicate of a reported issue from 2018.

Gaining plaintext passwords

According to information posted by the attackers, they “had been lurking on [the] Okta Agent servers sniffing passwords of people whose passwords couldn't be cracked from their domain controller hash dumps.”

The term “Okta Agent” could theoretically refer to one of five Okta agents used to integrate with Active Directory or LDAP (in this case, AD seems likelier). One likely option would be the Okta Active Directory password sync agent: “A lightweight agent installed on your domain controllers that will automatically synchronize AD password changes, send to Okta, and keep your user’s AD passwords in sync with the apps they use.”

From this we can infer that controlling that agent could enable an attacker to sniff plaintext passwords.

https://www.okta.com/resources/whitepaper/ad-architecture/

The plaintext password reveal discovered by Tenable Cloud Security

This password synchronization opens the door to another technique (not categorized as a vulnerability by Okta): Creating a malicious application that, running the system for cross-domain identity management(SCIM) password synchronization procedure, syncs plaintext passwords.

There are other ways to expose plaintext passwords, including through a bug that the Tenable Cloud Security research team disclosed to Okta in March 2023. That bug enabled an attacker to exploit a race condition in the Okta user console to reveal the user’s plaintext password for an application.

Since the bug only enabled a user to reveal their own plaintext password, we combined it with the Org2Org technique described above to detail how an attacker can access every user console and exploit the bug. Okta indicated that they were not interested in remediating this bug.

Attackers can leverage these techniques to pivot to applications managed by Okta, including cloud applications. In the MGM attack, much of the focus has been on what appears to be on-premises workloads such as ESXi hypervisors. Yet, the attackers claim to have also gained global administrator privileges to MGM’s Azure tenant. They may have achieved this by accessing Azure through an Okta application or password obtained from the compromised Okta account (depending on the setup). If that is indeed the case, then a key component of that escalation was that users with permanent Azure global administrator entitlements were accessible through Okta.

As mentioned, this section is only intended as an overview of known techniques — discovered by researchers or used by attackers — that may enable an attacker to achieve the effects claimed in the MGM breach. We are not at this time aware of evidence that any of the aforementioned methods were used in the breach.

Authentication & authorization guardrails

Knowing that IdPs generally (and Okta specifically) are increasingly popular targets for attackers, and understanding that security measures like MFA are not bulletproof and can be bypassed, we need to adopt approaches that will prevent the malicious misuse of static permissions.

Temporary access approaches have emerged as a vital mitigation strategy in data access management. Instead of providing users or entities with indefinite access to systems or data, temporary access ensures that permissions are granted only for a specific period, after which they expire or need renewal. This strategy is particularly useful for situations that demand elevated privileges temporarily. By confining access to a predetermined time window, the potential for unauthorized or malicious activities is significantly reduced. If any credentials are compromised, the damage will be limited by the transient nature of the access.

We describe below possible temporary mechanisms that are valuable and could potentially reduce the impact of — or even prevent — a breach.

Just-in-time access

In the context of cybersecurity and access management, JIT refers to temporary access to resources only when needed and only for the duration required. The principle can be contrasted with traditional static permissions, which grant constant (and sometimes overly broad) access.

How JIT can benefit organizations:

• Limit exposure: By only granting access when required, JIT reduces the time windows during which a malicious actor could exploit access rights. If an organization implements JIT access controls, even if an attacker compromises credentials, they might find themselves with limited or no access.
• Reduce attack surface: Fewer persistent permissions available means fewer opportunities for attackers to exploit. This could potentially mitigate the damage or scope of a breach.
• Dynamic access control: JIT access management typically comes with adaptive authentication processes. For instance, if an employee or system requires access to sensitive data outside their usual patterns, the JIT controls could trigger additional authentication steps. This could help organizations detect or prevent unauthorized access during a breach.
• Improve auditing and monitoring: Under JIT, access events are more conspicuous because they occur in response to specific requests, which can make irregularities easier to spot. If an organization has JIT logging, access requests at odd times or from odd locations could be a red flag.

To be clear, while JIT can offer substantial security benefits, it is not a silver bullet. JIT access needs to be part of a comprehensive cybersecurity strategy.

Azure privileged identity management

Azure privileged identity management (PIM) is a service offered within Microsoft's Azure cloud. Instead of granting individuals perpetual elevated access, PIM allows for JIT privileged access so users are given the necessary permissions only when needed and for a defined period. PIM provides a means to monitor, audit and manage the activities of privileged accounts, ensuring that all high-level operations are subject to scrutiny.

FIDO2-compliant security keys

FIDO2 is a modern web authentication standard that uses physical devices (such as YubiKeys) for authentication. It offers a significant leap forward in securing user identities and preventing attacks like vishing. FIDO2 adds another layer of physical authentication to verify user identities. This means that even if an attacker successfully tricks a user over the phone, they would still be unable to access accounts without the necessary physical keys. By reducing the value and utility of stolen user information, FIDO2 can significantly mitigate the risks associated with breaches and the subsequent threats of vishing.

How we can help — Tenable Cloud Security JIT

The Tenable Cloud Security JIT capability reduces the cloud attack surface by offering temporary, as-needed access to sensitive resources. As an integral component of the Tenable cloud-native application protection platform (CNAPP), JIT ensures that elevated access is granted only when truly needed, curbing the risk associated with standing privileges. Advocated by industry thought leaders, JIT access control streamlines the process of requesting and granting elevated access, with minimal disruption to user workflows. A key element of Tenable Cloud Security's JIT feature is the platform’s best-of-breed cloud infrastructure entitlement management (CIEM) capabilities, which ensure optimal least privilege access to resources based on deep multi-cloud visibility into identities and permissions. Tenable’s self-service JIT portal simplifies the approval process and ensures that the given privileges align with business justifications.

By enabling teams to monitor and report on elevated sessions, authorization processes and more, Tenable Cloud Security JIT boosts transparency and accountability, and aids in adherence to regulations like PCI-DSS, GDPR and HIPAA. Tenable CNAPP, including JIT access, provides a holistic agentless security solution for AWS, Azure and GCP that automates cloud security from development to deployment. This comprehensive approach enables organizations to efficiently identify, prioritize and address security gaps and accelerate security collaboration in their public cloud environment.

Conclusion

The MGM breach is just the latest in a string of attacks targeting identity providers and using them as a vector to move laterally within an organization. This incident demonstrates, once again, that identity is a key perimeter in cloud environments and is currently extensively targeted. It is a wake-up call for modern organizations to ensure their cloud security solutions are covering the identity threat vector.