Quand un site WordPress est compromis, la panne la plus visible est rarement la plus dangereuse. Les injections de code, les redirections en cascade, les pages déformées, tout ça finit souvent par sauter aux yeux. Pourtant, le vrai risque continue souvent après le “retour à la normale”, parce qu’une compromission touche presque toujours les identifiants. Si un attaquant a eu accès aux mots de passe, il ne les oublie pas. Même si vous supprimez le fichier malveillant, il peut garder la porte déverrouillée pour revenir quand bon lui semble.
C’est là que la rotation des mots de passe devient non négociable. Pas un geste symbolique. Une procédure de sécurité, avec le bon niveau de rigueur, au bon moment, et dans le bon périmètre. Et surtout, avec une logique simple: tant que les identifiants n’ont pas été repris en main, vous ne savez pas à quel point le site est redevenu “à vous”.
Pourquoi la rotation est indispensable après une infection
Un site WordPress infecté n’est pas seulement un site “cassé”. C’est un site dont le contrôle a pu être intercepté. Une fois que l’attaquant a trouvé une voie d’accès, il peut:
- modifier un plugin ou un thème, créer un compte administrateur, voler des cookies de session, exfiltrer des identifiants, installer un mécanisme persistant (par exemple via une tâche planifiée, un hook, ou un fichier caché), ou tout simplement conserver des identifiants valides pour rebondir plus tard.
Le point clé, c’est que la rotation des mots de passe ne sert pas qu’à “changer ce qui est visible”. Elle sert à casser les accès probables restants. Si l’attaquant a récupéré votre mot de passe WordPress, votre nouveau site restera potentiellement accessible avec l’ancien, tant que vous ne l’avez pas invalidé. Si vous ne le faites pas, vous créez une situation classique: le site semble redevenir stable, puis des signaux réapparaissent quelques jours plus tard, souvent avec des traces plus difficiles à corréler car l’environnement a eu le temps de “se réinstaller”.
J’ai vu des équipes remettre en ligne un WordPress après nettoyage des fichiers, puis constater, une semaine plus tard, des publications d’apparence normale qui n’étaient pas les leurs. En analysant côté base de données et côté comptes, on a découvert un compte administrateur ajouté pendant l’incident, et des connexions qui utilisaient toujours un identifiant antérieur. Tant que les mots de passe n’ont pas été changés proprement, l’incident ne s’éteint pas vraiment. Il se contente de changer de forme.
Le piège le plus courant: changer “le mot de passe WordPress” et oublier le reste
Beaucoup de gens pensent à WordPress uniquement. Ils changent le mot de passe du compte principal, puis remplacent les fichiers corrompus et espèrent que tout est réglé. Ça peut aider, mais ce n’est presque jamais suffisant.
Dans un incident réel, les points d’accès se multiplient:
- accès au back-office WordPress via plusieurs comptes, accès à la base de données (souvent utilisé par des scripts de persistance), accès au serveur via SSH ou via le panneau d’hébergement, accès au compte mail utilisé pour les réinitialisations, accès aux services tiers (CDN, hébergement d’images, WAF, outils de monitoring), accès aux clés API (si elles existent dans des extensions ou des intégrations).
Si un seul de ces “points de contrôle” garde un mot de passe exposé, vous pouvez faire tourner la roue dans le vide. Le site peut rester infecté, ou se recontaminer dès que l’attaquant retrouve un moyen d’écrire.
C’est pour ça qu’on ne parle pas de rotation “au sens vague”. On parle de rotation ciblée, exhaustive dans le périmètre logique de l’incident, et réalisée avec un enchaînement qui limite les retours.
Avant de tourner: sécuriser la surface d’attaque et couper les accès
La rotation des mots de passe doit arriver au bon moment. Si vous changez les mots de passe alors que le site est encore accessible, l’attaquant peut continuer à agir pendant que vous travaillez. Il peut aussi modifier des éléments après coup, par exemple ajouter un autre utilisateur ou rejouer une charge utile.
Dans la pratique, la décision la plus saine est de réduire la possibilité d’actions concurrentes pendant que vous clarifiez l’ampleur du problème. Souvent, cela implique de mettre le site en mode “le temps de”.
Les manières exactes dépendent de votre contexte (hébergement partagé, VPS, accès technique), mais l’objectif est constant: empêcher l’attaquant de poursuivre ses modifications pendant que vous rétablissez la sécurité. Sur certains environnements, le blocage du trafic entrant, la désactivation temporaire de certaines fonctions, ou une mise en maintenance peut suffire. Sur d’autres, la fermeture plus stricte de l’accès administrateur ou le retrait temporaire d’identifiants dans les contrôleurs de déploiement est préférable.
Je garde une règle mentale simple: si vous n’avez pas encore confirmé ce qui a été modifié, ne laissez pas l’attaquant dans la même “fenêtre” d’action que vous.
Quels mots de passe faut-il réellement faire tourner
La rotation doit couvrir, au minimum, tout ce qui peut servir de vecteur d’accès. Dans un incident WordPress, je raisonne en cercles.
- Premier cercle, le plus évident: les comptes WordPress (au sens strict), et notamment les comptes ayant les rôles élevés. Deuxième cercle: les identifiants d’administration liés à l’hébergement et à la gestion du code (SSH, FTP, panel d’hébergement, gestionnaire de fichiers). Troisième cercle: la base de données et les identifiants de connexion. Quatrième cercle: l’accès à la boîte mail de référence, parce que beaucoup de compromissions s’appuient sur la réinitialisation et la récupération de compte. Cinquième cercle: les services “automatisants” qui pourraient réintroduire des accès (CI/CD, scripts, synchronisations, plugins d’intégration).
Ce n’est pas parce que “vous n’avez pas de raison de penser que l’attaquant a touché X” que vous pouvez ignorer X. Une infection, c’est justement la preuve qu’un chemin a existé.
Signes qui indiquent que la rotation doit être plus large
Il y a des signaux qui, sans prouver à eux seuls tout, suggèrent que l’attaquant a eu plus que la simple possibilité d’écrire une page. Dans ces cas, je recommande d’élargir la rotation, parfois au-delà du strict minimum.
- nouveaux comptes apparus sans explication, surtout avec des rôles admin ou éditeur tentatives de connexion répétées vers wp-login.php, ou plusieurs IP suspectes dans les logs modifications de fichiers applicatives après votre nettoyage, même si les symptômes visibles sont revenus au calme changement de paramètres WordPress non documenté (email de l’administrateur, URL, paramètres de sauvegarde, etc.) réapparition de redirections, de scripts externes, ou de base SEO incohérente peu de temps après remise en ligne
Cette liste n’est pas un diagnostic automatique. Elle sert de boussole: elle justifie une approche plus stricte.
Rotation des mots de passe: le bon ordre pour limiter le risque
La rotation n’est pas seulement une succession de remplacements. C’est une stratégie pour empêcher l’attaquant de conserver une fenêtre valide. L’ordre compte, surtout si vous avez encore des accès actifs, ou si des comptes utilisent des sessions longues.
Concrètement, l’ordre ci-dessous correspond à une logique terrain: d’abord invalider l’accès au niveau applicatif, ensuite couper l’accès “infrastructure”, puis vérifier que rien ne redevient possible via des voies secondaires.
Mettez le site en mode contrôlé (maintenance ou blocage d’accès) avant la première rotation, afin d’éviter des actions simultanées. Changez les mots de passe des comptes WordPress, en particulier tous les comptes avec des privilèges élevés. Déconnectez les sessions si l’outil le permet. Changez le mot de passe de l’accès hébergement (SSH, panel, FTP) et invalidez les connexions actives si votre hébergeur propose une option équivalente. Changez le mot de passe de la base de données (et mettez à jour la configuration WordPress correspondante), puis validez que WordPress se connecte correctement. Changez le mot de passe de la boîte mail liée aux comptes (et vérifiez les règles de redirection, alias, et dispositifs de récupération), puis surveillez immédiatement toute tentative de réinitialisation.Cette séquence réduit une erreur fréquente: tourner un seul mot de passe pendant que d’autres identifiants restent valides. Elle aide aussi à empêcher un “replay” de l’accès pendant la phase de nettoyage.
Attention aux sessions, aux cookies et aux comptes “en apparence” supprimés
Même si vous changez un mot de passe, il existe des cas où l’attaquant garde un accès pendant un temps. WordPress repose sur des sessions et des cookies. Un attaquant qui a déjà une session valide peut continuer à naviguer tant que la session n’est pas expirée ou invalidée.
D’où une pratique utile: après rotation, vérifiez les comptes utilisateurs et déconnectez les sessions pertinentes quand c’est possible. Si votre incident a laissé des traces de connexions récentes, considérer l’expiration forcée est souvent raisonnable.
Sur certains hébergements, vous pouvez également agir au niveau “php session” ou via l’outil WordPress. Dans d’autres, vous devrez vous contenter de mettre fin au moins aux accès via mots de passe et d’observer le comportement. Le point central reste le même: un mot de passe neuf ne garantit pas que toutes les sessions existantes deviennent immédiatement inactives.
Autre point délicat: les comptes “en apparence” supprimés. Un attaquant peut créer un compte puis le supprimer, ou ne garder qu’un artefact. Après rotation, la vérification manuelle des utilisateurs, leur date de création, et leurs rôles est un geste simple qui évite des heures d’enquête après coup.
La rotation ne remplace pas le nettoyage, elle le complète
Il faut être clair sur une chose: changer les mots de passe n’efface pas une charge utile déjà installée. Si un plugin malveillant reste présent, ou si un fichier de thème a été modifié, l’attaquant peut toujours revenir via d’autres chemins, y compris en profitant de la persistance déjà en place.
Le bon réflexe est de combiner:
- nettoyage du code (fichiers, plugins, thèmes, éventuels scripts) vérification de l’intégrité des fichiers (au moins sur une base pragmatique) rotation des identifiants dans le périmètre raisonnable durcissement minimal (mises à jour, règles d’accès, réduction des surfaces inutiles)
Ce qui m’importe, c’est le scénario “deux étapes”. Vous ne voulez pas une approche où vous nettoyez d’abord sans casser l’accès. Et vous ne voulez pas non plus l’inverse, tourner sans nettoyer. Dans les incidents réels, les deux logiques se recouvrent, mais la rotation reste l’assurance contre le retour via identifiants.
Comment vérifier que la rotation a fonctionné
Après rotation, le site ne doit pas seulement “sembler normal”. Il doit être vérifiable. La vérification ne doit pas être lourde, elle doit être régulière et orientée symptômes.
Commencez par observer l’administration: tentatives de connexion, nouveaux utilisateurs, changements de paramètres, logs d’erreurs, et comportement du front. Ensuite, contrôlez les points de persistance connus: fichiers inattendus, accès aux répertoires sensibles, présence de scripts externes ajoutés, et redirections.
Si vous disposez d’un outil de sécurité (WAF, scan, monitoring), utilisez-le comme baromètre. Mais gardez votre lucidité: un scan qui ne détecte pas ne prouve pas l’absence. L’absence de détection n’est pas la même chose que la preuve de propreté.
Un indicateur qui rassure, c’est la stabilité sur plusieurs jours, en particulier si votre site a un volume de trafic faible ou moyen. Une infection opportuniste peut tenter un retour rapidement. Si rien ne réapparaît sur un laps de temps raisonnable, votre probabilité de contrôle augmente.
Construire un plan de mots de passe qui évite de recommencer
La rotation est un moment de sécurité, pas un événement isolé. Si vous utilisez encore des mots de passe réutilisés, si vous stockez des identifiants dans des endroits risqués, ou si vous laissez des accès partagés, vous préparez la prochaine crise.
Ici, l’enjeu est plus “process” que technique. J’ai vu des équipes réagir en changeant tout le jour J, puis réutiliser les anciens schémas de gestion juste après. Deux semaines plus tard, un incident de même nature revient, parfois sur un autre compte.
Sans transformer votre fonctionnement en usine à gaz, vous pouvez viser quelques principes simples: chaque compte critique a un https://gardewp.fr/nettoyage-malware-wordpress/ mot de passe unique, la boîte mail de récupération n’est pas une boîte “générique” laissée sans surveillance, et l’équipe dispose d’un circuit clair pour gérer les accès. La rotation devient alors un geste intégré, pas une panique.
Les erreurs qui compliquent tout
Il existe des erreurs classiques qui font perdre du temps et, parfois, empirent la situation. Je les liste en vrac dans le style des retours terrain, parce qu’elles reviennent assez souvent pour mériter d’être gardées en tête.
- changer un seul mot de passe et oublier les comptes secondaires laisser des sessions actives sans les invalider quand c’est possible modifier la configuration WordPress pendant que la base n’a pas été sécurisée réinstaller des sauvegardes “propres” mais en gardant les mêmes identifiants compromis dans les réglages conserver les mêmes identifiants hébergeur qui avaient déjà permis la compromission ignorer les emails de récupération, et constater après coup des réinitialisations déclenchées par l’attaquant
Dans une compromission, le temps est précieux. Plus on corrige de manière cohérente, plus on limite le cycle “on nettoie, puis ça revient”.
Particularités selon votre environnement WordPress
Tous les WordPress ne se ressemblent pas, et la manière de faire tourner les accès dépend de votre architecture.
Si vous êtes sur un hébergement mutualisé, la rotation côté SSH peut être plus simple ou au contraire inexistante, selon les services disponibles. Si vous êtes sur un VPS avec accès root, il faut aussi réfléchir aux utilisateurs système et aux clés SSH. Si vous utilisez un outil de déploiement, vous devez prendre en compte les identifiants stockés dans les variables d’environnement. Enfin, si votre WordPress est derrière un proxy, un CDN ou un WAF, vérifiez que les règles de sécurité n’ont pas été contournées, ou que des endpoints n’ont pas été laissés trop ouverts pendant la phase d’assainissement.
L’idée n’est pas de tout révolutionner. L’idée est d’identifier où se trouvent les portes d’entrée, et de les fermer proprement.
Après l’incident: garder de la preuve et documenter
Le travail de rotation est aussi un travail de mémoire. Notez les dates de changement, les comptes ciblés, les actions de nettoyage réalisées, et les symptômes observés avant et après. Si vous devez expliquer l’incident à une équipe, à un hébergeur, ou à un partenaire, ce dossier réduit le temps de reconstitution.
Cette documentation aide aussi pour un point pratique: savoir quand vous avez tourné les accès, et donc savoir si une nouvelle anomalie est une réinfection probable, ou une persistance apparente.
Dans certains cas, un incident WordPress infecté laisse des traces dans la configuration, et la rotation sans documentation rend l’enquête confuse. Une chronologie simple, même sur un fichier texte, fait gagner du temps.
Une dernière vérification mentale
Avant de considérer l’incident terminé, je reviens à une question. Est-ce que j’ai cassé tous les chemins d’accès que l’attaquant a pu utiliser, et est-ce que je l’ai fait après avoir réduit les possibilités d’action concurrente?
Si la réponse est oui, et si le site reste stable après plusieurs jours d’observation, vous avez une base solide. Si la réponse est “j’ai changé X mais je ne sais pas pour Y”, alors il reste une zone à risque. Dans ces moments là, mieux vaut étendre la rotation et vérifier un peu plus, que remettre en production en gardant une incertitude.
La rotation des mots de passe n’est pas une étape “technique” au sens étroit. C’est une mesure de contrôle. Un site WordPress compromis peut être nettoyé, mais tant que les identifiants ne sont pas repris en main, le contrôle reste incomplet. C’est précisément ce que la rotation vise à réparer.