Trouver la backdoor oubliée après un premier nettoyage
Racine, uploads, mu-plugins, cron, options qui s'exécutent, .htaccess : un scan de signatures rate un one-liner. Après un premier nettoyage qui n'a pas tenu, on compare aux originaux et on suit les dates — pas on réinstalle une troisième fois à l'aveugle.
Racine, uploads, mu-plugins, cron, options qui s'exécutent, .htaccess. Un scan de signatures rate un one-liner. Comparez aux originaux, suivez les dates.
Partir du symptôme qui est revenu
La même redirection mobile, le même fichier à la racine, le même admin recréé : le symptôme oriente. Un admin qui revient *sans* nouveau PHP oriente vers la base ou une clé. Un fichier qui revient oriente vers une écriture (porte, FTP encore ouvert, voisin). Notez l'heure du retour. C'est le fil. Voir pourquoi 48 h.
Ne recommencez pas par installer un énième scanner. Vous avez déjà le bruit. Vous avez besoin d'un inventaire.
Si le symptôme est une page d'hameçonnage, coupez l'URL, puis cherchez. Exception habituelle.
La carte des endroits, pas le feeling
Racine : PHP qui n'est pas `index`, `wp-*.php` officiels, `xmlrpc`. Uploads et « cache » : tout ce qui s'exécute. `wp-content/mu-plugins`. Thème enfant vs parent. `uploads` et `blogs.dir`. `.htaccess` à plusieurs niveaux. Crons panel *et* crons CMS. Options `*_autoload` qui embarquent du JS / PHP selon le produit — on cherche les *écarts*, on ne « vide pas options ».
La page métier et le guide listent l'esprit. Ici, l'ordre de passage pour ne pas en oublier un. Inclure htaccess dans la même tournée.
Les sites addon / parked du même FTP : même carte. Un scan « WordPress A » ignore WordPress B.
- Racine et htaccess (tous).
- mu-plugins, thèmes, uploads.
- Cron, options, voisins.
Comparer, ne pas tout lire
Zip officiel du cœur, des extensions et du thème (source propre, pas le zip « premium gratuit »). Un outil de diff. Tout fichier en trop est suspect. Toute ligne en trop dans un fichier officiel aussi. Vous n'avez pas à comprendre chaque fonction. Vous avez à restaurer l'officiel ou à isoler l'inconnu.
Le thème sur-mesure n'a pas d'officiel. On le compare à *votre* copie d'avant-incident, ou on le lit par dates / fonctions hors sujet (réseau sortant, eval dissimulé). Si vous ne savez pas, déléguez ce morceau. Supprimer un thème métier au jugé casse le site et pas forcément la porte (copie en mu-plugin).
Les uploads ne se « comparent » pas à un zip. Là : pas d'exécution PHP (interdire), inventaire des extensions étranges, dates.
Base, cron, utilisateurs
Utilisateurs admin nés pendant la fenêtre, rôles changés, transients qui chargent du code (plus rare, à connaître). Crons qui appellent une URL ou un PHP inconnu. Un cron système (panel) qui relance un mineur à 3 h : invisible dans Wordfence.
Les clés et webhooks : une app password recrée un utilisateur ou pousse du contenu. Ce n'est pas un fichier, c'est une porte.
Une injection encore ouverte réécrit l'option après votre UPDATE. Fermez l'entrée applicative, pas seulement la ligne sale.
Voisins de compte et sauvegardes
Autre dossier du même utilisateur système. Un site mort de 2018. Un backup Updraft *téléchargeable* qui contient encore le shell : l'attaquant le repose. Isolez les archives, sortez-les du web. Sauvegardes ensuite, pas un zip public.
Un cron de l'ancien serveur après migration. Vérifiez.
Object cache qui ressert un vieux fichier : purge. Autre piège de « c'est revenu sans fichier nouveau ».
Ce que les dates disent vraiment
Une grappe de fichiers touchés la même minute : bon fil. Un fichier à la date d'origine avec une ligne ajoutée : la date ment ou le touch n'a pas eu lieu. On s'appuie sur le *diff*, pas seulement sur `mtime`.
Les logs FTP / sFTP : qui a écrit à l'heure du retour. Si c'est encore votre ancien mot de passe, le mystère tombe. Panel d'abord, toujours.
Horodatage serveurs décalé : notez le fuseau. Évitez les conclusions « c'est avant l'incident » à cinq minutes près.
Isoler, documenter, retirer
Copie du suspect hors site (preuve), retrait ou remplacement par l'officiel, pas un éditeur « nettoyer cette ligne » si vous ne maîtrisez pas le fichier. Permissions ensuite. Écrit : chemin, date, action. Pour l'hébergeur et le constat s'il y a enjeu données.
Ne collez pas le contenu dans un ticket public. Chemin + hash suffisent souvent.
Si vous hésitez entre légitime et porte : isolez (renommer hors web, droits). Le site casse ? Vous saurez. Il ne casse pas ? Vous teniez une porte.
Le test des 48 heures
Après la tournée : tests mobile / privé / Google, `site:`, fichiers nouveaux, admins nouveaux. Si ça revient, vous avez manqué un item de la carte, pas « le destin ». Reprenez le symptôme, pas un quatrième plugin.
Activez une journalisation légère pour les trente jours. C'est le filet.
Créer un espace si la carte dépasse ce que vous savez comparer. Joignez « ce qui est revenu et à quelle heure » : ça vaut dix scans.
- Carte complète, y compris voisins.
- Diff officiel + crons + comptes.
- 48 h de vérité, pas le soir même.