Caesars, 2023: social engineering at the IT support vendor

The attack path, step by step

What the published record says happened at each stage, then our reading of it: what would have stopped the step, what would have caught it in progress, and what a test would have shown first.

1. 1

   Step 1. First access

   Step 1: If the way in was the support desk, not the firewall

   Caesars' filing does not name the attacker, and neither advisory names Caesars. The advisories are read here for the technique they document, not as an attribution.

   Caesars said 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.[1]

   The FBI and CISA advisory on the group they call Scattered Spider describes its actors posing as IT or help desk staff by phone or SMS to obtain employee credentials, and persuading help desk staff to reset passwords or MFA tokens so they can take over accounts.[2]

   Microsoft describes the group it calls Octo Tempest calling an organisation's help desk and socially engineering it into resetting a user's password or changing or adding an MFA factor.[3]

   Would have stopped it

   • Help desk identity checks that do not rest on facts an attacker can research: a call back to a number already on file, a manager's confirmation, or approval from a device the user has already enrolled
   • No password reset or new MFA factor on the strength of a phone call alone, and a delay, with notice to the user, before a new factor becomes active
   • The same verification rules written into the contract with an outsourced support provider, and checked, not assumed

   Would have caught it

   • An alert on any password or MFA reset that is followed by a sign-in from a new device or location
   • A notice to the account owner, through a channel they already use, whenever their sign-in factors change

   What a test would have shown

   A pretext call to the support desk, agreed in advance with the provider, shows whether a caller armed only with public information can get a reset. It is one of the cheapest tests to run, and one of the few that exercises a third party's process rather than your own.

2. 2

   Step 2. Moving inside

   Step 2: What the advisories say comes next

   Caesars' filing does not describe the attacker's movements. These are the group's documented techniques, set out so the controls that follow have something concrete to answer.

   The FBI and CISA advisory says the actors deploy remote monitoring and management tools to maintain persistence.[2]

   It also says they add a federated identity provider to the victim's single sign-on tenant and turn on automatic account linking.[2]

   Among its mitigations, the advisory recommends application controls that allowlist remote access programs, and phishing-resistant MFA such as FIDO/WebAuthn, which it describes as not susceptible to push bombing or SIM swap attacks.[2]

   Would have stopped it

   • Application allowlisting that blocks remote access tools nobody approved
   • Changes to single sign-on federation restricted to very few accounts, each behind phishing-resistant MFA

   Would have caught it

   • An alert when a remote monitoring tool appears on an endpoint that has never run one
   • An alert on any change to federation settings or any new identity provider in the tenant

   What a test would have shown

   From an assumed foothold, a test tries exactly these moves: install a remote tool, enrol a new factor, touch federation. Each one either raises an alert or becomes a finding with the evidence attached.

3. 3

   Step 3. Acting on objectives

   Step 3: A copy of the loyalty program database

   Caesars said the unauthorised actor acquired a copy of, among other data, its loyalty program database, which includes driver's licence numbers and/or social security numbers for a significant number of members.[1]

   It said it had no evidence to date that member passwords or PINs, bank account information or payment card information were acquired.[1]

   It said its customer-facing operations, including its physical properties and its online and mobile gaming applications, were not affected and continued without disruption.[1]

   Would have stopped it

   • The most sensitive fields, such as licence and social security numbers, kept out of the general customer database or encrypted with keys a support-level account cannot reach

   Would have caught it

   • An alert on bulk reads or exports of the customer database, above all from accounts that do not normally run them

   What a test would have shown

   An assumed-breach test measures the distance between a support-level account and the customer database: how many steps it takes, and which of them anyone notices.