The accounts were the entry point
Mandiant's 10 June 2024 account of UNC5537 described data theft from Snowflake customer environments using compromised customer credentials. Its investigation did not find evidence that those incidents originated from a breach of Snowflake's enterprise environment. The Canadian Centre for Cyber Security likewise described identity-based activity and relayed the vendor's statement that the activity was not the result of a product vulnerability.
The important distinction is between a flaw in a cloud service and unauthorised use of a customer's valid account. Both can cause serious exposure, but their remediation routes differ. An organisation waiting for a product patch can lose time when the immediate problem is an accepted identity and the data it is authorised to export.
Mandiant reported that some credentials came from older infostealer infections and remained valid. That makes credential age operationally relevant: a compromised endpoint can create a risk that persists after the endpoint itself has been rebuilt.
Follow an account from sign-in to data export
A successful login is only the beginning of a useful investigation. Establish the account's role, the databases and objects it could access, and the activity performed during the relevant sessions. Join identity records with query and data-movement records where the platform makes them available.
Three boundaries deserve separate attention.
Authentication. Which factors and access restrictions were actually enforced for this account? Do not infer the answer from a company-wide MFA policy if service, legacy or exception accounts have a different path.
Authorisation. Which role was active, and what could it read or export? An account that legitimately needs limited query access may not need broad access across unrelated datasets. Review effective permissions, not only the role name chosen by its owner.
Data movement. What records show staging, export or download activity? A large query can be legitimate; an unfamiliar location can also have a benign explanation. Correlate the action, account, timing and expected workflow before labelling data as stolen.
An infostealer response should include connected services
When a workstation is suspected of credential theft, rebuilding the machine addresses its local state. It does not invalidate every password, token or session that could have been observed there. Maintain a list of services the user or process could access and use it to guide revocation and credential replacement.
This need not become an indiscriminate reset of every account in the organisation. Start with the authority plausibly available to the affected environment, prioritise powerful or long-lived credentials, and record the evidence supporting scope decisions. Keep recovery credentials away from systems still considered untrusted.
The tj-actions incident exposed credentials in build output. The acquisition route differs, but the cleanup problem is similar: restoring the machine or workflow does not revoke the authority already copied from it.
Service accounts need an owner and a retirement path
Automated data workflows can accumulate credentials that nobody reviews during ordinary workforce access checks. Each account should have a named operational owner, documented purpose, authentication method, effective permissions and a process for replacement or retirement.
A useful review asks what would happen if the account appeared in a credible credential-exposure report today. Could the owner identify the jobs using it, rotate it without uncontrolled outages, and inspect its recent activity? A secret stored in a vault is still difficult to recover if its dependencies are undocumented.
Inspect the login history within a defined window
A narrow, read-only starting query
For an authorised role with access to Snowflake's Account Usage views, a bounded login-history query can help locate activity for review:
SELECT EVENT_TIMESTAMP, USER_NAME, CLIENT_IP, IS_SUCCESS
FROM SNOWFLAKE.ACCOUNT_USAGE.LOGIN_HISTORY
WHERE EVENT_TIMESTAMP >= DATEADD('day', -7, CURRENT_TIMESTAMP())
ORDER BY EVENT_TIMESTAMP DESC
LIMIT 100;
Check the current Snowflake documentation for view privileges, retention and latency before relying on the result. The query reads metadata; it does not revoke sessions, change permissions or prove that a login was malicious. A limit of 100 rows is convenient for an initial inspection but can omit relevant activity in a busy account.
For the actual investigation, define the account population and time window, preserve appropriate records and correlate sessions with authorised workload expectations. Do not copy account names, source addresses or raw query text into a public report simply because the underlying example is read-only.
An empty result needs interpretation. It can reflect the chosen time range, view availability, privilege scope or data latency. It cannot be converted into a conclusion that no unauthorised access occurred.
Join authentication evidence to the data owner's decision
Suppose a synthetic service account shows an unfamiliar successful login. The identity owner can assess the authentication context, but the data owner is needed to explain the datasets and exports the account was permitted to access. The application owner can identify the normal jobs using it.
Bring those three views together before deciding the exposure scope or replacing an account on which production depends. The result should identify known activity, plausible authority and unresolved data-access questions separately. That supports both incident response and a controlled credential replacement without inventing a precise theft count from incomplete telemetry.
Count evidence, not customer populations
Notification populations, attempted targets and confirmed data theft are different measurements. The public incident record does not support treating every customer of the platform as a victim, nor does an organisation's presence in a notification process establish a measured amount of stolen data.
For a local handover, record the affected identities, enforced controls, relevant session and query findings, credentials replaced and unresolved data-access questions. That gives the next team a basis for action. A generic cloud-breach label does not tell it which authority remains usable.