Un site WordPress qui a été compromis, ce n’est pas seulement une histoire de “site défiguré” ou de pages de spam qui apparaissent. Très souvent, la première porte d’entrée reste le même classique: le formulaire de connexion. Quand un attaquant prend le contrôle, il ne le fait pas toujours en exploitant une vulnérabilité impressionnante. Parfois, il commence par un réglage négligé, une protection trop faible, ou un environnement déjà fragilisé.
J’ai vu plusieurs scénarios où le formulaire de connexion devenait le “point d’impact” principal. Un cas typique, c’est celui du site qui n’a rien l’air de suspect côté public, mais où le journal d’accès montre des rafales de tentatives sur wp-login.php. Une autre variante, plus sournoise, est celle où l’attaquant ne cherche pas à forcer les identifiants tout de suite, mais à tester des utilisateurs, repérer des comptes, et préparer ensuite des actions depuis l’interface d’administration.
Ce guide part d’un principe simple: si vous suspectez un site WordPress infecté, ou si vous avez déjà confirmé qu’il l’est, sécuriser le formulaire de connexion est une étape prioritaire, mais ce n’est pas un “bouton magique”. Il faut traiter le risque de manière structurée, en tenant compte des faux positifs, de la compatibilité, et du fait que des plugins et thèmes peuvent aussi reintroduire le problème.
Quand le formulaire de connexion devient une cible
Le formulaire de connexion WordPress est un endroit logique à attaquer. Il est standard, il existe partout, et il donne accès à la surface d’administration. Même si vous avez appliqué des mises à jour, le mécanisme de connexion peut rester exposé à trois familles de problèmes.
D’abord, les tentatives d’accès automatisées. Ce sont parfois des bots “basiques” qui testent des combinaisons d’identifiants, parfois plus intelligents, capables de ralentir ou d’alterner les demandes pour éviter les protections trop simples. Sur un site dont l’authentification est peu restrictive, vous pouvez voir des centaines de tentatives en quelques heures.
Ensuite, les attaques liées à la phase de session. Un attaquant peut tenter d’exploiter des paramètres, des cookies, ou une logique de redirection mal maîtrisée, surtout si un plugin de sécurité ou un plugin tiers a introduit un comportement étrange.
Enfin, il y a les compromissions “post-login”. Dans ce cas, le formulaire est touché parce que la connexion réussit, puis l’attaquant installe une persistance: un plugin malveillant, une tâche planifiée, des modifications dans les fichiers, ou des comptes administrateurs créés. Le formulaire n’est pas le seul problème, mais il est le point d’entrée.
Ce que j’ai appris en situation réelle, c’est que sécuriser la connexion sans vérifier l’intégrité du site revient parfois à “fermer la porte” alors que la pièce de derrière est ouverte. Oui, le risque baisse. Non, la compromission peut rester active.
Distinguer incident, suspicion, et hardening
Avant de vous lancer, faites la différence entre trois états.
Un incident avéré, c’est quand vous avez des indicateurs solides: fichiers modifiés, plugins inconnus, comptes créés, modifications d’options inhabituelles, redirections, ou activité anormale confirmée par des traces et des fichiers.
Une suspicion, c’est quand vous voyez des comportements anormaux mais pas de preuve formelle, par exemple des pics de tentatives et des logs qui ne correspondent pas à vos usages, ou un plugin récemment installé que vous n’êtes pas certain de maîtriser.
Le hardening, c’est l’approche “préventive” ou “renforcée” après la purge, pour que la connexion ne soit plus un maillon faible.
Dans la pratique, la bonne stratégie consiste à combiner les trois, mais dans le bon ordre. D’abord, nettoyer et vérifier. Ensuite, durcir. Enfin, maintenir et surveiller.
Nettoyer d’abord, sinon vous sécurisez la mauvaise cible
Je sais que c’est tentant: “ajoutons un captcha, un anti-bot et un verrouillage, et on verra”. Sur un site réellement infecté, ça peut marcher, mais ça peut aussi vous donner un faux sentiment de sécurité.
Concrètement, si des identifiants volés ont permis à l’attaquant de déposer une persistance, il peut revenir même si le formulaire devient plus difficile à attaquer. Pire, certaines modifications peuvent continuer à exister dans des fichiers ou dans la base, et votre durcissement ne les effacera pas.
Le bon réflexe consiste à vérifier au minimum:
- la présence de plugins et thèmes ajoutés récemment, surtout ceux que vous ne reconnaissez pas ; les comptes utilisateurs, y compris les rôles administrateur et éditeur ; les fichiers modifiés dans le temps récent ; les tâches planifiées et les injections dans les fichiers du thème.
Je ne vais pas lister une “procédure de chirurgie” minute par minute, car chaque hébergement et chaque site a ses contraintes. Mais sur un incident réel, j’ai souvent constaté que la première victoire, c’est de stopper ce qui réintroduit le risque: suppression des composants inconnus, restauration de versions propres, et réinitialisation crédible des accès.
Protéger le formulaire: les leviers qui changent vraiment la donne
Une fois le site nettoyé et validé, l’objectif est de rendre la connexion plus robuste contre les attaques automatisées et contre les connexions à risque.
La difficulté, c’est que WordPress est flexible. Cette flexibilité est une force pour vous, mais aussi une surface d’attaque. Les réglages de sécurité doivent donc équilibrer protection et compatibilité, notamment avec vos utilisateurs réels et vos outils de maintenance.
1) Réduire la “visibilité” de l’endpoint
La première amélioration consiste à limiter la portée d’attaques “qui frappent l’URL par défaut”. Beaucoup de scripts automatisés testent wp-login.php et tentent des identifiants courants. Modifier l’URL de connexion ou limiter l’accès à certains chemins peut diminuer le bruit.
Attention toutefois: changer l’URL ne supprime pas le problème, et il faut assurer la cohérence pour:
- vos rôles et vos connexions légitimes ; vos outils qui se connectent automatiquement (systèmes de déploiement, monitoring, scripts) ; votre plugin de sécurité lui-même, qui peut s’attendre à certains chemins.
Sur certains environnements, j’ai vu des blocages inattendus après des modifications d’URL, parce que le formulaire de connexion, les redirections et les règles de filtrage n’étaient pas alignés. Le résultat, c’est un incident de service, pas juste une sécurité.
Donc oui, ça peut aider, mais testez d’abord sur une copie, ou au moins avec un compte test et une fenêtre de maintenance.
2) Renforcer l’authentification sans casser l’usage
Le verrouillage après trop d’échecs est une arme simple, mais elle doit être réglée avec discernement. Un site avec trop de verrouillages peut bloquer un utilisateur légitime qui a une erreur de mot de passe, ou un équipe qui fait des mises à jour depuis des postes dont la connexion Internet varie.
En pratique, je privilégie une stratégie où:
- le blocage est progressif (d’abord une friction, puis un blocage plus ferme) ; les périodes de blocage sont assez courtes pour limiter l’impact, mais suffisamment longues pour casser les rafales de bots ; les protections distinguent les attaques massives et les erreurs ponctuelles.
Le “bon” https://gardewp.fr/ réglage dépend du volume de trafic et de votre base d’utilisateurs. Sur un blog à faible trafic, quelques verrouillages légitimes peuvent devenir vite problématiques. Sur un site très exposé, une friction trop douce ne sert à rien.
3) Ajouter de la vérification humaine quand c’est nécessaire
Le captcha et ses variantes peuvent réduire fortement les tentatives automatisées. Mais là aussi, il y a un piège classique: un captcha mal intégré peut rendre la connexion pénible, surtout sur mobile, sur les navigateurs moins courants, ou quand votre fournisseur de captcha est instable.
J’ai déjà vu des équipes activer un captcha agressif, puis perdre des connexions administrateur pendant des heures, parce que la page https://gardewp.fr/nettoyage-malware-wordpress/ de connexion ne parvenait pas à charger le script externe, ou parce que la configuration de compatibilité n’avait pas été testée.
Si vous utilisez un captcha, faites-le de manière progressive. Par exemple, l’activer uniquement après quelques tentatives échouées, ou sur des conditions qui ressemblent plus à une attaque qu’à une session normale.
4) Exiger des mots de passe robustes, et éviter les comptes “faciles”
Je n’insisterai pas sur les slogans, mais sur le terrain, les mots de passe “évidents” sont encore une cause fréquente d’accès compromis.
Après un incident, il est sain de forcer un renouvellement des mots de passe, au minimum pour les comptes ayant des droits élevés. Idéalement aussi pour tous les utilisateurs qui avaient accès à l’administration pendant la période de risque.
Le compromis, c’est que vous devez pouvoir joindre vos utilisateurs. Sur des sites de petites structures, j’ai vu des équipes qui changeaient tous les mots de passe d’un coup sans prévoir une communication, puis perdaient l’accès quelques jours après, faute de coordination. Un incident de sécurité devient un incident opérationnel.
5) Activer l’authentification multifacteur, surtout pour les rôles sensibles
C’est souvent l’une des protections les plus efficaces contre les compromissions liées aux mots de passe. Même si un attaquant parvient à obtenir un mot de passe, le deuxième facteur casse la plupart des scénarios de prise de contrôle.
Le bon compromis dépend des besoins de votre équipe: il existe des options plus adaptées à des comptes techniques et des options plus adaptées à des comptes humains.
Sur le terrain, j’observe deux points:
- le MFA réduit fortement le risque de “reconnexion” après vol de mot de passe ; mais il faut gérer les cas de perte d’accès, et prévoir une procédure interne de récupération.
Un MFA sans plan B, c’est une sécurité qui se retourne contre vous.
Configuration concrète: ce que j’ajuste presque toujours après un incident
Plutôt que de vous donner un empilement de plugins, je préfère décrire ce que je contrôle et ce que je corrige, en gardant à l’esprit que votre stack peut être différente.
Contrôler les réglages d’accès en première ligne
Avant même de parler de captcha ou de MFA, je veux que l’attaque brute perde du temps. Cela passe souvent par:
- une limitation des tentatives d’accès ; une surveillance et une journalisation des échecs ; un blocage logique quand une origine devient suspecte.
Le détail compte: si vous bloquez trop agressivement, vous créez un déni de service involontaire. Si vous bloquez trop peu, les bots s’habituent et continuent.
Vérifier ce que vos plugins font réellement
Dans un site infecté, la tentation est de “faire confiance” aux plugins de sécurité. Problème: un plugin peut être mal configuré, ou pire, sa configuration peut avoir été modifiée par l’attaquant. Et certains plugins de sécurité agressifs, combinés à un cache ou à un pare-feu, peuvent créer des effets de bord.
Par exemple, un système qui bloque des IP sur la base de logs pourrait se tromper si les logs sont incomplets ou si votre CDN modifie les adresses sources. J’ai déjà eu des situations où l’IP “réelle” n’était pas celle attendue, et du coup des règles de blocage touchaient des utilisateurs légitimes.
Ce que je fais: je vérifie l’intégration avec le reverse proxy ou le CDN, et je contrôle la source des IP. Ce point est moins “sexy” que la liste des fonctionnalités, mais c’est là que beaucoup d’échecs de durcissement se jouent.
Mettre à jour, puis valider l’intégrité
Mettre à jour WordPress, les thèmes et les plugins est une évidence. Mais après un incident, je traite la mise à jour comme une validation: je veux un site cohérent, des composants propres, et des fichiers sans surprises.
Une bonne pratique que j’utilise: restaurer les composants WordPress depuis une version connue propre, puis recharger uniquement ce qui doit rester. C’est plus coûteux en temps, mais plus fiable quand le doute est installé.
Étape par étape, sans se tromper de moment
Pour garder la maîtrise, je raisonne en séquence. Voici la logique que j’utilise, en restant volontairement pragmatique.
1) Confirmer le niveau d’accès et la persistance: ai-je un compte suspect, un plugin inconnu, une tâche planifiée, des fichiers modifiés récents ?
2) Nettoyer et restaurer: supprimer l’élément malveillant, restaurer ce qui peut l’être, et durcir ensuite. 3) Réinitialiser les identifiants: mots de passe et, si nécessaire, rotation des clés liées aux sessions ou à l’authentification. 4) Renforcer la connexion: limitation d’échecs, captcha au bon moment, MFA pour les rôles sensibles. 5) Surveiller après la correction: les journaux, les tentatives, et les signaux d’une reprise d’activité. 
Ce schéma évite un piège fréquent: mettre le durcissement avant la purge, puis rater le composant responsable de la compromission.
Journalisation et surveillance: le vrai filet de sécurité
Un formulaire sécurisé sans visibilité, c’est comme une serrure neuve sur une porte dont les gonds sont rongés. Vous devez pouvoir voir ce qui se passe.
Après durcissement, surveillez au moins:
- les pics de tentatives d’accès ; les erreurs de login répétées ; les changements de paramètres, surtout liés à l’authentification ; les nouveaux utilisateurs ou changements de rôles.
Je recommande de conserver un historique suffisamment long pour comparer. Si vous ne voyez que les dernières minutes, vous ne comprendrez pas si un changement de configuration a réduit la charge ou seulement déplacé le trafic.
Côté pratique, cela dépend de votre hébergement. Certains fournissent des logs d’accès bas niveau, d’autres proposent des exports, certains combinent via des outils de sécurité. L’idée reste identique: vous devez pouvoir relier une action (par exemple activation du MFA) à un changement mesurable côté tentatives et sessions.
Limites, effets de bord, et cas réels
Le durcissement n’est pas magique, et il y a des cas où il faut arbitrer.
Par exemple, si vous avez des utilisateurs qui se connectent depuis des réseaux d’entreprise avec des IP qui changent souvent, le blocage par IP peut devenir pénible. Dans ce cas, il vaut mieux s’appuyer davantage sur un MFA et sur des contrôles de comportement plutôt que sur un blocage strict.
Autre exemple: si vous utilisez un CDN ou un pare-feu applicatif, la détection de l’IP source peut être trompée. Résultat: soit vous bloquez le mauvais “client” (tout le monde semble pareil), soit vous ne bloquez jamais. Là, c’est un paramétrage technique, pas une volonté de “sécurité plus forte”.
J’ai aussi vu des sites qui activaient trop de protections en même temps, puis perdaient l’accès et ne pouvaient pas identifier la cause. Un bon réflexe est de ne modifier que quelques paramètres à la fois, pour que le diagnostic soit possible.
Enfin, ne confondez pas réduction des tentatives et absence de risque. Un attaquant peut toujours tenter autre chose, comme des scans de fichiers, des tentatives de chargement de scripts, ou une exploitation d’un autre point du site. La connexion est une porte critique, mais pas la seule.
Un petit guide de vérification avant de se dire “c’est bon”
Une fois la purge faite et le durcissement déployé, j’aime faire un contrôle final. Pas long, pas bureaucratique, juste utile.
- Vérifier que tous les comptes admin sont connus et que les utilisateurs inattendus ont été supprimés. Tester la connexion avec un compte de test, y compris sur mobile. Contrôler que les règles de blocage ne touchent pas vos propres IP ou vos plages. Confirmer que le MFA fonctionne réellement, y compris avec les options de récupération prévues. Surveiller les logs pendant 24 à 48 heures pour vérifier que les tentatives se tassent.
Ces vérifications évitent les mauvaises surprises qui arrivent souvent quand on “pense avoir fini” trop vite.
Et si l’attaque revenait malgré tout ?
Si, après sécurisation du formulaire, les tentatives reprennent à un niveau inhabituel, ou si vous détectez une nouvelle persistance, il faut éviter l’autopersuasion. Le réflexe le plus fiable, c’est de revenir aux fondamentaux: intégrité des fichiers, plugins, base de données, rôles, tâches planifiées.
Souvent, le retour d’activité signifie soit:
- un composant qui n’a pas été supprimé complètement ; un plugin réintroduit par une mise à jour ou par une restauration incorrecte ; des identifiants de session ou d’API encore utilisables ; un vecteur différent de la connexion (formulaire d’inscription, API, thèmes, fichier upload).
Le formulaire de connexion reste un point d’attaque logique, mais il peut aussi être “seulement” le lieu où la menace se manifeste.
Ce que je dirais à une équipe qui fait face à un site WordPress infecté
Dans les équipes que j’ai accompagnées, le stress vient surtout de la perte de contrôle. On a l’impression que tout peut être compromis, et chaque action technique ressemble à un pari.
Si vous devez retenir une idée, c’est celle-ci: sécuriser la connexion est indispensable, mais c’est la phase visible d’un processus plus large. Le formulaire doit être durci, oui, mais votre priorité reste de restaurer un site fiable, de comprendre ce qui a permis l’accès initial, puis de rendre les connexions futures beaucoup plus coûteuses pour l’attaquant.
Quand le site est propre, que les comptes sont sous contrôle, et que la connexion n’est plus un point d’entrée facile, les tentatives se raréfient. Et surtout, quand elles reviennent, vous avez les logs pour comprendre.
Ressources internes à votre hébergement: où regarder vraiment
Sans lister des liens que je ne peux pas vérifier, je vous propose une démarche simple: cherchez les endroits où la plateforme vous donne des preuves.
Regardez:
- les journaux d’accès web (tentatives sur le endpoint de login, codes HTTP, User-Agent suspects) ; les journaux applicatifs si vous en avez (WordPress, plugins de sécurité, logs de l’authentification) ; l’historique des modifications de fichiers si votre hébergement le permet ; la console d’administration du serveur, notamment pour les tâches et les planifications.
C’est souvent dans ces “espaces de preuve” que l’on tranche entre “bruit” et attaque structurée.
Si vous voulez, décrivez votre configuration (hébergeur, utilisation d’un CDN, plugins de sécurité actuels, présence ou non de MFA), et ce que vous observez dans les logs (volume de tentatives, erreurs, périodes). Je peux alors vous proposer une approche de durcissement plus ajustée, sans ajouter de couches inutiles.