Connor Moucka Pleads Guilty in Snowflake Customer Data Theft Campaign

Connor Moucka has pleaded guilty in a case tied to attacks on at least 165 Snowflake customers, according to reporting highlighted by Techmeme. The techmeme Canadian case connects one defendant to a campaign that exposed billions of sensitive records, including data associated with AT&T.

The plea changes the legal posture surrounding one of 2024’s widest cloud data theft campaigns. Yet it does not resolve the central security dispute exposed by those attacks. Snowflake said its platform was not breached, while customers relied on accounts without sufficient identity protections.

That distinction matters, but it offers little comfort to organizations whose data was stolen. The attacks showed how valid credentials, weak authentication, and concentrated cloud data can produce consequences resembling a platform-wide breach.

The techmeme Canadian case moves from allegations to admission

Moucka’s plea converts a major part of the Snowflake case from an accusation into an admitted criminal matter.

Jonathan Greig of The Record reported that Moucka pleaded guilty to participating in the 2024 hacking campaign. Techmeme surfaced that report on August 5, 2026. The available report says the Canadian national faces decades in prison.

Moucka, also known as Alexander Antonin Moucka, was arrested in Kitchener, Ontario, on October 30, 2024. He consented to surrender for extradition purposes in March 2025 and appeared in federal court in Seattle that July.

He originally pleaded not guilty to all charges. The Justice Department’s public Moucka case page, last updated before the reported plea, listed an October 19, 2026 trial date.

The federal case also names John Erin Binns, who was not in United States custody when the Justice Department last updated its page. Prosecutors charged the defendants with wire fraud, computer fraud, aggravated identity theft, extortion-related offenses, and associated conspiracies.

The original indictment described intrusions into at least 10 victim organizations. It alleged that the defendants and their associates accessed billions of records, demanded ransoms, and advertised stolen information on cybercrime forums.

Those records allegedly included call and text histories, banking information, payroll records, passport numbers, and Social Security numbers. Prosecutors also alleged that the group obtained millions in extortion payments.

The figure of 165 organizations comes from the broader threat investigation, not the count of specifically charged victims. Mandiant and Snowflake said they notified approximately 165 organizations whose Snowflake environments were potentially exposed.

That distinction is important. A criminal case usually presents selected incidents needed to prove specific charges. A threat investigation can describe a wider campaign, including incidents that never appear as separate criminal counts.

The reported plea does not automatically establish every public claim about all 165 organizations. It establishes criminal responsibility within the scope accepted by the court and the plea agreement. The precise admitted facts, dismissed charges, sentencing exposure, and restitution terms depend on documents filed in the case.

Still, the change is substantial. Moucka’s defense no longer appears headed toward the scheduled trial. Attention now turns to the factual admissions and how the court will assess the campaign’s scale.

The case also gives security teams something more concrete than an anonymous threat-cluster label. A campaign once discussed mainly through incident reports now has a defendant reportedly accepting responsibility.

That legal development sharpens the larger question. Who was responsible for preventing a valid but stolen password from unlocking a repository filled with sensitive corporate data?

A simple login path created extraordinary damage

The campaign did not require a newly discovered Snowflake software vulnerability, according to the investigations published after the attacks.

Mandiant tracked the activity as UNC5537, a label for a financially motivated threat cluster. Its investigators said attackers systematically accessed customer Snowflake instances with stolen credentials.

An infostealer is malware designed to collect passwords, browser data, session information, and other credentials from an infected device. Those stolen credentials are often bundled into logs and traded through criminal markets.

Mandiant found that some credentials used in the Snowflake campaign came from infostealer infections dating to 2020. In affected environments, passwords had sometimes remained valid for years after their theft.

The investigators identified three recurring weaknesses. Compromised accounts lacked multifactor authentication, passwords had not been rotated, and network allow lists did not restrict logins to trusted locations.

Mandiant said at least 79.7 percent of the accounts used by the attackers had evidence of earlier credential exposure. Its detailed UNC5537 analysis traced every incident it handled to compromised customer credentials.

Multifactor authentication, commonly called MFA, requires an additional credential beyond a password. Depending on the implementation, that second factor might be a security key, passkey, authenticator code, or approved device.

Without MFA, a working username and password can be enough to impersonate the real user. The cloud service sees a successful authentication unless other controls detect the unusual source or behavior.

The attackers reportedly used Snowflake’s ordinary interfaces and supported database commands after logging in. Mandiant observed access through Snowsight, Snowflake’s browser interface, and SnowSQL, its command-line client.

Investigators also observed an attacker-named reconnaissance utility tracked as FROSTBITE. The tool queried account details, roles, users, organization names, sessions, and other information that helped operators map accessible environments.

Once the attackers located useful tables, they could stage data inside the customer instance. Standard SQL and Snowflake commands let them select records, compress exported files, and retrieve those files.

Nothing about that workflow required attackers to break encryption or defeat the underlying cloud infrastructure. They abused permissions granted to accounts whose credentials they controlled.

That point explains why the campaign became so consequential. The attackers could use the same repeatable process against different organizations after obtaining another set of credentials.

Cloud centralization amplified the results. Companies use data platforms to combine customer records, financial information, operational data, and analytics workloads. A compromised account can therefore provide access to information gathered from many business systems.

The technical mechanism was ordinary enough to be overlooked. No zero-day exploit was needed. A zero-day is a previously unknown software flaw for which defenders have not yet deployed a fix.

Instead, the campaign joined a mature criminal supply chain. Infostealers collected credentials, underground markets distributed them, and extortion operators converted access into leverage.

Mandiant described the techniques as neither particularly novel nor sophisticated. That assessment makes the incident more troubling, not less. Basic identity failures enabled attacks with an unusually broad impact.

The guilty plea does not change that mechanism. It confirms that prosecution can reach an individual participant, while the reusable attack path remains available to other groups.

Snowflake’s shared responsibility model meets an uncomfortable reality

The primary conflict is between contractual responsibility and operational control.

Snowflake has consistently maintained that investigators found no evidence of a breach, vulnerability, or misconfiguration in its enterprise environment. Its position draws a clear boundary between the platform and individual customer accounts.

The company repeated that point in a regulatory filing. It said threat actors accessed some customer accounts after those customers failed to implement safeguards such as MFA and network access policies.

That explanation fits the available forensic findings. Mandiant also found no evidence that unauthorized access came from a compromise of Snowflake’s corporate systems.

Customers, however, bought a managed cloud service partly to reduce infrastructure and security burdens. When approximately 165 organizations can be exposed through similar account weaknesses, responsibility becomes more complicated than a configuration checklist.

A shared responsibility model divides security duties between a cloud provider and its customers. The provider protects the service, while customers manage identities, permissions, data, and certain configurations.

This division is necessary. A cloud vendor cannot decide which employee needs access to each customer dataset. It also cannot safely rotate every customer credential without understanding the applications that depend on it.

Yet a provider controls defaults, authentication options, alerts, documentation, administrative interfaces, and the rollout of mandatory protections. Those choices strongly influence whether customers make secure decisions.

Before Snowflake changed its policies, newly created accounts did not have a built-in authentication rule requiring every relevant user to enroll in MFA. Customers could enable protections, but availability did not guarantee adoption.

Snowflake later introduced a default policy requiring MFA enrollment for qualifying password users on new accounts. Its MFA documentation records the earlier state and the subsequent change.

The company has continued moving toward stronger authentication. Its current plans call for deprecating single-factor password access for human users and eliminating password authentication for service users.

Those steps amount to an important product judgment. Some controls are too important to remain optional, especially when a service concentrates sensitive data for thousands of businesses.

The reversal is subtle. Snowflake’s position that customers failed to use available controls can be factually correct. Its later decision to enforce stronger defaults also suggests that availability alone did not manage the risk adequately.

This does not make Snowflake responsible for malware installed on a contractor’s personal computer. Nor does it eliminate a customer’s duty to rotate leaked passwords and monitor privileged accounts.

It shows that cloud security outcomes emerge from both sides of the service boundary. A customer chooses users and permissions, but the provider designs the path of least resistance.

Contractor access illustrates the problem. Mandiant found cases where infostealers compromised contractor computers also used for personal activities, including gaming or pirated downloads.

One contractor may work with several organizations and hold elevated permissions in each environment. A single infected device can therefore expose credentials linked to multiple corporate accounts.

Security teams cannot assume that every identity originates from a managed employee laptop. They need controls that remain effective when an endpoint falls outside their direct supervision.

Providers face the same reality at a different scale. Authentication systems must expect that passwords will leak, users will reuse credentials, and some customers will postpone optional safeguards.

The techmeme Canadian case therefore challenges a narrow reading of shared responsibility. Assigning a duty does not ensure that thousands of customers will perform it consistently.

A safer model combines customer accountability with provider-enforced minimums. It also makes exceptions visible, time-limited, and difficult to create accidentally.

AT&T shows why cloud account security is enterprise security

The AT&T incident turned a compromised cloud account into a privacy event affecting nearly an entire national wireless customer base.

AT&T disclosed in July 2024 that threat actors had illegally downloaded records from a third-party cloud platform. The dataset covered calls and text messages during a six-month period in 2022, plus limited records from January 2023.

The company said the affected data included the telephone numbers involved in calls or text messages. Some records also contained cell-site identification numbers associated with interactions.

AT&T said the downloaded records did not include the content of calls or text messages. They also did not contain Social Security numbers, dates of birth, or other personal information such as names.

That limitation did not make the records harmless. Communications metadata can reveal relationships, routines, business contacts, and sensitive patterns even without message content.

AT&T said the data involved nearly all its wireless customers, customers of mobile virtual network operators using its network, and some landline customers who interacted with those numbers.

The company’s filing said it learned on April 19, 2024, that a threat actor claimed to have accessed and copied call logs. AT&T investigated and worked with law enforcement.

This was not a marginal dataset sitting in an isolated experimental system. It was information derived from the daily communications of a major telecommunications provider’s customer base.

The incident demonstrates why cloud data warehouses deserve the same security attention as production identity systems. Data platforms often hold copies drawn from numerous applications, even when they do not operate those applications directly.

Attackers understand that concentration. Instead of penetrating several operational systems, they can target the analytical repository where the organization has already combined valuable information.

The Snowflake campaign reportedly affected other recognizable organizations, including Ticketmaster parent Live Nation, Santander, Advance Auto Parts, Neiman Marcus, and LendingTree.

Different victims exposed different data because their Snowflake instances held different workloads. The repeatable element was identity compromise, not a single standardized dataset.

That pattern pressures enterprise buyers as much as Snowflake. Security reviews often focus heavily on a vendor’s encryption, certifications, availability, and vulnerability management.

Those controls matter, but they do not answer whether every human account uses phishing-resistant authentication. They also do not reveal whether old contractor credentials remain active.

Procurement teams should ask how a platform prevents single-factor access, distinguishes human and service identities, and detects logins from unexpected networks. They should examine whether privileged exports create immediate alerts.

Data owners also need to map what enters an analytical platform. A warehouse that quietly accumulates passport information, financial records, or communications metadata can become a higher-value target than its original risk classification suggests.

That inventory must include copies and derived datasets. Removing a field from an operational application does not protect an older export retained elsewhere.

A searchable internal record can help teams preserve decisions about data access and incident response. For example, a maintained engineering knowledge base can connect runbooks, ownership records, and prior security findings.

Documentation is not a security control by itself. It becomes useful when responders can quickly identify owners, dependencies, authentication exceptions, and the business purpose of exposed tables.

The AT&T example also complicates the phrase “third-party incident.” Customers rarely care which party operated the compromised account when their information appears in criminal hands.

Regulators, courts, and affected individuals examine the complete chain. That chain includes the data owner, the cloud provider, contractors, identity administrators, and anyone who left an unnecessary account active.

A guilty plea cannot settle the security accountability debate

Criminal accountability and defensive accountability answer different questions.

The Moucka prosecution asks whether named defendants committed specific federal offenses. The broader security debate asks which organizations were positioned to prevent or limit the attacks.

A guilty plea can provide evidence about tools, collaborators, payments, and victim selection. It may also support restitution claims and help investigators connect activity previously attributed only through technical indicators.

It cannot establish that every affected company had identical controls. Nor can it prove that one vendor policy would have stopped every incident in the wider campaign.

Public reporting also requires careful treatment of scale. Mandiant said approximately 165 organizations were potentially exposed and notified. The Justice Department’s case page describes alleged hacking schemes involving at least 10 victim organizations.

Those figures measure different scopes. Presenting all 165 as proven victims in Moucka’s admitted conduct would go beyond the public evidence available here.

The exact plea terms matter for the same reason. Readers should watch for the filed plea agreement and the court’s record of admitted facts, rather than assuming every original count remained intact.

Sentencing is also unresolved. Federal statutory maximums can produce large headline totals, but judges do not simply add every maximum and impose the result.

The court considers the offenses of conviction, sentencing guidelines, criminal history, victim losses, cooperation, restitution, and arguments from both parties. A reported exposure of “decades” describes legal risk, not a final sentence.

Snowflake’s security response deserves similar caution. Stronger MFA requirements reduce the risk from stolen passwords, but MFA is not a complete defense against modern social engineering.

Google threat researchers reported in 2026 that ShinyHunters-branded operations had expanded their tactics. Attackers used voice phishing and credential-harvesting sites to obtain single sign-on credentials and MFA codes.

Some operations persuaded help desks or users to approve malicious enrollment actions. Others captured session tokens, which can let an attacker operate after a legitimate authentication event.

That evolution weakens any claim that mandatory MFA closes the issue permanently. It does, however, remove the easiest version of the attack, where a reusable password provides direct access.

Security teams need phishing-resistant authentication for sensitive roles. Passkeys and hardware security keys bind authentication to legitimate sites more effectively than codes that users can relay.

They also need controls after login. Network restrictions, behavior analytics, short-lived sessions, export monitoring, and least-privilege permissions reduce the damage from a compromised identity.

Service accounts require separate attention. These nonhuman identities support applications and automated workflows, so interactive MFA usually does not fit their use.

Stronger alternatives include key-pair authentication, workload identities, narrowly scoped permissions, and automated credential rotation. Teams should prevent service credentials from becoming permanent master keys.

Data movement deserves dedicated monitoring. A user who suddenly enumerates many tables, creates temporary stages, compresses large exports, and retrieves them from a new location creates a detectable sequence.

Organizations should test whether those actions generate useful alerts. A nominal logging feature provides little protection if nobody receives the signal or knows how to investigate it.

Cloud providers can reduce ambiguity by supplying high-confidence detections as defaults. Customers can then tune those detections without designing every rule from scratch.

The techmeme Canadian report adds a legal milestone, but the skeptical conclusion remains necessary. Arresting and prosecuting individual operators does not dismantle the credential economy that supplied their access.

Infostealer logs remain abundant. Criminal groups can purchase old credentials cheaply, test them at scale, and concentrate effort on accounts that still work.

Defenders therefore need to treat password exposure as an expected event. The relevant question is whether a stolen credential remains useful long enough to cause material harm.

Three signals will show whether the Snowflake lessons endured

The next phase should be measured through court records, authentication enforcement, and evidence of repeated cloud attacks.

The first signal is Moucka’s written plea agreement and sentencing record. Those documents should define which conduct he admitted, the victims covered by that admission, and any agreed loss calculation.

A detailed factual statement would strengthen the public understanding of how the campaign operated. A narrow agreement would require continued caution when connecting Moucka to every incident attributed to UNC5537.

Sentencing will also show how prosecutors and the court value damage produced through stolen credentials. Restitution findings may reveal costs that public breach notices did not capture.

The second signal is Snowflake’s completion of its stronger authentication rollout. The most meaningful measure is not whether MFA features exist, but whether single-factor password access actually disappears from ordinary human accounts.

Exceptions deserve close scrutiny. Legacy business intelligence tools, reader accounts, trial environments, and service integrations can preserve weaker paths if organizations do not complete migrations.

Enterprise buyers should ask vendors for enforcement dates and exception inventories. They should also verify those answers through their own account configurations.

A successful transition would weaken the original attack path. Persistent exceptions or delayed enforcement would show that usability and compatibility pressures still outweigh the stated security goal.

The third signal is whether attackers reproduce the campaign against other software-as-a-service platforms. Mandiant warned in 2024 that UNC5537’s approach could extend beyond Snowflake.

Its later reporting showed that related extortion activity had already evolved toward voice phishing, single sign-on compromise, and theft from multiple cloud applications.

That evolution would reinforce the article’s central judgment. The lasting issue is not one vendor or one defendant, but the gap between centralized cloud data and inconsistent identity enforcement.

A decline in password-driven compromises would show that mandatory controls are working. Continued breaches through session theft or help-desk manipulation would shift attention toward phishing-resistant identity and post-login detection.

The techmeme Canadian story is therefore not merely the closing chapter of a 2024 hacking case. It is a test of whether cloud providers and customers changed the conditions that made the campaign repeatable.

Moucka’s reported guilty plea gives the criminal case a clearer answer about individual responsibility. The enterprise answer remains unfinished.

Security leaders should use the moment to verify every privileged account, remove dormant identities, restrict trusted networks, and monitor bulk exports. They should also ask vendors which protections are enforced rather than merely offered.

The final question is practical: if an employee or contractor password entered a criminal log tonight, which control would stop it tomorrow morning?