Comptes clients créés en masse sur une boutique
Deux cents comptes d'un coup, e-mails jetables, mêmes plages d'IP, inscriptions à 3 h du matin : ce n'est pas une campagne d'acquisition. On coupe l'inscription le temps de voir, on sépare le bot de l'accès admin, on n'efface pas les vrais clients dans la foulée.
Emails jetables, mêmes plages d'IP, inscriptions la nuit. Désactivez l'inscription le temps du diagnostic, cherchez un bot et un accès admin.
Ce que la rafale indique
Créer un compte client est le geste le plus simple qu'un script puisse faire sur une boutique. Ça teste que le formulaire répond, que l'e-mail part, que la table `users` s'écrit. Ça fournit aussi une session : avis, wishlist, parfois un espace « mes commandes » qui sert une page injectée.
Ce n'est pas le même incident qu'un admin fantôme. Ici les rôles sont « Client » ou « Customer ». Le danger n'est pas `manage_options` ; c'est le volume, le SMTP saturé, et parfois le contenu déposé dans le profil (URL, bio, avatar PHP).
Une boutique B2B avec validation manuelle qui se retrouve avec 800 « en attente » un lundi matin a le même sujet, plus un file de commerciaux noyée. Traitez le flux avant de répondre à chaque e-mail « bienvenue ».
Couper l'inscription sans fermer la boutique
WooCommerce : Réglages → Comptes → décocher « permettre la création de compte ». PrestaShop : boutiques → clients → inscription. Magento : Stores → Configuration → Customers. Les clients déjà connectés continuent à payer. Les visiteurs checkout-invité aussi, si vous l'autorisez.
C'est un geste provisoire, le temps du diagnostic. Le laisser six mois « au cas où » vous coûte des inscriptions réelles. Notez l'heure de la coupure : elle sépare le flux pirate du flux normal dans les exports.
Si l'inscription passe par un plugin (membre, LMS, marketplace), le réglage Woo ne suffit pas. Coupez aussi ce formulaire. Un seul endpoint ouvert suffit au bot.
- Inscription boutique officielle.
- Plugin membres / marketplace / LMS.
- API REST création d'utilisateur.
- Checkout qui crée un compte automatiquement.
E-mails jetables, IP, horaires
Exportez les comptes créés depuis la date suspecte : e-mail, date, IP si vous la stockez. Triez. Une colonne entière `@mailinator`, `@guerrillamail`, `@tempmail`, ou des plus `+` sur Gmail générés en série, ce n'est pas votre cible marketing.
Les IP : /24 ou /16 identiques, ASN d'hébergeur (OVH, DigitalOcean, un VPN) alors que vos clients sont en fibre Orange. Un plugin de log de connexion aide ; sinon les journaux web autour de `wp-login.php?action=register` ou `authentification`.
Les horaires : un fuseau qui n'est pas le vôtre, un palier toutes les 8 secondes. Un humain ne s'inscrit pas à ce rythme. Gardez ce tableau : il justifie auprès de l'hébergeur un pic SMTP, et auprès de Google un volume d'URL `/mon-compte/` si elles ont été indexées.
Bot public ou quelqu'un déjà dedans
Bot public : le formulaire d'inscription est ouvert, sans captcha, ou avec un captcha cassé. Les comptes ont un rôle client, rien d'autre. Fermer le formulaire + captcha + limite de débit règle souvent le flux. Cherchez quand même si un admin n'a pas été créé dans la même fenêtre.
Quelqu'un déjà dedans : les comptes ont un rôle trop haut, ou ils sont créés via l'admin / l'API avec une clé. Là, couper l'inscription publique ne change rien. Cherchez les clés REST, les employés, le webshell.
Le test : coupez l'inscription publique. Si les lignes continuent d'apparaître dans `wp_users` ou `ps_customer`, l'écrivain est interne. C'est le même test que pour les articles qui reviennent.
WooCommerce, PrestaShop, Magento : où lire la liste
WordPress / Woo : `wp_users` + rôle `customer` dans `wp_usermeta`. L'écran Utilisateurs filtre par rôle. Attention aux comptes WordPress « abonné » créés par un formulaire de commentaires ou un LMS : ce n'est pas la même table métier, c'est le même symptôme.
PrestaShop : `ps_customer`, colonne `date_add`, `active`, `email`. Un grand nombre de `active = 0` peut être un bot que la validation e-mail a stoppé — ou des comptes prêts à être activés par un cron. Magento : `customer_entity`. Exportez, ne scrollez pas l'admin.
Croisez avec les commandes fantômes. Un compte sans commande n'est pas inoffensif (spam d'inscription, SMTP). Un compte avec commande à 0 € est prioritaire : il a touché le tunnel.
Nettoyer sans tuer les comptes payants
Ne faites pas « supprimer tous les comptes depuis le 1er du mois ». Vos clients du week-end sont dans le tas. Filtrez : e-mail jetable, pas de commande payée, date dans la rafale, IP du bot. Les trois derniers critères ensemble, vous pouvez effacer ou désactiver.
Désactiver est plus sûr qu'effacer si un doute existe (homonyme, e-mail pro rare). Un compte désactivé ne s'authentifie plus ; vous le réouvrez si un vrai client écrit.
Les e-mails de « votre compte a été créé » ont déjà pu partir. Si votre domaine est en train de se faire blacklister, coupez le SMTP transactionnel le temps du ménage. Voir le site envoie du spam.
- Export horodaté hors serveur.
- Filtre jetable + sans commande payée + fenêtre de temps.
- Désactivation plutôt que purge si doute.
- SMTP coupé si le volume d'accueil explose.
Ce que ces comptes ont pu faire
Laisser un avis, remplir un champ « société » avec une URL, uploader un avatar. Sur certains thèmes, l'avatar n'est pas une image. Cherchez dans `uploads` des fichiers déposés à l'heure des inscriptions. Un `.php.jpg` dans ce dossier est plus grave que le compte lui-même : voir double extension.
Un espace « mes fichiers » ou un marketplace vendeur transforme chaque compte en répertoire d'upload. Si vous avez ce type d'extension, ces comptes ne sont plus du bruit : ils sont un vecteur. Interdisez PHP dans ces dossiers tout de suite.
Les points de fidélité, les avoirs, les listes de prix B2B : un script qui s'inscrit puis s'attribue un tarif, c'est de la fraude, pas seulement du spam. Regardez les règles client / groupes PrestaShop.
Refermer : captcha, limite, rôles
Quand vous rouvrez l'inscription : captcha qui marche (testez-le), limite de débit au niveau serveur si l'hébergeur le propose, validation e-mail obligatoire, interdiction des domaines jetables si un plugin le fait proprement. Ce n'est pas du « pentest » ; c'est remettre le formulaire dans un état normal.
Révoquez les clés API qui créent des clients. Un webhook CRM trop permissif recrée le flux. Moins de comptes staff avec droit « ajouter un client ».
Si `site:votre-domaine.fr` liste des milliers de `/mon-compte/` ou de pages auteur, ce sont souvent des URL techniques indexées, pas des pages spam. Noindexez l'espace client ; ne désindexez pas tout le domaine.
Quarante-huit heures de surveillance
Rouvrir l'inscription et partir le week-end, c'est rater la recréation. Surveillez le `COUNT` des clients à J+1 et J+2. Un palier qui reprend au même rythme : l'entrée n'était pas le formulaire, ou un second formulaire vit encore.
L'hébergeur qui a vu un pic mail apprécie un ticket factuel : « inscriptions bot du [date], inscription coupée le [heure], SMTP calme depuis ». Ça évite une suspension pendant que vous triez.
Vous pouvez déclarer la boutique si les tables et les rôles custom dépassent une soirée. Les gestes de ce soir — coupure inscription, export, panel — restent les bons, que vous continuiez seul ou non.