What Everyone Got Wrong About the MGM Hack

It was a scene straight out of a casino heist movie, but without George Clooney’s suavity to soften the chaos. Various systems at MGM Casinos–ranging from slot machines, to hotel key cards, to escalators–had been shut down. Guests were locked out of their rooms, while hotel staff scrambled to compensate, taking food orders with pen and paper and cashing out gambling winnings from a fanny pack. One customer said, “I asked them how long this was gonna be, and they said it could be one day, it could be three weeks.”

MGM Resorts, proprietors of some of the most famous hotels and casinos on the Vegas strip, had been hacked. And what happens in Vegas certainly didn’t stay there this time; all of MGM Grand’s Hotels and Casino properties saw outages. Systems as far-flung as New York, Ohio, and Michigan were affected by one breach.

An attack that hinged on a simple vishing call (that’s phishing over the phone) to MGM’s IT desk had snowballed into one of the most notorious ransomware attacks of 2023. Cybersecurity journalists immediately started predicting that the MGM hack would be spoken of in the same breath as the disastrous Uber and Marriott data breaches before it.

In a story this bombastic, in which both the hackers and victims pulled some headline-worthy shenanigans, it can be genuinely hard to know where to focus our attention. But when we look past the sequins and neon, we see that the MGM hack isn’t unique; in fact, it sits at the nexus of several emerging trends.

For one thing, hackers are increasingly gaining access to corporate networks through calls to the help desk, and they’re getting better at it all the time. But we shouldn’t be too quick to blame IT workers. Instead, we need to look at the security gaps that set them up to fail. (And when it comes to MGM’s security, we’re about to find a lot of gaps.)

How The MGM Hack Happened

As with almost every hack, the full details of what happened to MGM will likely never be known–the company has a vested interest in ahem keeping its cards close to the chest.

Even the reporting we do have contains conflicting reports on the incident and the groups and methods involved. Adding to the confusion is the fact that Caesars, another famous casino, suffered a very similar attack at almost the same time, though not necessarily by the same hackers.

As such, we’ll explore both the knowns and unknowns of the MGM attack in order to piece together what seems like a likely–albeit uncertain–timeline of events.

We’ll begin with a behind-the-scenes look at the hack itself. Much of this is drawn from a statement published by alleged members of notorious ransomware group ALPHV (also known as BlackCat), in which they take credit for the hack, explain their actions, and take several potshots at MGM’s security team and corporate leadership.

Of course, we have to take any report claiming to be from a group of cybercriminals with several grains of salt. For one thing, there’s no confirmation that this statement is actually from ALPHV–this was a high profile crime, and more than one statement has tried to take credit. For another thing, these groups are, you know, criminals who lie for a living, and who likely want to protect their trade secrets. (It’s worth saying that we’ll also be treating statements from MGM with a healthy dose of skepticism).

However, the statement is at least realistic in terms of how it describes the process of hacking MGM. Regardless of veracity, then, it can still provide some useful insight into one version of events.

Part one: The vishing call

The MGM attack began when social engineers called MGM’s help desk. They impersonated an employee using information likely sourced from social media and the company website.

It’s unclear what the attacker asked the help desk for–likely a password or MFA reset–but it worked, and they were granted access to the account of a super administrator with advanced privileges across MGM’s systems. (Hence the countrywide shutdowns, and why MGM needed to ‘take offline’ so many disparate components of their own infrastructure to contain the scope of the attack.)

This phone call should have triggered some tough user verification, but according to Bloomberg, MGM was basically using the honor system:

“‘A former MGM employee who was familiar with the company’s cybersecurity policies…said that to obtain a password reset, employees would only have to disclose basic information about themselves–their name, employee identification number and date of birth–details that would be trivial to obtain for a criminal hacking gang.’”

Andrew Martin, Ryan Gallagher, and Katrina Manson–Bloomberg, Sep 15, 2023

Part two: MGM tries to shut out the hackers

According to the purported ALPHV statement, MGM noticed something was amiss when the hackers were “lurking their Okta Agent servers, sniffing passwords.”

MGM’s initial response was to shut down their Okta sync servers, which connected their Okta and Azure systems. But it was too late, and the bad actors “continued having super administrator privileges to their Okta, along with Global Administrator privileges to their Azure tenant.”

In an effort to evict the hackers, MGM next began taking down its own infrastructure, causing chaos for its guests.

The hackers deploy ransomware

The ALPHV statement claims that “No ransomware was deployed prior to the initial take down of [MGM’s] infrastructure by their internal teams.” When MGM failed to communicate with the hackers, they used ransomware to encrypt, “more than 100 ESXi hypervisors in [MGM’s] environment.”

Whether or not that sequence of events is perfectly accurate, what’s not disputed is that MGM refused to pay the ransom. Their competitor Caesars made the opposite choice when they were attacked a week or so earlier, and reported paying $15 million to bad actors to ensure that their customer data wasn’t leaked.

ALPHV’s statement claims that MGM refused to pay not out of a principled stance, but because of “insider trading” that ensured no one at the top would lose money. We’ll let the financial press assess that particular claim, but regardless, the MGM and Caesars hacks have certainly stoked the ongoing debate over whether it’s ethical to pay up in a ransomware attack.

Public fallout and MGM’s losses

After ten days of consistent outages, MGM announced that “all of our hotels and casinos are operating normally.” This is contradicted by a regulatory filing they made 25 days after the initial breach, in which they admitted they were still restoring client-facing systems.

And after 3 weeks, MGM Resorts International CEO Bill Hornbuckle still reported that the whole incident was “totally behind us.”

Unfortunately, the same couldn’t be said for their customers. MGM confirmed that breached customer data included: names, driver’s license numbers, dates of birth, and for a “limited number of customers,” social security numbers and passport numbers. The company offered credit monitoring and identity protection to the people impacted.

It seems MGM’s employees may also have been victimized by this attack. A Nevada-based blogger also reported an MGM employee telling him that the hackers had gotten all of their employment records, from social security numbers to bank info.

The situation for MGM Employees is worse than most of us realize pic.twitter.com/x2Vpy4xGT0

— Jacob Orth (@JacobsVegasLife) September 20, 2023

Without yet accounting for the many lawsuits being levied against them, MGM anticipates around $100 million in revenue loss from this incident, but expects cybersecurity insurance to cover most of that. “I can only imagine what next year’s bill will be,” Hornbuckle quipped in a panel at G2E.

(He later complained about the “staggering” rise in cybersecurity insurance costs).

This attitude, of course, is a big part of the problem. Companies focus more on guarding revenue than client data. They rely on insurance rather than proactively investing in security.

Sara Morrison at Vox asked, “Did prominent casino chain MGM Resorts gamble with its customers’ data?” More and more, it seems like we have an affirmative answer. But the bigger question is whether this hack will have a long-term impact on MGM's–or other companies’-behavior.

Scattered Spider and ALPHV: The Hackers Behind the MGM Attack

It’s worth taking a slight detour to talk about the bad actors behind the MGM and Caesars hacks, since these groups bear a lot of responsibility for the current wave of help desk attacks.

While various reports say it “only took a 10-minute phone call to shut down MGM Resort,” that’s seriously underselling the sophistication of this attack, which combined social engineering and ransomware into a scarily effective combo.

The threat actors known as “Scattered Spider” (also known by, or associated with: Scattered Swine, Oktapus, Octo Tempest, and a variety of other monikers) have been widely blamed for the MGM hack. They’re a versatile and prolific English-speaking group known for their skill in social engineering and SIM-swapping attacks.

Side note: hacker groups don’t name themselves. Instead, they get their names from security vendors who study them, much like viruses or distant stars. The question being, why give your enemies cool nicknames? Aren’t they intimidating enough without adding sunglasses and a leather jacket?

As we already said, ALPHV/BlackCat have also been linked to the attack. They’re a notorious Eastern European ransomware group that have targeted hundreds of organizations worldwide (including Reddit). Their RaaS (ransomware as a service) software is one of the most used ransomware families observed by IBM.

Scattered Spider and ALPHV bring rather disparate skillsets to the table, so the idea that they might be collaborating is concerning to security experts.

Microsoft recently reported on a spate of recent attacks in which hackers use sophisticated social engineering techniques to get a foothold in a network, then use subtle techniques to establish persistence, and finally use their targets’ own EDR and MDM tools to deploy devastating ransomware.

Microsoft theorized that this new combo attack is the result of some type of partnership between members of Scattered Spider and ALPHV. Reuters reported that the specific members involved in the casino jobs call their team “Star Fraud” (the result we get when hacker groups do name themselves).

Regardless of the exact nature of their partnership, as Joseph Cox of 404 Media puts it, “The unlikely bedfellows make powerful partners in crime.”

The Growing Pattern of Help Desk Attacks

One of the most damning aspects of the casino attacks is that the victims were warned ahead of time. Shortly before the MGM attack, Okta reported on “a consistent pattern of social engineering attacks against IT service desk personnel…”

And indeed, this type of attack has been behind a lot of recent high-profile breaches:

• Caesars confirmed that their attack started with their third-party IT desk. It then escalated to ransomware, and their payout of $15 million.

• The 2021 source code leak at Electronic Arts took place when attackers “mimicked an already-logged-in EA employee’s account…and then tricked an EA IT support staffer into granting them access to the company’s internal network.”

• It’s suspected that the recent Clorox hack (a mess even bleach couldn’t clean up) also began with social engineering-and may have been the work of the same group that hit MGM.

IT service desks make a lot of sense as a target for social engineering attacks. The very nature of their job means that they have incredible access and power.

Most importantly, they hold the keys to authentication–over 40% of all help desk tickets are related to password resets. And while passwords are widely acknowledged as insecure, IT can get hackers past tougher authentication methods as well. Okta observed that attackers would ask IT to “reset all Multi-factor Authentication (MFA) factors” for the accounts they wanted to breach.

It’s easy to hear these stories and ask why IT workers weren’t more suspicious. But vishing attackers can be extremely convincing (and they’re getting more convincing all the time), and in a massive company, it’s not as though the person on help desk duty knows everyone else on a first name basis. On top of that, IT desks are often under pressure to solve problems quickly, they aren’t always afforded the luxury of taking things slow when someone calls for help.

The actual problem goes much deeper than IT help desk workers trying to do their jobs, since the judgment of a single person simply shouldn’t be the only failsafe. And, when it comes to preventing these types of attacks, companies are securing the wrong vulnerabilities entirely.

The Conventional Wisdom on Preventing Phishing Attacks

A lot of observers have laid the blame for the MGM hack on poor identity verification methods. In the case of MGM, that’s a fair critique, since it seems like their only verification came in the form of easily-phished information. To learn what a more secure flow looks like, we reached out to an engineer for a third party IT help desk service.

“For anything like password resets, permission changes, or access to sensitive data, we require verification. I wrote an integration with DUO so that we can use Duo push verification if the user has that. If not, we go to SMS (all of our users have contacts that include their cell phone numbers). If neither of those options are available, we generally reach out to the point of contact and have them contact the user and reach back out to us. We document how we verified the user’s identity in the ticket.”

Ryan W, Security Automation Engineer

This is certainly better, but it’s still far from perfect. It defaults back to SMS (“we still can’t get away from that,” Ryan laments), which is vulnerable to SIM-swaps and other man-in-the-middle (MITM) attacks. These are both known tactics of the threat actors that hit MGM.

Okta and Microsoft both recommend a long list of methods to better verify employee IDs. Among others, they suggest:

1. Implement multi-factor authentication. This is good advice, even if it’s just table stakes for a secure organization. If possible, don’t enable weak factors like security questions or SMS.

2. Explore passwordless authentication options. Passwords are one of the least secure authentication methods, and are due for retirement. Even if you can’t get rid of them for your entire company, require that super administrators use more secure methods like biometrics or a YubiKey.

3. Limit the number of super administrators. Microsoft also suggests “Reducing the number of users with permanently assigned critical roles.” Continually updating permissions to practice the principle of least access isn’t easy, but it is a core requirement for Zero Trust security.

4. Use tougher authentication for highly sensitive data. Okta recommends that “privileged applications” should require re-authentication at every sign in.

It’s unsurprising that a lot of these recommendations concern user identification and authentication. At Kolide, we are very much of the opinion that accessing super admin accounts should require more verification than knowing the person’s birthday.

However, these attacks have breached a lot of companies, many of whom did have more strenuous security, like MFA.

As Paul Martini put it on DarkReading:

“Many analysts have become fixated on the idea that MGM could have prevented the incident if only it had been using better identity solutions or stronger methods of verifying user identities…the reality is that identity products alone would not have prevented this attack.”

Paul Martini–DarkReading, Nov 07, 2023

The conversation around the MGM hack is part of a long tradition of security pros focusing on user identity and missing another crucial angle: the user’s device.

How Device Trust Prevents Phishing

It’s clear that bad actors are very good at impersonating employees, using their names, their personal information, and even their voices. But they’re still stuck using their own devices. That’s where device trust comes in.

Device trust is the idea that a user’s device has to be known and in a secure state before it can access a company’s sensitive resources.

Let’s break down that definition. Since Kolide is a device trust company, we’ll use ourselves as an example:

• “Known” means that when you install the Kolide agent, you register your device with it. When you do that, the Kolide service and device agent set up a secret and unique way to identify each other whenever you log in. Crucially, this identifier is unspoofable, so hackers can’t phish it or fake it. (For a more technical explanation of how this works, check out our docs.)

• “In a secure state,” means that the device meets an organization’s security requirements. This could include being enrolled in the company’s MDM, having EDR installed, and a host of other things that are difficult for a hacker to fake.

• “Access to a company’s sensitive resources” is controlled by making Kolide part of user authentication. If their device doesn’t have Kolide or can’t pass its posture checks, it can’t authenticate.

Thus, if MGM had Kolide, the attack would have happened something like this:

1. The bad actors call the IT help desk. They get a password reset or an MFA reset. (So far, so bad.)

2. When they try to log into the vished account, though, they’re stopped. Their device doesn’t have Kolide installed, so it can’t authenticate.

3. They try to install the agent, but their device can’t register with Kolide without approval from IT.

4. Even assuming the hacker is able to install Kolide on their device, they then have to pass Kolide’s compliance checks. This will be a time-consuming process, in which every minute increases the chance that someone (likely the end user being impersonated) notices this suspicious activity.

Both Microsoft and Okta briefly mention device trust in their list of suggestions on preventing MGM-style attacks. Microsoft makes two device-related suggestions:

• “Enforce MFA registration from trusted locations from a device that also meets organizational requirements.”

• “Review recently registered device identities.”

Okta, meanwhile, devotes one sentence:

• “Turn on and test New Device and Suspicious Activity end-user notifications.”

These are both steps in the right direction, but don’t go far enough in preventing intrusions, instead of just responding to them.

For one thing, maintaining a list of “trusted locations” can be hard for a sprawling remote organization, and it’s especially flawed when bad actors are known to use VPNs to mask their location.

End-user notifications for new devices are worth having. But by the time someone checks their email, it might be too late. If you’re reviewing already registered devices, then it’s definitely too late.

To put it in the simplest terms possible: an unknown device shouldn’t be able to authenticate in the first place.

Microsoft and Okta’s offhand mentions of device trust among a sea of user verification suggestions indicates how badly overlooked this aspect of security is. Device trust is way more than a helpful asterisk or something that’s “worth a mention.” It’s a crucial factor in a multi-factor authentication flow.

And it’s the missing key that could have prevented many of the attacks we’ve mentioned, including MGM’s.

Place Your Bets on Device Trust

Social engineers, stage magicians, and corporate CEOs all share one key tactic: misdirection.

They want audiences and victims to look at the shiny race car, the rosy profit report, or the “urgent phone call” from a high-ranking employee–anything except their own sleight of hand.

In the case of the MGM hack, the attention has focused on the phone call and the hapless help desk worker. But the deeper story is about a company that didn’t give its own IT department the tools to identify a hacker, or to limit the damage once one was inside.

Lackluster ID verification isn’t at the core of every social engineering attack. If you refocus your vision away from the headlines, you can notice that they’re missing something obvious–the very device you’re reading them on.

Want to read more security stories like this one? Subscribe to the Kolidescope newsletter!