Hacker confirms access through infostealer infection [withdrawn]
A security firm claimed that a Snowflake sales engineer’s stolen credentials enabled attackers to access data from hundreds of Snowflake customer accounts, potentially tying recent breaches at companies like Ticketmaster and Santander to a single infostealer infection. Commenters scrutinize the technical plausibility of such broad access from one employee account, contrast the firm’s allegations with Snowflake’s more limited official statement about credential‑stuffing and demo accounts, and note that the original blog post has since been withdrawn. The incident prompts broader concern about identity‑based attacks, weak or optional MFA, overprivileged access for sales and support staff, and the ethics of threat‑intelligence vendors that buy data from criminals and publicly expose individual employees.
Alleged Breach and Scope
- Thread centers on claims that a data theft affecting Ticketmaster, Santander, and possibly many others involved Snowflake-hosted data and a stolen Snowflake employee credential via an “infostealer” malware.
- Some commenters treat this as potentially “one of the largest breaches ever” if a privileged account really allowed broad access.
- Others note that screenshots in the article mostly showed demo-like data, making “hundreds of breached customers” seem overstated.
Disputed Root Cause
- Hudson Rock’s post claims: malware stole a Snowflake sales engineer’s credentials and session cookies; attacker accessed ServiceNow, bypassed Okta/MFA, generated tokens, and exfiltrated many customers’ data.
- Snowflake’s official communication says impacted access came from customer credentials exposed elsewhere, not from a product vulnerability or misconfiguration, and that a compromised demo account did not contain sensitive data.
- Commenters highlight this as a direct conflict: internal-employee-centric mega-breach vs. multiple customer-side credential compromises.
- Extent of any access to real production data remains unclear in the thread.
Snowflake Architecture & Access Practices
- Multiple participants say Snowflake employees normally cannot read customer data unless explicit, time-bounded access is granted, and customers can own encryption keys.
- Others describe common practice where sales engineers create demo accounts and sometimes ingest or are shared customer data, potentially with weak controls or non-expiring access.
- Concerns raised about:
- Optional rather than enforced MFA.
- Session/refresh token expiry.
- Lack of rate/volume limits and egress monitoring on support/demo accounts.
- Customers misconfiguring network access and roles.
Hudson Rock’s Role and Credibility
- Several commenters question Hudson Rock’s reputation, citing prior low-effort breach “blogspam” and bans elsewhere.
- The article is criticized for:
- Doxing the specific employee whose machine was infected.
- Including a chat snippet where the attacker endorses buying Hudson Rock’s services, seen as a marketing plug or even collusion.
- The post was later withdrawn without an explicit retraction, which further reduces trust in their account for many participants.
Security Lessons & Reactions
- Strong themes: principle of least privilege; mandatory MFA; short-lived tokens; strict approval and expiry for employee access to customer data; network restrictions.
- Some compare this to past “cloud provider was blamed but customer misconfig was root cause” incidents.
- There is debate on whether not paying ransom is wise; many doubt criminals’ promises regardless.
- Overall sentiment: whatever the exact facts, a single compromised workstation leading to large-scale access indicates serious systemic and process weaknesses.