Scanner malware WordPress : détecter les contenus redirigés invisibles

Un site WordPress peut être “propre” à l’œil, rapide à charger, même bien référencé, et pourtant être en train de distribuer autre chose. Le piège le plus sournois, ce sont les contenus redirigés invisibles, ceux qui ne se manifestent pas forcément dans l’interface classique, mais se déclenchent selon l’utilisateur, le contexte navigateur, l’agent, la géolocalisation, ou simplement le moment où la page est servie.

C’est exactement le genre de cas où un “scanner malware WordPress” n’est pas un gadget. C’est un outil de tri, pour gagner du temps, réduire les angles morts, et surtout comprendre le mécanisme de l’infection avant de tout remettre au propre à l’aveugle.

Je vais parler ici de ce que j’ai vu sur le terrain, des indices qui doivent vous alerter, et surtout de la façon de détecter des redirections invisibles sans tomber dans les conclusions hâtives.

Le symptôme : un site qui ne ressemble à rien, mais qui agit autrement

Quand on dit “contenu redirigé invisible”, on parle souvent d’un comportement conditionnel. Vous ouvrez une page et elle affiche le contenu attendu. Un autre test, sur un autre navigateur, un autre réseau, ou en mode incognito, mène ailleurs: vers une page de type spam, une landing commerciale, un faux formulaire, parfois même une page de téléchargement.

Dans certains cas, le site n’illustre pas directement la redirection. Il peut servir une page avec une portion de script injecté, un iframe caché, ou un code qui modifie la navigation après quelques secondes. La page semble normale au premier coup d’œil, mais au chargement complet, le navigateur bascule vers la destination malveillante.

Ce comportement a un avantage pour l’attaquant: il limite le nombre de signalements et rend le diagnostic plus pénible. Le webmaster ne voit rien sur son poste. Les crawlers “basiques” peuvent aussi être trompés. Et si vous cherchez uniquement dans vos fichiers “visibles”, vous https://gardewp.fr/ passez à côté.

Pourquoi les scanners ne suffisent pas seuls

Les outils automatisés sont utiles, mais ils ont des limites. Un scanner peut détecter des signatures connues, des chaînes typiques, des fichiers modifiés, ou des patterns d’obfuscation. Mais une infection réussie est parfois polymorphe, ou générée dynamiquement. Elle peut aussi résider dans des endroits moins classiques, par exemple dans des options WordPress, des entrées en base, ou des fichiers qui ne sont pas “malicieux” au sens strict mais qui exécutent du code à certains moments.

J’ai déjà vu des cas où:

le scanner retournait “rien à signaler”, alors que l’exploit était déclenché uniquement par un agent utilisateur précis; le scanner pointait un fichier suspect, mais la vraie redirection venait d’une valeur stockée en base, modifiée par le même acteur; plusieurs plugins “propres” avaient été touchés indirectement, via des hooks ou des filtres, sans que le binaire soit clairement corrompu.

Un bon réflexe consiste à traiter le scanner comme un radar. Il indique des zones où regarder, pas forcément une preuve finale. La preuve, c’est l’observation du comportement et la vérification des sources.

Comprendre le mécanisme des redirections invisibles

Les redirections invisibles s’appuient souvent sur des combinaisons: injection de code, conditions de déclenchement, et masquer la trace côté front.

Sur WordPress, les voies fréquentes passent par:

des fichiers modifiés dans le thème ou dans des dossiers “attendus” mais rarement surveillés; des ajouts dans des champs de base, par exemple des options, des métadonnées d’articles, ou des templates forcés; des scripts injectés via des hooks, parfois dans des plugins qui semblent légitimes; une logique qui ne s’active que pour certains visiteurs, ce qui rend la détection manuelle plus difficile.

Le détail qui fait la différence, c’est la condition. Si la redirection dépend de l’empreinte navigateur, du referer, de l’URL d’entrée, ou d’un cookie, un test “au hasard” ne suffira pas.

J’ai eu un incident où la redirection ne se déclenchait que lorsque la requête contenait un paramètre très spécifique, ajouté automatiquement par une campagne. Sur le poste du webmaster, sans cette campagne, tout semblait normal.

Les indicateurs qui doivent vous pousser à investiguer

Avant même de lancer un scanner malware WordPress, il faut repérer les signaux. Le plus important, ce n’est pas “un symptôme”, mais un ensemble: une anomalie et un doute sur la source.

Voici les signaux que je prends au sérieux, car ils collent souvent à une injection conditionnelle ou à une modification de sortie:

une hausse soudaine du nombre de pages vues sur des URL qui ne correspondent pas à votre trafic habituel des traces de redirections ou d’erreurs 302/307 dans des logs serveur, surtout sur des pages “ordinaires” des changements invisibles côté HTML, par exemple un script ajouté en fin de page, ou une modification de contenu au moment où le navigateur “termine” le rendu des alertes dans la Search Console ou des messages “harmful site” liés à une fraction des pages des comportements différents selon les appareils: mobile et desktop pas identiques, ou navigateur précis seulement

Si vous voyez au moins un ou deux de ces points, vous avez suffisamment de matière pour investiguer. Si tout est totalement stable et que les logs montrent rien, lancer un scanner peut coûter du temps sans vous rapprocher de la vérité.

Préparer un diagnostic propre avant de “nettoyer”

Avant de supprimer des fichiers ou de réinstaller des plugins, j’aime garder un cadre de travail. Le risque, sinon, est d’effacer ce qui servirait à comprendre l’origine et de ne pas identifier l’entrée initiale.

La préparation passe par trois actions simples, que je fais presque systématiquement: 1) isoler le site de test, idéalement via un clonage ou au minimum une copie de travail (fichiers et base); 2) collecter des exemples d’URLs qui provoquent la redirection, et noter dans quel navigateur et quel contexte; 3) récupérer des logs applicatifs ou serveur, au moins pour les périodes où l’anomalie a été observée.

À ce stade, vous gagnez énormément en efficacité. Vous n’attaquez plus “un malware”, vous analysez un mécanisme.

Mettre en place une vérification côté navigateur, sans tomber dans les faux positifs

Un piège courant est de se contenter du HTML affiché “source”. Sur certains cas, le code malveillant peut être déclenché après coup, par un script, ou par un chargement différé. D’autres fois, le HTML de la page “source” n’expose rien, car la redirection s’effectue au niveau du navigateur par remplacement de fenêtre, navigation forcée, ou injection dans le DOM.

Donc, je recommande une approche de test progressive:

comparer le comportement sur deux navigateurs différents, idéalement un plus ancien si vous avez le doute d’un ciblage; tester en navigation privée, pour contrôler les cookies; vérifier si la redirection se produit immédiatement ou après quelques secondes, car cela change la probabilité d’un déclencheur par chargement de ressource.

Je fais aussi attention aux erreurs d’interprétation: une redirection peut venir de votre cache, de votre CDN, ou d’une règle de sécurité. Si l’infection est réelle, la redirection “malveillante” a souvent une signature unique: domaine externe, chaîne de requête suspecte, ou contenu clairement non associé à votre activité.

Lancer un scanner malware WordPress, puis exploiter ses sorties avec méthode

Le scanner est utile pour deux choses: repérer des fichiers modifiés et détecter des signatures ou de l’obfuscation. Mais pour que cela serve à quelque chose, il faut travailler les résultats comme un dossier d’enquête.

Je procède en général de cette façon:

je classe les alertes par emplacement (fichiers du thème, du plugin, racine WordPress, mu-plugins, dossiers uploads); je regarde la date de modification des fichiers quand c’est disponible dans l’outil, et je la compare à vos périodes de maintenance; je cherche des chaînes typiques d’injection, par exemple base64, eval, gzinflate, concaténations, ou appels à des fonctions qui construisent des URLs à la volée.

Attention aussi à la “bruiterie”. Les scanners peuvent signaler des faux positifs sur des bibliothèques minifiées, des scripts de tracking, ou des composants de thèmes qui embarquent des obfuscations. Ce n’est pas automatique, mais ça arrive. Dans le doute, je préfère confirmer par observation du comportement et par corrélation des changements.

Quand le scanner identifie un fichier suspect, je ne supprime pas immédiatement. Je capture son contenu (au moins la partie concernée), puis je l’analyse: quel hook, quelle condition, quel point d’exécution. C’est là que vous comprenez si vous avez affaire à une redirection invisibile via une logique front ou une redirection serveur.

Et si le scanner ne trouve rien d’évident, ce n’est pas une fin. Ça veut souvent dire que la charge est dans la base, dans un paramètre, ou dans un fichier qui n’est pas reconnu par la signature utilisée.

Là où ça se cache souvent: options, templates et métadonnées

Les redirections invisibles ne vivent pas forcément dans des fichiers “lisibles”. Sur WordPress, beaucoup de mécanismes reposent sur des valeurs en base, et un attaquant peut injecter du code ou forcer des comportements via des options.

Quand je suspecte une infection par redirection conditionnelle, je cherche notamment:

des options contenant des scripts ou des fragments HTML; des filtres ajoutés via des hooks, parfois déclenchés sur wp_head ou wp_footer; des éléments de thème qui récupèrent une valeur et l’affichent sans échappement correct.

Un symptôme fréquent, c’est que l’HTML renvoyé contient un fragment ajouté à la page, souvent discret. Si vous examinez le code généré en fin de rendu, vous pouvez y voir une balise script ajoutée, ou un comportement sur un appel à navigation.

Même si vous n’êtes pas à l’aise avec la lecture brute SQL, vous pouvez analyser la sortie HTML et remonter à la source côté serveur. C’est plus fiable que de supposer.

Corréler avec les logs: le raccourci qui évite les longues semaines de doute

Les logs, quand ils sont disponibles, font gagner un temps énorme. Ils vous indiquent sur quelles URL la redirection s’est déclenchée et à quel moment. Ils peuvent aussi montrer le statut HTTP.

Sur une redirection “invisible”, vous voyez souvent un 302 ou 307 à un moment, ou une série de requêtes vers une ressource externe. Si votre site est derrière un reverse proxy ou un CDN, la granularité dépend de votre configuration, mais même des logs partiels sont utiles.

Je regarde aussi les patterns:

mêmes URL d’entrée, destinations variables l’apparition d’un domaine externe en destination sur une page que vous n’avez jamais liée des erreurs 404 en cascade sur des chemins “bizarres”, parfois liés à une tentative de reconnaissance avant injection

Avec une corrélation simple, vous pouvez réduire votre champ de recherche. Sans logs, on “traque” un fantôme.

Deux voies de nettoyage, selon ce que vous avez trouvé

Le nettoyage ne doit pas être une punition aveugle. Il doit coller à la nature de l’infection.

Si votre analyse montre un fichier modifié dans un thème ou un plugin, la voie la plus saine consiste à:

restaurer le fichier depuis une version officielle saine; vérifier que le même contenu ne revient pas après activation; inspecter ce qui a donné les permissions pour modifier le système (identifiants, plugin vulnérable, mauvaise politique de mots de passe, fichiers uploads exécutables, etc.).

Si l’attaque est plus “insidieuse”, par exemple injection via base ou option, vous devez aussi purger les valeurs, pas seulement les fichiers. Et surtout, vous devez identifier le point d’entrée initial.

J’ai vu des sites “réparés” en supprimant le script visible, puis infectés à nouveau deux jours plus tard, parce que l’attaquant conservait une trappe dans une option de base ou dans un fichier qu’il régénérait à chaque visite.

Donc le bon nettoyage combine:

la restauration de la partie compromise, la suppression de la persistance, et la fermeture des portes d’entrée.

Un exemple concret: redirection déclenchée sur un profil de visiteur

Prenons un scénario typique. Vous avez un article A. Pour vous, la page affiche normalement. Pourtant, quelqu’un vous signale être arrivé sur un domaine externe après avoir ouvert l’article sur mobile.

Vous testez:

en navigation privée, sur mobile, vous constatez une redirection après environ 4 à 7 secondes sur desktop, rien ne se produit dans la barre d’adresse, vous voyez que la destination finale est un domaine qui n’a rien à voir avec votre activité

Votre scanner repère un fragment dans un fichier de thème, pas au niveau de functions.php en clair, mais dans un petit fichier chargé en cascade. La charge est obfusquée, et elle ne s’exécute qu’avec une condition liée au user agent.

Dans ce cas, la correction n’est pas seulement de “supprimer la ligne”. Il faut:

restaurer le thème à la version saine, puis chercher d’éventuelles charges en base qui pourraient remplacer le fichier modifié après restauration; vérifier que le plugin que vous utilisez, celui qui “rassemble” des scripts dans le thème, n’a pas été compromis à l’origine.

Le piège, c’est de croire que l’infection réside toujours dans un seul fichier. En réalité, la persistance peut être en plusieurs points.

Comment tester sans vous piéger: méthode de confirmation

À ce stade, je recommande une confirmation par étapes, parce que les “preuves” faibles créent souvent des erreurs.

Voici la seule mini check list que j’utilise en urgence, quand une redirection invisible est suspectée:

comparer le HTML généré avec et sans votre navigateur habituel, en regardant surtout les balises script ajoutées surveiller le réseau dans les outils développeur, et identifier une requête ou un document déclencheur vers un domaine externe vérifier les statuts HTTP (302, 307) et la destination finale, pas seulement l’écran visible recouper les logs serveur sur une fenêtre de temps courte avec l’URL d’entrée faire tourner un scanner malware WordPress, puis confronter les résultats à ce que vous observez dans le rendu

Si les observations et le scanner convergent, vous avez un diagnostic solide. Si ça diverge, vous continuez à analyser, sinon vous risquez de corriger un faux positif.

Quand le scanner ne trouve rien: hypothèses plausibles

C’est fréquent, et ce n’est pas forcément une bonne nouvelle. Si le scanner ne révèle rien, plusieurs hypothèses sont réalistes:

l’injection est stockée en base, et le scanner ne scanne pas suffisamment l’existant; l’obfuscation est “sur mesure” et ne correspond pas aux signatures connues; le déclencheur est une condition rare, par exemple un referer précis, un cookie spécifique, ou un fragment d’URL; un composant de votre chaîne (cache, CDN, reverse proxy) ajoute la redirection, et ce n’est pas WordPress à proprement parler.

Dans ces situations, l’approche la plus efficace consiste à se concentrer sur le comportement observé dans le navigateur et à remonter vers la source serveur. Une inspection https://gardewp.fr/nettoyage-malware-wordpress/ du flux réseau, combinée à la comparaison du rendu entre profils de visiteurs, donne souvent une piste plus fiable que la seule signature.

Durcir après la correction, sans transformer WordPress en bunker

Une fois que tout est propre, la meilleure protection, c’est de rendre l’entrée beaucoup plus coûteuse. On ne cherche pas la perfection, on cherche à réduire la probabilité qu’un attaquant réussisse la prochaine fois.

Il y a un équilibre entre sécurité et maintenance. Trop de restrictions cassent des workflows. Pas assez, et vous revenez au même point.

Je traite la remise en sécurité comme un ensemble cohérent:

renforcer l’authentification, limiter les identifiants faibles et les utilisateurs inutiles; vérifier les plugins et thèmes, supprimer ceux que vous n’utilisez pas; sécuriser l’accès à l’administration et surveiller les changements de fichiers; mettre en place une surveillance régulière du comportement, pas uniquement du système de fichiers.

Si vous avez déjà eu une redirection invisible, je vous conseille de garder un protocole de test. Un simple test automatisé, ou même une routine manuelle sur vos URL critiques, peut détecter une récidive avant que le référencement n’encaisse le coup.

Une seconde check list, pour éviter les erreurs classiques de “débogage”

Voici l’autre liste courte, celle que j’utilise quand le nettoyage est terminé et que je veux vérifier que la persistance est vraiment coupée:

tester les URL touchées en navigation privée et sur un navigateur différent vérifier l’absence de scripts suspects dans le HTML rendu (surtout en fin de page) contrôler les domaines de redirection dans les requêtes réseau, aucune ressource externe non justifiée re-lancer un scanner malware WordPress après restauration, pour voir s’il reste des traces surveiller les logs pendant une période (quelques jours) pour confirmer que la redirection n’a pas réapparu

Cette étape évite le scénario “on a supprimé le symptôme, l’attaquant a gardé la mécanique”.

Pièges et cas limites que je rencontre souvent

Il y a des situations où “redirection invisible” peut être confondue avec des mécanismes légitimes.

Par exemple:

une redirection liée au consentement cookies, certains scripts peuvent changer la navigation après acceptation; un paramétrage de cache au niveau CDN qui route des URLs selon des règles internes; un plugin SEO ou de tracking qui déclenche des comportements spécifiques selon l’état du navigateur.

C’est pour ça que je privilégie la combinaison de trois preuves: observation du comportement, corrélation logs, et analyse des fichiers ou valeurs modifiées. Aucun élément seul ne suffit.

Autre cas limite: les infections partielles. Parfois, seul un sous-ensemble d’URL est affecté, ou seule une catégorie de visiteurs est ciblée. Vous pouvez penser que le site est revenu à la normale, alors qu’une page encore infectée reste exploitable, et elle nourrit l’attaque.

Si vous vous occupez d’un site à fort trafic, ce genre de “restes” finit vite par se voir, ne serait-ce que par les variations de taux de clic ou par des plaintes utilisateurs.

Choisir le bon moment pour la chasse aux redirections

Il vaut mieux agir vite, mais pas dans la précipitation qui efface la preuve. Je préfère sécuriser l’accès, mettre de côté les éléments d’analyse, puis corriger. Si vous supprimez tout immédiatement sans copie, vous perdez la possibilité de comprendre d’où vient le déclencheur.

L’ordre que je privilégie, c’est:

observer et reproduire la redirection, collecter l’info réseau et les logs, lancer le scanner et l’exploiter, restaurer ce qui est corrompu, puis valider avec des tests comparatifs.

Le temps de traitement varie selon la taille du site et le niveau d’accès, mais la méthode évite les allers-retours.

Ce que vous pouvez faire dès maintenant, sans casser votre site

Si vous suspectez des contenus redirigés invisibles, vous pouvez commencer par des actions qui ne nécessitent pas d’être “administrateur WordPress expert”.

Faites un test en navigation privée, sur deux navigateurs différents, et observez si une redirection se produit avec un délai. Examinez le réseau dans les outils développeur, cherchez une requête vers un domaine externe non attendu. Notez précisément l’URL d’entrée, l’URL de destination, et le moment où ça arrive. Lancez un scanner malware WordPress, puis concentrez-vous sur les alertes qui correspondent aux pages ou fichiers impliqués dans votre observation.

Si vous tombez sur une piste claire (fichier modifié ou option de base suspecte), la suite consiste à restaurer et valider, pas à “nettoyer au feeling”.

Les redirections invisibles sont difficiles à attraper parce qu’elles ont été conçues pour éviter vos diagnostics habituels. Pourtant, elles laissent des traces, dans le navigateur, dans les logs, et dans ce que WordPress renvoie quand il croit servir un visiteur “cible”.

Un scanner malware WordPress est un point de départ sérieux, à condition de le traiter comme une enquête, pas comme un jugement final. La vraie victoire, c’est la convergence entre le comportement observé et la source identifiée, puis la suppression de la persistance pour que l’attaque ne revienne pas dès le lendemain.