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
Découvrez le piège à partir d’un exemple, puis les gestes que vous pouvez faire. Vous pouvez suivre cette lecture sans connaissances en informatique.
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 consiste à essayer sur d’autres services des identifiants et mots de passe déjà volés. L’attaquant automatise ces essais. Utiliser un mot de passe différent pour chaque compte empêche qu’un même secret ouvre plusieurs portes. Si vous changez seulement celui du service ayant annoncé une fuite, vos autres comptes restent exposés tant qu’ils acceptent l’ancien mot de passe.
- 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.
Si vous remarquez l’un de ces signes, vérifiez la situation. Un indice isolé ne suffit pas à prouver 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.
Même complexe, un mot de passe connu d’un attaquant peut être réutilisé sur les autres services où vous l’employez.
À 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 ?
Prenez un moment pour répondre et expliquer votre choix, puis ouvrez la correction.
Voir la réponse expliquée
Oui. L’attaquant connaît déjà le mot de passe et peut essayer directement l’identifiant associé. Même complexe, un mot de passe réutilisé peut ouvrir le second compte.
Analyser un cas technique
Ce cas s’adresse aux personnes qui développent, administrent ou analysent ces systèmes. Si vous découvrez le sujet, commencez par « Comprendre et agir ».
Étude de cas fictive
Des identifiants volés ailleurs sont essayés sur votre service
L’attaquant dispose déjà de paires d’identifiants et de mots de passe volées ailleurs. Il les essaie sur un nouveau service en comptant sur leur réutilisation : c’est le credential stuffing. Un essai peut réussir du premier coup et laisser peu d’indices à une détection qui ne cherche que de nombreux échecs par compte.
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.
Quelles informations comparer
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.
Ce que ces indices ne permettent pas de conclure
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
L’équipe responsable du système peut utiliser ces contrôles dans un environnement de test autorisé. Vous pouvez lire et comprendre le cas sans effectuer ces manipulations.
- 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 ?
Quelle décision prendriez-vous, et sur quel indice vous appuieriez-vous ? Répondez 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
Les extraits permettent de s’exercer à lire les traces du cas. Si vous disposez des outils et des accès nécessaires, le guide de collecte vous aide aussi à rechercher ces informations.
Lire les extraits commentés (reconstitution fictive)
Ces extraits contiennent des valeurs fictives. Certains champs correspondent à ceux des outils documentés ; d’autres réunissent plusieurs sources pour faciliter l’explication. Vos propres exports pourront donc avoir une autre forme. Lisez d’abord les explications des champs, puis repérez-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
Utilisez les sources disponibles dans vos outils et auxquelles vous êtes autorisé à accéder. Vous pouvez comprendre la fiche sans posséder ces outils. Vérifiez que les journaux étaient activés pendant la période étudiée. Gardez l’export original avec son fuseau horaire et sa provenance dans un espace à accès restreint. Pour l’analyse, travaillez sur une copie dont vous avez retiré les 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 comprendre votre situation et trouver de l’aide : 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
