MGM aftermath: A New Era of Corporate Cyber & Identity Threats

In our last post, we discussed a trend in identity-based social-engineering attacks that has become so commonplace; it's even got IDP vendors posting warnings publicly to their users about it. Details are still coming to light, but it appears this attack has commenced on its biggest victim yet – a colossal $33 billion empire, MGM.

For nearly a week now, in an unprecedented cyber onslaught, MGM has been under siege, rendering the entertainment empire’s data services inoperable. The assailants, a ransomware group dubbed ALPHV, infiltrated MGM's digital fortress by exploiting social engineering tactics to gain the keys to the kingdom, and subsequently, holding those keys for ransom. According to The Record, hackers claimed they had access to MGM Resorts' Okta and Azure environments starting on Friday and gained administrator privileges, allowing them widespread access to the company's systems.

(Not to mention the week prior, yet ANOTHER similar attack was carried out on Caesar’s!)

It's a grim reminder that no company is immune to a novel breed of attacks that can be carried out with astonishing simplicity – by some reports, with an online search, followed by a 10 minute helpdesk call! In this blog, we outline how an ITDR solution can help organizations plan for and be prepared for the potential scenario that played out with MGM. 

The Unveiling of MGM's Digital Heist

For those of you who haven’t reviewed the details, ALPHV's audacious breach of MGM's cyber defenses unfolded in three effortless steps:

Step 1: The LinkedIn Trail

Their journey commenced with a LinkedIn search for an MGM employee. Personal information scavenged from the employee's profile gave them an identity to launch the step with.

Step 2: The Help Desk Charade

With an employee's identity in hand, ALPHV initiated a call to MGM's company-wide IT help desk. They masqueraded as the employee, concocting a tale of a locked-out account that demanded urgent resolution. The help desk, lacking a proper procedure, granted access to the account they believed belonged to the distressed employee ALPHV had identified just minutes earlier.

Step 3: The Breach

The consequences were swift and severe. The hack crippled MGM's operations, causing delays at check-in counters, errors flashing on slot machines, parking systems going dark, and an inaccessible company website. MGM's booking site was rendered useless, directing frustrated customers to seek support.

Pointing Fingers: A Complex Culprit

While it might seem convenient to place blame squarely on the help desk agent who succumbed to the attack in a mere ten minutes, the culpability does not rest with a single individual's training or judgment. 

The organization lacked a structural safety net for situations like these – no mechanism to verify the caller's identity when conventional methods failed. The help desk agent had no option but to rely on trust and intuition.

Once the attackers are in, or even beforehand, there is also the possibility of complimentary attack methods which only increase the potential damage (in the MGM case, agent password sniffing, adding additional IDP and users, etc).

Why Almost Any Business Is Vulnerable

This unsettling episode at MGM is not an isolated incident. Businesses across the globe are taking steps beyond traditional password security by implementing multi-factor authentication (MFA) devices, containing private codes necessary for access. These measures have successfully thwarted conventional password hacks in the past. 

However, they are vulnerable to social engineering attacks (and as a side note, some are saying now that certain MFAs are no longer MFAs at all).

For MGM, profits lost may be at least $25 million per day as mentioned in an earnings report… but what about the other costs? Employees for example, they naturally wonder how they’ll get paid if their company’s software systems are down. Customers may wonder how safe it is to use their credit cards, let alone share other personal information with a compromised entity. How will falling victim to this attack affect cyber insurance coverage premiums, even eligibility?

Addressing IDP-focused Attacks with Trustle 

With IDP-focused attacks now the new normal, organizations need to mitigate their risk of falling victim. To help mitigate against such attacks, businesses are implementing just-in-time (JIT), zero-standing (ZSP) to least-privileged access (LPA) solutions, such as Trustle’s innovative ITDR (Identity and Threat Detection & Response) suite.

By keeping user accounts at ZSP until JIT, LPA is needed, stolen credentials will be a lot less useful to attackers. Trustle provides time bound access and workflows to keep your users at ZSP until JIT, LPA is needed.

When your users are in a least-privileged access (LPA) state after requesting just-in-time (JIT) access, you need to ensure those people should indeed have that access. Trustle helps you audit your users and permissions, and ensure LPA is in fact LPA by comparing permissions across teams, departments and titles, verifying that all assigned permissions are actually being used.

By leveraging Trustle’s ITDR solution [even with just a subset of the most critically privileged users], you can make sure that only authorized, legitimate users have access to critical systems. And even if least privilege is granted, the impact of a potential breach is minimized. 

Here’s an example of how Trustle can prevent vertical, as well as lateral movement in an attack scenario similar to MGM’s: 

1. Fast forward to a users’ credentials being stolen, via phishing, social engineering, or any other method. The bad actor now has an identity to login with.

Since Trustle keeps this user (and all users) at zero standing access to all resources until access to these resources are needed, this bad actor must request least-privileged access (LPA) to additional resources to move around and do damage.

2. As the organization mandates the only way to gain LPA is via Trustle (ie, helpdesk doesn’t even have the ability to grant access) the bad actor must request privilege escalation through Trustle’s Slack or web app interface.

Once the bad actor makes the LPA request, the request is sent to their manager, who must approve it before the bad actor, impersonating the legitimate user, gains access to it.

3. The manager is notified of the request access via Slack, email, or the Trustle web app. Within the request, Trustle has flagged the request with [one or more] of these Trustle detected identity-based anomalies:

• MFA settings for this identity have recently been modified
• There have been recent failed logins against this identity
• The access request creation time is outside of the identity owner’s normal working hours
• The requested permissions have never been requested before
• The IP requesting the access has never been used by the identity owner before
• The IP is coming from a known anonymizing proxy IP
• The requesting user agent has never been used by the identity owner before

4. The manager, seeing the anomalous nature of the request:
5. 1. Does not grant the requested access
   2. Responds directly through Trustle to immediately remove all LPA access the user has
   3. Responds directly through Trustle to alert INFOSEC, IT, and SIEM team members of the incident

At this point, the manager has not only denied the additional requested access, but also disabled all access to all existing resources, and alerted the greater team to the incident. With the identity the bad actor is utilizing neutralized, the manager can take manual steps to verify the legitimacy of the identity and the request.

Setting up Trustle takes less than 30 minutes, and can immediately provide value by helping you keep your users at ZSP until LPA is needed, as well as help identify who your users are, what access they have, and how they got it. For a free evaluation or demo, click here to speak to one of our experts.