Speculation around the precise vectors and network architectures of some of Las Vegas’ biggest casinos continues in the wake of a brace of ransomware attacks on Caesars Entertainment and MGM Resorts – as the latter continues a piecemeal recovery of impacted systems.
One thing that appears increasingly likely is that attacks involved social engineering breaches to take over highly privileged Okta Super Administrator accounts. This week Okta’s Chief Security Officer David Bradbury said five of the identity management firm's clients, including MGM and Caesars, had fallen victim to ransomware groups since August.
The Stack also surfaced an earlier interview with MGM's then-head of security who said of Okta MFA rollout that “I think our biggest challenge was, and this is something we learned the hard way, was the password reset."
Bradbury did not name the other victims, in an interview with Reuters.
Caesars: What happened?
Caesar’s said in a September 7 filing with the SEC that it had identified “suspicious activity in its information technology network resulting from a social engineering attack on an outsourced IT support vendor used by the Company” admitting that although customer-facing operations were unaffected, it had suffered a serious data breach.
It did not name the vendor.
Caesars hinted in the filing that it had paid a ransom, saying: “We have taken steps to ensure that the stolen data is deleted by the unauthorized actor, although we cannot guarantee this result” (The WSJ puts the figure at $15 million, half an initial $30 million demand.)
MGM Resorts: Getting back on its feet
MGM Resorts’ hotel websites were back up this week, with guest Wi-Fi also working. It is now taking bookings through third-party sites but warned of continued impact from the attack, telling customers this week that “visitors to our Las Vegas and regional properties may have interruptions in their ability to use Slot Dollars and FREEPLAY.
“MGM Rewards points currently are [also] not available for use…”
A group known as “Scattered Spider” told Reuters that it had stolen six terabytes of data from the two hotels. The ALPHV ransomware group meanwhile has claimed the MGM attack. (With affiliations between malware writers, initial access brokers and ransomware groups nebulous and criminals prone to boasting, precise attribution is hard.)
ALPHV claims its attack on MGM meanwhile involved gaining admin credentials on its Okta SSO platform as well as its Azure cloud tenant. After failing to persuade MGM to negotiate, it then hit ~100 ESXi hypervisors with ransomware on September 11, the group has claimed.
MGM: Longstanding Okta customer
The comments by both Okta’s CSO and ALPHV put the spotlight back on a late August blog by the identity management software company in which it said customers had “reported a consistent pattern of social engineering attacks against their IT service desk personnel, in which the caller’s strategy was to convince service desk personnel to reset all MFA factors enrolled by highly privileged users. The attackers then leveraged their compromise of highly privileged Okta Super Administrator accounts to abuse legitimate identity federation features that enabled them to impersonate users within the compromised organization.”
Precisely what this means is still somewhat unclear. Even Okta seems unsure as to the exact initial attack path – the social engineering was not the be-all and end-all of the attack; other elements had to fall into place too. The attackers, in these incidents, Okta said tentatively, “appeared to either have a) passwords to privileged user accounts or b) be able to manipulate the delegated authentication flow via Active Directory (AD) prior to calling the IT service desk at a targeted org.”
(If you have a more precise idea of the attack path and how these attacks unfolded and how to minimise the risk of such paths, comments welcomed.)
MGM has worked with Okta for many years. In 2018 the casino giant’s then-Executive Director of Security Operations, Elena Seiple, described the company as having already rolled out Okta MFA, saying that “I think our biggest challenge was, and this is something we learned the hard way, was the password reset. People kept forgetting their passwords and forgetting how to login to Okta, because you have to go to the portal, so that was the challenge. Implementing DSSO, or desktop single sign on, helped alleviate that challenge. Then we also did some things like, in big letters put how to reset your password on the Okta homepage because you think people would know, but you [need to] make instructions and everything as simple as possible…”
Okta has since urged customers to:
- Protect sign-in flows by enforcing phishing-resistant authentication with Okta FastPass and FIDO2 WebAuthn.
- Configure Authentication Policies (Application Sign-on Policies) for access to privileged applications, including the Admin Console, to require re-authentication “at every sign-in”.
- If using self-service recovery, initiate recovery with the strongest available authenticator (currently Okta Verify or Google Authenticator), and limit recovery flows to trusted networks (by IP, ASN or geolocation).
- Review and consolidate the use of Remote Management and Monitoring (RMM) tools by help desk personnel, and block execution of all other RMM tools.
- Strengthen help desk identity verification processes using a combination of visual verification, delegated Workflows in which helpdesk personnel issue MFA challenges to verify a user’s identity, and/or Access Requests that require approval by a user’s line manager before factors are reset.
- Turn on and test New Device and Suspicious Activity end-user notifications.
- Review and limit the use of Super Administrator Roles - Implement privileged access management (PAM) for Super Administrator access, and use Custom Admin Roles for maintenance tasks and delegate the ability to perform high-risk tasks.
- All Administrative roles in Okta can be constrained to a specific group. We recommend using Custom Admin Roles to create help desk roles with the least privileges required in your organization, and to constrain these roles to groups that exclude highly privileged administrators.
- Enforce dedicated admin policies - Require admins to sign-in from managed devices and via phishing resistant MFA (Okta FastPass, FIDO2 WebAuthn). Restrict this access to trusted Network Zones and deny access from anonymizing proxies.
