Pourquoi supprimer des fichiers au hasard aggrave le piratage
Beaucoup de fichiers infectés sont aussi nécessaires au site. Les retirer casse l’affichage sans fermer l’entrée. On isole, on compare à l’original, on retire ensuite. Effacer tous les PHP « suspects » d’un scan, c’est le plus court chemin vers une 500 et un backdoor encore là.
Beaucoup de fichiers infectés sont aussi nécessaires au site. Les retirer casse l'affichage sans fermer l'entrée. On isole, on compare, on retire ensuite.
Pourquoi le delete au jugé aggrave
Supprimer des fichiers malware au hasard mélange deux objets : des parasites (`radio.php` à la racine) et des fichiers CMS retouchés (`wp-includes/canonical.php`, `functions.php` du thème). Jeter les premiers, après copie, est juste. Jeter les seconds = White Screen, permaliens morts, admin mort — et le prepend dans `.user.ini`, lui, est toujours là. Vous avez un site cassé plus une porte. C’est le dossier « inaccessible après nettoyage », le lendemain.
Le scan qui liste 80 fichiers « critiques » pousse au massacre. 70 sont souvent le thème minifié, une lib, un cache. Wordfence pendant l’attaque : on s’en sert pour trier, pas comme liste d’exécution.
L’entrée (compte, faille, voisin) ne se delete pas avec un PHP. Vous pouvez vider la racine de tous les noms bizarres et vous faire réinfecter à H+4. Delete n’est pas clôture.
- Copie avant tout rename / delete.
- Un fichier à la fois, tester le front / l’admin.
- Pas de « tout ce que le scan a dit » en une passe.
Isoler n’est pas supprimer
Renommer `x.php` → `x.php.off` ou déplacer hors web. Si le site meurt, vous remettez. Si le site vit, vous aviez un parasite (ou un fichier jamais appelé — encore utile au constat). Isolation = test. Suppression = après comparaison, ou après certitude « n’appartient pas au CMS ».
chmod 000 : isolation brutale, parfois utilisée par l’hébergeur. Ça casse si c’était un fichier cœur. Préférez le rename, plus réversible dans le file manager.
Un dossier entier `plugins` renommé : test légitime (panne vs plugin). Ce n’est pas « supprimer les malware ». C’est un levier temporaire, noté, remis ensuite pièce par pièce.
Comparer : le seul juge fiable
Zip officiel du cœur, de l’extension, du thème parent. Diff. Identique → ne pas toucher, ou faux positif. Différent → regarder le diff, pas la taille seule. Trois lignes `eval` : remplacer par l’officiel, ne pas delete le fichier (le CMS en a besoin). Fichier en plus, absent de l’officiel : candidat à l’isolation.
Thème enfant, mu-plugins, uploads : pas d’officiel. Là, on lit. Si vous ne lisez pas, vous n’effacez pas : vous déléguez. Soi-même ou pas.
La date aide, elle ne juge pas. Un fichier cœur touché le jour d’une maj officielle est normal. Le même fichier touché à 3 h 12 un dimanche, moins.
Ce que les scanners font prendre pour du malware
Code minifié, `eval` de certaines libs (vieux builders), signatures trop larges sur `base64` d’images inline, fichiers de cache, backups `.sql` (ce ne sont pas des malware, ce sont des fuites potentielles — les retirer du web, pas les jeter sans copie). Un thème premium « ionCube » : parfois légitime, parfois nulled infecté. Le scan ne sait pas. Le zip de l’éditeur, si.
Wordfence « repair » d’un enfant : casse fréquent. Annulez, restorez l’enfant depuis votre copie d’avant le repair, pas depuis une Updraft sale.
Imunify qui quarantine `wp-login.php` : front/admin morts. Restaurez depuis le zip cœur, expliquez le faux positif, cherchez le vrai path à côté.
`.htaccess` vidé, `index` écrasé : deux classiques
Vider `.htaccess` « pour enlever la redirect » tue les permaliens WP, parfois tout le routing. Isolez les lignes ajoutées (Rewrite vers un tiers, auto_prepend). Gardez un stub WP officiel. Sauvegardez l’ancien sous `htaccess.pirate.date`.
Écraser `index.php` par un fichier vide : 500. Remettez l’index du zip cœur (2 Ko), ne laissez pas un blanc. Si la home est une page CMS, l’index cœur ne suffit pas : il faut aussi options / template. Défacement.
Ces deux gestes sont les rois du site mort après tentative. Réversibles si vous avez copié. Définitifs si vous n’avez pas copié et que l’hébergeur n’a plus de backup.
Uploads : le piège inverse (là, oui, du PHP)
Dans `uploads/`, `img/`, `media/`, un `.php` n’a rien à faire. Isolation / retrait après copie, presque toujours. Double extension `facture.pdf.php` : pareil. Ne « comparez pas à WordPress.org » : ces fichiers n’y sont pas.
Les images `.jpg` avec un payload à la fin : plus rare, plus sale. Ne deletez pas tout le médiatheque. Cherchez les mtimes de la nuit, les tailles aberrantes. Un wipe uploads = site vidé de ses photos, clients furieux, malware peut-être encore dans le thème.
Interdisez PHP dans uploads (règle serveur) après coup. C’est un durcissement, pas le delete du jour J.
Ordre de retrait une fois sûr
Parasites hors CMS → prepend / htaccess lignes pirates → fichiers cœur remis à l’officiel (pas delete) → extensions inconnues désactivées puis sorties → options / JS en base (ce n’est pas un fichier) → crons. Secrets en parallèle (panel déjà fait). Un levier, un test.
Documentez chaque retrait (chemin, heure). Constat abuse et assurance. Ticket.
Ne « nettoyez pas aussi le vieux dossier old/ » au jugé : cartographiez, ou éteignez le vhost. Multi-sites.
Si vous avez déjà tout jeté
Stop. Repartez de la copie d’avant votre Kärcher, ou du backup hébergeur, pas d’une réinstall par-dessus le désastre. Site inaccessible. Si aucune copie : zip officiels + ce qui reste, et acceptez de perdre des contenus. C’est le prix du hasard.
N’enchaînez pas un deuxième massacre « pour réparer le premier ». Un prestataire préfère un tree trop delete qu’un tree delete + trois plugins « fix » + un restore sale.
La leçon tient en une ligne : isoler, comparer, retirer. Pas l’inverse.