top of page

Caesars Entertainment Breach 2023: Social Engineering, Vendor Risk, and Extortion

Sep 23, 2023
4 min read

Updated: Aug 31

Three weeks before MGM went dark, the same attackers called a help desk that worked for Caesars, and walked away with the loyalty database. No outage, no headlines at first, a negotiated ransom, and zero guarantees the data was ever deleted.


Case type: Social engineering / vendor compromise / extortion

Identified: Sept 7, 2023  Disclosed: Sept 14, 2023

Attribution: Scattered Spider (UNC3944)





On August 18, 2023, attackers associated with Scattered Spider targeted the help desk of an outsourced IT support vendor used by Caesars, according to court records later filed in the FBI's ransom-tracing case and Caesars' own notice to state regulators. The technique matched the group's signature: voice phishing, a convincing story, and support staff talked into bypassing multi-factor authentication. The reported initial access did not require deceiving a Caesars employee. The attackers targeted an outsourced IT support provider with access into Caesars' environment.


By August 23, they had reached the crown jewels: the Caesars Rewards loyalty program database, containing sensitive information including driver's license numbers and Social Security numbers for a significant number of members. Then the attackers made their demand: $30 million not to publish it.



Caesars discovered the intrusion on September 7, twenty days after entry, when its investigation determined the loyalty database had been copied. The company activated incident response, brought in outside cybersecurity firms, and notified law enforcement and state gaming regulators. According to reporting by Bloomberg and The Wall Street Journal, it also negotiated the demand down and paid roughly $15 million. Caesars has never confirmed the figure. Its September 14 SEC filing says only that it took steps "to ensure that the stolen data is deleted by the unauthorized actor," followed by seven words that say everything: "although we cannot guarantee this result."



Customer-facing operations were never disrupted. No ransomware was deployed. For most of the public, the breach generated far less visible disruption than the MGM incident that followed.



The attackers never called Caesars


Caesars' internal controls were only part of the security picture, because the reported initial access occurred through an outsourced IT support provider. An outsourced IT support vendor held the kind of access that could reach the loyalty database, and that vendor's caller-verification process was, in practice, part of Caesars' security perimeter: unexamined, untested, and effective right up until someone tested it.


The attackers never called Caesars. They called someone Caesars trusted.

Vendor risk is usually discussed as a data-storage problem: what happens if a supplier holding your data gets breached. Caesars shows the sharper version. A supplier with access to your systems becomes part of your attack surface, and weaknesses in its identity-verification or access processes can become pathways into your environment.




The same call, three weeks apart, two different endings


The MGM attack that followed used the same technique against MGM's own internal help desk, and MGM refused to pay. The result was ten days of visible disruption and a roughly $100 million hit the company itemized in a securities filing. Caesars reportedly paid, and its customer-facing operations were not materially disrupted. MGM did not pay and experienced significant operational disruption. It is tempting to read that comparison as a verdict on paying. It shouldn't be. Those outcomes do not establish that the ransom decision caused the difference. Here is what the payment bought, and what it didn't:



The ransom was reported before the breach was even formally disclosed. And in a coda the attackers didn't plan for, the FBI later traced the payment across blockchains and froze millions of it. Caesars experienced a far quieter operational aftermath than MGM. The payment did not guarantee an ending.





Not one decision. A set of conditions.


The question organizations should ask isn't "how did the vendor get fooled?" A more useful question is: what conditions allowed one compromised support process, at a different company, to lead to weeks of unauthorized access and exposure of sensitive customer data?





Their desk answers the phone. Your data answers for it.


Most third-party risk programs focus on what vendors store. The Caesars breach argues for a second question that matters at least as much: what can this vendor touch? An IT support vendor rarely holds your data at rest, but it may hold the keys to everything: reset rights, remote access, privileged tooling. For every vendor with access, organizations should know:



Caesars' filing notes the company took steps to ensure the vendor "has implemented corrective measures." That sentence, arriving after the breach, is the whole lesson in miniature: the time to examine a vendor's help desk is before an attacker does.









“Your Vendor's Help Desk Is Part of Your Attack Surface.”


The Caesars breach is usually remembered as a footnote to MGM's, the casino that paid and stayed quiet. It deserves its own reading. It shows that access outsourced is risk outsourced in name only, that the reported timeline placed roughly twenty days between initial access and discovery, and that paying a ransom does not guarantee resolution.


Together with MGM, it also offers something rare: the same attack, run twice, with both endings on the record. Neither ending is good. The organizations that fare best against this playbook are the ones that never have to choose between them.


BECAUSE ATTACKERS DON'T STOP AT YOUR ORG CHART. ACCESS IS ACCESS, NO MATTER WHOSE PAYROLL ANSWERS THE PHONE.



Sources:


Comments


bottom of page