AT&T: two breaches, one still unexplained, and a $177 million settlement two and a half years in the making

Background

AT&T disclosed two separate data breaches within four months of each other in 2024. They are not the same incident, they don't share a confirmed cause, and treating them as one story — which a lot of early coverage did — misses the actual lesson in each. One is a textbook case of a stolen password reaching a cloud data warehouse with nothing standing in the way. The other is a 73-million-record dataset that AT&T, more than two and a half years later, still hasn't been able to explain the origin of. A federal court finalized a combined $177 million settlement covering both in October 2026 — closing AT&T's civil exposure, not the open questions underneath it.

How the confirmed half of this breach actually happened

What actually happened

The first breach surfaced publicly in late March 2024: a dataset covering roughly 73 million current and former AT&T account holders — names, addresses, phone numbers, Social Security numbers, dates of birth, and account passcodes — appeared on a cybercrime forum. AT&T's own position is that the data appears to be from 2019 or earlier, but the company has not confirmed whether it came directly from AT&T or from a vendor, and has never definitively resolved whether this is the same dataset a hacker calling themselves ShinyHunters claimed to be selling back in 2021, which AT&T denied at the time.

A few days into the disclosure, a security researcher demonstrated that the account passcodes in the leaked file — which AT&T had described as encrypted — could be decoded in seconds using a lookup table. That forced a correction to AT&T's public messaging about how protected the data actually was.

The second breach is a different animal entirely, and a much better-understood one. Mandiant's investigation tied it to stolen AT&T credentials used to log into AT&T's own account on Snowflake, the cloud data-warehousing platform AT&T used to store customer interaction records. No breach of Snowflake's own infrastructure occurred — the attacker, tracked as UNC5537, walked in through AT&T's front door with a valid password. Between April 14 and 25, 2024, they pulled call and text metadata — not message content, but who called or texted whom, how often, for roughly how long, and for a subset of records, which cell towers were involved — covering nearly all of AT&T's wireless and reseller customers from May through October 2022 and on January 2, 2023.

AT&T disclosed the second breach in July 2024. A hacker later claimed to a reporter that AT&T paid roughly $400,000 for assurance the stolen data would be deleted — a claim that has never been independently corroborated and should be treated as unverified, not fact.

Both breaches ended up in the same multidistrict litigation. On October 2, 2026, a federal judge gave final approval to a $177 million settlement split across two funds — $149 million tied to the March breach, $28 million tied to the Snowflake-linked July breach — closing out AT&T's civil liability about two and a half years after the first breach was disclosed.

Root cause

Timeline

Detection

What to monitor for in your own environment

Containment, eradication & recovery

Security control analysis

Controls that would have prevented or limited this

Blast radius

Where the $177 million settlement actually goes

What they got right

AT&T disclosed both 2024 incidents publicly and notified affected customers rather than staying silent, and when a researcher showed the March dataset's passcode "encryption" was trivially reversible, AT&T corrected its public guidance within days rather than letting the inaccurate claim stand.

For the Snowflake-linked breach, AT&T's cooperation with federal investigators contributed to criminal charges against multiple individuals tied to the broader campaign — a real, if slow, consequence for the people responsible, not just a check written to make the lawsuit go away.

The $177 million settlement gives affected customers a calculable, real payment rather than a token year of credit monitoring nobody asked for, and it closes litigation that could otherwise have dragged on for years longer without resolution for anyone.

Why this keeps happening

AT&T is the largest and costliest example of a pattern that hit more than 165 organizations using Snowflake for data warehousing: a password harvested months or years earlier by commodity infostealer malware, traded on a criminal marketplace, was enough to log into a company's own data warehouse and walk out with everything in it. Snowflake itself wasn't broken into at any of these organizations — their own front doors just didn't have a deadbolt.

Three people have been tied to this campaign with real legal consequences so far, at very different stages. Cameron John Wagenius, a former US Army soldier, pleaded guilty and was sentenced to roughly five years and ten months. Connor Riley Moucka, who personally collected at least $495,000 across the campaign by his own admission, pleaded guilty in August 2026 and was awaiting sentencing as this was written — a reminder that "criminally resolved" doesn't mean every defendant's sentence is already final. A third, John Erin Binns, remains outside US custody.

The unresolved status of the March dataset is its own kind of lesson. More than two and a half years after disclosure, AT&T still hasn't said definitively where it came from or whether it connects to a 2021 claim it once denied. A settlement can close the legal exposure without the underlying security question ever getting answered — and a reader of this case study should notice that gap, not assume it was quietly resolved somewhere off the record.

None of this required a novel exploit. It's the same failure, repeated at victim after victim: a cloud platform account reachable with nothing but a password, holding more customer data than anyone had fully inventoried, discovered by an attacker before it was discovered by its own owner.

Lessons for your own environment

1. A data warehouse is a production system, not a back-office tool

   Snowflake held nearly all of AT&T's customer interaction history. Any platform holding that much data needs the access controls of a production system handling sensitive data — not a lighter standard because it's "just analytics."

2. A secure platform doesn't make your account on it secure

   Snowflake's own infrastructure was never breached at any victim in this campaign. Every single one was compromised through their own account, with their own credentials. The platform's security and the customer's account security are two separate problems, and only one of them is the vendor's job.

3. A credential doesn't expire just because it's old

   The credentials used in this campaign were reportedly harvested well before they were used, in some cases with no direct connection to Snowflake at all. A password nobody's rotated is a liability with no built-in deadline.

4. Not every breach gets a clean root-cause answer, and that's worth saying plainly

   AT&T still can't confirm where the March 2024 dataset came from. A mature response plans for that real possibility and says so directly, instead of letting silence get read as something being hidden.

5. A settlement is a legal outcome, not a security outcome

   The $177 million payout resolves AT&T's civil liability. It says nothing about whether the account-security gap that caused the Snowflake breach has actually been closed — or whether the same gap exists on some other platform today.

CISO & board lessons

• Get an actual inventory of every SaaS and cloud-analytics account reachable with a password alone and no second factor. Treat "we haven't gotten MFA onto that one yet" as a finding to close on a deadline, not a footnote to revisit next quarter — this exact gap is what turned one stolen password into a 165-victim campaign.
• Use this case's actual number the next time identity-security budget loses out to a customer-facing project: $177 million and two and a half years of litigation, against the cost of enforcing MFA on one account.
• When an outside party demonstrates your "protected" data isn't actually protected — as happened here with the reversible passcodes — treat that as a critical finding regardless of what your own team believed walking in. Internal confidence is not the same as independent verification.
• Build the organizational muscle to say "we don't know" about a root cause when that's genuinely true. AT&T's inability to explain the March dataset's origin is now a permanent part of the public record; a prepared, honest version of that statement lands very differently than one forced out under pressure.

Action plan

Could this happen in your organization?

• Could someone log into your cloud data warehouse with nothing but a username and password, from anywhere on the internet?
• Do you know which of your vendor and SaaS accounts hold the most sensitive data, and are those specifically prioritized for MFA — or does MFA get rolled out by convenience rather than by data sensitivity?
• If a credential-marketplace feed flagged one of your service or admin accounts today, would anyone actually see that alert in time to act on it?
• How old is the oldest, never-rotated credential currently granting access to a system holding customer data?
• Could your organization currently explain, with confidence, where every dataset you hold actually came from — or do you have your own version of AT&T's unexplained pre-2020 file?
• If you had to disclose a breach today, could legal and security agree on one accurate public statement the first time, or would it need a correction later the way AT&T's passcode-encryption claim did?

If this happened to you: what to ask, and what to say

Knowing the lesson isn’t the same as knowing what to do with it Monday morning. A security lead, a CISO, and a customer-facing team each need something different from this incident.