Si votre site WordPress est piraté, commencez par conserver une copie de l’état compromis, coupez les accès actifs, changez tous les identifiants, puis contrôlez les administrateurs, les fichiers, la base de données et les tâches planifiées. Supprimer le spam visible ne suffit pas. Il faut aussi éliminer les comptes de persistance et fermer la porte d’entrée avant de remettre le site en service.

Le scénario étudié ici synthétise un incident réel entièrement anonymisé. Les noms, dates, volumes et éléments d’infrastructure ont été modifiés. Le cas est intéressant parce qu’il ne reposait pas sur un plugin infecté : une attaque de connexion distribuée avait contourné une limite par adresse IP, puis les intrus avaient créé de nouveaux administrateurs et publié du contenu indésirable.

Reconnaître rapidement un site WordPress piraté

Un article inconnu, une redirection vers un casino, une page pharmaceutique ou un nouvel administrateur suffisent pour traiter la situation comme un incident de sécurité. WordPress cite aussi les alertes des moteurs de recherche, les avertissements antivirus, l’envoi de spam et toute création d’utilisateur non autorisée parmi les indicateurs de compromission.

Notez immédiatement ce qui est visible, l’heure avec le fuseau, la dernière action légitime et les comptes concernés. Prenez des captures, exportez les journaux disponibles et réalisez une copie des fichiers et de la base avant de nettoyer. Cette sauvegarde compromise ne doit jamais remplacer une sauvegarde saine. Elle sert de preuve et permet de comprendre le vecteur d’entrée.

  • contenus, utilisateurs ou extensions que personne ne reconnaît ;
  • redirections différentes selon le mobile, le pays ou la provenance Google ;
  • fichiers PHP récents dans wp-content/uploads ;
  • modification inexpliquée de .htaccess, wp-config.php ou d’un thème ;
  • sessions administrateur nombreuses ou provenant d’emplacements inhabituels ;
  • tâches cron, mots de passe d’application ou comptes FTP inconnus.

Une page cassée n’est pas nécessairement un piratage. Une erreur PHP se reproduit généralement de façon stable, alors qu’une compromission produit souvent des comportements sélectifs ou des changements qui n’ont aucune origine éditoriale.

Comment un brute-force distribué contourne la limite par IP

Dans le scénario anonymisé, le nom de l’administrateur était facile à découvrir et la page wp-login.php restait publiquement joignable. Des dizaines d’adresses IP ont ensuite testé chacune un très petit nombre de mots de passe. La règle en place bloquait une IP après plusieurs échecs, mais aucune adresse ne dépassait seule le seuil.

Cette technique ressemble au credential stuffing quand les couples identifiant et mot de passe viennent d’une fuite antérieure. Elle peut aussi prendre la forme d’un password spraying, où un mot de passe courant est essayé contre plusieurs comptes. OWASP rappelle qu’un réseau de proxys permet de maintenir un faible volume par IP tout en produisant une attaque importante au niveau global. Un simple compteur par adresse ne doit donc jamais être l’unique défense.

L’échelle est considérable : Wordfence indique avoir bloqué plus de 55 milliards de tentatives liées aux mots de passe en 2024, provenant de près de 136 millions d’adresses IP distinctes. Le rapport regroupe brute-force, credential stuffing et autres attaques sur les identifiants. Ces chiffres ne décrivent pas tous les sites WordPress, mais ils illustrent pourquoi une défense limitée à une seule IP laisse un angle mort.

Une fois le mot de passe accepté, l’attaquant n’a plus besoin d’exploiter une faille PHP. Il utilise les fonctions normales de WordPress pour créer d’autres administrateurs, ouvrir plusieurs sessions, publier du spam ou installer une extension. Ces comptes secondaires constituent une persistance : changer seulement le mot de passe du compte principal ne les déconnecte pas.

Pour prévenir ce premier accès, consultez aussi notre guide consacré à la protection de WordPress contre les attaques brute-force. La réponse à incident présentée ici commence après le premier signe de compromission.

Reconstituer le vecteur sans tirer de conclusion trop vite

La chronologie est souvent plus fiable qu’une intuition. Comparez la date de création des comptes, les premières publications indésirables, les modifications de fichiers et les connexions visibles dans les journaux. Si les faux administrateurs apparaissent après une connexion réussie, mais que le cœur, les plugins et les thèmes correspondent aux distributions officielles, le vol ou la découverte d’un identifiant devient une hypothèse forte.

À l’inverse, un fichier récemment ajouté dans un plugin, un PHP dans les médias, une option chargée automatiquement avec du code ou une tâche cron inconnue orientent vers une exécution de code et une backdoor. Plusieurs vecteurs peuvent coexister. Un attaquant connecté comme administrateur peut ensuite déposer un fichier pour survivre à la rotation du mot de passe.

Attribuez un niveau de confiance à votre conclusion. Des journaux complets peuvent prouver une connexion et sa source. Des journaux déjà purgés ne permettent qu’un scénario probable. Écrivez clairement ce qui est confirmé, ce qui est cohérent et ce qui reste inconnu. Cette discipline évite de fermer la mauvaise porte.

Contenir l’incident sans détruire les preuves

Commencez par limiter l’exposition. Si le site distribue du malware ou redirige les visiteurs, placez-le temporairement en maintenance au niveau du serveur. Ne travaillez pas uniquement depuis wp-admin : un pirate peut encore y être connecté ou avoir modifié l’interface.

Créez ensuite une image des fichiers et un export de la base. Conservez les journaux d’accès, les journaux PHP et la liste des tâches planifiées. Prévenez l’hébergeur, surtout sur un serveur mutualisé, afin qu’il vérifie une éventuelle contamination voisine et conserve ses propres traces.

La documentation officielle WordPress recommande aussi d’analyser l’ordinateur utilisé pour administrer le site. Un voleur d’identifiants local peut récupérer le nouveau mot de passe immédiatement. Le navigateur, le gestionnaire FTP et le poste de travail font partie du périmètre de l’incident.

Après la copie forensique, changez les accès depuis un appareil sain : WordPress, panneau d’hébergement, FTP ou SFTP, base de données et services externes. Révoquez toutes les sessions et régénérez les clés de salage WordPress pour invalider les cookies existants.

Supprimer les faux administrateurs et les accès persistants

Vérifiez la liste des utilisateurs depuis l’interface et directement avec WP-CLI. Contrôlez le login, l’adresse email, la date d’inscription, les rôles et les sessions. Un compte inconnu doit être sauvegardé dans le rapport d’incident, puis supprimé. Réattribuez son contenu seulement après l’avoir inspecté, faute de quoi vous risquez de conserver du spam sous le nom d’un auteur légitime.

# Lister les administrateurs et leur date de création
wp user list --role=administrator 
  --fields=ID,user_login,user_email,user_registered,roles

# Voir puis détruire toutes les sessions d’un compte
wp user session list ID_UTILISATEUR
wp user session destroy ID_UTILISATEUR --all

# Contrôler les mots de passe d’application
wp user application-password list ID_UTILISATEUR

# Supprimer un compte suspect après sauvegarde des preuves
wp user delete ID_SUSPECT --reassign=ID_ADMIN_LEGITIME

Contrôlez aussi les comptes FTP, SSH, cPanel et les utilisateurs supplémentaires de la base de données. Sucuri souligne qu’un site nettoyé se retrouve rapidement compromis si un compte administrateur ou FTP malveillant reste actif.

Terminez par une rotation du mot de passe de chaque administrateur légitime. Utilisez une valeur longue, unique et générée par un gestionnaire de mots de passe. Une ancienne valeur réutilisée sur un autre service doit être considérée comme compromise partout.

Vérifier le cœur, les plugins, les thèmes et les médias

Un scanner distant voit ce qui est envoyé au navigateur, mais pas toutes les backdoors du serveur. Combinez donc un scan externe, une comparaison des fichiers et une inspection des emplacements où du PHP ne devrait pas apparaître.

# Comparer le cœur avec les empreintes officielles WordPress.org
wp core verify-checksums --include-root

# Comparer les plugins issus du dépôt officiel
wp plugin verify-checksums --all --strict

# Chercher du PHP dans le dossier des médias
find wp-content/uploads -type f 
  ( -name '*.php' -o -name '*.phtml' -o -name '*.phar' ) -print

# Repérer les fichiers modifiés récemment
find . -type f -mtime -14 -print

# Lister les événements WordPress planifiés
wp cron event list

La commande wp core verify-checksums télécharge les empreintes correspondant à la version et à la langue installées, puis compare les fichiers avant même de charger WordPress. Une différence n’est pas automatiquement malveillante, mais elle exige une explication. Pour un plugin premium ou personnalisé, comparez le serveur avec une archive propre conservée hors ligne.

Inspectez particulièrement wp-config.php, .htaccess, les fichiers de thème, les mu-plugins, wp-content/uploads et la racine Web. Recherchez les appels inattendus à eval, base64_decode, gzinflate, shell_exec ou des écritures de fichiers. Ces fonctions ont aussi des usages légitimes : le chemin, l’auteur et le contexte comptent davantage qu’un mot isolé.

Nettoyer la base et les contenus injectés

Supprimez les articles, pages, commentaires, menus et widgets ajoutés par l’attaquant. Vérifiez les brouillons, la corbeille et les révisions. Recherchez les domaines inconnus, les scripts, les iframes, les textes dans une langue inattendue et les redirections.

Contrôlez ensuite les tables wp_options et wp_usermeta. Les valeurs siteurl, home, active_plugins, les options chargées automatiquement et les jetons de session méritent une attention particulière. Examinez aussi les tâches cron et les contenus planifiés qui pourraient republier le spam après le nettoyage.

Si les moteurs ont indexé les pages pirates, notez leurs URL avant suppression. Elles doivent répondre en 404 ou 410, sauf si une redirection vers une page réellement équivalente est pertinente. Vérifiez Google Search Console, les actions manuelles, les problèmes de sécurité et le rapport d’indexation avant de demander un nouvel examen.

Fermer la porte face aux attaques distribuées

Une limite de cinq tentatives par IP arrête un script naïf, pas un botnet. Ajoutez une défense globale par compte, des fenêtres courtes et longues, une alerte sur les pays ou appareils inhabituels et un challenge pour les sources à risque. Un WAF en amont réduit aussi la charge avant que PHP et WordPress soient exécutés.

Le MFA reste la protection la plus robuste contre un mot de passe découvert. Quand son déploiement n’est pas possible, OWASP recommande de combiner plusieurs contrôles plutôt que de faire confiance à un seul. Pour une petite équipe administrative, une authentification HTTP Basic devant wp-login.php constitue un deuxième verrou au niveau du serveur. Elle doit impérativement fonctionner sous HTTPS.

# Fichier .htaccess à la racine, exemple Apache
<Files "wp-login.php">
    AuthType Basic
    AuthName "Accès administration"
    AuthUserFile "/chemin/prive/.htpasswd-wordpress"
    Require valid-user
</Files>

Apache recommande de placer le fichier de mots de passe hors du répertoire public. Le mot de passe Basic circule dans la connexion HTTP et ne doit donc jamais être utilisé sans TLS. Testez le login, la déconnexion, la récupération de mot de passe et les intégrations légitimes après activation.

Masquer l’URL d’administration réduit le bruit, mais ne remplace pas un contrôle d’accès. Si vous souhaitez ajouter une barrière serveur proprement, notre guide explique comment protéger wp-admin sans plugin. Bloquez également XML-RPC si aucune application ne l’utilise et empêchez l’énumération publique des identifiants via REST ou les archives d’auteur.

Roter les secrets au-delà de WordPress

Le mot de passe WordPress n’est qu’un secret parmi d’autres. Rotez le panneau d’hébergement, les comptes FTP ou SFTP, la base de données, les clés API, les webhooks, les mots de passe d’application et les jetons de déploiement susceptibles d’avoir été lus pendant l’intrusion.

Créez des comptes techniques dédiés avec le minimum de droits. Un outil qui dépose seulement des contenus ne devrait pas partager le mot de passe maître de l’hébergement. Stockez les secrets hors du webroot, ne les inscrivez jamais dans une sauvegarde publiquement téléchargeable et retirez les anciens fichiers .bak, .old ou journaux de débogage.

WordPress recommande aussi de désactiver l’éditeur de fichiers intégré avec DISALLOW_FILE_EDIT. Sur une infrastructure gérée par déploiement, DISALLOW_FILE_MODS peut aller plus loin en empêchant l’installation et la modification de thèmes ou plugins depuis l’administration. Cette option impose toutefois un processus externe fiable pour les mises à jour de sécurité.

Valider la récupération avant de rouvrir le site

Ne concluez pas sur la disparition du spam visible. Refaites l’inventaire avec des contrôles indépendants. Le site doit répondre correctement, les fichiers doivent correspondre aux sources propres et aucun accès inconnu ne doit subsister.

  • un seul ensemble d’administrateurs connus et justifiés ;
  • aucune session ni aucun mot de passe d’application inattendu ;
  • aucun PHP dans les médias ;
  • cœur et plugins officiels conformes aux checksums ;
  • aucune tâche cron, redirection ou option inconnue ;
  • login protégé et testé depuis un navigateur non authentifié ;
  • page d’accueil, articles, formulaires et administration fonctionnels ;
  • scan externe propre et absence d’alerte dans Search Console ;
  • sauvegarde réellement restaurable sur un environnement isolé.

Pour préparer cette dernière étape avant qu’un incident survienne, suivez notre méthode de sauvegarde WordPress avec test de restauration. Une archive jamais restaurée n’est pas encore une garantie de reprise.

Surveiller le site pendant les jours suivants

Une réinfection rapide indique généralement qu’un accès ou une backdoor a été oublié. Pendant au moins 72 heures, contrôlez quotidiennement les administrateurs, les fichiers récemment modifiés, les tâches planifiées, les publications et les requêtes de connexion.

Configurez des alertes pour toute création d’administrateur, modification d’un fichier critique, connexion depuis un nouvel environnement et changement de plugin. Conservez les journaux plus longtemps que la période habituelle de découverte d’un incident. Une rétention trop courte peut effacer la connexion initiale avant l’analyse.

Maintenez WordPress et ses extensions à jour depuis des sources officielles. Supprimez les thèmes et plugins inutilisés plutôt que de simplement les désactiver. Notre méthode d’audit des plugins WordPress aide à vérifier versions, provenance et vulnérabilités connues.

Les erreurs qui provoquent une nouvelle compromission

  • Restaurer sans changer les accès : le pirate se reconnecte avec le même secret.
  • Supprimer immédiatement toutes les traces : vous perdez la chronologie et le vecteur d’entrée.
  • Faire confiance à un seul scanner : un scan distant ne voit pas toute la persistance serveur.
  • Changer uniquement le mot de passe principal : les autres administrateurs et sessions restent valides.
  • Installer plusieurs plugins de sécurité au hasard : les conflits compliquent l’analyse sans corriger la cause.
  • Garder des sauvegardes dans le webroot : une extension inhabituelle peut exposer leur code et leurs secrets.
  • Annoncer une sécurité absolue : une correction réduit le risque, elle ne rend jamais un système impossible à pirater.

Checklist de réponse à un piratage WordPress

  1. Confirmer les indicateurs et noter l’heure.
  2. Limiter l’exposition si les visiteurs sont en danger.
  3. Conserver une copie des fichiers, de la base et des journaux.
  4. Travailler depuis un appareil sain.
  5. Roter tous les accès et détruire les sessions.
  6. Supprimer les utilisateurs et contenus malveillants.
  7. Vérifier le cœur, les extensions, les thèmes, les médias et les crons.
  8. Nettoyer la base et les résultats indexés.
  9. Corriger le vecteur d’entrée avec plusieurs couches.
  10. Tester le site, le login et une restauration.
  11. Surveiller toute récidive pendant plusieurs jours.

FAQ sur un site WordPress piraté

Faut-il restaurer immédiatement la dernière sauvegarde ?

Non. Identifiez d’abord si la sauvegarde précède l’intrusion et changez les accès compromis. Une restauration contaminée ou remise en ligne avec le même mot de passe sera rapidement piratée à nouveau.

Un plugin de sécurité peut-il nettoyer tout le site automatiquement ?

Il peut détecter de nombreux fichiers connus, mais il ne remplace pas l’audit des utilisateurs, des sessions, des comptes d’hébergement, de la base et des tâches planifiées. Utilisez plusieurs sources de vérification.

Comment savoir si l’entrée vient d’un mot de passe ou d’un plugin ?

Reconstituez la chronologie avec les connexions, créations d’utilisateurs et modifications de fichiers. Un login réussi suivi de comptes administrateur, sans différence dans les distributions officielles, favorise l’hypothèse du mot de passe. Un fichier ajouté ou modifié avant la première connexion suspecte favorise une faille applicative.

Limiter les tentatives par IP suffit-il contre le brute-force ?

Non. Une attaque distribuée utilise de nombreuses IP avec un faible volume chacune. Combinez le contrôle par IP avec une limite par compte, un WAF, des alertes, un second verrou serveur et idéalement une authentification multifacteur.

Quand peut-on considérer le nettoyage comme terminé ?

Lorsque les accès sont rotés, les sessions détruites, les utilisateurs vérifiés, les fichiers et la base contrôlés, le vecteur fermé, les tests fonctionnels réussis et aucune récidive observée pendant la période de surveillance.

Sources vérifiées

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.