Snowflake 2024 : 560 M de comptes exposés faute de MFA — leçons pour la France
AT&T, Ticketmaster, Santander : 160 organisations Snowflake compromises en 2024 par UNC5537 via des credentials volés sur Telegram. Cause unique : MFA non imposée. Comment UniSOC monitore les fuites credentials en continu.
Snowflake 2024 : 560 millions de comptes Ticketmaster volés à cause d'une absence de MFA
TL;DR — Entre avril et juin 2024, le groupe UNC5537 / Scattered Spider / ShinyHunters a compromis 160 organisations clientes de Snowflake sans casser une seule fois la défense de Snowflake. Méthode : achat de credentials volés par infostealers (Lumma, RedLine, Raccoon) sur des marketplaces criminelles, login direct sur les instances Snowflake clientes. Aucune MFA n'était activée. Victimes : Ticketmaster (560 M de comptes), AT&T (logs téléphoniques de quasi tous ses clients sur 6 mois), Santander, Neiman Marcus, Lending Tree, Advance Auto Parts. Coût en cumul des recours collectifs : plusieurs milliards de dollars.
La double leçon Snowflake
Le breach Snowflake de 2024 raconte deux histoires différentes en parallèle :
- L'histoire technique : un attaquant a acheté des credentials volés et s'est logué. Pas de 0-day, pas de zero-click exploit, pas d'APT sophistiqué. Du brute-force trivial sur des comptes laissés sans MFA.
- L'histoire commerciale : Snowflake n'imposait pas la MFA par défaut. Le SaaS partait du principe que ses clients « savaient ce qu'ils faisaient ». 160 d'entre eux ne savaient pas. Snowflake a changé sa politique en juillet 2024, mais après les faits.
Cette deuxième histoire est la plus importante : elle explique pourquoi les conditions par défaut d'un fournisseur cyber peuvent générer des breaches massifs sans qu'aucun attaquant fasse preuve d'ingéniosité particulière.
Anatomie de l'attaque
Phase 1 — Collecte des credentials (mois → années avant 2024)
Des milliers d'employés à travers le monde ont été infectés par des infostealers (Lumma, RedLine, Raccoon, Vidar). Ces malwares s'installent via :
- Cracks de logiciels piratés (« cracked Photoshop »).
- Faux installeurs (« VPN gratuit »).
- Phishing classique avec attachement malveillant.
- Drive-by download sur des sites compromis.
Une fois installé, l'infostealer dump :
- Tous les credentials enregistrés dans les browsers (Chrome, Edge, Firefox).
- Les cookies de session (permettant le login sans mot de passe).
- Les wallets crypto, les fichiers
nommés "passwords", les SSH keys..txt
Ces dumps sont vendus en lots sur des marketplaces : Russian Market, 2easy, Genesis Market (avant son démantèlement), et de plus en plus sur des canaux Telegram dédiés.
Phase 2 — Identification des cibles Snowflake
Les attaquants UNC5537 ont filtré les credentials récupérés pour identifier ceux contenant la chaîne
snowflakecomputing.comPhase 3 — Login + exfiltration
Pour chaque cible :
- Login direct sur l'instance Snowflake avec le credential volé.
- Énumération des bases (
,SHOW DATABASES
).SHOW SCHEMAS - Export massif via
vers un bucket S3 ou Azure attaquant.COPY INTO - Vente des données sur BreachForums ou demande de rançon par email à la victime.
Aucune étape ne nécessitait de privilèges admin chez Snowflake. C'était littéralement « quelqu'un qui se connecte à votre application ».
Phase 4 — Monétisation publique
Pour Ticketmaster, le groupe ShinyHunters a annoncé sur BreachForums 560 M de comptes à vendre pour 500 000 $. Le sample fourni contenait nom, email, téléphone, adresse, derniers 4 chiffres de carte. AT&T a payé une rançon (montant non communiqué) pour faire supprimer une partie des données.
Pourquoi 160 organisations ont laissé ce risque ouvert
1. La MFA n'était pas imposée
C'est la cause racine, et elle relève à 80 % de Snowflake. Tout SaaS critique en 2024 doit imposer la MFA par défaut, sans option de désactivation pour l'admin du compte. Snowflake a changé sa politique en juillet 2024 — trop tard pour les 160 victimes.
2. Les organisations n'auditaient pas les login Snowflake
Aucune des 160 victimes n'a détecté l'attaque par elle-même. Toutes ont été notifiées par Snowflake ou par la presse plusieurs semaines après. Cela signifie : aucune n'avait connecté Snowflake à son SIEM, ou aucune ne regardait les logs.
3. Les credentials volés n'étaient pas monitorés
Toutes les fuites de credentials qui ont mené à ces breaches étaient publiquement vendues sur des marketplaces criminelles avant l'attaque. Aucune des 160 organisations n'avait de service de monitoring de fuites qui aurait alerté « le credential
john.doe@victime.com4. Les sessions n'étaient pas géo-fences
Les attaquants se connectaient depuis des IP en Europe de l'Est, en Asie. Aucune des victimes n'avait de politique de restriction géographique sur Snowflake (« mes employés sont aux US, donc bloquer les login depuis hors US »).
5. Les rotation de mots de passe étaient inexistantes
Beaucoup de credentials volés étaient valides depuis 12 à 36 mois. Les politiques modernes recommandent de ne plus rotater les mots de passe arbitrairement (NIST 800-63B), mais cela suppose MFA active + monitoring de compromis. Sans ces deux conditions, la rotation reste pertinente.
Ce que devrait faire tout SOC en 2026
Couche 1 : MFA dure partout
Pour tout SaaS contenant des données business : MFA obligatoire, sans option de désactivation par l'admin du compte. Préférer WebAuthn / FIDO2 / passkeys au TOTP (immune au phishing). C'est l'un des contrôles socle de la plateforme SOC managé UniSOC.
Couche 2 : Monitoring de fuites de credentials en temps réel
Service qui scanne les marketplaces criminelles, les dumps Telegram, les paste-bins. Alerte dès qu'un credential lié à votre domaine apparaît. Coût : modeste (HaveIBeenPwned API, Hudson Rock, XposedOrNot, IntelligenceX). ROI : massif.
Couche 3 : Detection « impossible travel » + géo-fences
Login depuis Paris à 14h, login depuis Bucarest à 14h05 → alert immediate. Si vos employés ne voyagent jamais hors UE, restreindre les login depuis hors UE.
Couche 4 : Audit log centralisé
Tout SaaS critique connecté à un SIEM. Logs de login, de download massif, de modification de permissions. Règles de détection sur les patterns « download massif depuis IP nouvelle ».
Couche 5 : Politique d'export
Limiter le volume de données exportable par session (ex : max 10 000 lignes / 5 min). Les exfiltrations massives ressortent immédiatement.
Comment UniSOC adresse les 5 couches
MFA dure
Portail client UniSOC : MFA obligatoire (TOTP + WebAuthn pour roles admin). Aucun bypass possible côté admin du tenant.
Monitoring fuites credentials
Notre pipeline Telegram OSINT (livré 2026-04-24) scanne 20+ canaux de stealers en continu. Match automatique sur les domaines des tenants. Si
*.votre-domaine.frcredential_exposureImpossible travel + géo-fences
Worker UEBA dans la stack
backend/dpi_ingestion/workers/Audit log centralisé
Tout login admin sur le portail UniSOC est loggé avec IP, géo (DB-IP city), user-agent (Udger v4 parsing), MFA factor utilisé. Retention 90 jours minimum, exportable client.
Politique d'export
Le portail client UniSOC limite naturellement les exports CSV (paginé, max 10k rows par appel) et logge chaque export dans l'audit trail.
Ce que la presse n'a pas raconté : la vraie facture
Au-delà des 22 M$ de rançon Change Healthcare ou des 500 k$ demandés par ShinyHunters pour Ticketmaster, le coût réel des breaches Snowflake a été :
| Poste | Estimation cumulée 160 victimes |
|---|---|
| Notifications individuelles obligatoires (FTC, équivalents EU) | > 200 M$ |
| Forensics + IR externe (Mandiant, CrowdStrike, etc.) | > 150 M$ |
| Recours collectifs (Ticketmaster seul : > 12 class actions) | > 1 Md$ projetés |
| Régulateurs (amendes RGPD, FTC, état-fédéral US) | > 300 M$ |
| Perte de capitalisation boursière (Ticketmaster -10 %, AT&T -5 %) | > 5 Md$ |
Total : largement plus de 6 Md$ de dommages cumulés, pour une attaque qui aurait été stoppée par une case "MFA obligatoire" cochée chez Snowflake.
Conclusion
Le breach Snowflake n'est pas une histoire d'attaquants brillants. C'est une histoire de conditions par défaut négligées côté éditeur, doublée de pratiques d'hygiène manquantes côté clients. C'est exactement le genre de scénario qu'un SOC moderne, bien outillé, doit rendre structurellement impossible.
Trois choses que vous pouvez faire cette semaine :
- Audit MFA sur tous les SaaS contenant des données business : pour chacun, vérifier que MFA est imposée par défaut.
- Souscrire à un service de monitoring de fuites de credentials. Ne pas attendre que le credential soit exploité.
- Connecter chaque SaaS critique à votre SIEM et écrire les règles de détection sur les patterns d'exfiltration.
Si vous ne faites pas ces trois choses, vous êtes statistiquement la 161ème victime du prochain breach SaaS de masse — un scénario que notre offre entreprises prévient en intégrant les 5 couches dès l'onboarding.
À lire aussi : Pipeline IoC depuis Telegram et BYOD et Shadow IT.
Vous voulez un audit MFA + fuites de credentials sur votre périmètre ? Demandez notre scan gratuit "Credential Exposure" → — résultat sous 48h, format PDF, niveau d'exposition par domaine.
