Stolen credentials, not a product flaw, still open the widest breach window

The breach narrative that still shows up in regulatory filings is rarely a cinematic zero-day. It is a username and a password that already worked somewhere else, replayed against a cloud service that trusted them.

That pattern became a public case study in the late spring of 2024, when criminal crews began emptying customer accounts on Snowflake. The company said the activity was not the result of a vulnerability, a misconfiguration, or a breach of the Snowflake platform itself. The accounts that fell were customer accounts. A common thread in the public reporting was the absence of multi-factor authentication. Mandiant, brought in to investigate, described a campaign it tracked as UNC5537: attackers logged in with credentials previously stolen from customer machines, then staged data and took it out.

What the disclosures actually established

Two names made the campaign impossible to file as a niche cloud story. Live Nation disclosed unauthorized access affecting Ticketmaster. AT&T disclosed that attackers had obtained call and text interaction records covering a broad set of its wireless customers. The company described that data as metadata about who contacted whom and when, not recordings of the conversations. Other organizations appeared in breach notices and in researcher reporting as the wave continued.

The precise row counts differ by victim and are easy to garble in a retelling. The operational fact does not. A data warehouse holds the joined, cleaned, highly useful copy of a business. An account that can run large queries against that copy is not a side door. It is the archive.

Snowflake’s public guidance at the time pushed customers toward multi-factor authentication, toward network policies that limit where a session may come from, and toward the habit of treating leaked credentials as an incident even when the vendor status page is green. Those are ordinary controls. The campaign showed how many production tenants were still running without them.

“Our vendor was breached” was the wrong sentence

It is comforting, and often inaccurate, to file this class of incident under third-party breach. A vendor breach means the provider’s own systems were compromised and customer data left with them. A stolen-credential login to a customer tenant is a different event. The provider furnished the room. The customer decided who held the key, whether a second factor was required, and whether a query that suddenly scanned a huge table was worth paging a human.

Shared-responsibility charts have said this for a decade. Incident reports keep demonstrating that the chart is not itself a control. Identity configuration is production infrastructure. It deserves the same owner, the same change review, and the same monitoring as the database it protects.

Infostealer malware on a contractor laptop is enough to start the chain. The malware family hardly matters at the executive level. What matters is that saved passwords leave the laptop and later turn up for sale. From there, a crew does not need a new phishing kit aimed at the data team. It needs a password that still works and a login that never asks for a second factor. This desk will not describe how those stolen logins are traded. Defenders should assume that a password saved in a browser on a workstation is already in someone else’s hands, and should design as if that assumption is true.

The failures that repeat

Across disclosures of this type, four gaps show up often enough to treat as a checklist rather than a surprise.

Optional MFA on the systems that matter. A consumer app can debate friction. A warehouse, an email admin console, a CI provider, and a support desk that can export customers cannot. Phishing-resistant factors for administrators — hardware keys or platform passkeys — close the replay that a tappable prompt sometimes does not.

Long-lived secrets with no owner. Service-account keys, personal access tokens, and integration users created for a quarter that ended two years ago still open the front door. If the token can read the customer table, it is an identity, not a string in a config file.

No alert on volume. The useful detective control in a warehouse is boring: a principal that normally touches one schema suddenly scanning many, or unloading data somewhere new. The alert is only real if a person is paid to see it on a Saturday.

Flat trust of the whole internet. Network policies and single sign-on conditional access are not glamorous. They turn “anyone with the password” into “the password plus a network the company recognizes.” They would not have saved every victim. They would have shortened the list.

What a serious program does now

A board does not need a new slogan. It needs evidence that the identity perimeter around SaaS is in scope for security engineering.

Start with an inventory that is not a spreadsheet from last year’s audit. Every tenant that stores customer, employee, or payment data gets a named owner, single sign-on, and a second factor the user cannot click past. Administrators are a smaller population than convenience prefers, and they use hardware-backed factors.

Then watch the tenant from the outside in. Export audit logs to a place the security team already reviews. Alert on new users, on privilege grants, on sign-ins from unusual places, and on large exports. Practice the call you will make when a vendor’s customer list starts lighting up on a Friday: who disables accounts, who calls counsel, who preserves logs before a retention window rolls them off.

Contract language helps after the fact and rarely during the night of the incident. A right to audit did not turn on multi-factor authentication. Buyers should still ask, in writing, whether the product can enforce single sign-on, whether a second factor can be required rather than suggested, whether logs can leave the tenant, and how fast the vendor will help with a credential-theft incident that is “only” on the customer side.

The headline you can already predict

The next campaign will wear a different product logo. The paragraph under it will look familiar: valid credentials, no second factor, a large query, a late disclosure. The vulnerability field will be blank.

That is not a reason for fatalism. It is a reason to stop spending the entire security budget on the bug classes that arrive with a logo and a CVE, and to spend a visible share on the door that does not. Multi-factor authentication on a data platform is not a maturity milestone for next year’s roadmap. It is the control that decides whether a password stolen off a laptop becomes a notification letter.

ZeroDay Times will keep covering the disclosures. The pattern is no longer the surprise. Leaving it in place is.

This briefing relies on public company disclosures and published reporting about the 2024 Snowflake customer campaign. It does not describe intrusion steps.