Cloaking WordPress nouvelle génération : quand un malware ne montre son vrai visage qu’à Googlebot (IP vérifiée)

On a tous déjà croisé du cloaking SEO (contenu différent selon l’audience) sur WordPress : du spam visible dans Google, mais invisible quand on visite le site « normalement ». Ce qui change dans les campagnes récentes, c’est le niveau de précision. Là où beaucoup d’attaquants se contentent d’un filtre sur le User-Agent, certains scripts vont jusqu’à vérifier que le visiteur est bien Googlebot… en validant son adresse IP contre des plages officielles de Google.

Dans un cas analysé par Sucuri, l’infection se trouvait directement dans index.php à la racine WordPress. Le fichier jouait le rôle de gatekeeper : selon l’identité du visiteur, il chargeait WordPress de façon normale ou injectait un contenu distant destiné aux robots d’indexation.

Le scénario : WordPress « propre » pour toi, contenu injecté pour Google

Le principe est simple sur le papier : masquer l’infection à l’admin du site et aux visiteurs humains, tout en exposant un contenu différent aux crawlers. Dans l’exemple étudié, Google se retrouvait à indexer une page qui n’était pas réellement servie par le site, mais récupérée à la volée depuis une URL externe, puis renvoyée comme si elle provenait du domaine compromis.

Ce type d’attaque vise principalement la réputation SEO : pages parasites dans l’index, dégradation des résultats, risque de blacklist, et détection retardée (puisque le propriétaire ne voit rien d’anormal lors de ses visites).

Ce qui rend ce malware intéressant : la vérification IP via ASN + CIDR

Beaucoup de scripts de cloaking font un test fragile du type « si HTTP_USER_AGENT contient Googlebot ». Problème : un User-Agent se falsifie en une seconde. Dans le cas présenté, l’attaquant a ajouté une seconde barrière : une bibliothèque en dur de plages IP appartenant à Google, associées à l’ASN (Autonomous System Number) de Google, au format CIDR.

ASN (Autonomous System Number) : l’« identité réseau » de Google

Un ASN représente un ensemble de blocs IP contrôlés par une entité (ici Google) et utilisés par ses services et son infrastructure. Vérifier que la requête provient d’une plage IP associée à l’ASN de Google permet de distinguer un vrai crawler issu de l’infra Google d’un bot qui imite simplement un User-Agent.

CIDR : décrire un bloc d’IP sans tout lister

Le CIDR est une notation compacte pour représenter une plage d’adresses. Exemple classique : 192.168.1.0/24. Le suffixe (/24) indique la taille du bloc et les adresses incluses. C’est le format standard qu’on retrouve partout : ACL réseau, firewall, routage, allowlists, etc.

Le détail qui fait mal : calculs bitwise (et support IPv6) بدل du simple « match »

Autre point marquant : la validation de plage IP ne se faisait pas via un test de chaîne ou une comparaison naïve, mais via des opérations bitwise (ET binaire) sur l’IP et un masque réseau. C’est une approche plus « bas niveau » : le script calcule mathématiquement si l’adresse du visiteur appartient au bloc CIDR attendu.

Sucuri note aussi la présence d’une prise en charge robuste d’IPv6, souvent ignorée par des scripts plus anciens. En pratique, ça réduit encore la surface de détection via des tests manuels classiques.

// Logique rapportée : appartenance à un réseau via masque
// ($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal)
// L'idée : après conversion en entier, on applique le masque et on compare.

// Logique rapportée : appartenance à un réseau via masque
// ($ip_decimal & $netmask_decimal) == ($range_decimal & $netmask_decimal)
// L'idée : après conversion en entier, on applique le masque et on compare.

Anatomie du flux d’infection (vu côté serveur)

Dans le index.php compromis, la décision se fait en plusieurs étapes, de façon assez défensive (du point de vue de l’attaquant) :

1. Filtrage initial via HTTP_USER_AGENT : recherche de chaînes liées à Googlebot, mais aussi à des outils de vérification/inspection et à certains crawlers/API Google.
2. Vérification IP « réelle » : test d’appartenance à des plages ASN Google en CIDR via des opérations bitwise, avec support IPv4 et IPv6.
3. Si (User-Agent + IP) = OK : récupération d’un payload distant et injection directe dans la réponse HTTP (le crawler pense que le site héberge ce contenu).
4. Si l’appel distant échoue : redirection vers /home/ pour éviter que Google indexe une page cassée.
5. Si User-Agent Google mais IP non valide : le script logge un événement de type « fake bot » puis renvoie vers la home légitime.
6. Sinon (utilisateurs normaux) : redirection immédiate vers la home, sans exposition du contenu malveillant.

Récupération de contenu distant via cURL

Une fois le visiteur « certifié » comme Google, le script va chercher du contenu externe via cURL, puis l’affiche tel quel. L’URL observée dans ce cas était : hxxps://amp-samaresmanor[.]pages[.]dev.

// Exemple de comportement décrit : fetch distant + echo
// (l'URL est volontairement neutralisée)
$url = 'hxxps://amp-samaresmanor[.]pages[.]dev';

// cURL récupère le contenu distant…
// … puis il est renvoyé dans la réponse pour le crawler.

// Exemple de comportement décrit : fetch distant + echo
// (l'URL est volontairement neutralisée)
$url = 'hxxps://amp-samaresmanor[.]pages[.]dev';

// cURL récupère le contenu distant…
// … puis il est renvoyé dans la réponse pour le crawler.

Pourquoi modifier index.php est particulièrement stratégique

Toucher à index.php (entrée principale) permet de contrôler une grande partie du trafic avant même que WordPress ne rende la page. Dans ce cas, le code malveillant s’appuyait aussi sur des fichiers cœur pour garder une apparence de normalité :

• wp-load.php : inclus pour « bootstrapper » l’environnement WordPress (accès config + base), via un require_once depuis le script.
• wp-blog-header.php : fichier normalement requis à la fin de l’index.php standard, ce qui aide à préserver le rendu attendu pour les visiteurs non ciblés.

Signaux d’alerte : ce qui doit te mettre la puce à l’oreille

Le piège de ce cloaking, c’est que la navigation normale peut sembler parfaitement saine. Les indicateurs les plus utiles sont souvent indirects :

• Résultats Google incohérents (snippets étranges, pages inconnues, spam, langues inattendues).
• Fichiers récemment modifiés, en particulier à la racine (index.php) et dans wp-includes/wp-admin.
• URLs suspectes (dans le code, dans les logs, ou visibles via des outils d’analyse).
• Logs serveur « bizarres » : redirections conditionnelles, accès répétés par bots, erreurs applicatives corrélées.

Nettoyage et prévention : les mesures qui comptent vraiment

Sur ce type d’infection, il faut traiter à la fois le symptôme (le fichier modifié) et la cause (le point d’entrée). Les actions recommandées dans la source couvrent l’essentiel :

1. Supprimer les fichiers/dossiers non reconnus (et pas seulement « commenter » le code suspect).
2. Auditer les comptes WordPress : retirer tout admin inattendu (y compris les comptes « support » ajoutés discrètement).
3. Réinitialiser les identifiants : WordPress, FTP/SFTP, panel d’hébergement, base de données.
4. Scanner la machine locale (poste du dev/admin) : un vol d’identifiants peut réinfecter le site immédiatement.
5. Mettre à jour WordPress, thèmes et plugins (et éliminer les extensions abandonnées).
6. Ajouter un WAF (Web Application Firewall) pour réduire les uploads malveillants et bloquer des communications vers des serveurs de commande (C2).
7. Mettre en place une surveillance d’intégrité des fichiers (File Integrity Monitoring) pour détecter toute modification non autorisée de fichiers cœur comme index.php.

À retenir

On n’est plus face à des redirections grossières ou à des injections visibles à l’œil nu. Ici, l’attaquant exploite la confiance des moteurs en ne montrant son contenu qu’à une infrastructure Google réellement vérifiée (User-Agent + IP ASN, IPv4/IPv6, bitwise matching), tout en laissant une expérience parfaitement normale aux visiteurs humains.

Dans ce contexte, les réflexes « dev » redeviennent des réflexes sécurité : contrôle d’intégrité, revue des modifications de fichiers sensibles, surveillance de l’indexation via Google Search Console et analyse des sorties réseau côté serveur.