Snowflake Hacker Pleads Guilty: How Stolen Credentials Enabled 165+ Cloud Attacks
By ScruteX Published Updated
On 6 August 2026, a 26-year-old Canadian pleaded guilty in a U.S. federal court to breaking into cloud data accounts at more than 165 organisations and stealing records tied to over 100 million people. He did not exploit a flaw in the cloud platform. He logged in with real usernames and passwords that malware had already stolen from other people's machines.
That single detail is the whole story. This was an identity-based cloud attack, not a platform breach.
Identity-based cloud attacks are intrusions where the attacker uses valid stolen credentials to sign in to a legitimate account, rather than exploiting a software vulnerability. In the Snowflake campaign of 2024, attackers took usernames and passwords harvested by infostealer malware, found the customer accounts that had no multi-factor authentication (MFA), and signed in as if they were the account owner. The platform itself was never compromised. The accounts were. The distinction matters, because it changes where you spend your defensive effort.
The 2024 Snowflake attacks were not caused by a breach of Snowflake's infrastructure. Attackers used credentials stolen by infostealer malware to access customer accounts that lacked MFA. Connor Moucka's August 2026 guilty plea confirms the campaign's scale, method and extortion activity. The main lesson for defenders is straightforward: protecting cloud infrastructure is not enough. Human credentials, service accounts, machine identities and third-party tokens can all become paths into sensitive cloud data.
What were the Snowflake credential attacks?
Between February and October 2024, a small group signed in to cloud data accounts that belonged to large organisations and pulled out terabytes of records. According to U.S. Department of Justice filings, the operators then tried to extort the victims and sold stolen data on cybercrime forums when victims did not pay.
Prosecutors named the primary defendant as Connor Moucka, 26, from Ontario, and charged a co-defendant, John Binns, over the same campaign. Moucka pleaded guilty to four counts: computer fraud, wire fraud, aggravated identity theft, and conspiracy.
The numbers from the court record are worth stating plainly. Prosecutors say the campaign affected more than 165 organisations and exposed billions of records tied to over 100 million individuals. The operators obtained at least 2.5 million dollars in bitcoin from a handful of victims who paid. Moucka personally collected at least 495,000 dollars, prosecutors say, including through the sale of stolen data on cybercrime forums and a re-extortion attempt that used a government official's stolen personal data. Victim organisations reported more than 9.5 million dollars in direct losses.
On sentencing, the exposure is severe. Moucka is scheduled to be sentenced on 27 October 2026. The aggravated identity theft count carries a mandatory two years that must run consecutively to his other charges, and the remaining three counts carry up to 30 years, so he faces as much as 32 years in total.
The guilty plea is the reason this campaign is back in the news. A plea turns a set of intelligence assessments into a matter of legal record. It confirms scale, method, and intent in a way that vendor reporting alone cannot.
What did the Justice Department and FBI say?
The Justice Department announced the plea the same day. Assistant Attorney General A. Tysen Duva of the Criminal Division framed it as a signal that operating from abroad or behind aliases does not put cybercriminals beyond the reach of prosecution.
The FBI put the harm in plain terms. W. Mike Herrington, the Special Agent in Charge of the FBI's Seattle field office, described Moucka's extortion as deliberate and said it caused lasting harm to the targeted businesses and to their customers. That second half matters for how you scope an incident like this. The loss does not stop at the breached company. It lands on every person whose records were taken, and it keeps landing when the same data is used again, as it was in the re-extortion attempt.
The investigation was international. Law enforcement in Australia, Spain, Ukraine, and Turkey assisted, which is a reminder that identity-based intrusions rarely sit inside one jurisdiction. The credentials, the infrastructure, the operators, and the victims are usually spread across several.
What the guilty plea confirms, and what it does not
A plea is strong evidence, but it is narrow. It is worth separating what is now settled from what is still open, because reporting often blurs the two.
What the plea confirms: Moucka accessed cloud data accounts at more than 165 organisations, used stolen credentials to do it, and extorted victims and sold data. Those facts are now on the record, admitted by the person who did them, not inferred from telemetry.
What the plea does not settle. It resolves the case against Moucka only. Binns was arrested separately in Turkey, where a court approved a U.S. extradition request that he is contesting, and his case continues on its own track while he remains outside U.S. custody. Restitution and Moucka's exact sentence stay undecided until the 27 October hearing. And a figure worth handling with care: in 2024, the platform provider and the incident responders said they had notified roughly 165 potentially exposed organisations, and prosecutors now cite a similar number of confirmed victims, but the public filings do not establish that the two counts describe an identical set of companies. Confidence: high on the method and the admitted conduct, medium on any one-to-one mapping between the 2024 notification list and the 165 confirmed in the plea.
That discipline is not pedantry. When you brief a board or a regulator, the difference between "admitted in court" and "reported in 2024" is the difference between a fact and an assessment. Both belong in the report. They do not belong in the same sentence without a label.
Threat actor profile: who ran the campaign
The plea puts a name to the primary operator. Connor Riley Moucka, 26, of Ontario, admitted to the intrusions. He is known online by several handles, including Waifu, Judische, ellyel8, and catist. Handles matter in an investigation, because the same alias tends to recur across forums, chat channels, and leak posts, which is how scattered activity gets tied back to one person.
Beyond the individual, the activity sits inside a wider tracked group. Incident responders track the cluster as UNC5537, the designation assigned by Mandiant. The extortion and leak activity has also been publicly linked to the ShinyHunters brand, a name that has surfaced across several high-profile data-sale and extortion campaigns. Confidence on the individual is now high, since it rests on a guilty plea. Confidence on the broader group links is medium: they are consistent with the observed tactics and public reporting, but group branding is fluid and often shared or reused between operators.
| Field | Detail |
|---|---|
| Name | Connor Riley Moucka, 26, of Ontario |
| Aliases | Waifu, Judische, ellyel8, catist |
| Tracked cluster | UNC5537 (designation assigned by Mandiant) |
| Public branding link | ShinyHunters (extortion and leak activity) |
| Co-defendant | John Binns (arrested in Turkey, contesting extradition) |
| Status | Pleaded guilty 6 August 2026; sentencing 27 October 2026 |
For a defender, the actor's name matters less than the actor's method. Moucka did not need rare skill. He needed stolen credentials, a list of accounts without MFA, and a script to sweep them. That profile is cheap to copy, which is why the pattern outlived the arrest.
How did attackers get in without breaking the platform?
The entry method was ordinary, which is exactly why it worked. The attackers did not write an exploit. They bought and collected the output of infostealer malware.
Infostealers are commodity malware that run on an infected endpoint and copy whatever is useful: saved browser passwords, session cookies, autofill data, and local credential stores. The infected machine often belongs to a contractor, a developer, or an employee who reused a work password on a personal device. The stolen data lands in a "stealer log", a structured dump of one victim's credentials and sessions. These logs move through Telegram channels and credential marketplaces in bulk, sometimes within hours of infection.
The Snowflake operators worked from these logs. They searched the harvested credentials for cloud data platform logins, then tried those logins against the matching customer accounts. Where the account required only a username and password, the login succeeded. Court documents describe the use of custom software to sweep across accounts, identify what each one held (organisation name, user roles, network addresses), and find the ones worth draining.
No zero-day. No malware planted inside the platform. The attacker held the key because someone else's laptop had been infected months earlier, and that key still opened the door.
Why did missing MFA turn one stolen password into 165 breaches?
MFA is the control that would have stopped almost all of this, and its absence is the reason a password reused on an infected device became a full data theft.
When an account is protected only by a password, that password is a complete credential. Steal it, and you are the user. Add a second factor, and the stolen password becomes incomplete: the attacker holds one piece of a two-piece key and cannot sign in. The Snowflake operators did not defeat MFA. They found the accounts that had none. Across 165-plus organisations, enough accounts lacked a second factor to produce one of the largest identity-based cloud intrusions on record.
There is a second lesson hiding behind the first. The vulnerable accounts were often service accounts, machine identities, and legacy logins that no one had enrolled in MFA because no human logs in with them day to day. These are the accounts that hold the widest data access and get the least identity hygiene. Attackers know this. Machine and service identities are frequently the softest path into a cloud data store, precisely because they sit outside the human MFA rollout.
After the campaign, the platform provider moved to enforce MFA and to require longer passwords by default. That change is the right one. It also arrived after the data was already gone, which is the pattern with identity controls: the cost of skipping them is paid all at once, during an incident.
Timeline of the campaign
| Date | Event |
|---|---|
| Feb 2024 | Operators begin signing in to cloud data accounts using credentials pulled from infostealer logs. |
| May 2024 | Multiple organisations report data theft. Researchers open an investigation into the activity cluster tracked as UNC5537. |
| May to June 2024 | Organisations across telecom, banking, retail, and ticketing disclose breaches tied to their cloud data accounts. |
| Jun 2024 | The platform provider recommends mandatory MFA, credential rotation, and enhanced monitoring, and confirms its own infrastructure was not compromised. |
| Oct 2024 | Connor Moucka is arrested in Canada. Co-defendant John Binns is arrested separately in Turkey. |
| 2025 | Moucka is extradited to the United States to face federal charges. Binns contests a U.S. extradition request and remains outside U.S. custody. |
| Apr 2026 | A supply-chain compromise of the analytics provider Anodot leads to theft of authentication tokens used against connected cloud data environments, including Rockstar Games. |
| 6 Aug 2026 | Moucka pleads guilty to computer fraud, wire fraud, aggravated identity theft, and conspiracy. |
| 27 Oct 2026 | Moucka is scheduled to be sentenced. He faces up to 32 years. |
How the attack unfolded, step by step
The mechanics were repeatable, which is what let one crew hit so many targets. The flow ran like this:
- Infostealer infection – Malware infects an endpoint.
- Credential theft – Passwords and active sessions are stolen.
- Stealer log – Stolen data is packaged into a log.
- Underground sale – Logs are traded on cybercrime channels.
- Cloud access – Attacker finds cloud credentials with no MFA.
- Privilege discovery – Roles, databases, and permissions are enumerated.
- Data extraction – Bulk queries and exports are performed.
- Exfiltration – Terabytes of data are stolen.
- Extortion/resale – Data is used for extortion or sold.
Every stage here uses a legitimate feature. Login is login. A large export is a normal administrative action. That is what makes identity-based attacks hard to catch with tools tuned for malware and exploits. There is no payload to detect. There is only a valid user doing something a valid user is allowed to do, from a place and at a volume they normally would not.
MITRE ATT&CK mapping
Confidence: high for the techniques confirmed by the plea and court record, medium for internal tooling detail described in filings.
| Tactic | Technique | How it appeared here |
|---|---|---|
| Initial Access | T1078 Valid Accounts | Sign-in with stolen, valid credentials |
| Credential Access | T1555 Credentials from Password Stores | Passwords harvested by infostealer malware from endpoints |
| Reconnaissance | T1589 Gather Victim Identity Information | Enumeration of user and org identity data |
| Discovery | T1087 Account Discovery | Listing users and roles in each account |
| Discovery | T1069 Permission Groups Discovery | Finding privileged roles worth using |
| Collection | T1213 Data from Information Repositories | Querying customer datasets |
| Exfiltration | T1020 Automated Exfiltration | Bulk export of records |
| Command and Control | T1105 Ingress Tool Transfer | Custom tooling to automate enumeration across accounts |
| Impact | T1657 Financial Theft | Ransom demands and resale of stolen data |
The mapping tells a defender something useful: nine of these ten steps happen after a successful login. If you only watch for the login, you miss most of the attack. The strongest detection signals sit in the discovery and exfiltration stages, where a real account starts behaving unlike itself.
Who was hit and what was taken?
The victims spanned sectors that hold high-value regulated data. Public disclosures and court filings name organisations across several industries. The common thread was not the industry. It was the use of a cloud data platform with at least one account left without MFA.
| Sector | Named example |
|---|---|
| Telecommunications | AT&T |
| Banking | Santander |
| Retail | Neiman Marcus |
| Automotive | Advance Auto Parts |
| Ticketing | Ticketmaster |
| Education | Los Angeles Unified School District |
| Technology | Pure Storage |
| Financial services | LendingTree (QuoteWizard) |
The scale inside a single victim can be enormous. The Ticketmaster breach alone involved roughly 560 million user records, drawn from one account, through one weak identity. That is what makes an identity-based attack so efficient: the effort to compromise one account is small, and the data behind it can run to hundreds of millions of people.
The stolen data categories, drawn from the court record, read like a checklist of everything an identity-theft operation wants:
- Customer names, email addresses, and phone numbers
- Call and text metadata (records of contact, not message content)
- Banking and financial records
- Payroll information
- Driver's licence numbers and passport numbers
- Social Security numbers
- Regulated registration identifiers, including DEA numbers
- Internal business documents
In at least one instance described by prosecutors, the operator re-extorted a victim, threatening further release of already-stolen data, and used personal data belonging to a government official's family in that second demand. That detail matters because it shows the harm does not end when the initial ransom is paid or refused. Stolen data keeps working for the attacker long after the intrusion closes.
How this pattern is evolving: from stolen passwords to trusted integrations
The 2024 campaign abused stolen human credentials. The pattern seen since then abuses stolen machine trust, and that shift deserves attention.
In April 2026, a separate incident hit the same class of cloud data environments through a different door. A supply-chain compromise of the third-party analytics provider Anodot led to the theft of authentication tokens that customers had granted to that integration. Instead of a stolen password, the operators held pre-authorised tokens. A token is a credential a service holds so it can act on your behalf without a person logging in. Steal the token, and you inherit the trust the customer already granted to the integration. Connected environments, including those of Rockstar Games and other Anodot-linked customers, were reached without anyone breaking a password or defeating MFA, because the token had already cleared both. Confidence on this incident is medium: it rests on public reporting rather than a court record.
Set the two side by side and the trajectory is clear.
| Feature | 2024 campaign | 2026 Anodot incident |
|---|---|---|
| Entry point | Stolen usernames and passwords | Stolen third-party authentication tokens |
| Root cause | Missing MFA on customer accounts | Supply-chain compromise of Anodot integrations |
| Platform flaw exploited | No | No |
| Initial access | Valid credentials | Valid API and integration tokens |
| Primary objective | Data theft and extortion | Data theft through trusted integrations |
| Notable victims | AT&T, Ticketmaster, Santander, Neiman Marcus | Rockstar Games and other Anodot-connected customers |
| Threat pattern | Identity compromise | Supply-chain identity compromise |
The evolution is the point: 2024 targeted customer identities, and 2026 targeted the trusted third-party integrations those customers connected. In both cases the attackers abused legitimate authentication rather than exploiting the platform itself. As organisations finally enforce MFA on human logins, attackers move to the identities that MFA never covered: API tokens, OAuth grants, service accounts, and third-party integration credentials. Your third-party connections are now part of your identity attack surface, and they are often the least monitored part of it.
How to detect identity-based cloud attacks
You cannot detect these attacks by looking for malware inside the platform, because there is none. You detect them by modelling what each identity normally does and alerting when a valid account breaks its own pattern.
Watch for these signals in cloud data platform logs:
- Sign-ins from a country or network the account has never used, especially from commercial VPN ranges
- First-time authentication from a device or client not seen for that account before
- Logins to accounts that have MFA disabled, tracked as a standing exception list, not a one-off check
- A sudden jump in query volume or a shift to broad SELECT statements against high-value tables
- Large export operations, bulk
COPY INTO, or high-volume outbound transfers that do not match the account's history - Service and machine accounts logging in interactively when they normally run scheduled jobs
- Enumeration behaviour: rapid listing of users, roles, and databases in a short window
The value is in the baseline. A large export by an account that runs large exports every night is routine. The same export by a reporting account that has never exported anything is the incident. Detection here is about deviation from an identity's own normal, not about a static rule.
How to defend cloud data platforms against credential attacks
The defensive priorities follow directly from the attack chain. The goal is to make a stolen credential insufficient on its own and to catch abuse fast when a credential does work.
- Enforce MFA on every account, including service and machine identities. Treat any MFA exception as a tracked risk with an owner and an expiry, not a permanent hole.
- Kill password-only authentication wherever the platform allows it. Prefer phishing-resistant factors over one-time codes.
- Monitor for your own credentials in stealer logs and breach corpora. If an employee credential appears in an infostealer dump, rotate it before an attacker tries it. This is the single control that would have cut off the 2024 campaign at the source.
- Inventory and monitor third-party integration tokens. Scope each token to least privilege, rotate them, and revoke any that are unused or unnecessary. Treat integration credentials as identities that need the same watch as human logins.
- Baseline identity behaviour and alert on deviation: unusual geographies, new devices, query and export spikes.
- Apply least privilege to data access. An account that only needs to read three tables should not be able to export the whole warehouse.
- Rehearse the response. Assume a credential will eventually work and decide in advance how you detect the login, contain the account, and measure what was queried.
Key takeaways
- The 2024 Snowflake campaign was an identity-based attack. The platform was not breached. Customer accounts without MFA were.
- Infostealer malware, not a software exploit, supplied the credentials. Stealer logs turn one infected laptop into a working login for a corporate cloud account.
- MFA would have stopped most of it. The accounts that fell were often service and machine identities that no one had enrolled.
- The pattern is shifting from stolen passwords to stolen integration tokens. Your third-party connections are part of your identity attack surface.
- Detection depends on behavioural baselines. Nine of the ten attack steps happen after a valid login, so watching only the login misses the theft.
- The plea confirms the method and the scale on the record, but the case is not closed. Moucka faces up to 32 years at sentencing on 27 October 2026, a co-defendant is still contesting extradition, and restitution is not yet set.
Protect your credential exposure before it becomes a breach
Scrutex is an external security intelligence platform. Its Data Exposure Insights module monitors dark web sources, paste sites, breach corpora, and stealer logs for your leaked credentials and sessions, and its Threat Insights module maps active campaigns to your sector and region. Catching an infostealer-compromised credential before an attacker tries it is the control that would have broken the campaign described here at its first step. You can start on a free tier with a domain and a set of keywords.
FAQ
Q: Was Snowflake hacked in the 2024 breaches?
A: No. The cloud platform's own infrastructure was not compromised. Attackers signed in to individual customer accounts using valid credentials stolen by infostealer malware, targeting accounts that had no multi-factor authentication.
Q: What is an infostealer and how did it enable these attacks?
A: An infostealer is malware that copies saved passwords, session cookies, and other credentials from an infected device. Those credentials are packaged into stealer logs and sold in bulk. The operators searched these logs for cloud data platform logins and reused them against matching customer accounts.
Q: Would MFA have prevented the Snowflake attacks?
A: In almost every case, yes. MFA makes a stolen password insufficient on its own. The compromised accounts were the ones that relied on a password alone, many of them service or machine identities that had not been enrolled in MFA.
Q: How can an organisation detect identity-based cloud attacks?
A: Baseline each identity's normal behaviour and alert on deviation: logins from new geographies or devices, sudden query or export spikes, and interactive use of accounts that normally run scheduled jobs. Most of the attack happens after login, so behavioural monitoring matters more than watching the sign-in alone.
Q: How is this attack pattern changing in 2026?
A: Attackers are shifting from stolen human passwords toward stolen machine and integration credentials, such as third-party API and OAuth tokens. These identities often sit outside an MFA rollout, which makes connected integrations a growing part of the identity attack surface.
Q: Who was charged in the Snowflake attacks?
A: Prosecutors charged Connor Moucka, 26, of Ontario, and a co-defendant, John Binns. Moucka pleaded guilty on 6 August 2026 to computer fraud, wire fraud, aggravated identity theft, and conspiracy. Binns was arrested in Turkey and is contesting a U.S. extradition request, so his case continues separately.
Q: How long could the Snowflake hacker be sentenced to?
A: Moucka faces up to 32 years. The aggravated identity theft count carries a mandatory two years that run consecutively to his other charges, and the remaining three counts carry up to 30 years combined. Sentencing is scheduled for 27 October 2026, and the exact term and any restitution are not yet decided.