Comment détecter une injection de code et limiter les dégâts sur votre site infecté ?

Pourquoi Search Console est-il le point de départ d'une détection d'injection ?

Search Console centralise les alertes de sécurité remontées par le système de détection automatique de Google. Quand le crawler identifie du code suspect, du cloaking ou des redirections malveillantes, il signale les URLs concernées dans la section Sécurité et actions manuelles.

Le premier réflexe consiste donc à vérifier cette propriété pour obtenir une liste initiale des pages compromises. C'est un gain de temps considérable plutôt que de scanner manuellement des milliers de pages. Mais attention : cette liste n'est jamais exhaustive au moment où vous la consultez.

Pourquoi wget ou curl sont-ils indispensables pour confirmer l'infection ?

Les injections de code modernes détectent souvent le user-agent de Googlebot et masquent le contenu malveillant aux navigateurs classiques. Vous pouvez voir une page propre dans Chrome alors que Google crawle du spam pharmaceutique.

wget ou curl permettent de récupérer le code source brut tel qu'il est servi au robot, sans interprétation JavaScript ni cache navigateur. C'est le seul moyen de constater ce que Google voit réellement. Si vous trouvez des scripts obfusqués, des iframes cachés ou des liens externes suspects, vous tenez votre confirmation.

Que signifie explorer le système de fichiers pour évaluer les dégâts ?

Une fois l'injection confirmée côté front, il faut remonter à la source dans l'arborescence serveur. Les fichiers .htaccess modifiés, les scripts PHP injectés dans le thème WordPress, les bibliothèques JavaScript compromises : tout doit être audité.

Cette phase d'exploration révèle l'ampleur réelle de l'attaque. Certaines injections ne touchent que quelques templates, d'autres infectent la base de données ou créent des milliers de pages fantômes dans des répertoires cachés. Sans cette cartographie complète, vous risquez de nettoyer en surface et de laisser la porte ouverte à une réinfection immédiate.

• Search Console fournit la liste initiale des URLs compromises détectées par Google
• wget ou curl confirment l'injection en récupérant le code source réel servi au crawler
• L'exploration serveur identifie tous les fichiers modifiés ou ajoutés par l'attaque
• Le délai entre infection et détection peut laisser le temps à l'attaquant de multiplier les points d'entrée
• Ne jamais se fier uniquement à l'affichage navigateur : le cloaking fausse complètement le diagnostic

Cette méthodologie est-elle suffisante face aux injections récentes ?

La procédure décrite par Google reste valide comme point de départ, mais elle suppose que l'injection soit déjà détectée. Or, les techniques d'obfuscation modernes retardent cette détection de plusieurs jours, voire semaines. Pendant ce temps, votre site sert du spam, perd des positions et accumule des sanctions manuelles.

Les injections les plus sophistiquées ciblent désormais des fichiers légitimes rarement audités : bibliothèques JavaScript tierces, plugins abandonnés, fichiers de cache. Wget seul ne suffit plus si le code malveillant est chargé de manière conditionnelle selon l'IP ou le référent. [A vérifier] : Google ne précise pas comment gérer les injections qui ne se déclenchent que pour certains segments de trafic.

Quelles sont les limites de Search Console dans ce contexte ?

Search Console ne remonte que les URLs que Googlebot a effectivement crawlées ET analysées comme suspectes. Si votre site compte 50 000 pages et que seules 200 sont crawlées par semaine, une injection récente peut rester invisible pendant des mois dans les sections non prioritaires.

Pire : les attaquants créent souvent des milliers de pages orphelines avec noindex initial, puis basculent en index après quelques jours. Ces pages n'apparaissent jamais dans Search Console avant d'avoir causé des dégâts. Il faut donc croiser avec les logs serveur et un monitoring actif des modifications de fichiers.

Le nettoyage seul résout-il le problème de fond ?

Nettoyer l'injection sans corriger la faille de sécurité initiale garantit une réinfection rapide. La plupart des infections WordPress exploitent des plugins obsolètes ou des thèmes piratés. Supprimer le code malveillant sans patcher le CMS revient à laisser la porte ouverte.

Concrètement, l'exploration du système de fichiers doit identifier non seulement les fichiers modifiés, mais aussi les vecteurs d'entrée : permissions 777 abusives, formulaires sans CSRF token, upload de fichiers non validés. Sans cette analyse, vous perdrez des jours à nettoyer en boucle le même site. Et le temps perdu, c'est du trafic et des revenus qui partent.

Que faut-il faire immédiatement après la détection d'une injection ?

Première action : isoler le site si l'infection est massive. Passer temporairement en maintenance pour stopper la diffusion de contenu malveillant limite les pénalités Google. Simultanément, exportez tous les logs serveur des 30 derniers jours pour tracer le point d'entrée initial.

Ensuite, utilisez wget avec le user-agent Googlebot sur un échantillon d'URLs signalées dans Search Console. Comparez le code source obtenu avec ce que votre navigateur affiche. Si vous constatez des différences significatives, le cloaking est confirmé et l'attaque est probablement plus étendue que ce que Google a détecté.

Comment cartographier précisément l'étendue des dégâts ?

Connectez-vous en SSH et lancez une recherche récursive des fichiers modifiés récemment : find . -type f -mtime -7 pour les 7 derniers jours. Croisez cette liste avec un diff par rapport à une sauvegarde propre si vous en avez une. Les fichiers suspects présentent souvent des timestamps identiques ou des noms génériques : config.php, loader.php, cache.tmp.

Analysez également la base de données : les injections dans WordPress ciblent fréquemment wp_posts pour insérer des liens cachés ou wp_options pour modifier les règles de réécriture. Un simple SELECT cherchant 'eval(', 'base64_decode(' ou 'gzinflate(' révèle 80% des infections courantes. Les attaquants ne font pas toujours dans la subtilité.

Quelles erreurs éviter pendant le nettoyage et la récupération ?

Ne supprimez jamais de fichiers avant d'avoir documenté leur présence et leur contenu. Vous aurez besoin de ces preuves pour comprendre le vecteur d'attaque et éviter une réinfection. Beaucoup de SEO paniquent et effacent tout, puis se retrouvent avec le même problème la semaine suivante.

Autre piège : restaurer une sauvegarde trop ancienne. Si votre backup date d'avant l'infection mais aussi d'avant plusieurs mises à jour de sécurité, vous réintroduisez les failles initiales. Préférez un nettoyage chirurgical fichier par fichier avec validation manuelle.

• Vérifier Search Console quotidiennement pour détecter les nouvelles URLs compromises
• Tester les pages suspectes avec wget et le user-agent Googlebot pour confirmer le cloaking
• Identifier les fichiers modifiés récemment avec find et comparer avec une version propre
• Rechercher dans la base de données les patterns d'obfuscation classiques (base64, eval, gzinflate)
• Patcher immédiatement le vecteur d'entrée avant de nettoyer le code malveillant
• Soumettre une demande de réexamen dans Search Console après nettoyage complet