--- title: "Cloaking WordPress nouvelle génération : quand un malware ne montre son vrai visage qu’à Googlebot (IP vérifiée)" url: "https://helloblog.io/fr/cloaking-wordpress-malware-googlebot-ip-verifiee/" date: "2026-01-13" modified: "2026-01-20" author: "Aminata Diallo" language: "fr_FR" categories: ["Sécurité"] tags: ["Cloaking", "Googlebot", "Malware", "SEO", "WordPress"] featured_image: "https://helloblog.io/app/uploads/sites/4/2026/01/featured-3-1024x572.jpg" excerpt: "Certains malwares WordPress ne se contentent plus d’une redirection grossière : ils servent un contenu externe uniquement aux crawlers Google, en vérifiant l’IP via des plages ASN en CIDR. Résultat : toi tu vois ton site, Google indexe autre chose." --- # 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. ``` ## 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. ``` ## 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. #### Point notable sur l’infrastructure observée Selon l’analyse citée, le domaine `amp-samaresmanor[.]pages[.]dev` était détecté par des vendors sur VirusTotal et plusieurs sites auraient été trouvés infectés au moment de l’écriture. Ça souligne l’intérêt de surveiller les connexions sortantes et les domaines externes appelés depuis le front. ## 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. ![Schéma illustrant une logique conditionnelle basée sur la vérification IP](https://helloblog.io/app/uploads/sites/4/2026/01/IP-Verified-Conditional-Logic.png) *Le contenu malveillant n’est servi qu’aux visiteurs dont l’identité est validée (crawler + IP). — *Forrás: Sucuri Blog** ![Capture montrant une différence entre ce que Google voit et ce que les visiteurs voient](https://helloblog.io/app/uploads/sites/4/2026/01/What-Google-sees.png) *Exemple de cloaking : Google indexe un contenu différent de celui affiché aux visiteurs humains. — *Forrás: Sucuri Blog** ![Illustration du format CIDR pour représenter des plages IP](https://helloblog.io/app/uploads/sites/4/2026/01/CIDR-format.png) *Le CIDR sert à décrire des blocs d’adresses IP de façon compacte. — *Forrás: Sucuri Blog** ![Diagramme montrant une vérification multi-couches User-Agent puis IP](https://helloblog.io/app/uploads/sites/4/2026/01/Multi-Layer-Identity-Verification.png) *User-Agent + validation IP : une stratégie plus difficile à contourner. — *Forrás: Sucuri Blog** ![Schéma illustrant la validation d’adresse IP via opérations bitwise](https://helloblog.io/app/uploads/sites/4/2026/01/Bitwise-IP-Range-Validation.png) *Les opérations bitwise permettent de tester l’appartenance à un bloc réseau (CIDR). — *Forrás: Sucuri Blog** ![Schéma montrant la récupération d’un payload distant via cURL](https://helloblog.io/app/uploads/sites/4/2026/01/Remote-Payload-Execution-via-cURL.png) *Le payload est récupéré à distance puis renvoyé comme si le site l’hébergeait. — *Forrás: Sucuri Blog** ![Exemple de filtrage User-Agent pour différents services Google](https://helloblog.io/app/uploads/sites/4/2026/01/User-Agent-Filtering.png) *Le script cible plusieurs User-Agents liés à l’écosystème Google, pas uniquement Googlebot. — *Forrás: Sucuri Blog** ![Diagramme illustrant la logique conditionnelle et le logging d’erreurs](https://helloblog.io/app/uploads/sites/4/2026/01/Conditional-Logic-and-Error-Logging.png) *Logique : bot légitime → payload, bot fake → redirection + log, humain → site normal. — *Forrás: Sucuri Blog** ## Références / Sources - [Malware Intercepts Googlebot via IP-Verified Conditional Logic](https://blog.sucuri.net/2026/01/malware-intercepts-googlebot-via-ip-verified-conditional-logic.html) - [Google Sees Spam, You See Your Site: A Cloaked SEO Spam Attack](https://blog.sucuri.net/2026/01/google-sees-spam-you-see-your-site-a-cloaked-seo-spam-attack.html) - [VirusTotal URL report](https://www.virustotal.com/gui/url/5a006beedf563c6215a31746d011d13fd4f2561a1bf3b557484c4532b13e1ec6?nocache=1) - [PublicWWW – amp-samaresmanor.pages](https://publicwww.com/websites/amp-samaresmanor.pages/) - [Sucuri Website Firewall](https://sucuri.net/website-firewall/) - [Sucuri Malware Detection & Scanning (File Integrity Monitoring)](https://sucuri.net/malware-detection-scanning/)