La question qu'on nous pose sans cesse

Chaque semaine, nous recevons le même appel à l'aide : « 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 là-dedans. »

Ou encore une variante : « Cette page n'est qu'un article de blog sur les cryptomonnaies. Ce n'est pas une tentative d'hameçonnage. »

Nous comprenons que cela puisse prêter à confusion. Si vous vous rendez sur un domaine qui a été signalé et que vous tombez sur une page tout à fait normale — ou sur une redirection « propre » vers un site légitime —, il est naturel de penser que le signalement est erroné. Mais cette page « propre » ne constitue pas 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 [REDACTED] acheminent les victimes, et pourquoi THE ENABLERS REGISTRY considère chacun de ces schémas comme une infrastructure malveillante avérée — sans aucune exception.

Comment les systèmes antivirus ont changé la donne

Il y a dix ans, le possibly 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 possibly phishing et l'ajoutaient à leurs listes de blocage. Le nom de domaine disparaissait alors en quelques heures ou quelques jours.

Puis, le secteur s'est amélioré. Google Safe Browsing, Microsoft SmartScreen et plus de 100 moteurs antivirus sur des plateformes comme 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 hameçonnage et son blocage est passé de plusieurs jours à quelques minutes.

Les auteurs d'hameçonnage étaient 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 d'hameçonnage à 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.

La course à l'armement : à mesure que la détection des logiciels malveillants passait de plusieurs jours à quelques minutes, les auteurs d'hameçonnage ont réagi en mettant en place une infrastructure de camouflage qui affiche un contenu différent selon qu'il s'agit de scanners ou de véritables victimes.

Qu'est-ce que le « cloaking » exactement ?

Le « cloaking » consiste à proposer un contenu différent selon les visiteurs, en fonction de leur identité. Dans le contexte du hameçonnage, cela signifie une seule 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 connues des centres de données, les plages VPN et les blocs d'adresses IP des fournisseurs de solutions de sécurité reçoivent la version « propre ». 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 d'analyse de sécurité sont identifiés et filtrés.
• Géolocalisation — La page de hameçonnage 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 publicité 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 des appareils — JavaScript vérifie la résolution de l'écran, les polices installées, le moteur de rendu WebGL, l'API de la batterie et d'autres indicateurs afin de distinguer les appareils réels des émulateurs.
• Règles liées au temps — La page de hameçonnage 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 hameçonnage.

L'infrastructure de dissimulation filtre les visiteurs à plusieurs niveaux. Au moment où une véritable victime accède à la page de hameçonnage, tous les systèmes de défense automatisés ont déjà été trompés par un leurre inoffensif.

Un dispositif de dissimulation sophistiqué combine tous ces éléments. Il en résulte un domaine qui apparaît comme parfaitement irréprochable à tous les scanners sur Internet, tout en volant activement les identifiants des victimes ciblées.

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 hameçonnage est [REDACTED].

[REDACTED] est un produit ad-tech à part entière, conçu pour permettre aux spécialistes du marketing d'affiliation d'acheminer le trafic en fonction des caractéristiques des visiteurs. Il prend en charge d'emblée tous les critères de filtrage énumérés ci-dessus : plages d'adresses IP, localisation géographique, appareil, source de référence, agent utilisateur. Les auteurs d'attaques de hameçonnage n'ont qu'à le configurer pour rediriger les « scanners » vers une page blanche et les victimes vers la page de hameçonnage.

Notre étude, publiée sous le titre [REDACTED] TDS : 1 500 panneaux exposés, identifié 1 565 planches de [REDACTED] 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 hameçonnage.

[REDACTED] TDS : un système commercial de répartition du trafic réutilisé comme infrastructure principale pour le camouflage des attaques de hameçonnage. Plus de 1 565 panneaux identifiés et répertoriés.

Parmi les autres plateformes TDS que nous rencontrons, on peut citer :

• Binôme — Tracker auto-hébergé très utilisé dans le cadre d'opérations menées dans la région de la CEI
• BeMob — Outil de suivi basé sur le cloud avec filtrage d'adresses IP et détection des bots
• Routeurs PHP personnalisés — Scripts développés en interne utilisant MaxMind GeoIP et des listes noires d'adresses IP
• IANA #1910 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 possibly phishing, on parle de évasion.

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 est toujours le même : « Vérifie par toi-même : ça te redirige simplement vers NASDAQ:COIN.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 soit inoffensif. C'est le mécanisme de camouflage lui-même. Le TDS a déterminé que le visiteur est un robot d'analyse, et la réponse la plus sûre — celle qui a le plus de chances de donner lieu à une analyse sans problème — consiste à le rediriger vers le véritable site web.

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.NASDAQ:COIN.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 possibly phishing page
  return renderPhishingPage(); // Credential harvester
}

Le problème de la « page blanche »

Une « page blanche » est le contenu leurre qu’un domaine de hameçonnage 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), 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 naturel. En hébergeant du contenu de haute qualité sur un domaine de hameçonnage, les opérateurs atteignent deux objectifs à la fois : ils échappent à la détection et Ils renforcent l'autorité de leur domaine, ce qui permet à leurs liens de hameçonnage 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 hameçonnage utilisant la technique « white page » :

Les pages blanches ne constituent pas une stratégie d'évitement passive. Il s'agit d'outils de référencement actifs qui renforcent l'autorité d'un domaine, améliorent son classement dans les résultats de recherche, puis exploitent cette réputation pour mener des attaques de hameçonnage auprès des victimes via les résultats de recherche naturels.

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 hameçonnage s'affiche 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 hameçonnage dissimulées ne reposent pas sur le référencement naturel. Deux des méthodes les plus agressives d'acquisition de trafic sont les suivantes : publicité payante et campagnes par e-mail, qui recourent toutes deux à des techniques de dissimulation pour contourner le contrôle de la plateforme.

Masquage dans Google Ads

Notre enquête sur le Réseau de draineurs [REDACTED] documenté Plus de 55 domaines utiliser Google Ads pour générer du trafic vers des sites qui vident le portefeuille. Le mécanisme :

1. 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). Publicité approuvée.
2. Diffusion d'une publicité ciblant les mots-clés « connect wallet » et « crypto airdrop ».
3. 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 plat qui fait mal au portefeuille.
4. La victime connecte son portefeuille. Ses avoirs sont vidés en quelques secondes via une transaction pré-signée.

Le système de vérification des publicités de Google — comme tout outil de vérification automatisé — ne voit que la page blanche. La publicité continue d’être diffusée, et l’opérateur continue de payer Google pour chaque victime redirigée vers son site.

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 :

1. Un e-mail de hameçonnage contient un lien vers un domaine masqué.
2. 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. L'e-mail a été envoyé.
3. Le destinataire clique sur le lien depuis son client de messagerie. Adresse IP résidentielle, source de référence correcte, zone géographique cible. Page de hameçonnage affichée.

Pourquoi le principe de « 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 » — qu’il faudrait attendre l’apparition du contenu de hameçonnage proprement dit avant d’agir. Cet argument repose sur une mauvaise compréhension du « cloaking ».

Le cloaking n'est pas une technologie neutre. C'est infrastructure adversaire conçue spécifiquement pour échapper à la détection. Un domaine utilisant une technique de dissimulation a déjà affiché son intention : montrer une chose aux systèmes de sécurité et une autre aux victimes. Il ne s'agit pas là d'une configuration qui sert un objectif légitime.

Dans notre ensemble 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é le moindre site web légitime qui ait eu besoin de rediriger des visiteurs non ciblés vers le domaine d’une autre entreprise, ou d’afficher un blog sur les cryptomonnaies à l’intention des robots d’indexation tout en proposant un formulaire de connexion aux visiteurs provenant de plages d’adresses IP spécifiques.

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… une page « propre ». Un article de blog. Une redirection vers NASDAQ:COIN.com. De leur point de vue, il n’y a pas lieu d’intervenir.

C'est exactement le scénario qui s'est déroulé dans notre Enquête sur IANA #3765 et notre Enquête « IANA #1479 ». 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 défendu activement l'exploitant du domaine.

Le problème est systémique :

• Les équipes chargées de lutter contre les abus des registraires 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 dispositif de lutte contre les abus de l'ICANN ne tient pas compte du cloaking — Les signalements d'abus nécessitent des preuves de l'existence d'un contenu préjudiciable. Si ce contenu n'est visible que par les victimes, le processus de vérification mis en place par le registraire ne permettra jamais de le détecter.

C’est pourquoi THE ENABLERS REGISTRY fonctionne comme une couche indépendante. Nous ne nous contentons pas d’accéder à l’URL depuis 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 de détection

Le tableau complet : à chaque technique de dissimulation correspond une méthode de détection. Le défi ne réside pas dans la technologie, mais dans la nécessité de convaincre les registraires, les plateformes publicitaires et les passerelles de messagerie de les mettre en œuvre.

Conclusion

Le cloaking n'est pas une zone grise. C'est le la technique d'esquive la plus efficace qui soit dans le hameçonnage moderne, et tous les maillons de l'écosystème du hameçonnage — de Google Ads aux passerelles de messagerie en passant par les équipes chargées de lutter contre les abus chez les registraires — ne parviennent actuellement pas à y remédier.

Lorsque THE ENABLERS REGISTRY signale un domaine pour « cloaking », il ne s'agit pas d'une simple supposition. Nous constatons la présence d'une infrastructure malveillante dont le seul but est de présenter 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 nom de domaine a été signalé :

• Si vous êtes un opérateur en règle et que vous pensez qu'il s'agit d'un faux positif, introduire un recours. Nous les examinons tous.
• Si vous exploitez une infrastructure de cloaking, nous le savons déjà. La page blanche que vous avez affiché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. En effet, sur 50 000 analyses, nous ne nous sommes jamais trompés concernant ce signal.

Recherches et ressources connexes

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 hameçonnage 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.