Data from Cloud Storage

This technique sits downstream of credential theft, not exploitation. In the UNC5537 campaign, Mandiant found the entry point was stolen Snowflake credentials, most harvested by infostealer malware families (Vidar, Lumma, Racoon Stealer, Redline, and others) running on non-Snowflake-owned machines, frequently a contractor's personal laptop outside any corporate monitoring. Roughly 80 percent of the compromised accounts had credentials already exposed in prior breach data, none had MFA enabled, and some passwords had not been rotated since 2020, which is why a years-old infostealer log became a live key to production data in 2024.

MITRE's own procedure examples show the same downstream position across unrelated actors: Scattered Spider enumerating cloud resources for exfiltration after gaining account access, and APT42 and AADInternals-driven operations collecting Microsoft 365 and OneDrive data once a session is already established. After the collection step, UNC5537 moved straight to monetization, listing stolen datasets from roughly 165 victim organizations for sale on cybercrime forums and running direct extortion against victims, which is the pattern that makes fast detection at the GetObject or query_history layer worth the tuning effort: by the time the data is staged, the attacker is close to done.

Cloud storage is read constantly by things that are not attackers. Scheduled ETL jobs, backup agents, S3 cross-region replication, and BI tools like Looker, Tableau, or dbt all generate high-volume GetObject calls or Snowflake SELECT statements as their entire job description. A rule that fires on volume alone will bury the SOC in legitimate batch traffic, especially around nightly or end-of-month processing windows when read volume spikes for everyone at once.

The fix is the same allow-list discipline that works for RMM tools: enumerate the service accounts, IAM roles, and Snowflake CLIENT_APPLICATION_ID values your environment actually runs on a schedule, and tune the anomaly threshold against activity outside that set. A known ETL role reading its usual buckets at 2 AM is noise; the same role reading a bucket it has never touched, or a human account suddenly running SnowSQL from an ASN with no prior login history, is signal. Cross-referencing recent infostealer or credential-exposure alerts against the account doing the reading turns a marginal anomaly into a high-confidence one.

When a cloud data-access alert fires, first establish whether the identity and pattern match a known, scheduled workflow: does this role or account have a documented ETL, backup, or BI job that explains the read? If the client application, source network, or table scope is one this account has never used, treat that mismatch as the real signal, not the raw volume number. Pull the account's recent login and query history to see how far the session has already gone, whether it is still reconnaissance (SHOW TABLES, small SELECTs) or already staging (temporary stage creation, compressed COPY INTO).

Escalate immediately once staging or export activity appears, since by that point the theft is close to complete rather than in progress. Revoke or force-rotate the credential and any associated API token or SAS token, terminate the active session, and enable MFA on the account if it was missing, since that gap is what let stolen credentials from years-old infostealer logs work in the first place. Preserve the query_history or CloudTrail record of exactly what was read, since scoping the breach for notification depends on knowing which tables or objects the session actually touched, not just that access occurred.