Une boutique en ligne semble avoir été nettoyée après un piratage. Les redirections ont disparu, les fichiers suspects ont été supprimés et tout fonctionne de nouveau normalement. Pourtant, quelques jours plus tard, les mêmes anomalies réapparaissent. Cette réinfection d’un site e-commerce n’est pas forcément due à une nouvelle attaque. Elle peut résulter d’un accès caché, d’une base de données compromise ou d’une vulnérabilité restée ouverte. Comprendre ces mécanismes est indispensable pour mener un audit de sécurité complet et éviter qu’une boutique ne soit compromise à nouveau.
Pourquoi une boutique nettoyée peut-elle se réinfecter ?
Lorsqu’un site e-commerce infecté retrouve un fonctionnement normal après la suppression de quelques fichiers, il est tentant de considérer l’incident comme terminé. Or, la disparition des symptômes ne prouve pas que la cause a été éliminée.
Le cas le plus simple est celui d’une vulnérabilité toujours présente. Un module, un thème, une extension ou une dépendance peut contenir une faiblesse permettant à un tiers de déposer de nouveaux fichiers ou de modifier certaines données. Si cette faiblesse n’est pas corrigée, l’attaquant peut reproduire l’intrusion.
La réinfection peut aussi venir d’un fichier secondaire passé inaperçu. Certains fichiers malveillants ne servent pas directement à afficher une redirection ou à modifier le tunnel de commande. Leur rôle consiste uniquement à recréer d’autres éléments supprimés pendant le nettoyage.
Une tâche planifiée peut produire le même effet. Les tâches planifiées, souvent appelées tâches cron, exécutent automatiquement des actions à intervalles réguliers. Elles sont utilisées légitimement pour envoyer des e-mails, mettre à jour des stocks ou générer des sauvegardes. Lorsqu’une tâche inconnue recrée un fichier malveillant, le nettoyage semble efficace pendant quelques heures, puis l’infection revient.
D’autres causes sont possibles :
- un mot de passe volé reste utilisable ;
- un compte FTP, SFTP ou d’hébergement n’a pas été désactivé ;
- une clé d’accès compromise est toujours valide ;
- une sauvegarde déjà infectée a été restaurée ;
- un module ou un thème modifié a été conservé ;
- plusieurs mécanismes de persistance ont été installés.
La situation peut être comparée à une fuite d’eau. Essuyer le sol supprime temporairement la flaque, mais si la canalisation n’est pas réparée, l’eau reviendra. De la même manière, nettoyer un site piraté ne consiste pas seulement à supprimer ce qui est visible. Il faut aussi identifier le point d’entrée et vérifier qu’aucun accès secondaire ne subsiste.
La persistance cachée dans la base de données
Les fichiers du serveur ne sont pas le seul emplacement à contrôler. Une partie importante du fonctionnement d’une boutique est enregistrée dans sa base de données : comptes utilisateurs, paramètres, contenus, modules actifs, adresses du site et blocs personnalisés.
Un attaquant peut donc conserver une présence sans laisser de fichier immédiatement identifiable.
Du code peut, par exemple, être injecté dans une page, une description de produit ou un bloc HTML. Ce code peut charger un script externe, afficher une publicité inattendue ou rediriger certains visiteurs. Il peut aussi rester discret en ne s’activant que dans des conditions particulières.
Une redirection peut également être enregistrée dans un paramètre de configuration. Dans ce cas, remplacer les fichiers du site par une version saine ne suffit pas, car la donnée malveillante est toujours présente dans la base.
Les éléments à examiner incluent notamment :
- les contenus contenant du JavaScript ou des iframes inattendues ;
- les adresses principales de la boutique ;
- les paramètres récemment modifiés ;
- les comptes utilisateurs inconnus ;
- l’adresse e-mail liée à l’administration ;
- les données enregistrées par les modules ;
- les jetons ou clés stockés dans la configuration.
Un antivirus de fichiers ne contrôle pas nécessairement toutes ces informations. Il peut signaler un fichier suspect tout en ignorant une modification stockée dans une table de la base de données.
Cette analyse doit toutefois être menée avec prudence. Une boutique utilise de nombreuses relations entre ses tables. Supprimer une ligne sans comprendre sa fonction peut rendre un module inutilisable, perturber les commandes ou empêcher l’accès à l’administration. Avant toute intervention directe, une sauvegarde complète est indispensable. Lorsque la structure de la base n’est pas maîtrisée, l’analyse doit être confiée à un développeur ou à un professionnel de la sécurité.
Les comptes administrateurs frauduleux
Un compte administrateur frauduleux offre à un attaquant un moyen simple de revenir sur une boutique après le nettoyage. Il peut s’agir d’un nouveau compte créé pendant l’intrusion ou d’un compte existant dont les identifiants ont été récupérés.
La première vérification consiste à dresser la liste complète des administrateurs. Chaque compte doit être associé à une personne, un prestataire ou un usage précis.
Il faut notamment contrôler :
- le nom du compte ;
- l’adresse e-mail associée ;
- la date de création ;
- la date de dernière connexion, lorsqu’elle est disponible ;
- le niveau de permissions ;
- le statut actif ou inactif ;
- la raison pour laquelle le compte existe encore.
Un nom crédible ne constitue pas une preuve de légitimité. Un compte portant le nom d’un service technique, d’un ancien collaborateur ou d’une agence peut avoir été créé pour se fondre dans la liste des utilisateurs autorisés.
Les comptes d’anciens salariés et prestataires doivent faire l’objet d’une attention particulière. Même lorsqu’ils sont légitimes à l’origine, ils peuvent devenir un risque s’ils ne sont plus utilisés ou si leurs mots de passe n’ont jamais été renouvelés.
Le contrôle ne doit pas se limiter à l’interface d’administration de la boutique. Les accès FTP, SFTP, SSH, les comptes d’hébergement, les outils de sauvegarde et les systèmes de déploiement doivent également être vérifiés.
Changer uniquement le mot de passe du compte principal ne suffit donc pas. Si un autre accès compromis reste actif, l’attaquant peut continuer à modifier le site sans utiliser le compte qui vient d’être sécurisé.
Comment auditer réellement la sécurité du site ?
Un audit de sécurité sérieux suit une méthode progressive. L’objectif n’est pas de supprimer immédiatement tout élément inhabituel, mais de comprendre ce qui s’est produit avant d’agir.
La première étape consiste à conserver une copie complète du site et de sa base de données avant toute modification. Cette copie permet de revenir sur les éléments suspects et de préserver les preuves.
Il faut ensuite tenter d’identifier la période probable de l’incident. Les premiers symptômes, les alertes reçues, les changements de comportement et les dates de modification des fichiers aident à établir une chronologie.
L’analyse des fichiers récemment créés ou modifiés permet ensuite de repérer les anomalies. Cette vérification doit inclure le cœur du CMS, le thème, les modules, les extensions, les fichiers de configuration et les répertoires contenant des contenus téléversés.
Le cœur du CMS peut être comparé à une archive officielle correspondant à la même version. Les différences observées ne sont pas toutes malveillantes, car certaines boutiques contiennent des personnalisations légitimes. Elles doivent néanmoins être expliquées.
Un outil automatisé peut aider à trier les fichiers et à repérer certaines signatures. Par exemple, un scanner de malware pour boutique en ligne peut compléter l’analyse humaine, sans remplacer la vérification de la base de données, des comptes, des accès techniques et des journaux du serveur.
L’audit doit ensuite couvrir les points suivants :
- conserver une copie du site avant toute intervention ;
- déterminer la date probable de l’incident ;
- analyser les fichiers récemment créés ou modifiés ;
- comparer le cœur du CMS avec une version officielle saine ;
- contrôler les thèmes, modules, extensions et dépendances ;
- examiner la base de données ;
- vérifier les administrateurs et les accès techniques ;
- contrôler les tâches planifiées ;
- analyser les journaux de connexion et d’erreurs ;
- rechercher la vulnérabilité ayant permis l’intrusion ;
- renouveler les mots de passe, clés et jetons ;
- surveiller le site après sa remise en ligne.
Les journaux sont particulièrement utiles pour comprendre l’enchaînement des événements. Ils peuvent montrer une connexion inhabituelle, une succession d’erreurs ou l’accès à un fichier sensible. Une adresse IP isolée ne suffit toutefois pas à identifier avec certitude l’auteur d’une intrusion. Elle constitue seulement un élément à rapprocher des autres preuves.
Les preuves à conserver pendant l’audit
Supprimer immédiatement un fichier suspect peut faire disparaître une preuve utile. Avant toute suppression, il est préférable de documenter l’élément, son emplacement et le contexte dans lequel il a été découvert.
Les informations à conserver comprennent :
- le nom et le chemin exact du fichier ;
- sa date de modification ;
- le compte utilisateur concerné ;
- un extrait pertinent des journaux ;
- l’adresse IP, lorsqu’elle est disponible ;
- la table ou l’entrée de base concernée ;
- une capture d’écran du comportement suspect ;
- l’action réalisée ;
- la date et l’heure de l’intervention.
| Élément contrôlé | Anomalie constatée | Niveau de risque | Action recommandée |
|---|---|---|---|
| Compte administrateur | Compte actif non reconnu par l’entreprise | Élevé | Désactiver après vérification et contrôler les connexions associées |
| Fichier du thème | Modification récente sans intervention planifiée | Moyen | Comparer avec une copie saine avant toute suppression |
| Tâche planifiée | Script lancé régulièrement sans fonction identifiée | Élevé | Suspendre la tâche et faire analyser le script |
Cette documentation facilite le travail des différents intervenants. Elle permet aussi de suivre les actions réalisées et d’éviter que plusieurs personnes modifient simultanément le site sans coordination.
Quand considérer que la boutique est réellement assainie ?
Une boutique en ligne piratée ne peut pas être considérée comme saine uniquement parce que les redirections ont disparu ou que la page d’accueil fonctionne de nouveau.
Plusieurs critères doivent être réunis.
Aucun fichier malveillant connu ne doit rester présent. La base de données doit avoir été contrôlée, les comptes inconnus supprimés et les accès légitimes sécurisés. Les mots de passe, clés et jetons susceptibles d’avoir été exposés doivent être renouvelés.
La vulnérabilité initiale doit aussi avoir été corrigée. Si elle se trouve dans une extension devenue inutile ou obsolète, sa suppression peut être préférable à son maintien. Les thèmes, modules et dépendances conservés doivent être mis à jour lorsque des versions fiables sont disponibles.
Les tâches planifiées doivent être vérifiées une par une. Les sauvegardes utilisées pour restaurer le site doivent également être considérées avec prudence, car une sauvegarde réalisée après l’intrusion peut contenir les mêmes éléments compromis.
Enfin, les journaux doivent être surveillés après la remise en ligne. Une période d’observation permet de repérer rapidement le retour d’une activité inhabituelle.
Un audit sérieux recherche donc deux choses : les traces laissées par l’intrusion et le chemin utilisé pour entrer. Supprimer les traces sans fermer le point d’accès laisse la sécurité d’une boutique en ligne incomplète.
Conclusion
La réinfection d’un site e-commerce survient souvent lorsque le premier nettoyage s’est limité aux symptômes visibles. Un fichier supprimé peut être recréé par une tâche planifiée. Un accès peut subsister dans un compte administrateur frauduleux, un service d’hébergement ou une base de données compromise. Une vulnérabilité non corrigée peut également permettre une nouvelle intrusion.
Pour assainir durablement une boutique, il faut examiner les fichiers, les données, les comptes, les accès techniques et les journaux. Un audit documenté permet de comprendre l’incident, de corriger sa cause et d’organiser une surveillance régulière après la remise en ligne.
FAQ
Pourquoi un site piraté se réinfecte-t-il après un nettoyage ?
Un site peut se réinfecter lorsque le nettoyage a supprimé les fichiers visibles sans corriger la cause de l’intrusion. Une vulnérabilité peut rester ouverte, un compte compromis peut encore être actif ou une tâche planifiée peut recréer les fichiers supprimés. La restauration d’une sauvegarde déjà infectée peut également réintroduire le problème. Il faut donc rechercher les mécanismes de persistance et sécuriser tous les accès.
Un antivirus suffit-il pour sécuriser une boutique en ligne ?
Non. Un antivirus ou un scanner peut aider à repérer certains fichiers suspects, mais il ne contrôle pas forcément les comptes administrateurs, les accès FTP, les tâches planifiées, les journaux ou toutes les données enregistrées dans la base. Il doit être utilisé comme un outil complémentaire. La sécurité repose sur une analyse globale, des mises à jour régulières et une vérification humaine des anomalies détectées.
Que faut-il vérifier après la suppression d’un malware ?
Il faut contrôler la base de données, les comptes administrateurs, les mots de passe, les clés d’accès, les tâches planifiées, les extensions et les journaux du serveur. La vulnérabilité initiale doit être identifiée et corrigée. Il est également recommandé de vérifier les sauvegardes avant de les restaurer et de surveiller le site après sa remise en ligne afin de détecter rapidement toute activité anormale.