Prise en charge en cours Lun–Ven · 9h–19h
Signaler un incident
PK.BOT PK.ECM

Credential stuffing : détecter l'attaque dans vos logs et la bloquer

Credential stuffing : détecter l'attaque dans vos logs et la bloquer

Vos clients reçoivent des emails "votre mot de passe a été modifié" qu'ils n'ont pas demandés. Des commandes apparaissent sur des comptes qui disent ne pas les avoir passées. Des connexions depuis des pays inhabituels sur vos dashboards. Ce sont les signaux d'une attaque par credential stuffing en cours. Pas une faille dans votre code : des identifiants volés ailleurs testés en masse sur votre site.

Définition en une phrase

Le credential stuffing est une attaque automatisée qui teste des millions de couples identifiant/mot de passe issus de fuites de données tierces (base Facebook, LinkedIn, site compromis) sur les formulaires de connexion de votre site, en comptant sur la réutilisation des mots de passe par les utilisateurs.

En clair, pour les non-initiés. Votre client utilise le même mot de passe sur votre boutique et sur un forum piraté en 2021. L'attaquant a acheté la base de données du forum sur le dark web. Il teste automatiquement chaque couple email/mot de passe de cette base sur des milliers de sites, dont le vôtre. Sur 100 000 tentatives, 2 à 5 % réussissent en moyenne. Ce sont des comptes réels de vos vrais clients, accessibles sans faille dans votre code.

Pourquoi c'est un signal d'achat pour PK.BOT et PK.ECM

Le credential stuffing est particulièrement destructeur sur les sites e-commerce. Un attaquant qui prend le contrôle d'un compte client peut :

  • Consulter l'historique des commandes et les adresses enregistrées.
  • Réutiliser un moyen de paiement sauvegardé pour passer une commande frauduleuse.
  • Modifier l'adresse de livraison avant de passer une commande avec le solde de points de fidélité.
  • Exporter les données du compte (emails, adresses) pour revente.

Sur les sites SaaS et les applications avec des données sensibles, le compromis de compte peut mener à une fuite de données réglementairement notifiable.

Le signal qui déclenche souvent notre intervention : un pic de connexions échouées sur /wp-login.php, /connexion, ou /mon-compte qui n'est pas corrélé à une campagne marketing. Plusieurs centaines ou milliers de HTTP 200 ou HTTP 302 sur l'endpoint de login en quelques heures, depuis des IPs de datacenters réparties sur plusieurs pays.

Comment détecter une attaque en cours dans vos logs

Pattern 1 : volume de POST anormal sur l'endpoint de connexion

# Apache / Nginx : compter les POST sur /wp-login.php par heure
grep "POST /wp-login.php" /var/log/nginx/access.log | awk '{print $4}' | cut -d: -f1,2 | sort | uniq -c | sort -rn | head -20

Un site normal voit 5 à 20 connexions par heure. Un site sous credential stuffing voit des centaines à des milliers.

Pattern 2 : multiples IPs, même comportement

# Identifier les IPs avec beaucoup de tentatives de connexion
grep "POST /wp-login.php" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -50

Dans un credential stuffing avec proxies rotatifs, chaque IP fait peu de tentatives (2 à 10), mais le volume total est élevé. À la différence d'un brute force classique depuis une seule IP.

Pattern 3 : User-Agents suspects ou uniformes

# Identifier les User-Agents sur les POST de connexion
grep "POST /wp-login.php" /var/log/nginx/access.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -rn | head -20

Un outil de credential stuffing comme OpenBullet ou Snipr génère souvent des User-Agents identiques ou avec des patterns répétitifs. Une liste de 10 User-Agents qui font chacun 5 000 tentatives est un signal fort.

Pattern 4 : connexions réussies depuis des géographies inhabituelles

Si votre base clients est française et que des connexions réussies viennent d'IPs russes, ukrainiennes, brésiliennes ou chinoises dans les logs Cloudflare, c'est un compromis de comptes probable. Cloudflare Security Events montre les pays d'origine.

Les contre-mesures que Secushot pose

Dans nos packs PK.BOT et PK.ECM, la réponse à une attaque de credential stuffing combine plusieurs niveaux :

1. Rate limiting sur les endpoints de connexion

# Cloudflare Rate Limiting
POST /wp-login.php : 5 requêtes par minute par IP
POST /connexion : 5 requêtes par minute par IP
POST /api/auth/login : 10 requêtes par minute par IP
Action : Block 10 minutes

Voir rate limiting pour les détails de configuration.

2. Managed Challenge sur les formulaires de connexion

Un Managed Challenge Cloudflare (successeur du JS Challenge) est transparent pour les vrais navigateurs : résolu en arrière-plan, sans friction visible. Les outils de credential stuffing sans moteur JavaScript complet échouent.

# Cloudflare Managed Challenge sur les formulaires de connexion
(http.request.uri.path contains "/wp-login.php" or 
 http.request.uri.path contains "/connexion") and
(cf.bot_management.score lt 30)
Action : Managed Challenge

3. Blocage des ASN de datacenter sur les endpoints d'authentification

La grande majorité des outils de credential stuffing tournent sur des VPS de datacenter (AWS, DigitalOcean, Hetzner, Linode). Bloquer les requêtes sur l'endpoint de connexion depuis des ASN de datacenter réduit drastiquement le volume d'attaque.

# Bloquer les ASN datacenters sur /wp-login.php
(ip.geoip.asnum in {16509 14061 24940 63949}) and
(http.request.uri.path contains "/wp-login.php")
Action : Block

À combiner avec une whitelist des IPs légitimes de l'équipe admin.

4. Notification forcée des comptes compromis

Quand un credential stuffing est confirmé, on identifie les comptes dont les connexions proviennent d'IPs suspectes et on force un reset de mot de passe. Sur WordPress, via WP CLI :

# Forcer le reset pour les utilisateurs sans activité normale récente
wp user list --role=customer --format=csv | grep "..."

5. Mise en place du 2FA

Après un credential stuffing, on recommande l'activation du 2FA (TOTP ou lien magique par email) sur les comptes clients à risque. Un mot de passe compromis ne suffit plus pour accéder au compte.

Les erreurs qu'on rencontre le plus souvent

1. Traiter le credential stuffing comme un brute force classique

Le brute force classique vient d'une seule IP avec des milliers de tentatives. Le credential stuffing vient de milliers d'IPs avec quelques tentatives chacune. Bloquer les IPs après 5 tentatives ne suffit pas : l'attaquant passe à l'IP suivante. Il faut des contre-mesures comportementales (challenge, bot score).

2. Réinitialiser seulement les mots de passe des comptes compromis

Si la fuite de données est externe (un autre site piraté), le problème est la réutilisation de mots de passe par vos clients. Forcer la réinitialisation des comptes compromis est nécessaire, mais l'idéal est de pousser vos clients à utiliser des mots de passe uniques. Mettre en place le 2FA est plus efficace que de courir après les mots de passe réutilisés.

3. Ignorer les connexions réussies dans les logs

On analyse souvent les requêtes qui échouent (HTTP 401, 403). Les connexions réussies depuis des IPs inhabituelles sont plus dangereuses : ce sont des comptes déjà compromis. On doit surveiller les connexions réussies avec géolocalisation anormale.

4. Ne pas journaliser les tentatives de connexion

WordPress par défaut ne journalise pas les tentatives de connexion échouées. Sans plugin de logging ou sans accès aux logs Nginx/Apache, l'attaque peut durer des semaines avant d'être détectée. On configure toujours la journalisation des authentifications dans nos interventions.

Questions fréquentes

Credential stuffing et brute force : quelle différence ? Le brute force génère des mots de passe au hasard ou par dictionnaire. Le credential stuffing utilise des couples réels email/mot de passe issus de fuites de données. Le taux de succès est beaucoup plus élevé (2 à 5 % vs moins de 0,01 % pour un brute force sur un compte particulier).

Comment mes clients peuvent-ils savoir si leur mot de passe a fuité ? Ils peuvent vérifier leur email sur haveibeenpwned.com. Les gestionnaires de mots de passe modernes (1Password, Bitwarden) alertent sur les mots de passe compromis. Communiquer cette ressource à vos clients après un incident est une bonne pratique.

Mon site peut-il être victime de credential stuffing s'il est petit ? Oui. Les outils de credential stuffing testent des millions de sites automatiquement. La taille du site ne protège pas. Ce qui protège : un rate limiting actif, un challenge sur le formulaire de connexion, et un 2FA disponible.

Le CAPTCHA protège-t-il contre le credential stuffing ? Un CAPTCHA classique résolu par des fermes humaines (souvent utilisées pour contourner reCAPTCHA) est efficacement contourné. Un Cloudflare Managed Challenge ou Turnstile est plus résistant car il combine analyse comportementale et défi JavaScript, sans image à résoudre.

Comment savoir si un compte client a été compromis via credential stuffing ? Signaux : connexion depuis un pays inhabituel pour ce compte, changement d'adresse email ou de mot de passe peu après la connexion, commande inhabituelle dans les minutes qui suivent la connexion. Ces événements dans les logs wp_usermeta ou dans les logs Cloudflare permettent de reconstruire la chronologie.

Pour aller plus loin

Des comptes clients compromis ou une attaque de connexion en masse sur votre site ? Notre pack PK.BOT (890 € TTC, livré en 48 h) pose le rate limiting, les challenges Cloudflare et identifie les comptes compromis. Rapport avec liste des IOC inclus. Briefer le pack PK.BOT

Dernière mise à jour · 22 avril 2026 ← Retour au lexique