Backdoor PHP : ce que c'est, concrètement, sur un site

Ce que c'est, sans folklore

Ce n'est pas un virus de PC, ni « le dark web ». C'est du code sur *votre* hébergement qui offre une porte persistante. L'entrée initiale a pu être une extension, un mot de passe, un voisin de compte. Une fois la porte posée, l'attaquant n'a plus besoin de cette entrée. D'où les sites « nettoyés » qui retombent. Le guide le dit en version courte ; ici, le détail pour le propriétaire.

On ne publie pas comment l'écrire. On publie comment la reconnaître par ses effets et ses emplacements, et comment s'en séparer en comparant à l'officiel.

Un webshell est une forme de backdoor (interface pour commander le serveur). Toutes les portes n'ont pas d'interface : une ligne dans un thème suffit.

Ce qu'elle permet, concrètement

Déposer d'autres fichiers, réécrire ce que vous venez d'enlever, créer un utilisateur administrateur, envoyer du mail, servir une page d'hameçonnage, miner, rediriger le mobile. Vous voyez le symptôme ; la porte est ce qui le recrée.

Parfois elle ne fait qu'attendre : rien de visible pendant des semaines. Un scan « clean » un mardi ne dit rien du jeudi.

Elle n'implique pas à elle seule une fuite clients. Elle rend la fuite *possible* tant qu'elle vit. Le constat données reste un autre livrable.

• Persistance (revenir).
• Écriture (réinfecter).
• Parfois exfil / spam / phishing.

Où elle se loge le plus souvent

Racine sous un nom anodin, dossier d'uploads (double extension, faux « cache »), must-use plugins WordPress, thème enfant, `includes` recopié, option de base qui s'exécute, tâche cron, `.htaccess` qui envoie vers un PHP, voisin de site du même compte. Un nettoyage qui ne regarde que `wp-content/plugins` la rate. Détail de chasse : trouver la porte oubliée.

Les dates de modification anormales aident, pas toujours : on peut toucher la date, ou injecter dans un fichier légitime ancien.

Les permissions trop ouvertes (777) n'*sont* pas la backdoor. Elles ont permis de l'écrire. On corrige les deux.

Pourquoi elle est petite et banale

Moins elle ressemble à un « virus.jar », plus elle passe. Un nom de cœur CMS, une image qui n'en est pas une, une ligne au milieu d'un fichier de traduction. D'où la méthode : *diff* contre le zip officiel, pas la lecture au feeling de 4 000 fichiers.

L'encodage et les fonctions dynamiques existent pour se cacher des signatures. Vous n'avez pas à les décortiquer. Un fichier qui n'existe pas dans l'officiel, ou une ligne en trop dans `wp-load.php`, se retire ou se restaure depuis la source saine.

Méfiez-vous des « décodeurs » en ligne : vous y collez parfois le reste de l'accès. Isolez, comparez, remplacez par l'officiel.

Ce qu'un antivirus voit, et rate

Les familles connues, les signatures. Une porte d'une ligne écrite pour votre site : souvent rien. « 0 détecté » n'est pas « 0 porte ». On scanne pour trier, on compare pour conclure. Un plugin cleaner pendant l'attaque ajoute du bruit ; on le pose à la fin, filet.

L'hébergeur qui marque un fichier : bon indice, pas inventaire. Demandez la liste, copiez avant de tout laisser « réparer » automatiquement.

Un rapport de 200 faux positifs (thème premium) noie la vraie ligne. Un humain trie, ou un prestataire qui connaît le CMS.

Backdoor n'est pas le piratage entier

Il peut y avoir *aussi* un admin fantôme, une clé API, un MX, une règle mail, un pixel. Retirer un PHP et s'arrêter, c'est le scénario des 48 heures. La porte est le cœur de la persistance fichiers. Ce n'est pas le seul cœur.

Une injection SQL peut recréer un admin sans nouveau fichier. Une XSS vole une session sans shell. On les cherche selon les signes, pas selon un seul mot à la mode.

Le chantier page métier vise la persistance. Les autres pages de ce lot, les autres persistances.

Ce qu'on fait, dans l'ordre

Copie hors serveur. Panel et FTP tournés. Inventaire (dates, inconnus, mu-plugins, cron, htaccess). Comparaison aux zips officiels. Retrait / restauration des écarts. Comptes et clés. Permissions et no-PHP uploads. Tests visiteur. Surveillance 30 jours. Pas de roman d'exploit entre les lignes.

Si une page d'hameçonnage est en 200, elle se coupe tout de suite, puis on reprend l'ordre. Exception déjà connue.

Vous pouvez déléguer. Critère : si vous ne savez pas si ce PHP « sert au thème », vous ne le supprimez pas au jugé. Isoler n'est pas détruire la preuve.

Comment savoir qu'on a fini

Plus de pages inconnues, plus de redirection mobile, plus de PHP exécutable dans les médias, plus de comptes fantômes, plus de réécriture après 48–72 h, `site:` stable. Ce n'est jamais une garantie métaphysique. C'est un faisceau. La journalisation couvre la fenêtre où une oubliée se montre.

Un second scan propre aide le moral. Le critère dur, c'est l'absence de *nouveaux* écarts à l'officiel.

Documentez ce qui a été trouvé (chemins, dates) pour l'hébergeur et l'assureur. Sans recopier le code malveillant dans un ticket public.

• Comparer, ne pas « sentir ».
• Toutes les persistances, pas un seul fichier.
• Surveiller, pas crier victoire le soir même.