Les boutiques PrestaShop concentrent de nombreuses données sensibles : informations clients, comptes administrateurs, modules tiers, accès au serveur et parfois des éléments liés au parcours de paiement. Cette richesse fonctionnelle en fait une cible régulière pour les cyberattaques. Pourtant, une boutique compromise ne présente pas toujours des symptômes évidents. Un malware peut rester discret pendant plusieurs semaines avant d’être découvert. Savoir détecter un malware sur une boutique PrestaShop permet avant tout de limiter l’exposition des données, d’identifier le point d’entrée et d’éviter une réinfection après le nettoyage.
Quels signes indiquent qu’une boutique est infectée ?
Une compromission ne provoque pas systématiquement une panne visible. Dans de nombreux cas, le site continue de fonctionner normalement tandis que du code malveillant agit en arrière-plan. C’est précisément cette discrétion qui rend l’analyse plus complexe.
Un premier indice peut être l’apparition de ralentissements inhabituels ou d’erreurs HTTP 500 sans modification récente du site. Bien que ces symptômes puissent avoir plusieurs origines, ils méritent une vérification lorsqu’ils apparaissent brutalement.
Les fichiers récemment modifiés constituent également un excellent indicateur. Découvrir plusieurs fichiers PHP modifiés alors qu’aucune mise à jour ou intervention technique n’a été réalisée doit immédiatement attirer l’attention. Les attaquants cherchent souvent à intégrer leur code dans des fichiers déjà présents afin de passer inaperçus.
La création d’un nouveau compte administrateur ou d’un employé inconnu dans le back-office représente un autre signal important. Certains malwares créent volontairement un accès persistant afin de conserver le contrôle de la boutique même après la suppression des fichiers infectés.
Des redirections vers des domaines inconnus, l’apparition de scripts JavaScript chargés depuis un serveur externe ou des comportements étranges dans le tunnel de commande peuvent également révéler la présence d’un malware PrestaShop. Dans certains cas, seuls certains visiteurs sont concernés, ce qui complique encore davantage le diagnostic.
Il est également recommandé d’examiner les répertoires qui ne devraient normalement contenir aucun fichier PHP. La présence de scripts dans les dossiers d’images, de téléchargement, de cache ou d’upload constitue souvent une anomalie nécessitant une analyse approfondie.
Les tâches cron inconnues, les hooks inattendus, les modules installés sans justification ou encore la réapparition régulière d’un malware après sa suppression indiquent fréquemment qu’un mécanisme de persistance est toujours actif.
Enfin, les premiers signes peuvent provenir de l’extérieur : une alerte du navigateur signalant un site compromis, une notification d’un prestataire de paiement, ou des clients rapportant des redirections inhabituelles lors du passage de commande.
Aucun de ces éléments ne constitue à lui seul une preuve définitive. C’est la combinaison de plusieurs indices, replacés dans leur contexte technique, qui permet d’orienter efficacement l’investigation.
Les principales menaces visant PrestaShop
Comprendre la nature des malwares les plus courants facilite considérablement leur détection. Chaque famille possède ses propres objectifs et laisse généralement des traces différentes.
Le webshell
Le webshell est l’une des menaces les plus fréquemment rencontrées sur les boutiques PrestaShop compromises. Il s’agit d’un fichier ou d’un fragment de code permettant à un attaquant d’exécuter des commandes à distance, d’explorer l’arborescence du serveur, de modifier des fichiers ou d’installer d’autres composants malveillants.
Son principal intérêt réside dans le maintien d’un accès permanent au serveur. Même si la faille initiale est corrigée, le webshell peut continuer à offrir un point d’entrée à l’attaquant tant qu’il n’est pas supprimé.
Selon les cas, il peut être placé dans un module, un override, un fichier système ou même dissimulé dans un répertoire qui ne contient normalement que des images.
Le dropper
Le dropper agit comme un installateur discret. Son objectif n’est pas nécessairement d’exécuter lui-même des actions malveillantes, mais de télécharger, reconstruire ou installer une charge supplémentaire.
Lorsqu’il est analysé isolément, ce type de fichier peut sembler relativement inoffensif puisqu’il ne contient parfois qu’une partie de la logique utilisée lors de l’attaque.
Cette caractéristique explique pourquoi certains scanners basés uniquement sur des signatures ne détectent pas toujours les droppers les plus récents.
Le card skimmer
Le card skimmer cible directement le tunnel de paiement de la boutique.
Son objectif consiste à intercepter les informations saisies par le client avant qu’elles ne soient transmises au prestataire de paiement ou à les rediriger discrètement vers un serveur externe contrôlé par l’attaquant.
Dans de nombreuses situations, la boutique continue de fonctionner normalement, ce qui rend la détection particulièrement difficile. Les administrateurs ne découvrent parfois le problème qu’après une alerte provenant d’un établissement bancaire, d’un prestataire de paiement ou de plusieurs clients victimes d’une fraude.
L’analyse du code JavaScript chargé durant le processus de commande constitue donc une étape essentielle lors d’un audit de sécurité.
La backdoor PHP
La backdoor PHP représente un mécanisme d’accès persistant permettant à un attaquant de revenir ultérieurement sur le serveur.
Contrairement au webshell traditionnel, elle peut être beaucoup plus discrète. Une backdoor peut être intégrée directement dans un fichier légitime, ajoutée dans un module installé, dissimulée dans un override ou encore créée sous la forme d’un nouveau fichier dont le nom semble parfaitement anodin.
Son rôle consiste essentiellement à contourner les protections mises en place après une première compromission.
Le compte administrateur frauduleux
Tous les accès persistants ne reposent pas forcément sur des fichiers malveillants.
Dans certains cas, l’attaquant crée simplement un nouveau compte employé PrestaShop ou modifie les permissions d’un compte existant afin de conserver un accès légitime au back-office.
Il est donc indispensable de contrôler régulièrement la liste des employés, les profils attribués, les autorisations accordées ainsi que les dates de création et de dernière connexion des différents comptes.
Une simple vérification de ces éléments permet parfois de découvrir une compromission passée totalement inaperçue.
| Menace | Objectif de l’attaquant | Indices possibles | Zones à analyser |
|---|---|---|---|
| Webshell | Maintenir un accès distant au serveur | Fichiers PHP inconnus, modifications récentes | Modules, overrides, dossiers système, uploads |
| Dropper | Installer une charge malveillante supplémentaire | Petit script discret, activité réseau inhabituelle | Modules, fichiers temporaires, tâches planifiées |
| Card skimmer | Intercepter les données du tunnel de paiement | Scripts externes, comportements anormaux lors de la commande | Tunnel de paiement, JavaScript, templates |
| Backdoor PHP | Conserver un accès persistant | Code injecté dans un fichier existant, nouvelles fonctions suspectes | Overrides, fichiers cœur, modules personnalisés |
| Compte administrateur frauduleux | Contrôler durablement le back-office | Nouvel employé, permissions modifiées, connexions inhabituelles | Comptes employés, profils, journaux d’activité |
La diversité de ces menaces montre qu’il ne suffit pas d’examiner uniquement les fichiers PHP récemment modifiés. Une boutique PrestaShop piratée peut présenter plusieurs mécanismes de persistance fonctionnant simultanément. Pour cette raison, l’analyse doit toujours être globale et porter aussi bien sur les fichiers que sur les comptes administrateurs, les modules installés, les journaux et la base de données.
Pourquoi les scans par mots-clés sont insuffisants
Face à une suspicion d’infection, la première réaction consiste souvent à rechercher quelques fonctions PHP réputées dangereuses. Cette approche peut constituer un premier filtre, mais elle est loin d’être suffisante pour détecter un malware sur une boutique PrestaShop.
Des fonctions comme eval, base64_decode ou gzinflate apparaissent effectivement dans de nombreux scripts malveillants. Pourtant, elles peuvent également être utilisées de manière parfaitement légitime par certains modules commerciaux, bibliothèques ou mécanismes de mise en cache. Un scanner reposant uniquement sur ces signatures produit donc facilement des faux positifs.
À l’inverse, les attaquants savent parfaitement contourner ce type de détection. Le code PHP obfusqué repose aujourd’hui sur de nombreuses techniques destinées à masquer son véritable comportement sans modifier son fonctionnement.
Parmi les méthodes fréquemment rencontrées figurent la concaténation de chaînes, plusieurs couches d’encodage successives, la génération dynamique des noms de variables, les appels indirects à certaines fonctions PHP, la compression ou le chiffrement du contenu, ainsi que la répartition d’une logique malveillante dans plusieurs fichiers différents.
Il est également fréquent qu’une partie du code soit injectée directement dans un fichier légitime du cœur de PrestaShop ou d’un module existant, rendant sa détection beaucoup plus difficile. Certains malwares récupèrent même leur charge utile depuis un serveur distant uniquement lorsqu’un ensemble précis de conditions est rempli, par exemple selon l’adresse IP du visiteur, un cookie particulier ou un paramètre spécifique de l’URL.
Dans ce contexte, l’analyse ne peut jamais se limiter à quelques signatures. Le contexte d’exécution, l’emplacement du fichier, son historique, ses permissions, ses dépendances et son comportement réel apportent souvent davantage d’informations que la simple présence d’une fonction sensible.
Analyser les fichiers et la base de données
Une erreur fréquente consiste à concentrer l’investigation uniquement sur les fichiers PHP. Or, une boutique compromise peut conserver des éléments malveillants dans sa base de données, capables de réinjecter automatiquement du contenu après le nettoyage des fichiers.
L’examen des fichiers commence généralement par l’identification des créations ou modifications récentes. Il est ensuite utile de comparer les fichiers du cœur avec une version officielle de PrestaShop afin d’identifier les différences inattendues.
Les dossiers contenant les modules, les overrides, les répertoires d’upload, le cache ou encore les images méritent une attention particulière. La présence de fichiers PHP dans certains de ces emplacements constitue souvent un indicateur important. Les permissions inhabituelles, les scripts JavaScript chargés depuis des domaines inconnus, les tâches cron et les fichiers de configuration doivent également être examinés avec soin.
La base de données représente une seconde source d’information essentielle. Les comptes employés, leurs permissions, les contenus CMS, les blocs HTML, les valeurs de configuration, les hooks enregistrés ainsi que les modules actifs peuvent révéler des modifications réalisées par un attaquant.
Une attention particulière doit être portée aux contenus contenant des scripts JavaScript inattendus ou des références vers des domaines inconnus. Certaines données stockées dans la base peuvent également permettre de recréer automatiquement une charge malveillante après le nettoyage des fichiers, expliquant pourquoi certaines infections semblent réapparaître quelques heures ou quelques jours plus tard.
Une investigation complète consiste donc à rapprocher les informations provenant du système de fichiers, de la base de données, des journaux d’activité et des comptes utilisateurs afin de reconstruire le scénario de compromission.
Utiliser un outil de détection local
Lorsqu’une analyse approfondie devient nécessaire, l’utilisation d’un scanner exécuté directement sur le serveur présente plusieurs avantages. Un outil local permet d’examiner un grand nombre de fichiers sans transférer l’intégralité du code source de la boutique vers un service externe.
Le Genisoft Security Scanner constitue une solution de ce type. Son approche consiste à faciliter l’identification des éléments suspects afin d’aider le webmaster dans son analyse, tout en conservant la maîtrise des données examinées sur l’hébergement.
Une analyse locale permet notamment de rapprocher plusieurs indicateurs, d’identifier les fichiers récemment modifiés, de rechercher des structures de code inhabituelles et de produire un rapport facilitant la vérification humaine.
Il convient néanmoins de rappeler qu’aucun scanner ne peut remplacer l’expertise d’un audit complet. Certains modules PrestaShop utilisent légitimement des fonctions PHP qui peuvent sembler suspectes au premier abord. Toute détection doit donc être vérifiée avant de supprimer un fichier ou de modifier une partie du code de la boutique.
Que faire après la détection d’un malware ?
La découverte d’un malware ne doit pas conduire à des suppressions précipitées. Une intervention méthodique limite le risque de perdre des éléments utiles à l’analyse ou de laisser subsister un mécanisme de persistance.
Si des données sensibles semblent exposées, placer temporairement la boutique en maintenance peut constituer une mesure prudente. Il est ensuite recommandé de conserver une copie des fichiers, des journaux système et des éléments suspects afin de faciliter les investigations.
Avant toute suppression, il est essentiel d’identifier le point d’entrée de l’attaque. Corriger uniquement les symptômes sans traiter la cause favorise souvent une nouvelle compromission.
Les fichiers modifiés doivent être restaurés depuis des sources propres et vérifiées. Le cœur de PrestaShop, le thème et l’ensemble des modules doivent ensuite être mis à jour. Les extensions abandonnées ou inutilisées ont également intérêt à être supprimées afin de réduire la surface d’attaque.
Le renouvellement de tous les mots de passe constitue une étape indispensable : accès au back-office, hébergement, base de données, FTP, SSH et éventuels services connectés.
Il convient également de contrôler les comptes administrateurs, leurs permissions, les tâches cron, les clés API, les accès externes ainsi que les mécanismes d’authentification pouvant avoir été ajoutés lors de la compromission.
Une fois la boutique remise en ligne, une surveillance régulière des fichiers, des journaux et des nouvelles modifications permet de détecter rapidement une éventuelle réinfection.
Enfin, lorsqu’un card skimmer ou une fuite potentielle de données de paiement est identifié, il est recommandé d’évaluer les obligations pouvant exister auprès du prestataire de paiement, des clients concernés et, selon la situation, des autorités compétentes. Les démarches à entreprendre dépendent du contexte de chaque incident.
Conclusion
Détecter un malware sur une boutique PrestaShop ne consiste pas à rechercher quelques signatures dans les fichiers PHP. Une analyse fiable repose sur le croisement des informations provenant des fichiers, de la base de données, des comptes administrateurs, des journaux système et du comportement global de la boutique.
Plus une compromission est identifiée rapidement, plus les possibilités de limiter ses conséquences sont importantes. Mettre en place une surveillance régulière des modifications, des accès et des composants installés reste aujourd’hui la meilleure approche pour détecter une anomalie avant qu’elle ne se transforme en incident majeur.
