Mots de passe volés : le piratage WordPress qui ne laisse aucune trace

Pendant quinze ans, sécuriser un WordPress a voulu dire « empêcher quelqu’un d’essayer ». Limiter les tentatives de connexion, masquer wp-login.php, poser un captcha, bannir les adresses IP trop bavardes. Ces réflexes restent utiles, mais ils traitent un problème qui n’est plus le principal. L’attaquant d’aujourd’hui n’essaie pas : il connaît déjà le mot de passe.

Les intrusions par identifiants valides — volés ailleurs, puis rejoués sur le site — sont en forte progression depuis le début de l’année. Elles ne ressemblent pas à un piratage : elles ressemblent à une journée de travail normale.

Une connexion réussie, du premier coup

Le scénario type, rapporté ces derniers mois sur des dizaines de sites, tient en quelques lignes. Une agence découvre sur un site client une extension qu’elle n’a jamais installée, au nom rassurant : « Admin Security Tools ». Elle remonte les journaux de connexion en s’attendant à trouver des centaines d’échecs. Il n’y en a aucun. Une adresse IP située à Francfort s’est connectée une fois, avec les bons identifiants, et rien d’autre. L’extension n’était pas l’attaque : c’était la porte de service posée par l’attaquant pour revenir même après un changement de mot de passe.

Tous les sites de cette agence étaient touchés par le même intrus. L’origine exacte des identifiants n’a pas pu être établie — poste infecté par un logiciel voleur de mots de passe, session de navigateur récupérée, hameçonnage réussi, ou fuite chez un tiers ayant eu accès aux accès. C’est précisément le point : on ne sait pas toujours où la fuite a eu lieu, et le site piraté n’en garde aucune trace.

Pourquoi la force brute n’est plus le sujet

Un mot de passe valide s’obtient aujourd’hui bien plus facilement qu’il ne se devine. Quatre circuits alimentent le marché :

• Les logiciels voleurs d’identifiants (infostealers), installés sur le poste de travail par un faux installeur ou une pièce jointe, qui exfiltrent en une passe tous les mots de passe enregistrés dans le navigateur — y compris celui de l’administration WordPress, et les identifiants du client FTP.
• Le vol de session : inutile de connaître le mot de passe si l’on récupère le cookie de connexion, qui reste valide jusqu’à son expiration.
• L’hameçonnage ciblé, devenu propre : une fausse notification de mise à jour, un faux message de l’hébergeur, une page de connexion copiée au pixel près.
• La réutilisation : le même mot de passe sur le site et sur un service tiers qui, lui, a fuité. L’attaquant n’a rien à casser, juste à essayer ailleurs.

Dans les quatre cas, le site reçoit une connexion parfaitement légitime. Aucune règle de limitation de tentatives ne se déclenche, aucun pare-feu ne bronche : du point de vue de WordPress, c’est vous qui vous connectez.

Ce que WordPress ne voit pas

Une installation WordPress nue n’a aucun moyen de repérer ce scénario. Elle ne journalise pas les connexions réussies, ne prévient pas qu’un compte administrateur s’est connecté depuis un pays inhabituel, ne propose pas de second facteur, et n’expire pas les sessions ouvertes. Ajoutez à cela que beaucoup de sites publient la liste de leurs comptes : l’API REST (/wp-json/wp/v2/users), les archives d’auteur et les données oEmbed livrent volontiers les identifiants de connexion. L’attaquant n’a donc à trouver qu’une moitié du couple.

Le corollaire est désagréable : l’absence d’alerte ne prouve rien. Un tableau de bord vert, un scanner silencieux et zéro tentative bloquée, c’est exactement ce qu’on observe sur un site où quelqu’un est entré par la porte.

Le signal à surveiller : les connexions qui réussissent

Le renversement de méthode tient en une phrase : arrêter de compter les échecs, commencer à regarder les succès. Trois questions suffisent à ouvrir le dossier.

• Qui s’est connecté ces trente derniers jours, depuis quelle adresse et à quelle heure ? Une connexion administrateur à 3 h du matin depuis un pays où personne ne travaille est un événement, même si tout va bien par ailleurs.
• La liste des comptes correspond-elle à la liste des personnes ? Les comptes de stagiaires partis, de prestataires d’il y a trois ans et d’extensions désinstallées survivent presque toujours, souvent avec le rôle administrateur.
• La liste des extensions installées correspond-elle à la liste des extensions choisies ? C’est ce test, et lui seul, qui fait tomber le scénario décrit plus haut.

La double authentification n’est plus une option de confort

Un mot de passe long et unique reste indispensable, mais il ne protège de rien une fois volé : sa force n’a aucune influence sur sa capacité à être recopiée. Le seul mécanisme qui casse la chaîne, c’est le second facteur. Un identifiant dérobé devient alors une information sans valeur.

Commencer par le plus simple plutôt que par le plus élégant

L’objection habituelle est humaine : les clients ne veulent pas installer une application d’authentification. Le second facteur par courriel — un code envoyé à l’adresse du compte — se met en place sans rien installer et ferme déjà l’essentiel du problème. Une application TOTP est plus robuste, une clé physique encore plus, mais un second facteur imparfait activé vaut infiniment mieux qu’un second facteur idéal repoussé de trimestre en trimestre.

L’activer là où ça compte

Sur tous les comptes administrateur et éditeur, et sur tous les sites — pas seulement sur celui qui a été touché. Un attaquant qui tient un accès s’en sert sur tout le portefeuille : les identifiants d’une agence ouvrent les sites de ses clients, et un poste infecté suffit à exposer l’ensemble.

Changer le mot de passe ne suffit jamais

C’est le réflexe le plus courant, et le plus insuffisant. Un attaquant qui a eu un accès administrateur pendant quelques minutes a eu le temps de se ménager plusieurs retours. Une remise au propre digne de ce nom suit cet ordre :

1. Déconnecter toutes les sessions en régénérant les clés de sécurité de wp-config.php — sinon le cookie volé reste valide malgré le nouveau mot de passe.
2. Réinitialiser tous les comptes, pas seulement le sien, et supprimer ceux qui ne correspondent à personne.
3. Inventorier les extensions et les thèmes, y compris les mu-plugins, qui s’activent sans apparaître dans la liste classique.
4. Vérifier les tâches planifiées : une tâche cron est un point de relance discret pour un code qui se réinstalle tout seul.
5. Changer aussi les accès périphériques : FTP/SFTP, base de données, panneau d’hébergement, comptes de messagerie associés. Ils sont souvent enregistrés dans le même navigateur que celui qui a fuité.
6. Restaurer depuis une sauvegarde antérieure à l’intrusion quand le doute persiste — ce qui suppose d’avoir des sauvegardes assez anciennes, et testées.

Comment nous intervenons

Nous ne vendons pas de logiciel de sécurité et nous ne promettons l’inviolabilité de rien. Notre travail consiste à réduire la surface d’attaque, à rendre l’anomalie visible, et à garantir qu’un retour en arrière reste possible. Concrètement, sur les sites que nous construisons et que nous maintenons :

• Comptes nominatifs et rôles minimaux. Pas de compte « admin » partagé entre l’agence, le client et le prestataire de passage : chacun le sien, au rôle le plus bas qui permette de travailler, et on ferme les accès quand la mission s’arrête.
• Second facteur sur les comptes à privilèges, et mots de passe gérés dans un gestionnaire dédié — jamais dans le navigateur, qui est justement la cible des logiciels voleurs.
• Durcissement de l’installation : édition de fichiers désactivée depuis l’administration, énumération des comptes fermée côté API REST et oEmbed, en-têtes de sécurité posés au niveau du serveur, fichiers d’installation et numéros de version inutiles retirés.
• Audit d’entrée systématique sur les reprises de site. Quand nous récupérons un WordPress dont personne ne connaît l’historique, nous commençons par l’inventaire : comptes réels, extensions abandonnées ou piratées, code laissé par d’anciens prestataires, tables orphelines, tâches planifiées en échec. C’est là que se trouvent les mauvaises surprises, pas dans le thème.
• Mises à jour suivies et sauvegardes restaurables. Une sauvegarde qu’on n’a jamais restaurée n’est pas une sauvegarde, c’est une hypothèse.

C’est la méthode que nous appliquons dans nos missions de développement et de maintenance WordPress comme dans les refontes et reprises de site — un sujet que nous abordons sous un autre angle dans notre article sur la façon de reprendre un site WordPress laissé à l’abandon.

Trois gestes à faire cette semaine

Si vous ne deviez retenir que trois actions, dans cet ordre :

1. Activer la double authentification sur tous les comptes administrateur, en commençant par le second facteur par courriel si c’est le plus rapide à déployer.
2. Ouvrir la liste des comptes et celle des extensions, et supprimer tout ce que personne ne revendique.
3. Sortir les mots de passe du navigateur et les confier à un gestionnaire dédié — c’est le geste qui coupe la voie d’entrée la plus fréquente.

Un doute sur l’état d’un site, une reprise à documenter, un portefeuille de sites à remettre au carré : écrivez-nous. Nous commençons toujours par regarder avant de proposer quoi que ce soit.