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.)
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.
Who exactly hacked MGM?
This is a surprisingly difficult question to answer, partly because there’s no standardized naming system for hacking groups.
The MGM attack has
commonly been attributed
to the hacker groups Scattered Spider (which sometimes goes by UNC3944,
Muddled LIbra, and StarFraud) and ALPHV (which is sometimes known as
BlackCat and Noberus).
To complicate things further, it’s not clear if the two groups
collaborated on this hack, if Scattered Spider merely used ALPHV’s
ransomware, or if one group attacked MGM while the other hacked Caesars.
We’ll go into a little more detail on them later, but for now, in this
timeline, we’re citing a report attributed to ALPHV specifically; when
we’re referencing that source, we’ll be referring to them as such.
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
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 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.
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.
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.
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?
Crowdstrike to Hackers
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.”
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.
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.
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.
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:
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 Kolide installed, so it can’t
authenticate.
They try to install the agent, but their device can’t register with Kolide without approval from IT.
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:
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.
Device trust is like Gandalf. Which makes hackers
the Balrog–dangit, now WE made them look cool.
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.
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.
Damage
caused to a car from fragments of a Patriot missile interception with a
rocket launched by Hezbollah in Lebanon towards the Biriya Forest in
northern Israel, March 28, 2024. 
Hamas and its terrorist allies remain deeply entrenched and ready to fight in Rafah