Comptes et authentification
Particuliers et entreprisesRéutilisation automatisée d’identifiants volés
Credential stuffing
Des mots de passe déjà divulgués sont essayés sur d’autres services.
Je pense être concerné : que faire ?
Comprendre et agir
À la fin de cette lecture, vous pourrez expliquer le piège et choisir une première réaction adaptée à votre rôle. Aucun prérequis informatique n’est nécessaire.
Une situation concrète
Un ancien service que vous utilisiez subit une fuite. Votre adresse et votre mot de passe sont récupérés puis essayés sur une boutique, un réseau social et votre messagerie. Si vous réutilisez la même combinaison, un incident extérieur peut ouvrir plusieurs comptes.
Comment cela fonctionne
Le credential stuffing réutilise des identifiants déjà connus, contrairement à une recherche qui devine le mot de passe. L’attaquant automatise les essais sur d’autres services. La meilleure séparation consiste à utiliser un mot de passe différent pour chaque compte. Modifier uniquement le mot de passe du service qui annonce la fuite laisse les autres comptes vulnérables si l’ancien secret y fonctionne encore.
- Un ancien secret fuit
Il provient parfois d’un autre site.
- La combinaison est réessayée
Plusieurs services sont ciblés.
- La réutilisation ouvre un compte
Un secret unique limite la propagation.
Les signes qui doivent attirer l’attention
- Des alertes de connexion apparaissent sur plusieurs services après une fuite.
- Des tentatives arrivent avec votre adresse sur des comptes rarement utilisés.
- Un accès inconnu suit l’utilisation d’un mot de passe partagé entre plusieurs sites.
Ces signes invitent à vérifier la situation. Pris isolément, ils ne prouvent pas tous qu’une attaque a réussi.
Ce que vous pouvez faire
Vos premiers réflexes
Utilisez un mot de passe unique par compte. Après une fuite, changez partout les mots de passe réutilisés, en commençant par votre messagerie.
Si vous êtes responsable du service ou de l’organisation
Détectez les essais répartis sur plusieurs comptes, y compris les succès rapides. Vérifiez les achats, exports et changements de profil après une connexion suspecte.
Un mot de passe complexe devient inefficace sur les autres services dès qu’il est connu et réutilisé.
À vous de décider
Votre mot de passe est très complexe mais identique sur deux sites. Une fuite du premier expose-t-elle le second ?
Choisissez votre réponse et expliquez pourquoi avant de lire la correction.
Voir la réponse expliquée
Oui. L’attaquant n’a plus besoin de le deviner : il essaie directement la combinaison divulguée. La complexité ne compense pas la réutilisation.
Analyser un cas technique
Pour les personnes qui développent, administrent ou analysent les systèmes concernés. Commencez par « Comprendre et agir » si ces notions sont nouvelles pour vous.
Étude de cas fictive
Des identifiants volés ailleurs sont essayés sur votre service
Le credential stuffing exploite la réutilisation des mots de passe. L’attaquant possède déjà des couples identifiant–mot de passe issus d’une autre fuite et les essaie sur un nouveau service. Il peut réussir du premier coup : un détecteur fondé uniquement sur les nombreux échecs d’un même compte verra peu de choses.
Dans le cas présenté, 120 adresses IP se répartissent les essais sur 850 comptes. Les 31 succès demandent un examen, en particulier lorsqu’ils sont suivis d’un changement d’adresse de livraison ou d’un export. Ces actions donnent davantage de poids au soupçon qu’une simple connexion depuis un réseau inconnu.
L’analyse doit rapprocher les tentatives à l’échelle du service : cadence, appareils, caractéristiques du client et succession des opérations. Une adresse IP peut changer à chaque essai, tandis que plusieurs utilisateurs légitimes partagent la même sortie réseau. Les décisions de blocage doivent tenir compte de ces deux situations. La MFA réduit le risque, mais il faut vérifier qu’elle couvre aussi les anciens protocoles et les parcours de récupération.
Le déroulement en schéma
Faites défiler le diagramme pour suivre les échanges ; les noms des acteurs restent en haut. Sur petit écran, faites aussi défiler de gauche à droite.
- Action
Tentatives réparties sur 850 comptes
Automatisation vers Protection d’accès
Trace cluster=c4
- Action
Faible volume par identité
Protection d’accès vers Authentification
- Action
31 sessions acceptées
Authentification vers Actions métier
Trace Succès à qualifier
- Action sur place
Adresse ou profil modifié rapidement
Actions métier
Trace u70 / u71
- Refus / blocage
Vérification supplémentaire des connexions suspectes
Protection d’accès vers Automatisation
Trace Mesure des faux positifs
- Action
Réauthentification d’une action sensible
Actions métier vers Authentification
Comment repérer cette attaque
Indices à rechercher
Chercher des vagues d’essais portant sur de nombreux comptes, même avec peu d’échecs par compte, puis des changements de profil, achats ou exports inhabituels après connexion.
Éléments à croiser
Regrouper les tentatives sur le service et la période, puis examiner les premières actions des comptes connectés. Un enchaînement connexion → modification sensible est plus instructif que le seul taux de succès.
Limites de l’interprétation
Les logs ne permettent pas de vérifier que le mot de passe provenait d’une fuite externe. Un grand nombre de sources et de comptes constitue un motif d’enquête, pas une preuve de réutilisation d’identifiants.
Comment réagir
Limiter les tentatives suspectes et renforcer la vérification des changements sensibles. Révoquer les sessions compromises et accompagner les titulaires pour remplacer les secrets réutilisés. Rechercher aussi une éventuelle fuite interne : le profil de la campagne ne permet pas, à lui seul, de connaître l’origine des identifiants.
Vérifier la correction
Ces contrôles s’adressent à l’équipe responsable du système. Les simulations se préparent dans un environnement de test autorisé ; la lecture du cas ne nécessite aucune manipulation.
- Une campagne de test répartie sur plusieurs sources doit être visible au niveau agrégé.
- Les clients légitimes partageant une IP ne doivent pas subir un blocage global.
- Les changements sensibles doivent déclencher une vérification même après une authentification réussie.
À vous de raisonner
Chaque compte ne reçoit qu’un ou deux essais, répartis sur de nombreuses adresses IP. Pourquoi un seuil d’échecs par compte peut-il manquer cette campagne ?
Formulez votre décision et l’élément qui la justifie avant d’ouvrir la correction.
Comparer avec le raisonnement expliqué
Le seuil n’est jamais atteint, et certains couples volés réussissent immédiatement. Il faut rapprocher les tentatives sur l’ensemble du service et examiner les actions après connexion. Un succès suivi d’un changement de livraison ou d’un export inattendu mérite davantage d’attention qu’une adresse IP isolée.
Consulter les détails techniques
Pour aller plus loin après l’étude du cas : les extraits servent à s’exercer à la lecture des traces ; le guide de collecte aide les personnes qui disposent des outils et des accès nécessaires.
Lire les extraits commentés — reconstitution fictive
Ces extraits utilisent des valeurs fictives. Certains reprennent des champs documentés ; d’autres regroupent plusieurs sources dans un format pédagogique. Ce ne sont pas des exports bruts à retrouver tels quels dans vos outils. Commencez par les champs expliqués, puis retrouvez-les dans les extraits.
device_first_seen- Synthèse du cas : appareil non observé auparavant dans la période disponible. Cela ne signifie pas nécessairement nouvel appareil physique.
client_cluster- Regroupement analytique choisi pour l’exemple ; il n’existe pas automatiquement dans les journaux du fournisseur d’identité.
Campagne peu visible dans un seuil par compte
JournalAgrégats normalisés sur quinze minutes ; les mots de passe ne sont ni stockés ni comparés par le détecteur.
client_cluster=c4 sources=120 accounts=850 attempts=1020 successes=31
actor=u70 failures=1 success=1 device_first_seen=true
actor=u70 post_login=change_delivery_address seconds=24
actor=u71 failures=0 success=1 device_first_seen=true
actor=u71 post_login=export_profile seconds=19
baseline client_cluster=usual accounts=90 success_ratio=0.94Préparer une collecte dans votre environnement
Choisissez les sources qui correspondent à vos outils et à votre périmètre d’intervention. Cette liste n’est pas un équipement requis pour comprendre la fiche. Vérifiez que les journaux nécessaires étaient activés pendant la période étudiée. Conservez l’export original, son fuseau horaire et sa provenance dans un espace à accès restreint ; travaillez sur une copie expurgée des secrets.
Microsoft Entra ID — Sign-in logs
- Où les trouver
- Centre d’administration Entra → Entra ID → Monitoring & health → Sign-in logs. Examiner séparément les connexions interactives, non interactives et celles des applications si elles sont concernées.
- Quoi relever
- Comparer le nombre de comptes, de sources et de réussites sur les connexions disponibles. Examiner aussi les applications non interactives concernées ; une attaque distribuée peut rester discrète par adresse IP.
- Accès et prérequis
- Rôle de lecture adapté, par exemple Reports Reader. Vérifier la période conservée et les exports disponibles ; une session applicative n’engendre pas nécessairement une nouvelle connexion Entra.
Service concerné — audit et historique à vérifier
- Où les trouver
- Dans l’outil d’administration ou les journaux du service concerné. Demander à son mainteneur où sont enregistrées les décisions d’autorisation et les opérations métier.
- Quoi relever
- Après chaque réussite suspecte, rechercher les modifications d’adresse de livraison, exports ou changements de récupération. Conserver identité, session pseudonymisée, action, heure et résultat, jamais le mot de passe essayé.
- Accès et prérequis
- Il n’existe ni fichier ni vocabulaire universels. Les champs proposés ici doivent être instrumentés s’ils manquent ; ne pas enregistrer mots de passe, jetons ou contenu privé intégral.
Si vous pensez être concerné
- Changez les secrets réutilisés, en priorité la messagerie et les comptes sensibles.
- Révoquez les sessions inconnues et vérifiez les actions accomplies.
- Informez le support professionnel si un secret de travail a été réutilisé ailleurs.
Pour qualifier votre situation et être orienté : obtenir une assistance sur 17Cyber. Dans une organisation, prévenez aussi le responsable ou prestataire chargé de la sécurité.
Sources et repères pour approfondir
- MITRE ATT&CK — Credential Stuffing — attack.mitre.org
- OWASP — Credential Stuffing Prevention — cheatsheetseries.owasp.org
- OWASP — authentification — cheatsheetseries.owasp.org
