Anatomie d’une cyberattaque : comment un module non validé a compromis un site e-commerce

Un matin de mars 2026, un e-commercant nous appelle : toutes les pages de son site affichent une erreur 404. Seule la page d’accueil fonctionne encore. En quelques heures, notre équipe découvre bien plus qu’un simple bug technique. Le site a été compromis. Un attaquant a pris le contrôle du serveur, installé des portes dérobées et potentiellement accéder à l’ensemble des données clients.

Voici le récit détaillé de cette attaque, de l’erreur initiale à la remédiation complète. Tous les noms et données ont été anonymisés, mais les faits techniques sont réels. Notre objectif : vous montrer comment une décision apparemment anodine peut ouvrir la porte à une intrusion majeure.

Jour 0 : un module installé sans validation

Tout commence par un geste banal. Le gérant du site e-commerce, qui tourne sous PrestaShop, décide d’installer un module de gestion de catalogue. Ce module, disponible sur les marketplaces habituelles, promet de simplifier la mise à jour des fiches produits. Installation en quelques clics, configuration rapide, utilisation immédiate. Le gérant passe trois heures à réorganiser son catalogue. Tout fonctionne.

Le problème : ce module présente une faille de sécurité connue et référencée publiquement (une CVE publiée depuis 2023). Cette faille permet à n’importe qui, depuis Internet, d’exécuter des requêtes SQL sur la base de données du site. Et le gérant a installé ce module sans en informer son prestataire technique.

Le jour même de l’installation, les logs montrent que des robots automatisés scannent déjà le site à la recherche de modules vulnérables. Ces bots tournent 24h/24 et testent des milliers de sites PrestaShop chaque jour. Quand ils trouvent un module vulnérable, l’exploitation commence.

Jour 1 à 5 : l’intrusion silencieuse

Dans les jours qui suivent l’installation du module, l’attaquant exploite la faille SQL pour déposer un fichier malveillant sur le serveur : un webshell. C’est un petit fichier PHP, déguisé en page d’erreur 404, qui donne un accès complet au serveur via un navigateur web. L’interface est protégée par une combinaison de touches cachées. Sans la connaître, impossible de distinguer ce fichier d’une vraie page d’erreur.

Avec ce webshell, l’attaquant peut :

• Naviguer dans tous les fichiers du serveur
• Lire la configuration de la base de données (identifiants, mots de passe)
• Exécuter des commandes système comme s’il était administrateur
• Uploader d’autres fichiers malveillants
• Modifier ou supprimer n’importe quel fichier

En parallèle, des tentatives de connexion au back-office PrestaShop apparaissent dans les logs. Une adresse IP inconnue teste la page de login avec plusieurs navigateurs différents (Firefox sur Linux, Chrome sur Windows, Safari sur iPhone) en quelques secondes. C’est la signature d’un bot de brute-force qui fait tourner ses user-agents pour contourner les protections.

Cinq jours après l’installation du module, la première connexion non autorisée au back-office est enregistrée.

Jour 5 à 9 : prise de contrôle progressive

L’attaquant ne se précipite pas. Il revient régulièrement, depuis des adresses IP différentes, pour explorer le back-office et le serveur. Les logs révèlent des connexions depuis au moins cinq adresses IP distinctes sur cette période, toutes étrangères à l’activité habituelle du client.

Au neuvième jour, l’attaquant passe à l’action :

• Il installe un thème pirate sur le site (probablement pour injecter du code malveillant dans les pages visibles par les visiteurs)
• Il modifie un module existant pour y cacher une copie de son webshell
• Il dépose des fichiers supplémentaires dans d’autres modules, créant ainsi plusieurs portes d’entrée de secours

Le fichier .htaccess du site, qui gère le routage des URLs, est renommé. Sans ce fichier, Apache ne peut plus diriger les visiteurs vers les bonnes pages. C’est ce qui provoque les erreurs 404 que le client constate le lendemain.

Jour 10 : la découverte et l’analyse forensique

L’e-commerçant nous signale le problème le matin. Notre équipe lance immédiatement une investigation. En moins d’une heure, nous identifions le .htaccess renommé. Mais en creusant, nous découvrons le webshell.

L’analyse des logs du jour de la découverte révèle qu’un opérateur, connecté depuis l’Indonésie, est en train d’utiliser activement le webshell au moment même où nous investiguons. Voici ce que nos logs montrent sur une fenêtre de 30 minutes :

Phase 1 – Reconnaissance. L’attaquant scanne systématiquement les modules du site à la recherche de ses webshells. Il teste des URLs avec des paramètres en indonésien (« ketua » qui signifie « chef »), une signature connue de certains kits d’attaque.

Phase 2 – Authentification. Il trouve son webshell, s’authentifie via un formulaire caché, et accède à l’interface d’administration du shell.

Phase 3 – Exfiltration probable. Une requête génère une réponse de près de 700 Ko. C’est anormalement élevé pour une simple page web. Il a probablement téléchargé un dump de fichiers ou de données.

Phase 4 – Navigation. Il parcourt les répertoires du serveur, lit des fichiers de configuration, exécute des commandes. Les tailles de réponses varient (3 Ko, 5 Ko, 11 Ko), indiquant des actions différentes à chaque requête.

Phase 5 – Basculement. Quand le premier webshell commence à retourner des erreurs (notre remédiation démarre), il bascule sur un second webshell caché dans un autre module. Celui-ci finit aussi par tomber.

Le lendemain, une autre IP indonésienne tente d’accéder au webshell principal. Elle obtient une erreur 404. La remédiation a fonctionné.

La remédiation : retour à un état sain

Face à l’ampleur de la compromission, la décision est prise de restaurer un backup complet du serveur datant de la veille de l’intrusion. C’est la seule façon de garantir qu’aucun fichier malveillant ne subsiste. Nettoyer fichier par fichier aurait été trop risqué : avec un accès complet au serveur, l’attaquant a pu modifier n’importe quoi, n’importe où.

Après la restauration :

• Suppression du module vulnérable et de tous les modules installés sans validation
• Changement de tous les mots de passe (back-office, base de données, FTP)
• Audit complet des modules restants
• Mise à jour de l’ensemble des composants du site
• Vérification de l’intégrité de la base de données

Les obligations légales : CNIL, plainte et RGPD

Un site e-commerce stocke des données personnelles : noms, adresses, emails, historique de commandes. L’attaquant ayant eu un accès complet au serveur, il a potentiellement pu accéder à l’ensemble de ces données.

Le RGPD impose plusieurs obligations dans ce cas :

• Notification à la CNIL dans les 72 heures suivant la découverte de la violation
• Information individuelle des clients si le risque pour leurs droits est élevé
• Documentation de l’incident dans un registre interne
• Dépôt de plainte auprès de la police ou de la gendarmerie pour accès frauduleux à un système informatique

Ces obligations incombent au responsable du traitement (le client), pas au prestataire technique. Notre rôle est de fournir les éléments techniques nécessaires, ce que nous avons fait via un rapport d’incident détaillé et l’extraction des logs serveur.

Ce que cette attaque nous apprend

Cette attaque n’a rien d’exceptionnel. Elle suit un schéma classique que notre équipe observe régulièrement. Voici les enseignements concrets.

Ne jamais installer de module sans validation technique

C’est la cause directe de cet incident. Un module avec une faille connue depuis trois ans a été installé sans vérification. Les marketplaces de modules ne garantissent pas la sécurité de ce qu’elles proposent. Avant toute installation, votre prestataire doit vérifier le module, sa version, ses vulnérabilités connues et sa réputation.

Les attaquants sont rapides et automatisés

Le jour même de l’installation du module vulnérable, des bots scannaient déjà le site. Ces robots testent des milliers de sites par jour. Ils connaissent les URLs des modules vulnérables et les exploitent automatiquement. Vous n’avez pas des semaines devant vous : la fenêtre entre l’installation d’un composant vulnérable et son exploitation se compte en heures.

Un webshell est presque invisible

Le fichier malveillant pesait quelques Ko et se faisait passer pour une page d’erreur. Sans une investigation ciblée, il serait resté en place indéfiniment. C’est pourquoi des audits réguliers de cybersécurité et une surveillance des fichiers modifiés sont indispensables.

Les backups sauvent des entreprises

Sans un backup propre datant d’avant l’intrusion, la remédiation aurait été beaucoup plus complexe, plus longue et plus incertaine. Avoir des sauvegardes régulières, testées et stockées hors du serveur de production n’est pas un luxe. C’est une assurance vie pour votre activité.

Les mots de passe du back-office sont une cible

L’attaquant a tenté du brute-force sur la page de connexion avec rotation de user-agents. Un mot de passe faible aurait cédé. L’authentification à deux facteurs (MFA) et des mots de passe robustes auraient bloqué ces tentatives. Ce sont des bonnes pratiques de base en cybersécurité qui font toute la différence.

Ce que vous pouvez faire dès maintenant

Vous gérez un site e-commerce ? Voici cinq actions à mettre en place cette semaine :

1. Faites l’inventaire de vos modules. Listez tout ce qui est installé. Supprimez ce que vous n’utilisez pas. Vérifiez les versions.
2. Activez l’authentification à deux facteurs sur votre back-office. C’est la mesure la plus rentable en cybersécurité.
3. Vérifiez vos backups. Sont-ils automatiques ? Récents ? Stockés ailleurs que sur le serveur de production ? Avez-vous déjà testé une restauration ?
4. Établissez une règle simple : aucun module, thème ou plugin n’est installé sans validation de votre prestataire technique.
5. Planifiez un audit de sécurité. Pas dans six mois. Maintenant.

La cybersécurité n’est pas un sujet réservé aux grandes entreprises. Les PME sont les cibles privilégiées des attaquants, précisément parce qu’elles sont moins protégées. L’incident que nous venons de décrire aurait pu être évité par une seule décision : demander un avis technique avant d’installer un module.

Vous avez un doute sur la sécurité de votre site ? Contactez notre équipe. On regarde ensemble. Pas de jargon, pas de panique. Juste un diagnostic concret et des solutions adaptées à votre situation.