Analyse · Identité
ShinyHunters : une arrestation, et ce qui ne change pas
Un chef présumé de ShinyHunters a été arrêté aux Pays-Bas. Les méthodes du groupe, comptes SSO, tiers et plateformes SaaS, restent ouvertes aux autres.
Par Sentrix · Publié le 2026-10-05
Le 29 septembre 2026, la police nationale néerlandaise a annoncé l'arrestation, le 15 septembre, d'un homme de 24 ans d'Amsterdam soupçonné de participer à une organisation criminelle liée à ShinyHunters. Le même jour, le FBI a présenté le suspect comme l'un des chefs présumés du groupe. Une arrestation compte. Elle ne ferme pas pour autant les portes que ce groupe a utilisées.
Ce que disent les autorités
La police néerlandaise. Le communiqué indique que le tribunal de Rotterdam a ordonné le maintien en détention du suspect pour au moins 90 jours de plus, que des supports de données ont été saisis et que l'enquête se poursuit. La police et le ministère public y invitent les entreprises à renforcer leur sécurité numérique par des mesures préventives.
Le FBI. Brett Leatherman, directeur adjoint de la Cyber Division, a déclaré : « Today, our partners at the Dutch National Police announced the arrest of one of the alleged leaders of ShinyHunters. » Selon le FBI, cité par CyberScoop, le suspect et ses complices présumés auraient compromis plus de 140 organisations depuis l'an dernier et obtenu au moins 70 millions de dollars en paiements d'extorsion. Au reste du groupe, il a adressé un avertissement direct : « The longer you stay in this, the more we learn about you. »
Les méthodes. BleepingComputer résume le mode opératoire attribué au groupe : viser les comptes SSO d'entreprise, les fournisseurs tiers et les plateformes SaaS comme Salesforce et Snowflake, voler des données, puis menacer de les publier.
Pourquoi ça compte
Aucune de ces méthodes ne repose sur un savoir que l'arrestation fait disparaître. Prendre un compte SSO demande un mot de passe, une MFA qui se laisse contourner, ou un centre d'assistance qui réinitialise sans vérifier. Passer par un fournisseur demande qu'il détienne un accès que personne ne surveille. Vider une plateforme SaaS demande qu'une application connectée ou un compte de service puisse exporter en volume sans alerte.
Ce sont des failles de gouvernance de l'identité, pas des vulnérabilités logicielles. Elles restent ouvertes à quiconque reprend le même manuel, et l'enquête néerlandaise comme l'avertissement du FBI disent clairement que le groupe ne se résume pas à une personne.
Le chiffre du FBI rappelle aussi l'économie de ce modèle : l'extorsion paie quand la victime n'a ni décidé à l'avance comment répondre, ni les journaux qui permettent de savoir ce qui est vraiment sorti.
Ce que nous en pensons chez Sentrix
Dans l'ordre :
- Rendre le SSO résistant à l'hameçonnage. Clés d'accès ou clés FIDO2 pour tous les comptes qui ouvrent le SSO, administrateurs d'abord. Notre article sur la MFA résistante à l'hameçonnage détaille le déploiement.
- Fermer la porte du centre d'assistance. Aucune réinitialisation de MFA ou de mot de passe sans rappel à un numéro déjà inscrit au dossier. La règle s'écrit, se forme et se vérifie.
- Revoir les applications connectées de chaque plateforme SaaS. Qui a un jeton OAuth, avec quelles permissions, et quand il a servi la dernière fois. Ce qui ne sert plus se révoque.
- Surveiller les exportations. Une alerte sur tout téléchargement ou requête en volume inhabituel, par utilisateur et par application, est le dernier filet avant l'extorsion.
- Tenir le registre des tiers qui détiennent un accès. C'est le chemin décrit dans les quatre 8-K de septembre. Notre module de gestion des tiers tient ce registre et ses preuves, et le module CTEM d'exposition continue garde à jour l'inventaire des identités et des accès exposés.
- Décider de la réponse à l'extorsion avant l'incident. Qui décide, sur quels critères, avec quel conseiller juridique et quels avis aux autorités.
Pour un MSP ou un MSSP, l'enjeu est multiplié : un seul compte SSO compromis chez le fournisseur peut ouvrir les consoles de tous ses clients. Accès séparés par client, MFA résistante à l'hameçonnage pour tout le personnel et journal de chaque connexion, c'est le minimum que vos clients vous demanderont.
La prochaine étape
Dressez la liste de vos comptes qui ouvrent le SSO et des applications connectées à vos plateformes SaaS, puis notez pour chacun le type de MFA et la date de la dernière revue. Les lignes sans réponse sont votre plan de travail. Si vous voulez que nous fassions la revue avec vous, voyez notre service identité et accès ou contactez-nous.
Sources
Questions fréquentes
- L'arrestation réduit-elle le risque pour mon organisation ?
- Peu, à court terme. La police néerlandaise parle d'un suspect parmi un groupe, l'enquête se poursuit et le FBI s'adresse publiquement aux membres restants. Les méthodes attribuées au groupe, prise de comptes SSO d'entreprise, passage par des fournisseurs tiers et vol de données dans des plateformes SaaS, ne demandent ni outil rare ni vulnérabilité inédite. D'autres équipes les pratiquent déjà.
- Quel contrôle protège le mieux un compte SSO ?
- Une authentification multifacteur résistante à l'hameçonnage, par clé d'accès ou clé matérielle FIDO2, pour tous les comptes qui ouvrent le SSO, à commencer par les administrateurs. Elle s'accompagne d'une règle stricte au centre d'assistance : aucune réinitialisation de MFA ni de mot de passe sans vérification par rappel à un numéro déjà connu ou en présence d'un gestionnaire.
- Pourquoi un MSP ou un MSSP est-il particulièrement exposé ?
- Parce qu'un seul compte SSO chez le fournisseur ouvre souvent les consoles de tous ses clients. Le groupe cible justement les fournisseurs tiers pour atteindre plusieurs victimes. Un MSP doit isoler ses accès par client, imposer la MFA résistante à l'hameçonnage à son personnel et pouvoir dire, pour chaque client, qui peut se connecter et d'où.
Parlons de votre programme de conformité.
Dernière mise à jour : 2026-10-05
