The 2024 cascade is still the cleanest case study. Attackers got hold of the credentials of an employee at a contractor that supported a popular cloud data warehouse. Through that single foothold, they walked into the data warehouses of a long line of well-known customers and helped themselves to whatever was sitting there. Customer rosters. Ticket sales. Contract details. Internal account histories.
The cloud vendor, technically, was not breached. Their platform did exactly what it was designed to do: accept valid credentials and serve up the data those credentials were authorized to access. The credentials were stolen, not their systems. From the customers’ point of view, that distinction was an accounting fiction. Their data was on the dark web.
What made the cascade so wide was a familiar set of habits: customers who had set up their warehouse months earlier and forgotten to enable multi-factor authentication on every account; service accounts whose passwords lived in shared Slack channels; long-running connector tokens that had outlived the contracts that produced them.
None of this was the platform’s fault, exactly. It was also entirely predictable. When you concentrate the data of dozens of large enterprises behind a single login form, the login form becomes the most valuable thing in the country.
Your data, your blast radius.
Eclipse deployments don’t share a tenant with anyone else’s. There’s no third-party login form between attackers and your data. When a vendor or contractor has a bad day, the news headline is theirs alone, not yours. “Blast radius” is a phrase we picked up from people who took it literally; we’d rather not see it applied to your customer list.
BleepingComputer’s ongoing reporting on the cloud-warehouse credential theft cascade. https://www.bleepingcomputer.com/