PrestaShop piraté : la méthode pour reprendre le contrôle

Comment on découvre qu'on est piraté

Personne n'apprend qu'il est piraté par un mail poli de l'attaquant. On le découvre par un détail qui cloche. Un client signale un prélèvement qu'il n'a pas fait. Une commande payée n'apparaît pas au back-office. Google Search Console annonce soudain des dizaines de pages que vous n'avez jamais écrites. Ou votre hébergeur suspend le serveur pour spam sortant.

Le cas le plus sournois reste le détournement de paiement. Le client commande, paie, et l'argent arrive ailleurs. Le catalogue a l'air sain, la boutique tourne, mais un script injecté dans la page de paiement lit la carte, ou un module de paiement falsifié encaisse sur un compte qui n'est pas le vôtre. Vous ne le voyez pas depuis le back-office. Le client non plus. Seul le rapprochement bancaire le révèle — souvent des semaines plus tard.

Si vous lisez cet article par prévention, retenez une chose : le meilleur détecteur d'intrusion d'une boutique, c'est un rapprochement bancaire quotidien et une consultation régulière de Search Console. Tout le reste arrive après coup.

Première heure : contenir, sans détruire

La réaction instinctive est de tout supprimer, de vider le cache, d'écraser les fichiers douteux. C'est la pire chose à faire. Vous détruisez les preuves, et vous laissez la porte d'entrée grande ouverte : demain matin, la boutique est à nouveau infectée, en moins bien.

La séquence correcte, dans l'ordre :

• Figez l'état. Faites une copie complète du disque ou un snapshot du serveur avant de toucher quoi que ce soit. C'est votre matière d'analyse, et votre preuve si des clients portent plainte.
• Coupez l'accès public. Page de maintenance derrière le serveur web, pas en mode maintenance PrestaShop — un attaquant actif passe outre.
• Révoquez tout ce qui sert à sortir : mots de passe SMTP, clés API Stripe et webhooks, tokens d'employés, clés FTP et SSH. Depuis un poste sain, pas depuis la machine que vous soupçonnez.
• Changez les mots de passe des comptes admin, base de données incluse, et cherchez des comptes employés que vous n'avez pas créés.
• Prévenez votre banque si un détournement de paiement est confirmé, et ouvrez un dossier chez votre hébergeur.

Contenir ne répare rien. Ça arrête l'hémorragie et garde les preuves intactes.

Une dernière règle de posture, qui vaut pour toute la suite : travaillez depuis un poste que vous savez sain, jamais depuis la machine d'où vous administriez la boutique au moment des faits — si l'infection vient de votre côté (poste compromis, mot de passe stocké en clair dans un mail), vous replanteriez la porte en croyant la réparer. Et notez tout ce que vous faites, avec les horaires : qui a vu quoi, quand, quel fichier a été isolé, quel accès a été révoqué. Ce journal servira trois fois — pour ne rien refaire deux fois, pour l'analyse finale de la porte d'entrée, et pour répondre aux clients sans improviser.

Trouver la porte d'entrée

Un site re-piraté trois jours après nettoyage, c'est presque toujours une porte d'entrée jamais refermée. Avant toute remise en ligne, vous devez savoir comment l'attaquant est entré. Les trois suspects habituels :

Côté base de données, les endroits à inspecter sont connus : comptes employés, tâches planifiées parasites, modules activés que personne n'a installés, adresses email de commande modifiées. Côté fichiers, les dates de modification racontent l'histoire de l'intrusion — un fichier cœur de PrestaShop modifié trois jours avant les premiers symptômes, c'est votre piste principale.

Comparez toujours avec une source propre : l'archive officielle de votre version pour le cœur, le dépôt du module pour les modules. Ce que vous ne savez pas expliquer, considérez-le hostile.

Nettoyer ou reconstruire : la vraie décision

Venons-en au point qui fâche. Beaucoup de guides vous expliquent comment nettoyer un site infecté fichier par fichier. Sur le terrain, c'est une perte de temps. Un attaquant qui a eu la main sur votre serveur a pu déposer des backdoors partout : dans les dossiers de cache, dans les commentaires de fichiers légitimes, dans des tâches planifiées, dans la base. Vous n'en trouverez jamais la certitude complète.

Un site piraté n'est plus à vous. Tant que vous ne l'avez pas reconstruit depuis une source saine, c'est l'attaquant qui vous prête votre boutique.

La méthode que j'applique et que je recommande : reconstruire. Vous gardez vos données — clients, commandes, catalogue — après les avoir nettoyées, et vous redéployez le code depuis une source de vérité versionnée. Ni le serveur infecté, ni ses fichiers, ni ses caches ne survivent à l'opération.

Concrètement, cela veut dire que vous avez intérêt, avant même d'être piraté, à ce que votre boutique soit déployable à la demande. Si votre code vit dans un dépôt et se déploie par une chaîne automatisée, la reconstruction est une opération d'un soir. Si tout vit en FTP sur un serveur unique, c'est un chantier. C'est la vraie leçon d'un incident : la vitesse de reprise se décide des mois avant le problème. Ceux qui veulent anticiper peuvent commencer par déployer PrestaShop sur un VPS dans un environnement reproductible ou s'inspirer d'une chaîne de déploiement automatisée type CI/CD — et pour la philosophy complète, le triptyque du fondateur souverain explique pourquoi dépendre d'une seule machine, d'un seul compte, d'un seul fournisseur, est le vrai risque.

Récupérer les données qui comptent

Reconstruire ne veut pas dire repartir de zéro. Avant de détruire l'ancien serveur, extrayez de l'ancienne base ce qui a de la valeur :

• Les clients et leurs adresses, en vérifiant les adresses email de contact de la boutique — un détournement passe souvent par une modification discrète de l'adresse de réception des commandes.
• Les commandes et l'historique, pour le service client et la comptabilité.
• Le catalogue, images comprises, en re-téléchargeant les modules depuis leurs sources officielles plutôt que depuis le serveur infecté.
• La configuration, champ par champ, en vous méfiant des valeurs modifiées récemment.

Chaque élément récupéré est passé au crible avant d'entrer dans la nouvelle installation. La confiance ne se transfère pas depuis un site compromis.

Refermer la porte : durcissement minimal

La reconstruction finie, la question devient : pourquoi l'attaquant ne reviendra-t-il pas ? Parce que vous aurez refermé ce qui a laissé entrer. Le minimum vital, sans discussion :

• Double authentification sur tous les comptes admin, sans exception.
• Comptes inutiles supprimés, pas désactivés.
• Modules retirés si vous ne les utilisez plus — chaque module installé est une surface d'attaque qui vit dans votre boutique.
• Cœur et modules tenus à jour, avec un processus de mise à jour régulier plutôt qu'un rappel pieux.
• Secrets renouvelés : mots de passe, clés API, tokens SMTP, et jamais les mêmes sur deux services.
• Sauvegardes testées : une sauvegarte jamais restaurée n'est pas une sauvegarde.
• Surveillance des modifications de fichiers et des échecs de connexion admin.

PrestaShop publie ses avis de sécurité au fil des versions : les avis de sécurité officiels de PrestaShop. C'est la référence à suivre avant les blogs, y compris celui-ci.

Après la tempête

Un piratage se paie trois fois : en trésorerie détournée, en temps de reconstruction, en confiance client. Les deux premiers se règlent par la méthode décrite ici. Le troisième se travaille : prévenez les clients concernés sans dramatiser, soyez précis sur ce qui a fuité et ce qui a été corrigé, et documentez l'incident. Vos clients n'attendent pas que vous soyez infaillible. Ils attendent que vous soyez clair.

Et une fois remis en selle, transformez l'incident en avantage : un processus de déploiement reproductible, des sauvegardes éprouvées, un accès admin verrouillé — c'est exactement ce qui distingue une boutique gérée d'une boutique subie. Ceux qui veulent aller plus loin dans cette direction trouveront dans la mise en place d'un environnement de production conteneurisé un bon point de départ, et sur la page qui présente mon parcours le contexte dans lequel j'écris ces méthodes.