Nettoyer un site infecté : la méthode, et pourquoi restaurer ne suffit pas toujours

Deux approches, une question à trancher avant tout

La restauration d’une sauvegarde remet le site dans l’état exact où il se trouvait à une date donnée. C’est rapide, mais cela n’est valable que si cette date précède le tout début de l’infection, pas seulement le moment où le problème a été remarqué : ce sont deux dates presque toujours différentes.

Le nettoyage manuel ciblé consiste à identifier précisément le code injecté, les comptes ou les accès ajoutés par l’attaquant, puis à les retirer sans repartir de zéro. Il demande davantage de temps d’investigation, mais il ne dépend pas de l’existence d’une sauvegarde saine.

Les deux approches ne s’opposent pas toujours : une sauvegarde ancienne et fiable peut servir de référence pour comparer les fichiers, même sans être utilisée telle quelle pour la remise en ligne.

Un exemple documenté du décalage entre faille et découverte

En 2014, Sucuri a documenté la campagne connue sous le nom de SoakSoak, liée à une faille dans l’extension Slider Revolution pour WordPress. Le correctif avait été publié par l’éditeur dès février 2014, mais l’exploitation massive de cette faille n’a été observée qu’entre septembre et décembre de la même année, notamment via des thèmes qui embarquaient une copie obsolète de l’extension à l’insu du propriétaire du site.

Ce cas illustre un point simple : le moment où une infection est remarquée ne dit rien sur le moment où elle a réellement commencé. Une sauvegarde vieille de plusieurs semaines, voire de plusieurs mois, peut donc déjà contenir un code malveillant resté silencieux jusqu’à son activation.

Un endroit que la simple comparaison de fichiers ne couvre pas

Sous PrestaShop, comparer les fichiers du cœur à une installation propre de la même version repère les fichiers du cœur modifiés. Mais le système d’override, qui permet légitimement d’étendre une classe ou un contrôleur sans toucher au fichier d’origine, ne fait pas partie de cette comparaison automatique : un fichier placé dans override/ est censé contenir du code personnalisé, un override malveillant s’y fond donc sans déclencher d’écart évident. Ce dossier mérite une relecture ligne à ligne, pas seulement une comparaison automatisée.