Quand un WordPress se met à “faire du bruit”, le premier réflexe est souvent de regarder les plugins, de vérifier le thème, de lancer un scan de fichiers. C’est logique. Mais dans beaucoup d’incidents que j’ai vus, la porte d’entrée et la persistance viennent d’un endroit plus banal: le dossier wp-content/uploads.
Oui, les images et les fichiers médias. Pas forcément “du contenu”, plutôt des uploads utilisés comme cache et tremplin. Un malware peut y déposer de quoi maintenir un accès, récupérer des payloads au bon moment, ou servir de relais entre un script discret et le reste du site.
Le sujet est délicat, parce que toucher aux médias sans méthode peut casser un site ou effacer des éléments légitimes. L’objectif, ici, c’est d’apprendre à contrôler les uploads en suspects, de manière pragmatique, sans partir en chasse aveugle.
Pourquoi les uploads finissent souvent impliqués
Les dossiers uploads ont une particularité: ils acceptent énormément de types de fichiers au fil du temps, et la plupart des sites ne surveillent pas la structure interne. Même si WordPress limite l’upload via sa configuration, les attaquants trouvent des chemins. Parfois c’est via une autorisation trop large, parfois via un contournement de vérification côté navigateur ou via une configuration serveur permissive.
Ensuite, il y a la logique opérationnelle des attaquants. Ils déposent un fichier “inutile” en apparence, puis déclenchent l’exécution via un mécanisme qui ne ressemble à rien de suspect au premier coup d’œil. Sur un site compromis, vous pouvez avoir un navigateur web normal qui ne montre rien, mais dès que vous appelez une page précise, un fichier dans uploads est consulté ou inclus.
Autre point, plus concret: uploads est souvent volumineux. En audit, on gagne du temps en sachant où chercher en priorité. Si vous avez déjà constaté des symptômes (redirections vers des domaines inconnus, injections de code dans les pages publiques, création de comptes admin, pics de trafic bizarres), contrôler les uploads fait sens, parce que c’est là que la persistance se matérialise parfois avec le moins d’effort.
Les signes qui doivent vous pousser vers wp-content/uploads
Les symptômes ne pointent pas toujours avec précision vers uploads, mais certains signaux reviennent dans les dossiers que j’ai ouverts:
- des fichiers nouvellement apparus dans des sous-dossiers uploads après un moment précis, alors que le site ne publiait rien de nouveau à cette période; des extensions inhabituelles (pas seulement des .php, aussi des formats déguisés, des doublons, des noms aléatoires); des fichiers avec dates de modification incohérentes par rapport aux événements connus (mise à jour, nouveau contenu, sauvegarde); des requêtes serveur répétitives vers des URLs qui commencent par /wp-content/uploads/ alors que vos visiteurs n’y vont pas naturellement; une présence de code dans des fichiers censés être “des médias”, ou des en-têtes de fichiers qui ne correspondent pas à leur extension.
Attention, un symptôme isolé ne suffit pas. Sur un site vivant, les médias bougent, et des automatismes peuvent toucher les médias (redimensionnement, optimisation, import RSS, migration). La méthode consiste à faire le lien entre l’anomalie et le comportement du site, pas à supposer.
Préparer le terrain: limiter les risques avant de toucher
Avant de supprimer quoi que ce soit, prenez deux précautions simples, mais non négociables:
Sauvegarde. Idéalement, une copie complète de wp-content et des fichiers PHP clés (au minimum wp-config.php, les thèmes actifs, les plugins actifs). Une sauvegarde “propre” si possible, pas juste un export MySQL sans fichiers. Accès en lecture seule si vous pouvez. Si vous avez la main sur un environnement de staging, clonez le site et analysez là.Vous allez peut-être vouloir analyser des dizaines, parfois des centaines, de fichiers. S’ils sont supprimés trop vite, vous risquez de masquer le problème ou de casser un rendu normal. Or, dans un nettoyage malware, la tentation est de “tout effacer”, puis de découvrir après coup que le site a perdu des images, des PDF, ou des ressources utilisées par des pages spécifiques.
Le compromis sain: comprendre avant d’enlever.
Construire une base de tri: ce qui est normal dans un uploads
Le piège classique, c’est de traiter uploads comme un dossier uniforme. En réalité, il est structuré et vivant.
Un WordPress standard crée des sous-dossiers par année et mois, comme 2023/11/. Selon les plugins, vous pouvez aussi voir des sous-dossiers supplémentaires (par exemple pour des importations, des copies, ou des galeries). Il peut aussi y avoir des fichiers racine (à la racine de uploads), mais ils sont moins fréquents sur un système standard.
En situation d’incident, je regarde d’abord trois choses:
- la volumétrie: combien de fichiers, et surtout combien ont été modifiés récemment; la cohérence des extensions: images attendues (JPG, PNG, WebP, GIF), documents attendus (PDF, parfois ZIP si des pages les utilisent), et le reste qui doit alerter; les noms: si vous voyez une série de noms aléatoires, ou des fichiers dont la taille est minuscule alors que “la page parle d’un gros média”, vous avez un signal.
Ce tri ne donne pas une certitude. Il donne un périmètre raisonnable. Ensuite, on examine ce périmètre avec des techniques plus précises.
Contrôler les uploads en pratique: une méthode qui marche en audit
Le contrôle ne doit pas être un “scan magique”. Sur un WordPress compromis, le but est d’identifier ce qui peut être:
- un fichier exécutable caché (PHP déguisé, scripts dans un chemin accessible); un fichier qui charge du code à partir d’une autre source; un fichier qui déclenche une action via des références depuis le reste du site.
Je fais souvent une analyse en deux temps: d’abord un inventaire ciblé, ensuite une vérification du contenu.
1) Lister les fichiers suspects selon des critères concrets
Sans vous perdre dans tout uploads, vous pouvez filtrer ce qui mérite d’être ouvert ou au moins inspecté.
En audit, je me concentre sur les éléments qui ne sont pas “juste une image”. Par exemple:
- extensions rarement associées à un site (et non utilisées par vos médias); fichiers minuscules qui portent une extension non attendue; modifications très récentes; noms très courts, ou suites répétitives.
Le principe, c’est que le malware a souvent un profil: il n’a pas besoin d’être volumineux, il a besoin d’être présent et accessible.
2) Vérifier la nature réelle du fichier
Une extension peut mentir. Le fichier aussi.
Quand j’inspecte un fichier suspect, je regarde:
- s’il ressemble à un binaire d’image ou s’il contient du texte; si on trouve des signatures de code (caractères typiques, balises PHP, fonctions de base, chaînes d’URL); si le fichier contient du code qui n’a rien à faire dedans.
Techniquement, vous pouvez utiliser des outils qui affichent l’empreinte du fichier. Sur un hébergement mutualisé, les options sont limitées, mais même un contrôle manuel via lecture partielle peut aider. Un bon indicateur, c’est de voir rapidement s’il y a du code lisible au début ou des motifs d’exécution.
Ici, l’objectif n’est pas d’être “forensique” au sens strict. Il faut être assez précis pour ne pas supprimer un média légitime par accident.
3) Identifier les références depuis le reste du site
Un fichier posé dans uploads ne sert à rien s’il n’est pas appelé. Je cherche donc, dans le reste de wp-content, des traces du suspect:
- recherche de son nom de fichier ou d’une portion de chaîne unique; recherche de chemins vers wp-content/uploads/ dans des fichiers PHP, ou dans des fichiers de configuration; vérification de nouveaux scripts dans des dossiers inattendus.
Une difficulté fréquente: le malware peut utiliser des mécanismes indirects, comme un fichier qui charge un autre fichier depuis uploads via un nom calculé. Dans ce cas, le contenu du fichier suspect peut donner une piste, même sans que le nom soit visible ailleurs.
4) Relier l’attaque au moment
Si vous avez accès https://gardewp.fr/ aux logs (ou ne serait-ce qu’à une estimation serveur), essayez d’alignement dans le temps. Par exemple:
- un upload suspect le 3 à 03:12; puis un pic de requêtes le 3 à 03:15; puis des modifications visibles sur des pages.
Ce n’est pas une preuve absolue, mais c’est une manière d’éviter de traiter des “vieux résidus” qui ne causent plus de problème, ou au contraire de rater une chaîne qui a déjà été remplacée.
Les extensions qui doivent déclencher un doute (et celles qui exigent une attention particulière)
Sans faire une liste exhaustive, je vous donne une logique plutôt qu’une règle universelle. Tout ce qui “peut être exécuté” côté serveur doit être considéré comme dangereux, surtout s’il se trouve dans un dossier servit par le web.
En pratique, beaucoup d’incidents tournent autour de fichiers qui ont l’air d’images ou de documents, mais qui contiennent des mécanismes d’exécution. Parfois, l’extension est .php ou assimilée. Parfois, ce sont des noms trompeurs, comme un .jpg qui contient du code. Parfois, le fichier n’est pas directement exécutable, mais il est chargé par un script déjà présent ailleurs.
La règle que j’applique sur un site de production est simple: si le fichier n’est pas utilisé par le site, et qu’il est dans un état incohérent, je le traite comme suspect au minimum. Ensuite, seulement ensuite, je décide quoi faire.
Des cas fréquents, rencontrés sur le terrain
Cas 1: le fichier “image” qui n’est pas une image
On a parfois un fichier dont l’extension est cohérente, par exemple .png. Mais quand on l’ouvre, le navigateur refuse, ou bien l’image est corrompue. En lecture partielle, on voit du code texte plutôt que des données binaires d’image.
Ce genre de fichier est souvent un stage. Il peut contenir une charge utile, ou un code qui reconfigure un comportement.
Ce que je fais dans ce cas: je confirme si ce fichier est appelé par d’autres éléments. Si non, la suppression peut être suffisante. Si oui, il faut regarder aussi le code qui l’appelle. Supprimer un stage sans enlever le moteur peut laisser le malware chercher à nouveau ailleurs.
Cas 2: un dossier uploads qui “pousse” des fichiers après chaque tentative de nettoyage
Le signal inquiétant n’est pas seulement la présence de fichiers suspects, c’est leur retour. Si, après avoir supprimé quelques fichiers dans uploads, vous constatez qu’ils réapparaissent, alors votre nettoyage est incomplet.
La cause la plus courante est qu’un script ailleurs a la capacité de réécrire dans uploads. Ça peut venir d’un plugin compromis, d’un script dans le thème, ou d’une porte d’accès plus profonde (compte admin, clé d’API volée, accès FTP réactivé par une tâche automatisée).
Dans ce cas, je ne m’acharne pas sur uploads seul. Je traite uploads comme un symptôme et je cherche le mécanisme d’injection.
Cas 3: des uploads légitimes qui ressemblent à des “parasites” à cause d’un plugin
Il existe des plugins d’optimisation, d’import, ou de synchronisation. Certains créent des fichiers temporaires, des variantes redimensionnées, ou des caches. Il peut y avoir des noms qui paraissent aléatoires.
Je me suis fait avoir une fois en supprimant “trop vite” des fichiers temporaires qui étaient utilisés par une galerie. Résultat, des images manquaient, et le site semblait “à moitié nettoyé”. Ce genre d’incident vous coûte du temps et de la crédibilité, même si vous avez finalement trouvé le vrai malware.
Donc la règle d’or que j’applique: si le fichier suspect est aussi manifestement utilisé (présent dans des pages, référencé dans des shortcodes, visible dans des URL), je le mets de côté pour inspection approfondie, au lieu de supprimer en premier.
Supprimer, masquer, ou mettre en quarantaine: décider avec prudence
Une fois que vous avez identifié un fichier suspect, que faire? La réponse dépend du niveau de certitude.
- Si vous avez confirmé qu’un fichier contient du code exécutable ou manifestement non conforme à son type, la suppression est souvent justifiée. Si vous n’êtes pas sûr, vous pouvez mettre en quarantaine (renommer le fichier, restreindre l’accès, déplacer le fichier hors de l’arborescence servie). L’idéal dépend de votre hébergement et de votre capacité à reconfigurer le serveur. Si vous savez que la référence est dynamique (le malware “recherche” un pattern), il peut être nécessaire de supprimer le code moteur ailleurs, sinon vous verrez des reuploads.
Voici mon approche de tri décisionnel, sous forme de mini-checklist pour garder le cap:
- Vérifier si le fichier est appelé (recherches de nom, de chemin, et occurrences dans le code). Contrôler le contenu (différence entre “média valide” et “contenu texte/codé”). Estimer l’impact (les URL de médias existent-elles dans le site, ou viennent-elles d’un plugin attendu?). Choisir une action réversible si possible (quarantaine avant suppression définitive). Recontrôler après suppression (taux de retour des fichiers, traces dans les logs).
C’est ce qui évite de nettoyer au hasard.
Mettre sous contrôle les uploads après incident, pour éviter la récidive
Nettoyer n’est pas terminer. Si vous ne changez rien, vous réouvrez la porte. Le dossier uploads est un endroit qui peut redevenir un réceptacle si la cause initiale existe toujours.
Les actions qui réduisent la surface d’attaque sont souvent plus efficaces que des suppressions récurrentes.
Sécuriser l’accès et les permissions
Je regarde en premier:
- qui peut uploader, via quels rôles et quelles méthodes, si des comptes ont des permissions excessives.
Un compte compromis, même sans “malware visible”, peut relancer l’injection. Dans un incident, la meilleure séquence que j’ai utilisée est celle-ci: révoquer les accès, changer les mots de passe, vérifier les rôles, puis seulement après, nettoyer et recontrôler.
Réduire les types de fichiers uploadables
WordPress et la configuration serveur peuvent limiter certains formats. Si votre site n’a pas besoin d’archives ZIP, de fichiers scripts, ou de certains formats, limiter réduit le risque.
Le point délicat: la limitation trop agressive casse parfois des fonctionnalités. Un exemple typique, un plugin de galerie peut s’appuyer sur des documents “non attendus” pour des importations, et vous bloquez le besoin métier.
Donc la règle: limiter ce qui est vraiment inutile pour votre cas, puis valider que votre chaîne d’édition et vos imports continuent de fonctionner.
Surveiller les modifications dans uploads
La surveillance n’a pas besoin d’être sophistiquée. L’essentiel est de savoir quand uploads change, et de quoi il s’agit.
Si vous êtes dans une configuration où vous pouvez consulter les logs, je recommande de prêter attention aux requêtes qui ciblent directement des fichiers dans wp-content/uploads/. Si ces requêtes n’ont pas de relation avec vos usages, vous tenez un fil.
Dans certains environnements, même un simple suivi via alertes de modification peut déjà faire gagner du temps.
Une stratégie de réponse globale: nettoyer uploads sans perdre l’essentiel
Contrôler uploads est essentiel, mais le piège est de se focaliser dessus au point d’oublier la cause.
Sur un site compromis, vous devez travailler à un niveau “chaîne d’infection”, pas à un niveau “fichier unique”. Le malware peut:
- se déposer dans uploads, mais le mécanisme d’injection peut être dans un plugin, et l’exécution peut dépendre d’un fichier déjà modifié dans wp-includes ou dans le thème.
C’est pour ça que, pendant le nettoyage, je fais souvent un aller-retour entre trois zones: le contenu suspect dans uploads, les modifications récentes dans wp-content (thème, plugins, fichiers additionnels), et les accès utilisateurs.
Plutôt que de multiplier les suppressions, je préfère identifier ce qui a le plus de chances d’avoir créé la situation.
Comment savoir si vous êtes “vraiment” propre
Après nettoyage, un faux sentiment de propreté peut apparaître. Le site redevient accessible, mais des injections sporadiques continuent, ou bien le malware attend une action précise pour se manifester.
Les signaux que je surveille après une intervention:
- disparition des redirections ou scripts injectés sur pages publiques; absence de nouveaux uploads suspects après une période comparable à la fenêtre d’apparition observée avant nettoyage; stabilité des plugins et des thèmes (pas de retouches automatiques); absence de nouveaux comptes ou changements de rôles.
Je fais aussi un test comportemental simple, en reproduisant les actions qui posaient problème avant (navigation sur pages qui redirigeaient, chargement de certaines ressources). Sur une compromission, le malware aime les triggers.
Les limites réelles (et pourquoi il faut parfois accepter une approche plus large)
Il y a des situations où contrôler les uploads ne suffit pas.
Par exemple, si la compromission vient d’une vulnérabilité, d’un compte admin pris, ou d’un accès serveur compromis, le dossier uploads ne sera qu’une conséquence. Même si vous supprimez tous les fichiers suspects, un mécanisme peut continuer à réinjecter.
Dans d’autres cas, la difficulté vient du volume. Sur un site très actif, uploads peut compter des milliers de fichiers. Travailler fichier par fichier n’est pas réaliste en production. Il faut alors combiner tri, analyse et recoupement via les logs ou des traces d’intégrité.
Enfin, il existe des cas où le malware est “dans” le serveur de manière plus large, pas seulement dans WordPress. Vous pouvez être en train de combattre un symptôme applicatif, alors que la cause est plus basse.
Quand c’est le cas, le bon réflexe est d’élargir l’investigation: rôles, tâches planifiées côté serveur, fichiers système, et durcissement général.
Deux règles simples qui m’ont évité pas mal d’erreurs
La première règle: ne nettoyez pas sans repérer ce qui a changé. Si vous supprimez des éléments au hasard, vous perdez la carte de l’incident.
La seconde règle: considérez uploads comme une zone de transit, pas comme une zone “sans risque”. Les médias sont la vitrine, mais l’attaque peut se cacher derrière.
Petit guide de travail le jour du nettoyage (sans se disperser)
Quand je dois intervenir, je veux un processus qui marche même sous pression. Voici comment je le mets en scène, sous forme courte, parce que l’essentiel se joue dans la discipline.
- Dressez un inventaire des fichiers récents et non standards dans wp-content/uploads. Inspectez le contenu des suspects, surtout ceux qui ne peuvent pas être de “vrais médias”. Cherchez des références (noms, chemins, morceaux de chaînes) depuis le reste de WordPress. Nettoyez avec une stratégie graduée, suppression ou quarantaine selon votre niveau de certitude. Vérifiez le retour après suppression, et cherchez la cause si les fichiers reviennent.
Avec ça, vous ne tombez pas dans le piège “j’ai supprimé, donc c’est fini”.
Ce que vous pouvez faire dès maintenant, si vous suspectez uploads
Si vous êtes en phase d’enquête, commencez par un inventaire ciblé de votre dossier uploads. Repérez les fichiers créés ou modifiés récemment, puis examinez leur cohérence. Ensuite, plutôt que de lancer des suppressions massives, faites le lien avec les événements côté site, logs si possible, et changements récents d’extensions, de thème ou d’utilisateurs.
C’est souvent là que la situation se clarifie. Un malware bien posé laisse des traces de comportement, et wp-content/uploads peut être un excellent endroit pour les voir. Pas parce que c’est “coupable”, mais parce que c’est pratique pour l’attaquant, et donc révélateur pour vous.
Si vous voulez, décrivez-moi votre contexte (hébergement mutualisé ou VPS, symptômes observés, et type de fichiers trouvés dans uploads). Je pourrai vous proposer une grille de tri plus précise, adaptée à votre cas, sans supposer trop de choses.