EN
en direct

Snowflake : un Canadien plaide coupable pour le vol de données de 165 organisations, 100 millions d’individus affectés

Le **5 août 2026**, **Connor Riley Moucka**, 26 ans, a plaidé coupable devant un tribunal fédéral américain pour son rôle dans le piratage de comptes **Snowflake**. Avec son complice **John Erin Binns**, il a exfiltré des téraoctets de données chez **165 organisations** en exploitant l’absence de **MFA**. Le verdict tombe deux ans après les faits — la leçon pour les équipes cloud est sans appel.

Une clé USB noire posée sur une surface anthracite, son connecteur légèrement tordu, un point lumineux ambre sur le circuit imprimé apparent

5 août 2026, 17 h 53 EDT. Connor Riley Moucka, 26 ans, alias Waifu, se tient devant un tribunal fédéral américain et plaide coupable de quatre chefs d’accusation : fraude informatique, fraude électronique, vol d’identité aggravé et association de malfaiteurs. Son crime — avoir siphonné les données de 165 organisations hébergées chez Snowflake entre février et octobre 2024, affectant plus de 100 millions d’individus et causant 9,5 millions de dollars de pertes.

L’affaire Snowflake n’est pas une attaque zero-day. C’est une leçon magistrale sur l’hygiène de sécurité cloud — et la conséquence directe d’une confiance excessive dans les défenses périmétriques sans le filet de sécurité le plus basique qui soit.

L’anatomie d’un braquage sans effraction

Le modus operandi de Moucka et Binns était d’une simplicité désarmante :

  1. Récolte d’identifiants. Via des infostealers — des malwares qui aspirent les mots de passe stockés dans les navigateurs — les attaquants ont collecté des couples identifiant/mot de passe valides pour des comptes Snowflake.
  2. Connexion directe. Les comptes visés n’avaient pas de MFA activée. Un simple login/mot de passe suffisait pour accéder à l’environnement cloud.
  3. Reconnaissance automatisée. Une fois connectés, Moucka et Binns utilisaient un logiciel personnalisé pour cartographier les instances : noms d’organisation, rôles utilisateur, adresses IP, chemins de stockage.
  4. Exfiltration massive. Plusieurs téraoctets de données ont été téléchargés depuis les tenants Snowflake.
  5. Extorsion. Les victimes ont été contactées pour payer une rançon en bitcoin. Au moins trois organisations ont cédé, pour un total de 2,5 millions de dollars. Moucka a également revendu les données sur des forums de hackers, empochant 495 000 dollars supplémentaires.

Les données volées incluaient des historiques d’appels et SMS, des informations bancaires et financières, et d’autres données personnelles identifiables (PII).

Les victimes : un who’s who des géants américains

La liste des organisations touchées illustre l’ampleur de la compromission :

OrganisationSecteur
AT&TTélécommunications
TicketmasterBilletterie/divertissement
SantanderBanque
Pure StorageStockage IT
Advance Auto PartsDistribution automobile
Neiman MarcusLuxe/retail
Los Angeles UnifiedÉducation publique
QuoteWizard/LendingTreeFintech

« Dans au moins un cas, Moucka a extorqué une seconde fois une victime avec des menaces de divulgation supplémentaire des données volées », précise le Département de la Justice américain.

Moucka a utilisé les données volées d’un officier gouvernemental et des membres de sa famille immédiate dans cette tentative de ré-extorsion — un niveau de nuisance qui dépasse le simple appât du gain.

Pourquoi le MFA n’était pas activé

La question qui brûle les lèvres de tout RSSI : pourquoi 165 organisations — dont des géants comme AT&T et Santander — n’avaient-elles pas activé le MFA sur leurs comptes Snowflake ?

La réponse est probablement multifactorielle :

  • Snowflake ne l’imposait pas à l’époque. Avant ces incidents, la plateforme recommandait le MFA sans le rendre obligatoire. Depuis, Snowflake a annoncé qu’il le rendrait obligatoire et a imposé des mots de passe d’au moins 14 caractères.
  • Comptes de service et automatisation. Les pipelines de données utilisent souvent des comptes de service pour lesquels le MFA est jugé « trop complexe » à intégrer. C’est un arbitrage qui coûte cher à l’épreuve des faits.
  • Fausse sensation de sécurité. Les données sont dans le cloud, derrière un fournisseur « enterprise-grade » — pourquoi s’inquiéter ? Cette attitude est précisément ce que les attaquants exploitent.

La réponse Snowflake et les leçons pour les équipes cloud

Snowflake a réagi après les faits en imposant, dans ses terms of service mis à jour, l’activation obligatoire du MFA pour tous les comptes et en renforçant les exigences de complexité des mots de passe. Mais la responsabilité ne s’arrête pas au fournisseur.

Trois actions concrètes pour les équipes cloud :

  1. MFA universel. Aucune exception — comptes de service inclus. Utilisez des solutions de MFA programmatique (certificats, aws-sdk avec MFA token, HashiCorp Vault) pour les pipelines CI/CD.
  2. Audit continu des accès. Activez les logs d’accès (Snowflake LOGIN_HISTORY, QUERY_HISTORY) et corrélez-les avec vos SIEM. Une connexion depuis une IP inconnue sans MFA doit générer une alerte critique en moins de 5 minutes.
  3. Rotation des credentials et infostealer awareness. Les mots de passe volés via infostealer ont permis l’attaque. Imposez une rotation régulière, interdisez le stockage de credentials dans les navigateurs sur les postes professionnels, et déployez un EDR capable de détecter les infostealers.

Verdict

L’affaire Moucka est close côté judiciaire — il encourt jusqu’à 32 ans de prison, la sentence étant prévue pour le 27 octobre 2026. Mais la leçon pour les équipes cloud est permanente.

Si vos données sont hébergées chez Snowflake — ou tout autre fournisseur SaaS/cloud — et que vous n’avez pas activé le MFA sur 100 % de vos comptes, arrêtez de lire cet article et activez-le. Maintenant.

Si vous gérez un pipeline de données en production, remplacez les comptes de service à mot de passe fixe par une authentification programmatique couplée à un secret manager. Les 2,5 millions de dollars extorqués à trois victimes auraient été impossibles si un simple second facteur avait été exigé.

Le cloud ne pardonne pas l’hygiène de sécurité minimale.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

AWS lance AgentCore Runtime Instances — le compute persistant élimine le cold start des agents IA en production

Présenté au **AWS Summit New York** le **7 août 2026**, **AgentCore Runtime Instances** apporte un compute stateful et persistant aux agents **Bedrock**, supprimant le *cold start* qui pénalisait les déploiements temps réel. Si vos agents IA mettent plus de trois secondes à répondre, le problème vient probablement de votre infrastructure — et AWS vient de le résoudre.

← Retour au fil

Tapez au moins deux caractères.

naviguer ouvrir esc fermer