They stole billions of records, including the call and text records of nearly all of AT&T’s wireless customers.
Connor Moucka, credential reuse, and the UNC5537 campaign
Connor Moucka pleaded guilty on August 5 to computer fraud, wire fraud, aggravated identity theft, and conspiracy after prosecutors say he and co‑conspirators used valid customer credentials — many years old — to log in to more than 165 Snowflake customer organizations. The campaign, attributed in reporting to UNC5537, did not exploit a Snowflake vulnerability; it relied on credentials that remained valid long after their exposure.
Snowflake’s phased deprecation and the SERVICE user type
Snowflake has moved to remove password authentication from non‑human accounts by deprecating the LEGACY_SERVICE user type and migrating such accounts to SERVICE, which cannot store a password. The vendor is running the change in three phases: September 2025–January 2026 required human users to present a second factor in Snowsight; May 2026–July 2026 required every newly created nonhuman user to be of type SERVICE; and August 2026–October 2026 begins account‑specific Phase 3 enforcement, when legacy service accounts in covered Snowflake accounts must migrate off password authentication by each account’s Phase 3 date.
Nobody's watching your logs at 2 AM.
Full SOC coverage without building one. Nubivance deploys and manages Rapid7 InsightIDR and MDR for organizations that need detection and response, not another dashboard.
Get coverageInventory and ownership: ACCOUNT_USAGE and what Snowflake can — and cannot — tell you
Snowflake exposes two concrete sources of truth for discovery: the ACCOUNT_USAGE schema, which stores the user list and their types, and a login history that records the client and source IP for each authentication attempt for 365 days. Together, those data give administrators the set of accounts that are still signing in with a password, when each last did so, and from where.
What Snowflake cannot provide is who asked for a service account, which systems depend on it, or who will accept pager calls if the account fails at 2 a.m. That contextual information often lives in the memory of the original requester, an old ticket, or nowhere at all — and that gap is the operational core of the migration challenge.
Choosing per‑account authentication: federation, key pairs, and role‑scoped tokens
Token Security and the source recommend against a one‑size‑fits‑all replacement. Snowflake offers four passwordless methods for SERVICE users; the practical advice in the material is to pick the method that fits each workload. Federation is the “default” where the workload can present an external identity to Snowflake. Key‑pair authentication or a role‑scoped token is the fallback where federation cannot be used — but the fallback must include network policy and a committed rotation schedule as part of the same change, not as deferred housekeeping.
The warning is explicit: migrating a long‑lived secret without network constraints and rotation policies will meet the Phase 3 deadline but recreate the same control failure in a new format.
Treat the replaced password as burned: Mandiant and Snowflake findings
Mandiant and Snowflake reported that at least 79.7% of the accounts used in the UNC5537 campaign had prior credential exposure. The earliest infostealer infection tied to one of those credentials dated to November 2020, and that password remained usable roughly three and a half years after it was stolen. The practical prescription is to assume a replaced credential is already in infostealer logs: search for reuse in secrets stores, CI variables, runbooks, and endpoints; revoke any dependent credentials; and reduce the account’s role scope during the cutover.
AI agents and the SERVICE_AGENT identity: governance questions repeat
Snowflake already recognizes automated AI agents as a distinct SERVICE_AGENT identity type. The label is new, but the control questions are familiar: who owns the agent, which identity does it use, what can it access, and when should that access end? The source frames Snowflake’s deadline as a preview of how much larger lifecycle and governance problems will grow as AI agents proliferate.
The facts in the record are simple: a campaign relied on long‑standing credential exposure; Snowflake has removed passwords from new non‑human users and is forcing migration for legacy service accounts; and forensic analysis shows most abused service credentials had prior exposure. The remaining work — discovering usage, assigning accountable owners, choosing appropriate authentication methods per account, and treating replaced secrets as compromised — is procedural and organizational, not purely technical. How quickly Snowflake customers convert that procedural work into durable governance will determine whether the next forced cutoff reveals holes or locks them shut.
Original reporting: https://www.bleepingcomputer.com/news/security/snowflake-ends-service-account-passwords-now-comes-the-hard-part/
