Audit logging for Snowflake account takeover
Audit logging only helps if it records the right edge of the event. For Snowflake customer data exfiltration, that means the login path, authentication method, IP, user agent, session creation, role changes, and data access after the session starts.
A stolen password with no enforced multi-factor authentication can produce a clean-looking session. The account opens, the role is accepted, the queries run, and the log reader gets a pleasant lie. The useful question is not whether someone signed in, but whether that sign-in matched the normal behaviour of that identity.
What good audit logs catch before the exfiltration starts
Good logs catch the change in pattern before the bulk download begins. A single account that authenticates from a new geography, a new ASN, or a fresh device fingerprint is not proof of compromise, but it is usually enough to merit a hard stop on any follow-on export.
The best signal is a chain, not a single event. A valid login, then a privilege check, then repeated COPY or UNLOAD style activity, then large result sets, then short-lived sessions that never touch the usual interactive workload. That sequence is common in takeover-led theft because the attacker wants volume, not finesse.
Session timing matters too. Access that lands outside the normal working window, followed by an immediate burst of reads from tables that the account rarely touches, is a better indicator than a single failed password attempt. Failed logins are noisy. Successful ones with a bad context are where the real damage starts.
The events that matter in Snowflake and the IAM trail around them
Snowflake logs only tell part of the story. The IAM trail around them matters just as much, because the useful evidence often sits with the identity provider, the MFA service, or the token broker rather than the warehouse.
Watch for:
- first-time login from a new source network
- MFA not present where it should have been
- password resets followed by immediate access
- role changes that expand read scope
- API or service account use that appears from an unusual host
- long export queries that match no normal analyst pattern
Those events matter because they describe intent. A real analyst can query a lot of data without trying to hide. An intruder with stolen credentials usually tries to get in, get the data, and get out before anyone notices the shape of the session.
Audit logging should preserve the join points between systems. If the identity provider sees a successful authentication and Snowflake sees a clean login, but the two timestamps, geographies, or devices do not line up, the account deserves attention. Half the work is spotting when a session is valid but absurd.
Gaps that let credential theft look normal
Password-only access is the obvious gap, and it is still the one that gets people hurt. If MFA is not enforced, stolen credentials remain useful long after a breach elsewhere. That was the weak point in the 2024 Snowflake-related intrusions, where stolen login details were used against customer accounts that did not enforce multi-factor authentication.
Weak logging makes the second gap. If logs do not keep enough detail to tie a login to a device, network, and identity event, a takeover can look like routine admin activity. That is how a compromised account walks out with terabytes while the dashboard stays calm.
Retention is another common failure. A lot of incident response depends on logs that were already rotated away. If the attacker spent days moving data, the investigation needs enough history to see the first bad login, not just the last download. Short retention turns a solvable event into a guessing game with nice charts.
Build detections and retention around real takeover behaviour
Detection rules should follow behaviour, not just volume thresholds. Large exports matter, but so do small early reads from unusual accounts, especially when they happen after a fresh authentication event or a password reset. A takeover often starts quietly because the attacker wants to test access before pulling the lot.
Set alerts for:
- logins without MFA where MFA is expected
- new source IPs paired with high-privilege roles
- immediate access to sensitive schemas after authentication
- sudden shifts from normal query shapes to bulk reads
- repeated access from short-lived sessions or unusual user agents
Keep the logs long enough to reconstruct the path from credential theft to exfiltration. If the warehouse is holding customer data exposure risk, the audit trail needs to survive the whole incident window, not just the latest rotation cycle. That means identity events, session data, and export activity all living long enough to line up without archaeology.
