Comment j’ai découvert et nettoyé un WordPress piraté
Récemment, un site WordPress hébergé chez OVH présentait plusieurs comportements anormaux. La base de données dépassait largement le quota autorisé (500mo sur l’offre Perso) et l’affichage du site déclenchait parfois des redirections vers des boutiques en ligne externes, signe classique d’une compromission.
Après un premier accès au serveur d’hébergement en SFTP, rapidement, j’ai vu que certains éléments n’étaient pas logiques.
Voici entre autres les étapes passées et les actions menées pour nettoyer le piratage et restituer un site sain :
Pour comprendre pourquoi les plugins non mis à jour constituent la principale porte d’entrée des pirates, consultez cet article : un site WordPress peut-il vraiment être piraté via un plugin pas à jour ?
Sommaire
- Étape 1 : Découverte des fichiers malveillants dans /wp-content/
- Étape 2 : Analyse du fichier mkhrcc.php : une backdoor complète
- Étape 3 : Analyse du fichier mhkrrc.php : module InjectBody
- Étape 4 : Analyse du fichier db-config.ini : cache malveillant
- Étape 5 : Synthèse du diagnostic
- Étape 6 : Première analyse élargie : erreurs critiques après restauration de /wp-admin
- Étape 7 : Cartographie des zones infectées
- Étape 8 : Analyse technique : fonctionnement de l’infection
- Étape 9 : Intervention : remise en état
- Résultat : un site sécurisé, propre et prêt pour l’avenir
- Durée du travail de détection puis désinfection
- FAQ – Désinfection et réparation d’un site WordPress infecté
- Recourir au nettoyage d’une experte
Étape 1 : Découverte des fichiers malveillants dans /wp-content/
Dans le dossier principal de WordPress se trouvaient plusieurs fichiers qui n’existent jamais dans une installation légitime :
mhkrrc.phpdb-config.ini- un fichier du même type, au nom aléatoire, similaire à
mkhrcc.php
Aucun de ces fichiers ne correspond à WordPress, à un plugin ou à un thème.
Étape 2 : Analyse du fichier mkhrcc.php : une backdoor complète
Le fichier contenait du PHP obfusqué utilisant notamment :
$_POST['b'],$_POST['f'],$_POST['c']- reconstruction dynamique de
file_put_contentsetbase64_decode - vérification de hash MD5 servant de mot de passe
Il s’agissait d’une backdoor permettant :
- l’upload de fichiers à distance
- l’écriture directe à la racine
- la réinstallation d’autres malwares
- le contrôle complet du serveur via une simple requête POST
Étape 3 : Analyse du fichier mhkrrc.php : module InjectBody
Son contenu était une configuration sérialisée :
a:4:{s:7:"enabled";s:1:"1";s:7:"timeout";i:300;s:6:"filter";s:16:"_posts|_postmeta";s:8:"loadstat";s:125:"<!-- stats -->";}
Ce format est typique de familles de malware documentées par Sucuri et Wordfence.
Il sert à :
- injecter du JavaScript ou du HTML dans les pages
- exécuter du code distant
- analyser et modifier posts et postmeta
- assurer une persistance même après mises à jour
Étape 4 : Analyse du fichier db-config.ini : cache malveillant
Bien qu’il porte une extension .ini, son contenu était du PHP sérialisé, utilisé comme “mémoire interne” pour recharger automatiquement la charge utile si un fichier infecté était supprimé. Cela indique une infection conçue pour survivre aux nettoyages classiques.
Étape 5 : Synthèse du diagnostic
Le site était victime d’une chaîne d’infection complète reposant sur :
- un uploader backdoor (accès pirate total)
- un loader InjectBody (injection dynamique de code)
- une configuration persistante (réinstallation automatique)
Ce schéma est conforme aux attaques référencées par Sucuri, Wordfence et l’OWASP.
Étape 6 : Première analyse élargie : erreurs critiques après restauration de /wp-admin
Chaque tentative de remplacement du dossier /wp-admin déclenchait une erreur critique.
Le site tournait sous WordPress 5.8.12 tandis que l’hébergement était passé en PHP 8.3, provoquant déjà des incompatibilités. L’existence de fichiers malveillants dans plusieurs zones expliquait l’instabilité globale.
Étape 7 : Cartographie des zones infectées
Plusieurs répertoires, parfois très anciens, contenaient du PHP exécutable. L’infection était disséminée au-delà du cœur WordPress.
1. Backdoors à la racine WordPress
wp-blogs.phpiijmdny7.php
2. Faux plugin masqué
Dossier : /wp-content/plugins/HelloDollyV2_jwbq/
Fichier interne infecté :
hello_dolly_v2.php
Il contenait une classeUnsafeCryptopermettant d’exécuter du code transmis à distance via AES-256-CTR.
3. Scripts dans des répertoires non liés à WordPress
Dossier : /audio/ad/
Sous-dossiers : style, theme/upload/temp
Fichiers anormaux :
index.phpmodifié- plusieurs
.txtcontenant du PHP masqué
4. Backdoor dans .well-known
Un fichier PHP dissimulé utilisant base64_decode, md5, glob, capable :
- d’envoyer des fichiers
- d’exécuter des commandes
- de modifier des permissions
Résumé des menaces
| Fichier / Dossier | Fonction malveillante | Risque principal |
|---|---|---|
wp-blogs.php, iijmdny7.php | Backdoor distante | Contrôle total |
/HelloDollyV2_jwbq/hello_dolly_v2.php | Exécution de commandes chiffrées | Injection continue |
/audio/ad/ | Scripts de persistance | Réinfection automatique |
.well-known/index.php | Webshell masqué | Upload illimité |
Étape 8 : Analyse technique : fonctionnement de l’infection
Le malware assurait :
- la persistance grâce à des points d’ancrage multiples
- l’exécution distante via le faux plugin encrypté
- la dissimulation dans des répertoires non liés à WordPress
C’est ce qui empêchait toute restauration classique et provoquait la réapparition des fichiers supprimés.
Étape 9 : Intervention : remise en état
L’intervention s’est déroulée en trois phases :
- Suppression absolue de tous les fichiers identifiés
Tous les fichiers PHP hors structure WordPress ont été supprimés. - Réinstallation propre du cœur WordPress
Les dossiers/wp-adminet/wp-includesont été remplacés par les versions officielles correspondant à WordPress 5.8.12. - Vérification serveur
L’espace disque, auparavant saturé par des caches malveillants et des fichiers inutiles, a été normalisé.
Le tableau de bord WordPress était immédiatement opérationnel.
La base de données est passée d’environ + de 500 Mo, à environ 400 MO. Puis désormais à 43 Mo.
Résultat : un site sécurisé, propre et prêt pour l’avenir
Une fois l’ensemble des portes dérobées éliminées, le site a retrouvé :
- un fonctionnement stable
- la possibilité de mettre à jour WordPress
- une base de données à nouveau dans les limites OVH
- un environnement sécurisé sans injection ni backdoor
Ce use case illustre une situation fréquente : un site vieillissant, une montée en PHP trop brutale et des fichiers dormants issus d’une infection ancienne. Le dépannage n’est pas qu’une simple question de compatibilité, mais bien un travail de détection, d’analyse et de nettoyage méthodique.
Durée du travail de détection puis désinfection
1. Analyse initiale et diagnostic : 45 minutes à 1 h
- tests d’accès au site et à l’administration
- inspection des symptômes (erreur critique, redirections, surcharge serveur)
- analyse rapide FTP + repérage des premiers fichiers anormaux
- vérification de la version PHP / WordPress
2. Exploration complète du serveur : 45 minutes à 1 h
- audit des dossiers hors WordPress
- recherche manuelle de fichiers PHP cachés
- comparaison avec une structure WordPress propre
- détection des backdoors disséminées
3. Nettoyage, suppression des fichiers malveillants et sécurisation : 45 minutes à 1 h 15
- suppression des backdoors repérées
- nettoyage des répertoires parasites
- contrôle des permissions
- vérification des fichiers réinjectés automatiquement
- inspection de
.well-known,audio/, racine, plugins, wp-content/uploads
4. Réinstallation propre du core WordPress : 15 à 30 minutes
- remplacement de
/wp-admin - remplacement de
/wp-includes - vérification version / compatibilité PHP
- test de chargement de l’admin
5. Contrôle final, tests et optimisation du serveur : 20 à 40 minutes
- test de navigation front + admin
- nettoyage de la base (taille, options douteuses)
- vérification des logs
- vérification espace disque OVH
- installation ou activation d’une solution de sécurité
FAQ – Désinfection et réparation d’un site WordPress infecté
Certains malwares ajoutent plusieurs portes dérobées dans différents répertoires. Même si vous supprimez un fichier infecté, un “loader” peut le recréer automatiquement. C’est pourquoi un nettoyage complet nécessite de vérifier tout le serveur, y compris les dossiers hors WordPress.
On retrouve souvent des fichiers aux noms aléatoires comme iijmdny7.php, mhkrrc.php, ou mkhrcc.php. D’autres infections se cachent dans des faux plugins, des sous-dossiers audio/, temp/, ou encore .well-known. Tout fichier PHP non natif de WordPress doit être examiné.
Une désinfection sérieuse demande généralement entre 2 h 30 et 5 h selon l’étendue de l’infection. Cela inclut l’analyse, la suppression des backdoors, la réinstallation propre de WordPress, les tests, puis le contrôle complet du serveur.
Oui, au minimum les dossiers /wp-admin et /wp-includes doivent être remplacés par une version officielle. Les fichiers du cœur de WordPress ne doivent jamais être modifiés. Leur remplacement garantit que le code source n’a pas été altéré.
Oui. Si votre site utilise une ancienne version de WordPress ou des plugins obsolètes, un passage brutal à PHP 8.2 ou 8.3 peut déclencher des erreurs fatales. Il est conseillé d’ajuster PHP uniquement après avoir vérifié la compatibilité de votre installation.
C’est possible. Certains scripts injectent des logs, du faux contenu ou des options répétées dans la base, ce qui peut rapidement saturer le quota de l’hébergement, surtout chez OVH. Cela ralentit le site et peut bloquer l’accès au tableau de bord.
Oui. Les backdoors peuvent enregistrer ou détourner des accès. Il est conseillé de changer les mots de passe WordPress, FTP, base de données et ceux liés à votre hébergement.
Après une désinfection complète, il est essentiel de :
- surveiller les modifications de fichiers
- Un site maintenu réduit fortement les risques de réinfection.
- mettre WordPress, les thèmes et les plugins à jour
- supprimer les comptes FTP inutilisés
- installer un pare-feu applicatif
- effectuer des sauvegardes régulières
Recourir au nettoyage d’une experte
Un site WordPress qui affiche une erreur critique, des redirections étranges ou un tableau de bord inaccessible n’est jamais un hasard. Ces problèmes peuvent venir d’un conflit, d’une mise à jour bloquée ou d’un fichier malveillant resté invisible pendant des mois. Grâce à une intervention claire et méthodique, je vous aide à rétablir votre site rapidement : analyse complète des fichiers, vérification serveur, remise en place d’un WordPress propre et sécurisation durable pour éviter que les incidents ne se répètent. Vous retrouvez un site stable, fonctionnel et prêt à être mis à jour en toute sécurité.
Votre site WordPress est piraté en ce moment ?
Un site WordPress qui affiche une erreur critique, des redirections étranges ou un tableau de bord inaccessible n’est jamais un hasard. Ces problèmes viennent souvent d’un conflit, d’une mise à jour bloquée ou d’un fichier malveillant resté invisible pendant des mois. Je vous aide à rétablir votre site rapidement
J’interviens sous 24h pour :
- Analyser et nettoyer les fichiers infectés
- Vérifier et sécuriser votre serveur
- Remettre en place un WordPress propre et sécurisé
- Éviter que les incidents ne se répètent
Contact urgence : contact@yesweblog.fr | 07 56 94 78 33
Webmaster WordPress depuis 15 ans
Sur le même Thème
