Comment supprimer un malware d'un site WordPress

Ce guide suppose que vous avez confirmé l'infection. Si ce n'est pas le cas, commencez par la vérification en cinq minutes. Si vous venez de trouver le problème, suivez d'abord les étapes de la première heure dans Comment réparer un site WordPress piraté. Elles couvrent la sauvegarde, la décision de mettre le site hors ligne et le changement de tous les identifiants, et il ne faut pas les sauter.

Étape 1 : créer un dossier de quarantaine

Déplacez les fichiers suspects hors du site au lieu de les supprimer. Un faux positif se restaure facilement, un fichier supprimé non. Placez le dossier en dehors de la racine web :

mkdir -p ~/quarantine

Étape 2 : remplacer le cœur de WordPress

Les dossiers du cœur ne doivent jamais contenir de code modifié à la main, donc les remplacer est sans risque. Enregistrez d'abord le numéro de version, car vous allez supprimer le fichier qui le contient :

VERSION=$(wp core version)
rm -rf wp-admin wp-includes
wp core download --force --skip-content --version=$VERSION
wp core verify-checksums

Le téléchargement restaure des copies saines des dossiers du cœur et des fichiers à la racine comme index.php et wp-login.php. La dernière commande doit indiquer que tout est vérifié. Toute ligne « File should not exist » signale un fichier étranger caché parmi les fichiers du cœur. Déplacez-le en quarantaine.

wp-config.php ne fait pas partie du téléchargement : ouvrez-le et lisez-le. Cherchez du code au-dessus des premières lignes ou sous la dernière ligne, ainsi que tout eval, base64_decode ou include pointant vers un fichier que vous ne reconnaissez pas.

Étape 3 : réinstaller les plugins et les thèmes

Réinstallez chaque plugin et chaque thème depuis sa source d'origine au lieu de nettoyer une copie infectée. C'est plus rapide et vous ne manquerez aucun fichier subtilement modifié.

wp plugin list
wp plugin install PLUGIN-SLUG --force
wp theme install THEME-SLUG --force
wp plugin verify-checksums --all

Les plugins et thèmes premium ne sont pas sur wordpress.org : téléchargez une copie neuve chez l'éditeur et envoyez-la sur le site. Supprimez tout ce que vous n'utilisez pas ou ne reconnaissez pas, et supprimez-le au lieu de seulement le désactiver. Les fichiers d'un plugin désactivé peuvent encore être exécutés directement par quiconque connaît leur chemin :

wp plugin deactivate PLUGIN-SLUG
wp plugin delete PLUGIN-SLUG

Étape 4 : vérifier les cachettes habituelles

Un malware reste rarement dans un seul fichier. Vérifiez ces endroits même après avoir remplacé le cœur et les plugins, car ils sont en dehors de ce que vous venez de réinstaller.

grep -RIl --include="*.php" -E "eval\(|base64_decode\(|gzinflate\(|str_rot13\(" wp-content
find wp-content/uploads -name "*.php"
ls -la wp-content/mu-plugins
cat .htaccess
wp cron event list

• Les résultats de grep. Ces fonctions apparaissent aussi dans du code légitime : une correspondance est une piste, pas une preuve. Ouvrez chaque fichier et lisez-le. Ne supprimez pas un fichier de plugin simplement parce qu'il correspond.
• wp-content/uploads. Il ne doit contenir que des médias. Tout fichier PHP ici va en quarantaine.
• wp-content/mu-plugins. Les plugins « must-use » se chargent automatiquement et n'apparaissent pas dans la liste normale des plugins. Un fichier ici que vous n'avez pas ajouté est un signe d'alerte fort.
• .htaccess. Comparez-le avec les règles WordPress par défaut. Des règles de redirection injectées, surtout celles qui dépendent du référent ou de l'appareil du visiteur, sont un classique du piratage.
• .user.ini et php.ini. Cherchez une ligne auto_prepend_file. Elle exécute un fichier avant chaque page et c'est un endroit favori pour cacher une porte dérobée.
• Les fichiers du thème. Ouvrez functions.php, header.php et footer.php dans votre thème actif et cherchez du code que vous n'avez pas écrit.
• Les tâches planifiées. Un événement cron qui appelle une fonction inconnue peut recréer une porte dérobée après que vous l'avez supprimée. Supprimez-le avec wp cron event delete HOOK-NAME.

Pour en savoir plus sur les accès cachés, voir Comment trouver une porte dérobée WordPress.

Étape 5 : nettoyer la base de données

Les malwares vivent souvent dans la base de données, là où l'analyse de fichiers ne regarde jamais. Sauvegardez-la d'abord avec wp db export. Votre préfixe de table n'est peut-être pas wp_, vérifiez-le :

wp db prefix
wp db query "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"
wp db query "SELECT ID, user_login, user_email, user_registered FROM wp_users ORDER BY user_registered DESC LIMIT 20;"
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' OR post_content LIKE '%display:none%';"
wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%' LIMIT 50;"

• siteurl et home. Les deux doivent être votre propre domaine. Une valeur différente redirige tout le site sans modifier un seul fichier.
• Les utilisateurs récents. Tout administrateur que vous n'avez pas créé peut être supprimé avec wp user delete ID --reassign=ADMIN-ID.
• Les articles et options contenant des balises script. Certains contiennent du code d'analyse ou d'intégration légitime. Examinez chaque résultat, puis ne nettoyez que la partie injectée.

Étape 6 : fermer l'accès utilisé par l'attaquant

Si vous n'avez pas encore changé tous vos identifiants, faites-le maintenant. L'ordre complet, de l'accès à l'hébergement jusqu'aux connexions WordPress, se trouve à l'étape 5 du guide de réparation. Régénérez les clés de sécurité avec wp config shuffle-salts pour que les sessions existantes prennent fin.

Étape 7 : vérifier, puis continuer à surveiller

wp core verify-checksums
wp plugin verify-checksums --all
find wp-content/uploads -name "*.php"

Videz tout cache. Visitez ensuite le site depuis votre téléphone en données mobiles, en arrivant depuis un résultat Google, car les redirections malveillantes se cachent souvent des visites directes. Si Google a signalé le site, demandez un réexamen dans Problèmes de sécurité de la Search Console. Refaites les vérifications après 24 heures puis après une semaine. Un fichier ou un compte administrateur qui revient signifie qu'une porte dérobée ou le point d'entrée a été manqué.

Si le malware revient

Une réinfection a presque toujours l'une de ces deux causes : une porte dérobée jamais trouvée, ou un point d'entrée jamais fermé. Revérifiez mu-plugins, .htaccess, .user.ini et les tâches planifiées. Suivez ensuite l'étape 7 du guide de réparation pour trouver comment l'attaquant est entré : plugins obsolètes ou piratés, identifiants d'hébergement volés et journaux du serveur.