Pourquoi nous bloquons les « pages blanches » et redirigeons vers les sites officiels : Le problème du cloaking expliqué
Le cloaking, les pages blanches et les redirections TDS constituent la colonne vertébrale des infrastructures modernes de phishing. Tout site qui y a recours est banni. Voici pourquoi — et ce que nous découvrons en levant le voile sur ces pratiques.
La question qu'on nous pose sans cesse
Chaque semaine, on nous adresse la même demande : « Vous avez signalé mon domaine, mais quand je le vérifie, il redirige simplement vers le site officiel. Il n'y a rien de malveillant ici. »
Ou encore une variante : « Cette page n'est qu'un article de blog sur les cryptomonnaies. Il ne s'agit pas d'une tentative d'hameçonnage. »
Nous comprenons que cela puisse prêter à confusion. Si vous consultez un domaine qui a été signalé et que vous tombez sur une page tout à fait normale — ou sur une redirection sans problème vers un site légitime —, il est naturel de penser que le signalement est erroné. Mais cette page sans problème n'est pas le résultat d'un bug dans notre système de détection. C'est l'attaque.
Cet article explique la technologie qui sous-tend le cloaking, pourquoi les « pages blanches » existent, comment les systèmes de répartition du trafic (TDS) tels que Keitaro acheminent les victimes, et pourquoi PhishDestroy considère chacun de ces schémas comme une infrastructure malveillante avérée — sans aucune exception.
Si vous lisez ce message parce que votre nom de domaine a été signalé et que vous pensez qu'il s'agit d'une erreur, nous vous invitons à lire ce message jusqu'au bout. Nous tenons également à procédure d'appel pour les faux positifs légitimes. Mais d'après notre expérience, les domaines qui recourent au cloaking sont malveillants dans 100 % des cas.
Comment les systèmes antivirus ont changé la donne
Il y a dix ans, le phishing était simple. Un pirate enregistrait un nom de domaine, mettait en ligne une fausse page de connexion et envoyait le lien aux victimes. Les éditeurs de solutions de sécurité finissaient par explorer cette URL, repéraient la page de phishing et l'ajoutaient à leurs listes de blocage. Le domaine disparaissait en quelques heures ou quelques jours.
Puis, la situation s'est améliorée. Google Safe Browsing, Microsoft SmartScreen et plus d'une centaine de moteurs antivirus sur des plateformes telles que VirusTotal ont commencé à analyser les URL en temps quasi réel. Les avertissements au niveau du navigateur ont considérablement réduit les taux de clics. Les hébergeurs ont mis en place des processus automatisés de retrait. Le délai entre la mise en ligne d'une page de phishing et son blocage est passé de plusieurs jours à quelques minutes.
Les auteurs d'hameçonnage se trouvaient confrontés à un problème : leurs pages étaient détectées plus vite qu'ils ne parvenaient à les mettre en ligne. Ils avaient besoin d'un moyen de présenter leur contenu frauduleux à de véritables victimes tout en paraissant totalement inoffensifs aux yeux de tous les systèmes automatisés chargés de les détecter.
La réponse était camouflage.
Le phishing moderne passe inaperçu non pas parce que la page de phishing est difficile à repérer, mais parce que le scanner ne voit jamais la page de phishing. Le scanner détecte un article de blog, une redirection ou une page blanche. La victime — qui se connecte depuis un pays précis, sur un appareil mobile, via une publicité payante — voit s'afficher le programme de collecte d'identifiants.
Qu'est-ce que le cloaking, au juste ?
Le cloaking consiste à proposer un contenu différent selon les visiteurs, en fonction de leur profil. Dans le contexte du phishing, cela signifie une chose : Les scanners de sécurité détectent une page inoffensive, tandis que les véritables victimes voient la page de hameçonnage.
Le filtrage peut s'effectuer à plusieurs niveaux :
- Réputation IP — Les adresses IP de centres de données connus, les plages VPN et les blocs d'adresses IP des fournisseurs de solutions de sécurité reçoivent la version normale. Les adresses IP résidentielles reçoivent la page de hameçonnage.
- Chaînes User-Agent — Les navigateurs sans interface graphique, les robots d'indexation connus (Googlebot, Bingbot, Screaming Frog) et les outils de scan de sécurité sont identifiés et filtrés.
- Géolocalisation — La page de phishing n'est affichée qu'aux visiteurs provenant des pays ciblés. Tous les autres voient une page blanche.
- En-têtes Referrer — Seuls les visiteurs provenant de sources spécifiques (une annonce Google, un lien contenu dans un e-mail de hameçonnage, une publication sur les réseaux sociaux) voient le contenu réel.
- Identification par empreinte numérique — JavaScript vérifie la résolution de l'écran, les polices installées, le moteur de rendu WebGL, l'API de gestion de la batterie et d'autres indicateurs afin de distinguer les appareils réels des émulateurs.
- Règles basées sur le temps — La page de phishing n'est active qu'à certaines heures (par exemple, pendant les heures de bureau dans le fuseau horaire cible) ; en dehors de ces plages horaires, elle affiche par défaut une page blanche.
- Suivi des cookies et des sessions — Lors de la première visite, la page blanche s'affiche. Les visiteurs qui reviennent sur le site et qui possèdent un cookie spécifique (créé lors du clic sur la publicité) voient s'afficher la page de phishing.
Un dispositif de camouflage sophistiqué combine tous ces éléments. Il en résulte un domaine qui apparaît comme parfaitement sain à tous les scanners sur Internet, tout en dérobant activement les identifiants des victimes ciblées.
Lorsque VirusTotal analyse une URL masquée, il affiche une page blanche. Résultat : 0/93 détections. Google Safe Browsing explore le site et détecte un article de blog. Résultat : sans avertissement. La victime clique sur cette même URL depuis son téléphone, après l'avoir vue dans une publicité Google : ils voient une fausse page de connexion à MetaMask. Il ne s'agit pas d'un problème théorique : c'est le mode opératoire standard du phishing moderne.
Les outils utilisés pour la supercherie
Le cloaking ne s'improvise pas. Il s'appuie sur un logiciel commercial spécialisé appelé Systèmes de répartition du trafic (TDS). Le plus couramment utilisé dans les opérations de phishing est Keitaro.
Keitaro est un produit ad-tech certifié, conçu pour permettre aux spécialistes du marketing d'affiliation de rediriger le trafic en fonction des caractéristiques des visiteurs. Il prend en charge d'emblée tous les critères de filtrage mentionnés ci-dessus : plages d'adresses IP, localisation géographique, type d'appareil, source de référence et agent utilisateur. Il suffit aux auteurs de hameçonnage de le configurer pour rediriger les robots d'exploration vers une page blanche et les victimes vers la page de hameçonnage.
Notre étude, publiée sous le titre Keitaro TDS : 1 500 panneaux exposés, identifié 1 565 planches de Keitaro en ligne hébergeant une infrastructure de hameçonnage. Pas 1 565 pages de hameçonnage — 1 565 panneaux de commande, chacun gérant simultanément des dizaines, voire des centaines de campagnes de phishing.
Parmi les autres plateformes TDS que nous rencontrons, on peut citer :
- Binôme — Un tracker auto-hébergé très utilisé dans le cadre d'opérations menées dans la région de la CEI
- Restez actif — Outil de suivi en ligne avec filtrage d'adresses IP et détection des robots
- Routeurs PHP personnalisés — Scripts développés en interne utilisant MaxMind GeoIP et des listes noires d'adresses IP
- Cloudflare Workers — Un routage en périphérie qui évalue les caractéristiques des visiteurs avant même que la requête n'atteigne le serveur d'origine
Le point commun : ils ont tous pour but d'afficher un contenu différent selon les visiteurs. Dans le domaine du marketing d'affiliation, on parle d'« optimisation du trafic ». Dans le domaine du phishing, on parle de évasion.
Nous avons construit le Outil de détection Keitaro pour détecter les traces de Keitaro TDS sur n'importe quel domaine. Il recherche les chemins d'accès connus au panneau de configuration, les modèles d'en-têtes de réponse, les chaînes de redirection et les signatures JavaScript associées aux installations de Keitaro.
Le scénario de la « redirection vers le site officiel »
L'un des schémas de cloaking les plus courants que nous rencontrons consiste en un domaine qui redirige simplement vers un site officiel. L'appel à l'action se présente toujours de la même manière : « Vérifie par toi-même : ça redirige simplement vers coinbase.com. Il n'y a pas d'hameçonnage. »
Voici ce qui se passe réellement :
Le fait que l'on soit redirigé vers le site officiel ne signifie pas pour autant que le domaine est inoffensif. C'est le mécanisme de camouflage lui-même. Le TDS a déterminé que le visiteur est un robot d'indexation, et la réponse la plus sûre — celle qui a le plus de chances de donner lieu à un scan sans problème — consiste à le rediriger vers le site web authentique.
Voici un exemple simplifié de la logique côté serveur :
// Simplified cloaking router (illustrative)
const SCANNER_IPS = ['34.0.0.0/8', '35.0.0.0/8', '64.233.0.0/16']; // Google, etc.
const BOT_UA = /bot|crawl|spider|scan|check|virus|curl|wget|python/i;
const TARGET_GEO = ['US', 'GB', 'CA', 'AU'];
function routeVisitor(req) {
const ip = req.headers['cf-connecting-ip'];
const ua = req.headers['user-agent'];
const geo = req.headers['cf-ipcountry'];
// If scanner/bot detected: redirect to official site
if (isInRange(ip, SCANNER_IPS) || BOT_UA.test(ua)) {
return Response.redirect('https://www.coinbase.com', 302);
}
// If not in target geography: show white page
if (!TARGET_GEO.includes(geo)) {
return renderWhitePage(); // Innocent blog post
}
// Real victim from target country: show phishing page
return renderPhishingPage(); // Credential harvester
}Aucun site web légitime ne redirige les visiteurs vers le domaine d'une autre entreprise. Si crypto-wallet-app[.]com redirige vers coinbase.com, ce domaine n'a aucune raison d'exister. Une véritable page Coinbase serait hébergée sur coinbase.com. C'est la redirection qui le trahit.
Le problème des pages blanches
Une « page blanche » est le contenu factice qu'un domaine de phishing masqué affiche aux scanners et aux visiteurs non ciblés. Malgré son nom, il s'agit rarement d'une page blanche vide. Les pages blanches modernes sont sites web entièrement fonctionnels conçu pour paraître authentique :
- Articles de blog sur les cryptomonnaies, la finance ou la technologie
- Pages de présentation de produits pour des outils SaaS génériques
- Articles d'actualité extraits de publications fiables
- Pages de domaines en attente affichant un message générique du type « À venir »
- Contenu optimisé pour le référencement naturel (SEO) et conçu pour figurer en bonne place dans les résultats de recherche
Ce dernier point est essentiel. Les pages blanches ne sont pas seulement des outils de contournement — elles sont Les outils du référencement. En hébergeant du contenu de haute qualité sur un domaine de phishing, les opérateurs atteignent deux objectifs à la fois : ils échappent ainsi à la détection et Ils renforcent l'autorité de leur domaine, ce qui permet à leurs liens de phishing d'apparaître en meilleure position dans les résultats de recherche.
L'attaque de « SEO poisoning » en trois phases
Voici le cycle de vie complet d'une campagne de phishing utilisant la technique « white page » :
Autorité de construction
Classement et indice
Activer le phishing
C'est pourquoi nous signalons les domaines dès la phase 1. Lorsque la phase 3 se déclenche, le mal est déjà fait. Attendre que la page de phishing apparaisse revient à attendre que les victimes perdent leurs identifiants et leur argent.
Scénarios de trafic actif : publicités et campagnes par e-mail
Toutes les tentatives de phishing dissimulées ne reposent pas sur le référencement naturel. Deux des méthodes les plus agressives d'acquisition de trafic sont publicité payante et campagnes par e-mail, qui recourent toutes deux au cloaking pour contourner le contrôle de la plateforme.
Masquage dans Google Ads
Notre enquête sur le BUYTRX drainer network documenté Plus de 55 domaines utiliser Google Ads pour générer du trafic vers des sites qui vident le portefeuille. Le mécanisme :
- L'opérateur soumet le domaine à l'examen de Google Ads. Le robot d'indexation de Google tombe sur une page blanche (un blog consacré à la technologie blockchain). Annonce approuvée.
- La campagne publicitaire cible les mots-clés « connect wallet » et « crypto airdrop ».
- Un utilisateur de Google clique sur l'annonce. TDS détecte une adresse IP résidentielle provenant d'un référent Google Ads. On a servi un égouttoir à portefeuille.
- La victime connecte son portefeuille. Ses fonds sont vidés en quelques secondes via une transaction pré-signée.
Le système de vérification des annonces de Google — comme tout outil de filtrage automatisé — ne voit que la surface des choses. L'annonce continue d'être diffusée, et l'opérateur continue de payer Google pour chaque victime générée.
Masquage des campagnes par e-mail
Les passerelles de messagerie (Microsoft Defender pour Office 365, Proofpoint, Mimecast) analysent les liens contenus dans les e-mails avant leur envoi. Cloaking procède de la même manière :
- L'e-mail de hameçonnage contient un lien vers un domaine masqué.
- La passerelle de messagerie analyse l'URL. Le système TDS côté serveur identifie la plage d'adresses IP de la passerelle. Il renvoie alors une page blanche ou redirige vers le site officiel. E-mail envoyé.
- Le destinataire clique sur le lien depuis son client de messagerie. Adresse IP résidentielle, référent correct, zone géographique cible. Page de phishing affichée.
Rien que dans le cadre de l'enquête BUYTRX, Google Ads finançait activement la diffusion de logiciels malveillants visant à vider les portefeuilles virtuels sur plus de 55 domaines. Chaque domaine a passé avec succès le contrôle automatisé de Google, car le robot d'indexation de Google ne voyait qu'une page blanche. Il ne s'agit pas d'une faille, mais d'une défaillance structurelle dans la manière dont les plateformes publicitaires valident les pages de destination en cas de cloaking.
Pourquoi le principe de la « présomption d'innocence » ne s'applique pas ici
On entend parfois dire qu’il est prématuré de signaler un domaine sur la base d’une infrastructure de cloaking, et qu’il faudrait attendre que le contenu de phishing apparaisse réellement avant d’agir. Cet argument repose sur une mauvaise compréhension du cloaking.
Le cloaking n'est pas une technologie neutre. C'est infrastructure malveillante conçue spécifiquement pour échapper à la détection. Un domaine utilisant le cloaking a déjà affiché ses intentions : présenter une image aux systèmes de sécurité et une autre aux victimes. Il ne s'agit pas d'une configuration qui sert un quelconque objectif légitime.
Tout domaine présentant n'importe quelle combinaison Parmi ces signaux, certains sont signalés comme malveillants :
- Diffusion de contenu conditionnel — Contenu différent en fonction de l'adresse IP, de l'agent utilisateur, de la localisation géographique, de la source de référence ou de l'empreinte digitale de l'appareil
- Empreintes digitales TDS — Keitaro, Binom, BeMob ou des signatures de routeurs personnalisées dans les en-têtes de réponse, les chaînes de redirection ou le JavaScript
- Rediriger vers les sites officiels — Toute redirection vers un domaine tiers légitime (notamment des sites bancaires, des plateformes de cryptomonnaie ou des fournisseurs de messagerie électronique)
- Page blanche avec un contenu sans rapport — Articles de blog, articles d'actualité ou contenu générique publiés sur un domaine enregistré récemment et ne présentant aucune activité commerciale avérée
- JavaScript anti-bot — Scripts d'identification qui vérifient la présence de navigateurs sans interface graphique, de WebDriver, les dimensions de l'écran ou le rendu sur le canevas avant de déterminer ce qu'il faut afficher
Dans notre base de données comprenant plus de 50 000 sites analysés, le nombre de domaines présentant ces signaux et qui se sont avérés légitimes est de zéro. Pas « rare » — zéro. Nous n'avons jamais rencontré un seul site web légitime qui ait eu besoin de rediriger les visiteurs non ciblés vers le domaine d'une autre entreprise, ou d'afficher un blog sur la cryptomonnaie pour les robots d'indexation tout en proposant un formulaire de connexion aux visiteurs provenant de plages d'adresses IP spécifiques.
Le cloaking est un signal binaire. Si un domaine affiche un contenu différent selon les visiteurs en utilisant les mécanismes décrits ci-dessus, il est signalé. Si un opérateur estime qu'il s'agit d'un faux positif, notre procédure d'appel a justement été créé à cette fin. À ce jour, aucun signalement lié au cloaking n'a donné lieu à un recours favorable.
Le problème du greffier
Le cloaking pose un problème en aval pour le signalement des abus. Lorsque nous signalons un domaine masqué à un registraire, l'équipe chargée des abus de ce dernier se rend sur l'URL et constate… qu'il s'agit d'une page normale. Un article de blog. Une redirection vers coinbase.com. De leur point de vue, il n'y a pas lieu d'intervenir.
C'est exactement ce qui s'est passé chez nous Enquête sur NiceNIC et notre Enquête sur NameSilo. Dans les deux cas, les bureaux d'enregistrement ont vérifié les domaines signalés, ont constaté que leur contenu était irréprochable et ont soit classé l'affaire, soit pris la défense de l'exploitant du domaine.
Le problème est systémique :
- Les équipes chargées de lutter contre les abus des registres utilisent les mêmes méthodes d'analyse que les éditeurs d'antivirus — ils accèdent à l'URL depuis des adresses IP de centres de données à l'aide de navigateurs classiques. Le cloaking contourne systématiquement cette méthode.
- Aucun registraire n'a investi dans la détection du cloaking — La technologie permettant de détecter la diffusion de contenu conditionnel existe (c'est nous qui l'avons développée), mais aucun registraire ne l'a encore mise en œuvre.
- Le cadre de l'ICANN en matière d'abus ne tient pas compte du cloaking — Les signalements d'abus nécessitent des preuves de la présence de contenus préjudiciables. Si ces contenus ne sont visibles que par les victimes, le processus de vérification mis en place par le registraire ne permettra jamais de les détecter.
Nous avons largement documenté ce phénomène. Notre rapport Quand les signalements d'abus restent sans suite explique en détail pourquoi les registraires ne prennent systématiquement aucune mesure à l'égard des domaines masqués, car leurs méthodes de vérification sont précisément celles que le cloaking vise à contourner.
C'est pourquoi PhishDestroy fonctionne comme une couche indépendante. Nous ne nous contentons pas de consulter l'URL à partir d'une seule adresse IP pour vérifier ce qu'elle affiche. Nous analysons les chaînes de redirection, les empreintes TDS, le comportement JavaScript, l'historique DNS, les journaux de transparence des certificats et les tendances temporelles sur des milliers de domaines. Lorsque nous signalons un domaine, nous avons déjà pris en compte le fait que celui-ci paraîtra « propre » à quiconque le vérifie de manière conventionnelle.
Résumé : Techniques de dissimulation et détection
| Technique | Ce que voient les scanners | Ce que voient les victimes | Méthode de détection |
|---|---|---|---|
| Filtrage basé sur l'adresse IP | Page blanche / redirection | Page de hameçonnage | Analyse multi-IP, comparaison de proxys résidentiels |
| Filtrage basé sur l'UA | Page blanche / 403 | Page de hameçonnage | Rotation des éléments UA : comparaison entre un navigateur sans interface graphique et un navigateur réel |
| Filtrage géolocalisé | Contenu générique | Hameçonnage localisé | Analyse de proxys multi-régions |
| Filtrage des sources de trafic | Page blanche | Hameçonnage (via une publicité ou un e-mail) | Usurpation de l'adresse de référence, simulation de clics publicitaires |
| Identification par empreinte digitale JavaScript | Page blanche (bot détecté) | Hameçonnage (appareil réel) | Analyse statique JavaScript, désobfuscation |
| Règles basées sur le temps | Nettoyage (en dehors des heures d'ouverture) | Hameçonnage (heures d'ouverture) | Balayage temporel, vérifications alignées sur le fuseau horaire |
| Contrôle d'accès par cookies/sessions | Nettoyage (première visite) | Hameçonnage (nouvelle visite avec cookie) | Analyse des sessions multi-visites, relecture des cookies |
| TDS (Keitaro/Binom) | Page blanche ou redirection | Redirigé vers une tentative d'hameçonnage | Outil de détection Keitaro, analyse des en-têtes et des redirections |
| Redirection vers le site officiel | 302 → site légitime | Page de hameçonnage | Analyse des destinations de redirection, validation de l'objectif du domaine |
Conclusion
Le cloaking n'est pas une zone grise. C'est le la technique d'esquive la plus efficace dans le phishing moderne, et tous les maillons de l'écosystème du phishing — de Google Ads aux passerelles de messagerie en passant par les équipes chargées de la lutte contre les abus chez les bureaux d'enregistrement — ne parviennent actuellement pas à y remédier.
Lorsque PhishDestroy signale un domaine pour cloaking, il ne s'agit pas d'une simple supposition. Nous constatons la présence d'une infrastructure malveillante qui n'a qu'un seul objectif : afficher un contenu différent selon les visiteurs. Sur plus de 50 000 analyses, le taux de faux positifs pour ce signal est nul.
Si votre domaine a été signalé :
- Si vous êtes un opérateur légitime et que vous pensez qu'il s'agit d'un faux positif, faire appel. Nous les examinons tous.
- Si vous exploitez une infrastructure de cloaking, nous le savons déjà. La page blanche que vous avez présentée à notre scanner n'est pas celle que voient vos victimes. Et nous avons les preuves pour le démontrer.
Une page blanche n'est pas un moyen de défense. C'est un aveu. Si votre site doit afficher un contenu différent selon les visiteurs, vous avez déjà répondu à la question de savoir s'il s'agit d'un site malveillant.
Tout domaine masqué est banni. Sans exception. Aucun recours n'a abouti. Car sur 50 000 analyses, nous ne nous sommes jamais trompés sur ce signal.
Recherches et ressources connexes
Keitaro TDS : 1 500 panneaux exposés
Comment nous avons cartographié 1 565 serveurs Keitaro alimentant des infrastructures de hameçonnage à travers le monde.
Outil de détection Keitaro
Analysez n'importe quel domaine à la recherche d'empreintes Keitaro TDS, de chaînes de redirection et de signatures de cloaking.
BUYTRX : 55 domaines, financement par Google Ads
Un réseau de sites qui vident les portefeuilles, utilisant des pages blanches masquées pour passer les contrôles de Google Ads.
Quand les signalements d'abus restent sans suite
Pourquoi les équipes chargées de la lutte contre les abus des bureaux d'enregistrement ne prennent-elles pas de mesures à l'encontre des domaines masqués, et quels changements faut-il apporter ?
Verdict de NiceNIC
L'ICANN a engagé une procédure contre NiceNIC pour son inaction systématique face aux signalements d'abus.
Enquête sur NameSilo
Comment NameSilo a pris la défense d'un voleur de cryptomonnaies ayant dérobé 2 millions de dollars et a inventé une histoire pour le couvrir.
Cet article s'appuie sur notre expérience opérationnelle acquise lors de l'analyse de plus de 50 000 domaines, de l'enquête sur des infrastructures de phishing actives et du dépôt de signalements d'abus auprès des bureaux d'enregistrement et de l'ICANN. Toutes les techniques décrites sont étayées par des preuves. Aucun accès non autorisé n'a été effectué à aucun moment au cours de nos recherches.
