Un site PHP compromis ne présente pas toujours des symptômes visibles. Il peut continuer à répondre normalement, afficher les bonnes pages et traiter les commandes sans erreur apparente. Pourtant, une backdoor discrète peut offrir un accès permanent à un attaquant, injecter du code à la volée ou exécuter des commandes à distance sans laisser de traces évidentes. C’est précisément ce qui rend l’analyse de code beaucoup plus complexe qu’une simple recherche de signatures connues.
Pourquoi les backdoors PHP passent souvent inaperçues
La plupart des administrateurs pensent qu’un malware PHP ressemble à quelques lignes utilisant eval(base64_decode()). Cette époque est largement révolue.
Les campagnes récentes misent davantage sur la discrétion que sur la sophistication. Les fichiers sont souvent nommés comme des composants légitimes, les fonctions dangereuses sont fragmentées et le code malveillant est réparti dans plusieurs emplacements.
Sur un serveur auto-hébergé, plusieurs centaines de milliers de fichiers peuvent être présents. Entre le cœur du CMS, les bibliothèques tierces, les modules et les caches, retrouver quelques lignes suspectes devient vite un exercice délicat.
J’ai rencontré plusieurs boutiques PrestaShop où le fichier infecté ne contenait aucune fonction classiquement considérée comme dangereuse. Le véritable code était téléchargé depuis un serveur distant uniquement lorsqu’une condition très précise était remplie : une adresse IP particulière, un cookie spécifique ou un User-Agent donné. Une inspection visuelle ne révélait absolument rien.
Pourquoi une simple recherche par mots-clés ne suffit plus
La première réaction consiste généralement à utiliser des commandes comme :
grep -R "eval(" .ou
grep -R "base64_decode" .Cette approche reste utile pour identifier rapidement certaines anomalies, mais elle montre rapidement ses limites.
Un attaquant peut très facilement reconstruire une fonction sans jamais écrire son nom en clair.
Au lieu d’appeler directement base64_decode, il peut assembler le nom caractère par caractère, utiliser des variables variables ou faire appel à une fonction dynamique.
Dans ce cas, grep ne trouvera absolument rien.
Autre difficulté : un projet moderne contient parfois plusieurs milliers d’occurrences parfaitement légitimes de chaînes proches des fonctions recherchées, notamment dans des bibliothèques externes. Les faux positifs deviennent rapidement ingérables.
Recherche par mots-clés ou analyse par flux de données ?
C’est probablement la différence la plus importante à comprendre lors d’un audit de sécurité.
Une recherche textuelle examine uniquement le contenu des fichiers.
Une analyse par flux de données cherche à comprendre comment les informations circulent réellement dans le programme.
Autrement dit, elle suit le parcours des variables.
Prenons un exemple simple.
Une variable provenant de :
$_GET$_POST$_COOKIEphp://input
est-elle ensuite transmise à une fonction capable d’exécuter du code ?
Une analyse de flux permet de répondre à cette question, même si les fonctions sont renommées ou construites dynamiquement.
Cette approche détecte également des chemins d’exécution complexes qui seraient impossibles à identifier avec une simple recherche textuelle.
C’est la raison pour laquelle les outils d’analyse statique modernes privilégient cette méthode plutôt qu’un simple balayage lexical.
Les techniques d’obfuscation les plus courantes
Les auteurs de malwares PHP savent parfaitement quels mots-clés recherchent les administrateurs.
Ils cherchent donc à les masquer.
Les techniques les plus fréquentes restent :
- encodage Base64 sur plusieurs niveaux ;
- compression avec
gzinflate(); - utilisation de
eval()uniquement en dernière étape ; - fonctions appelées dynamiquement ;
- variables variables (
$$variable) ; - concaténation de chaînes pour reconstruire un nom de fonction ;
- génération de code à l’exécution ;
- chargement différé depuis un serveur distant.
Certaines backdoors n’utilisent même plus eval().
Elles exploitent des mécanismes parfaitement légitimes du langage PHP, comme call_user_func(), ReflectionFunction, assert() sur d’anciennes versions de PHP ou encore des fonctions anonymes créées à la volée.
Cette évolution explique pourquoi beaucoup de scanners basés uniquement sur des signatures passent à côté de nombreuses compromissions.
Où concentrer les recherches dans un projet PHP
Tous les répertoires ne présentent pas le même niveau de risque.
Les dossiers suivants méritent une attention particulière :
- uploads : dépôt classique de webshells déguisés en fichiers médias ;
- cache : génération de fichiers PHP exécutables selon le CMS ;
- modules : cible privilégiée sur PrestaShop ;
- themes : modifications discrètes dans les templates ou les hooks ;
- vendor : plus rarement compromis, mais idéal pour cacher quelques lignes parmi des milliers de fichiers ;
- overrides : particulièrement sensible sur PrestaShop car le code y surcharge directement les classes natives.
L’expérience montre également qu’il faut examiner les fichiers récemment modifiés, les scripts dont les permissions diffèrent du reste du projet ou ceux dont la taille paraît inhabituelle.
Un simple fichier de 3 Ko ajouté dans un répertoire contenant uniquement des images mérite souvent davantage d’attention qu’un gros fichier PHP présent depuis plusieurs années.
Les spécificités d’un audit sur PrestaShop
PrestaShop possède plusieurs particularités qui compliquent les investigations.
Les modules tiers représentent évidemment la première source de risque. Beaucoup sont installés puis oubliés pendant des années.
Les overrides constituent un autre point sensible. Une surcharge de classe permet de modifier profondément le comportement du cœur sans toucher aux fichiers d’origine.
Les attaquants apprécient également les modules désactivés.
Ils restent présents sur le disque, sont rarement vérifiés et peuvent servir de cachette idéale.
Autre cas rencontré en production : un faux module portant un nom très proche d’un module officiel, installé plusieurs mois auparavant par un prestataire externe. Personne ne s’était aperçu qu’il ne provenait pas de la place de marché officielle.
Quel outil utiliser ?
Lorsqu’un projet devient volumineux, automatiser l’analyse est souvent préférable à une inspection manuelle. L’objectif n’est pas de supprimer automatiquement des fichiers, mais d’obtenir une cartographie fiable des éléments suspects en travaillant exclusivement en lecture seule.
Parmi les solutions disponibles, Genisoft Security Scanner constitue un exemple d’outil capable d’analyser un projet PHP sans modifier les fichiers présents sur le serveur. Cette approche permet d’examiner l’arborescence, de signaler des comportements suspects et de préparer un audit avant toute intervention.
L’intérêt d’une analyse en lecture seule est évident : aucune modification du site, aucun risque d’interrompre le fonctionnement de la boutique ou de perturber un environnement de production.
Pourquoi éviter toute suppression immédiate
La suppression d’un fichier suspect est rarement la première étape.
Il est préférable de :
- réaliser une sauvegarde complète des fichiers et de la base de données ;
- isoler les éléments suspects ;
- vérifier leurs dépendances ;
- comparer avec une version officielle du CMS ou du module ;
- identifier le vecteur d’infection avant de nettoyer.
Supprimer uniquement la backdoor sans corriger la faille d’origine revient souvent à voir le malware réapparaître quelques heures plus tard.
Il arrive également qu’un pirate ait ajouté plusieurs mécanismes de persistance. Tant qu’ils n’ont pas tous été identifiés, le nettoyage reste incomplet.
Les erreurs les plus fréquentes
Lors des audits réalisés sur des serveurs compromis, certaines erreurs reviennent régulièrement.
La première consiste à lancer un nettoyage directement en production sans disposer d’une copie complète du site.
La seconde est de faire confiance uniquement aux dates de modification des fichiers. Certains attaquants les modifient volontairement pour se fondre dans le reste du projet.
Une autre erreur fréquente est de concentrer les recherches exclusivement sur le dossier racine alors que les fichiers réellement dangereux sont souvent cachés dans des sous-répertoires rarement consultés.
Enfin, beaucoup d’administrateurs oublient de vérifier les tâches cron, les comptes FTP, les utilisateurs SSH, les accès administrateurs ou les clés API. Une backdoor PHP n’est parfois qu’un des éléments d’une compromission plus globale.
Ce qu’un audit efficace doit réellement apporter
Un bon audit ne cherche pas uniquement des signatures connues. Il doit permettre de comprendre comment le code s’exécute, quelles parties manipulent des données non fiables et où apparaissent des comportements inhabituels.
Cette démarche demande davantage de temps qu’un simple scan par mots-clés, mais elle réduit fortement le risque de laisser une porte dérobée active. Sur un site auto-hébergé, où l’administrateur maîtrise l’ensemble de l’infrastructure, une analyse régulière en lecture seule constitue souvent le meilleur compromis entre sécurité, disponibilité du service et maîtrise des risques.
FAQ
Comment savoir si un site PHP contient une backdoor ?
Les indices les plus courants sont des fichiers récemment ajoutés, des appels réseau inhabituels, du code obfusqué, des comptes administrateurs inconnus ou une activité anormale dans les journaux du serveur. Une analyse statique complétée par un audit manuel reste la méthode la plus fiable.
Grep permet-il de détecter tous les malwares PHP ?
Non. Grep est efficace pour retrouver des chaînes de caractères précises, mais il ne comprend pas la logique du programme. Les techniques d’obfuscation modernes contournent facilement ce type de recherche.
Pourquoi les dossiers vendor et cache doivent-ils être contrôlés ?
Ces répertoires contiennent un grand nombre de fichiers. Cette densité permet à un attaquant de masquer plus facilement quelques lignes malveillantes sans attirer l’attention.
Peut-on analyser un site en production sans risque ?
Oui, à condition d’utiliser un outil fonctionnant exclusivement en lecture seule. Aucune modification n’est apportée aux fichiers, ce qui limite les risques d’interruption de service.
Faut-il supprimer immédiatement un fichier suspect ?
Non. Il est préférable de sauvegarder le site, d’identifier précisément le rôle du fichier, de comprendre le vecteur d’infection et de vérifier qu’il ne s’agit pas d’un composant légitime avant toute suppression.
