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 (to the point of suing the FTC in order to block a probe into the incident).
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. We’ll be drawing from timelines made by news sources like The Wall Street Journal. Much of the specifics are also 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 to help fill in the gaps in the official version of events.
Part one: The vishing call
The MGM attack began when social engineers called MGM’s help desk.
The Wall Street Journal reported that, “The person on the line said they were an employee, but had forgotten their password…They gave some personal information over the phone. It all checked out.”
As for what “some personal information” entails, 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
The Wall Street Journal went on to report that, “A few minutes later, the real MGM employee received a notification that his password had been reset and reported this to the IT department. By then, it was too late.”
Part two: MGM tries to shut out the hackers
The initial call happened on Friday. Reports vary in terms of when MGM truly noticed that something was amiss (Saturday evening, at the earliest).
But regardless, MGM didn’t first take action until that Sunday. Their initial response was to shut down their Okta sync servers, which connected their Okta and Azure systems. But it was too late, and ALPHV’s statement said that they “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 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 reported an MGM employee telling him that the hackers had gotten all of their employment records, from social security numbers to bank info.
Without yet accounting for the many lawsuits being levied against them (fifteen consumer class-actions, at their last count), 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).
There has been a significant backlash in the press for MGM’s handling of this attack. Sara Morrison at Vox asked, “Did prominent casino chain MGM Resorts gamble with its customers’ data?” 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.
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.
In 2023, Microsoft reported on a spate of 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).
Even with the recent arrest of a British teenager connected to the hack, not much has been confirmed about the group’s formation, and they continue to target new victims. 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 (all the more reason to use an Enterprise Password Manager), 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 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:
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.
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.
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.
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. Accessing super admin accounts should certainly 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
Our own solution, 1Password Extended Access Management, works in part through securing user identities, like offering passwordless authentication and app insights. But 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.
Let’s break down that definition. Device trust is also a core aspect of 1Password Extended Access Management, so we’ll use ourselves as an example:
“Known” means that when you install the 1Password Extended Access Management agent, you register your device with it. When you do that, the agent sets up a secret and unique way to identify the device 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. 1Password Extended Access Management’s device trust solution lets admins choose from a library of over 100 policy checks that determine whether or not a device is considered secure.
“Access to a company’s sensitive resources” is controlled by making 1Password Extended Access Management part of user authentication. If their device doesn’t have the agent or can’t pass its posture checks, it can’t authenticate.
Thus, if MGM had 1Password Extended Access Management, the attack would have happened something like this:
The bad actors call the IT help desk. They get a password reset or an MFA reset. (So far, so bad.)
When they try to log into the vished account, though, they’re stopped. Their device doesn’t have 1Password Extended Access Management installed, so it can’t authenticate.
They try to install the agent, but their device can’t register without approval from IT.
Even assuming the hacker is able to install our agent on their device, they then have to pass the various 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 things like new devices or breached passwords 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 extended access management
Stage magicians and social engineers share one key tactic: misdirection.
They want audiences and victims to look at the fluffy white rabbit 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 know more about how device trust can keep your team safe from phishing attacks? Reach out for a demo!
Rachel Sudbeck
Content Associate
Tweet about this post