"Microsoft Clairty" n'est pas Microsoft Clarity : désobfuscation d'un script de fraude publicitaire par typosquatting

Une extension de navigateur injecte du JavaScript obfusqué depuis msclairty[.]com, un domaine typosquatté qui se fait passer pour Microsoft Clarity. Le script supprime les cookies Google Analytics, injecte des cookies d'affiliation avec la valeur pub=twsc, injecte des iframes cachés vers discounthero[.]org et détourne l'API Fetch. Étonnamment, aucun outil de sécurité ne signale ce domaine. Il s'agit de la première documentation publique de msclairty[.]com.

Qu'est-ce que msclairty[.]com ?

msclairty[.]com est un domaine typosquatté conçu pour se faire passer pour Microsoft Clarity (msclarity[.]com / clarity[.]ms), le populaire outil d'analyse et de carte thermique de Microsoft. En clair : les lettres « i » et « r » dans « clarity » sont inversées pour donner « clairty », ce qui est suffisamment subtil pour passer inaperçu au premier coup d'œil dans un journal réseau ou une balise de script.

Le domaine ne fournit pas d'analyses. Il délivre en réalité une charge utile JavaScript obfusquée qui effectue du cookie stuffing d'affiliation, de la suppression de cookies de suivi et du détournement de l'API Fetch dans le navigateur du visiteur.

Comment ce script a-t-il été découvert ?

Au cours des 48 dernières heures, nous avons commencé à observer des requêtes réseau vers msclairty[.]com sur plusieurs sites web sans lien entre eux dans notre télémétrie. La première requête que nous avons enregistrée date du 2 mars 2026 à 21h17 UTC, avec un trafic qui a fortement augmenté dans la matinée du 3 mars. Le trafic ne provient pas d'une balise de script compromise dans le code source de la page. Il est injecté par une extension de navigateur. Nous n'avons pas encore identifié l'extension spécifique responsable, mais le schéma d'injection est identique sur chaque site affecté : même charge utile obfusquée, même domaine, même comportement, quel que soit l'inventaire de scripts propre au site.

Le dénominateur commun est le navigateur de l'utilisateur final, pas le code du site.

Nous avons observé le script affectant des sites dans plusieurs secteurs sans lien entre eux, notamment le transport (comme les plateformes de réservation de vols), les plateformes SaaS (comme les outils de gestion de projet), les portails de gestion sportive et les portails de paiement gouvernementaux. Les visiteurs affectés utilisent plusieurs versions de Chrome (132, 138 et 145) et proviennent d'adresses IP américaines situées sur les côtes Est et Ouest. Chaque site affecté charge l'identifiant de campagne event.js identique et reçoit le même hash de charge utile, confirmant qu'il s'agit d'une campagne coordonnée unique fonctionnant via une seule extension de navigateur.

Les identifiants de campagne changent quotidiennement. Par exemple, le 2 mars, l'URL du chargeur était event.js?id=dHRcSiYkDj4&date=2026-03-02. Le 3 mars, un nouvel identifiant de campagne est apparu : event.js?id=XGp2NSkTRVs&date=2026-03-03. Le paramètre date= correspond à la date de chaque rotation de campagne. Cela signifie que l'infrastructure est activement maintenue et déploie de nouveaux identifiants de campagne chaque jour.

Chaque utilisateur affecté partage la même empreinte. Dans toutes les requêtes de notre télémétrie, le profil de navigateur est identique : Windows 10 x64, Google Chrome sur ordinateur, aucun appareil mobile. Pas une seule requête ne provient de Firefox, Safari, Edge, Brave, macOS, Linux, Android ou iOS. Il s'agit d'une extension exclusivement Chrome. Les indices client sec-ch-ua confirment un vrai Chrome (et non des forks Chromium qui se signalent différemment), et sec-ch-ua-mobile: ?0 confirme un ordinateur de bureau pour chaque requête. Nous n'avons observé que 5 adresses IP de visiteurs uniques sur tous les sites affectés, toutes sur des connexions résidentielles américaines.

L'attaque complète suit un schéma de chargement en deux étapes où le serveur prend des décisions de ciblage par requête sur la charge utile à délivrer.

Étape 1 : Script de chargement (event.js)

hxxps://msclairty[.]com/event.js?id=dHRcSiYkDj4&date=2026-03-02
hxxps://msclairty[.]com/event.js?id=XGp2NSkTRVs&date=2026-03-03

Le chargeur event.js pèse 8 599 octets. Le paramètre id= est un identifiant de campagne qui change quotidiennement. Le 2 mars, l'identifiant de campagne était dHRcSiYkDj4. Le 3 mars, il a changé pour XGp2NSkTRVs. Le paramètre date= correspond à la date de chaque rotation. Le premier chargeur que nous avons capturé a été modifié pour la dernière fois le 2 mars 2026 à 09:58:50 GMT.

Nous avons désobfusqué le chargeur et constaté qu'il effectue les opérations suivantes :

1. Détournement de la console. Il écrase les 7 méthodes de la console (log, warn, info, error, exception, table, trace) immédiatement au chargement, avant l'exécution de toute charge utile. Toute tentative de débogage ou de journalisation est ainsi silencieusement bloquée.
2. Vérification anti-iframe. Il compare window.self à window.top et s'arrête si le chargeur s'exécute dans un iframe. Cela garantit qu'il ne s'exécute que dans le contexte de navigation de niveau supérieur, évitant les environnements d'analyse ou de sandbox qui utilisent des iframes.
3. Vérification du cookie de déduplication. Il lit le cookie __tr_luptv à l'aide d'un helper getCookie(). Si le cookie existe déjà, le chargeur s'arrête. Ce cookie est défini par la charge utile après son déclenchement et remplit deux fonctions : l'attribution de l'attaquant pour la fraude aux commissions et un garde « ne pas exécuter deux fois » qui empêche une exécution répétée entre les chargements de page.
4. Requête de ciblage côté serveur. Il envoie un POST à msclairty[.]com avec Content-Type: application/x-www-form-urlencoded contenant quatre paramètres : url (l'URL de la page actuelle), referrer (document.referrer), unique_id (l'identifiant de campagne du paramètre id=) et ext: 'twsc' (l'identifiant d'affiliation de l'attaquant, codé en dur). Le serveur répond avec du JSON contenant un champ data (le nom de fichier encodé en Base64 pour la charge utile) et un champ type (la variante ?type= à charger).
5. Injection dynamique de la charge utile. Il construit l'URL de l'étape 2 en concaténant la réponse du serveur : https://msclairty[.]com/js/ + response.data + .js?type= + response.type, crée un élément ` Le chargeur envoie l'URL de la page et le référent, et le serveur répond avec le nom de fichier de la charge utile encodé et la valeur ?type=. Cela signifie que différents sites, différentes pages ou différents référents peuvent recevoir différentes variantes de charge utile. Par exemple, une page produit pourrait recevoir type=1 (cookie stuffing silencieux) tandis qu'une page de paiement pourrait recevoir type=5 (redirection forcée). La logique de ciblage est entièrement côté serveur et invisible pour l'analyse côté client.

   Étape 2 : Charge utile obfusquée

   hxxps://msclairty[.]com/js/[Base64-encoded-blob].js?type=[1-5]

   La charge utile pèse 10 007 octets. Le nom de fichier de type Base64 est généré côté serveur en fonction de l'URL de la page et du référent envoyés par le chargeur. Le paramètre ?type=, également choisi par le serveur, sélectionne laquelle des cinq variantes d'attaque est exécutée. La fonction à l'intérieur de chaque charge utile est nommée pour correspondre à sa variante (type1(), type2(), type8(), type9(), type11()).

   Quels outils de sécurité signalent msclairty[.]com ?

   Aucun. Nous avons vérifié toutes les principales plateformes de renseignement sur les menaces et tous les outils de sécurité disponibles. À la date de publication, pas un seul ne signale msclairty[.]com comme malveillant :

   • VirusTotal : 0 détection sur 90+ moteurs
   • urlscan.io : aucun résultat de scan, aucune soumission communautaire
   • Google Safe Browsing : non signalé
   • SecurityTrails : aucun historique DNS, aucun enrichissement WHOIS
   • ANY.RUN : aucune soumission sandbox pour ce domaine
   • Hybrid Analysis / Falcon Sandbox : aucun résultat
   • PhishTank : non répertorié
   • OpenPhish : non répertorié
   • MalwareBazaar : aucun échantillon
   • ThreatFox (abuse.ch) : aucune entrée IOC
   • Cloudflare Radar : aucune donnée

   C'est une couverture nulle sur toutes les principales plateformes. En clair, cet article est la première documentation publique de ce domaine utilisé à des fins malveillantes.

   Comment cside a détecté ce script

   cside a détecté ce script de manière autonome grâce à l'analyse comportementale à l'exécution. Aucun flux de menaces n'a signalé le domaine. Aucun scanner n'a renvoyé la charge utile. Aucune signature ne correspondait. La détection était entièrement basée sur ce que le script faisait dans le navigateur : suppression de cookies de suivi, injection d'un iframe caché, détournement de l'API Fetch et suppression de la console.

   Les scripts d'extension de navigateur échappent à votre contrôle en tant que propriétaire de site web. Vous ne pouvez pas empêcher une extension d'injecter du code dans vos pages. Mais il est utile de savoir que l'abus a lieu. Par exemple, le script supprime le cookie d'attribution RedTrack légitime (rtkclickid-store) et le remplace par le jeton d'affiliation de l'attaquant pub=twsc via la chaîne de redirection discounthero[.]org. Si vous utilisez RedTrack pour le suivi des conversions d'affiliation ou si vous dépendez d'une attribution de trafic précise, ce type de fraude vole activement des commissions à vos affiliés légitimes et vous ne le verriez jamais sans visibilité côté client.

   Utilisez cside pour comprendre comment votre application se comporte dans le navigateur. Détectez les signaux de fraude provenant des visiteurs, des agents IA et des dépendances côté client.

   cside a partagé ces informations avec Microsoft afin qu'ils puissent engager une procédure de retrait de msclairty[.]com pour typosquatting malveillant de leur marque Clarity. Nous avons également contacté RedTrack, car leur cookie d'attribution rtkclickid-store est explicitement ciblé pour suppression dans cette attaque et le jeton d'affiliation pub=twsc est utilisé pour remplacer l'attribution légitime des clics RedTrack par des demandes de commission frauduleuses.

   Commencez gratuitement ou réservez une démo pour parler à notre équipe.

   Pourquoi les outils d'IA et les scanners reçoivent-ils un 403 de msclairty[.]com ?

   Le serveur derrière msclairty[.]com fonctionne sur un backend Express (Node.js) fronté par Cloudflare. Les en-têtes de réponse incluent x-powered-by: Express, cf-cache-status et access-control-allow-origin: *. La charge utile est mise en cache par Cloudflare avec un max-age de 14 400 secondes (4 heures).

   Malgré la présence de Cloudflare, le serveur bloque activement l'analyse automatisée. Lorsque des outils basés sur l'IA comme ChatGPT, Claude et Perplexity tentent de récupérer du contenu depuis le domaine, le serveur renvoie une réponse 403 Forbidden. Il en va de même pour les scanners de sécurité automatisés et toute requête provenant de plages d'adresses IP de datacenter.

   Il s'agit d'un filtrage délibéré basé sur les plages d'adresses IP, les chaînes user-agent ou d'autres empreintes de requête. Le serveur ne délivre la charge utile JavaScript malveillante que lorsque la requête semble provenir d'un vrai navigateur avec le bon référent, le bon user-agent et les bons en-têtes. Les adresses IP de datacenter, les user-agents de bots connus et les signatures de requêtes des outils d'IA sont tous bloqués.

   Ce comportement anti-recherche explique également pourquoi VirusTotal, urlscan.io et d'autres plateformes de scan renvoient des résultats propres ou aucun résultat. Ils ne reçoivent jamais la vraie charge utile.

   Que révèlent les en-têtes de requête sur l'extension msclairty[.]com ?

   Chaque requête dans notre télémétrie partage une empreinte de navigateur identique : Windows 10 x64, Google Chrome sur ordinateur, sec-ch-ua-mobile: ?0. Il n'y a pas une seule requête provenant de Firefox, Safari, Edge, Brave ou d'un navigateur mobile. Ni macOS, ni Linux, ni Android, ni iOS.

   C'est significatif. Si l'extension était disponible sur l'écosystème Chromium plus large, nous nous attendrions à voir des user-agents Edge ou Brave dans le lot, puisque les deux prennent en charge les extensions du Chrome Web Store. Le fait que chaque requête signale « Google Chrome » dans les indices client sec-ch-ua et les chaînes user-agent Chrome standard suggère qu'il s'agit soit d'une extension exclusivement Chrome, soit qu'elle n'a été installée que par des utilisateurs de Chrome jusqu'à présent.

   Trois versions de Chrome apparaissent dans les données : 132, 138 et 145. Chrome 132 a été publié en janvier 2025 et est désormais obsolète. Chrome 138 et 145 sont plus récents. La répartition sur plusieurs versions exclut un exploit spécifique à une version et est cohérente avec une extension installée volontairement qui persiste à travers les mises à jour de Chrome.

   Autres schémas d'en-têtes notables :

   L'en-tête sec-fetch-storage-access apparaît avec les valeurs active et none lors des chargements initiaux de scripts (sec-fetch-dest: script). Cela indique que l'extension interagit avec l'API Storage Access, qui régit l'accès aux cookies intersites. C'est cohérent avec une extension qui a besoin d'un stockage intersite pour faire fonctionner son mécanisme de cookie stuffing.

   Toutes les requêtes POST utilisent content-type: application/json avec des valeurs content-length variables allant de 604 à 10 246 octets. Ce sont les balises event.js qui renvoient des données à msclairty[.]com. Les tailles de charge utile variables suggèrent que le script exfiltre différentes quantités de données de page ou de session selon le contexte de navigation.

   L'en-tête dnt: 1 (Do Not Track) est présent dans les requêtes des utilisateurs de Chrome 145 et Chrome 138, mais absent de Chrome 132. Il s'agit d'une préférence utilisateur, pas d'un comportement d'extension, mais cela confirme que ce sont de vrais utilisateurs finaux avec des navigateurs configurés individuellement.

   Quand le domaine msclairty[.]com a-t-il été enregistré ?

   Le certificat SSL de msclairty[.]com a été émis le 20 février 2026 à 20:14:54 UTC. C'est seulement 10 jours avant que nous observions pour la première fois du trafic en direct depuis ce domaine le 2 mars. Il s'agit d'un domaine fraîchement enregistré, créé spécifiquement pour cette campagne.

   Les détails d'enregistrement WHOIS sont masqués derrière un service de confidentialité. Aucun enregistrement DNS historique n'existe pour ce domaine dans SecurityTrails ou les bases de données DNS passives.

   Que fait le script msclairty[.]com ?

   Après désobfuscation, le script effectue six actions distinctes. Aucune d'entre elles n'a quoi que ce soit à voir avec l'analyse ou les cartes thermiques.

   Étape 1 : Détection des DevTools

   Le script vérifie si les outils de développement du navigateur sont ouverts avant d'exécuter quoi que ce soit. Il compare window.outerWidth - window.innerWidth et window.outerHeight - window.innerHeight par rapport à un seuil de 120 pixels. Il vérifie également Firebug et window.chrome.isInitialized.

   Si une vérification indique que quelqu'un inspecte la page, le script s'arrête immédiatement. Il ne s'exécute que pour de vrais utilisateurs, jamais pour des développeurs ou des chercheurs en sécurité.

   Étape 2 : Détournement de la console

   Le script écrase sept méthodes natives de la console : log, warn, info, error, exception, table et trace. Les sept sont remplacées par des fonctions vides sans effet. Cela empêche tout avertissement ou sortie de débogage d'apparaître si quelqu'un ouvre les DevTools après le chargement du script.

   Un appel séparé à console.clear() se déclenche sur un minuteur de 3 secondes pour effacer tout ce qui aurait pu être journalisé avant que l'écrasement ne prenne effet.

   Étape 3 : Suppression des cookies de suivi

   Le script supprime les cookies suivants au niveau du chemin et du domaine racine :

   • _ga (identifiant client Google Analytics)
   • _gid (identifiant de session Google Analytics)
   • rtkclickid-store (attribution des clics d'affiliation RedTrack)

   C'est le comportement le plus important à comprendre. En supprimant le cookie RedTrack rtkclickid-store, le script efface l'attribution légitime du clic d'affiliation pour ce visiteur. En supprimant également les cookies Google Analytics, il supprime toute trace de la façon dont l'utilisateur est arrivé sur le site. La vraie source de trafic du visiteur disparaît entièrement. Cela ouvre la voie au jeton d'affiliation de l'attaquant (pub=twsc) pour devenir la seule source d'attribution.

   Étape 4 : Injection d'iframe caché et cookie stuffing d'affiliation

   Un iframe caché de 1x1 pixel est injecté dans le corps de la page. L'iframe charge l'URL suivante :

   hxxps://discounthero[.]org/us/s/red_u_plain.php?t=direct&s=287&d=[target]&pub=twsc

   L'iframe utilise referrerpolicy="noreferrer" pour supprimer l'en-tête référent.

   Voici ce que signifie chaque paramètre d'URL :

   • t=direct : marqueur de type de trafic
   • s=287 : identifiant de campagne
   • d=[target] : le site victime de la fraude (la valeur change selon le site cible)
   • pub=twsc : l'identifiant d'éditeur affilié de l'attaquant

   La valeur pub=twsc est le compte d'affiliation qui reçoit la commission frauduleuse. C'est le cœur de l'attaque. L'iframe caché charge silencieusement une chaîne de redirection via discounthero[.]org qui dépose un cookie d'affiliation dans le navigateur de l'utilisateur. Si l'utilisateur visite ensuite le site cible et effectue un achat, l'attaquant derrière pub=twsc perçoit une commission qu'il n'a jamais générée. La suppression des cookies à l'étape 3 garantit qu'aucune attribution concurrente n'existe.

   Après 20 secondes, l'iframe est supprimé du DOM. Aucune trace visuelle ne subsiste sur la page.

   Étape 5 : Détournement de l'API Fetch

   À l'intérieur de l'iframe injecté, le script monkey-patche window.fetch. Toute requête fetch contenant nivtrck[.]com (encodé en bml2dHJjay5jb20= en Base64) est silencieusement bloquée avec une Promise rejetée.

   Cela empêche un service de suivi concurrent d'enregistrer la vraie source de trafic. L'attaquant ne veut pas seulement du crédit pour la visite ; il bloque activement les autres trackers pour qu'ils ne capturent aucune donnée d'attribution qui entrerait en conflit avec son cookie frauduleux.

   Étape 6 : Suppression du référent et cookie de suivi de l'attaquant

   Une balise `` est injectée dans le `` de la page, supprimant les en-têtes référents sur toutes les navigations sortantes. Cela masque la fraude aux analyses en aval sur le site cible.

   Le script définit également son propre cookie de suivi :

   __tr_luptv = [horodatage actuel moins 300 000 millisecondes]

   La valeur du cookie est Date.now() - 300000 (heure actuelle moins 5 minutes), définie à la fois sur le chemin racine et le domaine racine du site. Cet horodatage antidaté signale probablement à la chaîne de redirection discounthero[.]org que le visiteur a déjà été marqué et ne doit pas être traité à nouveau.

   Comment le script msclairty[.]com est-il obfusqué ?

   Le code utilise une pile d'obfuscation standard mais efficace qui met en échec la plupart des outils d'analyse statique :

   • Un tableau de chaînes rotatif contenant environ 95 entrées encodées en Base64
   • Une fonction de décodage qui traduit les indices du tableau en chaînes lisibles à l'exécution
   • Des objets proxy qui enveloppent les appels de fonctions et les références de chaînes derrière des noms de propriétés aléatoires
   • Une boucle de mélange IIFE qui fait tourner le tableau jusqu'à ce qu'une somme de contrôle corresponde, garantissant que le décodeur produit des valeurs correctes

   Le code obfusqué ressemble à du bruit aléatoire. Aucun outil d'analyse statique, scanner de signatures ou détection basée sur des expressions régulières n'identifiera un comportement malveillant à partir du code source brut. Il faut exécuter le décodeur pour voir ce que fait le script.

   Qu'est-ce que discounthero[.]org ?

   discounthero[.]org est le point de terminaison de redirection pour la fraude d'affiliation utilisé dans cette attaque. Contrairement à msclairty[.]com, ce domaine a une présence établie sur plusieurs plateformes de renseignement sur les menaces :

   • Hébergé sur l'infrastructure AWS à l'adresse IP 3.68.5.1 (AS16509, AMAZON-02), géolocalisé en Allemagne
   • Classé comme distributeur d'adware par Gridinsoft
   • Signalé comme malveillant dans les analyses sandbox ANY.RUN avec des indicateurs de phishing Tycoon 2FA
   • Apparu dans les rapports d'analyse Falcon Sandbox aux côtés de domaines de fraude publicitaire connus
   • Signalé par des utilisateurs dans plusieurs forums de navigateurs comme source de redirections de malvertising, y compris des incidents sur les forums de la communauté Daz3D
   • Utilise le point de terminaison de redirection red_u_plain.php avec des paramètres par campagne (s=, d=, pub=, t=)
   • La chaîne de redirection passe par gracylifestyle[.]com (Cloudflare) vers d33old9jdtt77h.cloudfront.net (Amazon CloudFront)

   Qu'est-ce que nivtrck[.]com ?

   nivtrck[.]com est le domaine de suivi que le script bloque activement via le détournement de l'API Fetch. Ce domaine n'a aucune documentation publique sur toutes les plateformes de renseignement sur les menaces, les rapports sandbox et les bases de données d'historique WHOIS. Il peut s'agir d'un service de suivi légitime dont l'attaquant veut supprimer l'attribution, ou il peut appartenir à une opération de fraude concurrente.

   Indicateurs de compromission (IOC) pour msclairty[.]com

   Type	Valeur	Objectif
   Domaine	msclairty[.]com	Délivrance du script, typosquat de Microsoft Clarity
   URL	msclairty[.]com/event.js	Script de chargement de l'étape 1
   URL	msclairty[.]com/js/[encoded].js?type=1	Charge utile obfusquée de l'étape 2
   SHA256	7ad3dcdcc83eba9298b800a9cbbc00720c35859880bf00ba7bab8883f750f0ff	Hash de event.js (chargeur), 8 599 octets
   SHA256	27e6d46c37d2cb8ef3cf21b70ce03b5090eae988f4e3923cd0902a7bde8c4e94	Hash de la charge utile (.js?type=1), 10 007 octets
   ID de campagne	id=dHRcSiYkDj4	Campagne du 2 mars 2026 (rotation quotidienne)
   ID de campagne	id=XGp2NSkTRVs	Campagne du 3 mars 2026 (rotation quotidienne)
   Domaine	discounthero[.]org	Point de terminaison de redirection pour la fraude d'affiliation
   Adresse IP	3.68.5.1	Hébergement de discounthero[.]org (AWS, Allemagne)
   ASN	AS16509 (AMAZON-02)	Infrastructure de discounthero[.]org
   Domaine	nivtrck[.]com	Tracker concurrent bloqué par le script
   Nom du cookie	__tr_luptv	Cookie d'attribution de l'attaquant ET indicateur de déduplication du chargeur
   Valeur du cookie	Date.now() - 300000	Horodatage antidaté, 5 minutes dans le passé
   ID d'affiliation	pub=twsc	Compte d'éditeur de l'attaquant pour la fraude aux commissions
   Paramètre POST du chargeur	ext: 'twsc'	Identifiant d'affiliation codé en dur dans la requête de ciblage du chargeur
   Paramètre POST du chargeur	url, referrer, unique_id	URL de la page, référent et ID de campagne envoyés au serveur
   Content-Type	application/x-www-form-urlencoded	Format de la requête POST de ciblage du chargeur
   ID de campagne	s=287	Identifiant de campagne dans l'URL de redirection
   Variante de charge utile	?type=1 (fonction type1)	Cookie stuffing d'affiliation silencieux via iframe caché
   Variante de charge utile	?type=2 (fonction type2)	Cookie stuffing + injection de contenu via le modèle {{link2}}
   Variante de charge utile	?type=3 (fonction type8)	Détournement de clics : ajoute une redirection d'affiliation aux liens sortants
   Variante de charge utile	?type=4 (fonction type9)	Détournement de clics : redirige d'abord l'utilisateur vers discounthero
   Variante de charge utile	?type=5 (fonction type11)	Redirection automatique : navigue de force vers la page après 400 ms
   Chemin URL	/us/s/red_u_plain.php	Gestionnaire de redirection de discounthero[.]org
   Certificat SSL émis	20 février 2026, 20:14:54 UTC	Domaine créé 10 jours avant le premier trafic observé
   Chargeur modifié	2 mars 2026, 09:58:50 GMT	Horodatage de dernière modification de event.js
   Première observation	2 mars 2026, 21:17:09 UTC	Trafic le plus ancien dans la télémétrie cside
   ETag	W/"2717-Eekqo9gobf+ksAb6+kvO6VgzCto"	ETag de la charge utile (inchangé sur toutes les requêtes)
   ETag	W/"2197-19cadfc7987"	ETag de event.js (inchangé sur toutes les requêtes)
   Infrastructure	Cloudflare + Express (Node.js)	Pile serveur de msclairty[.]com
   Vecteur d'injection	Extension de navigateur (non identifiée)	Mécanisme de délivrance du script

   Pourquoi cette attaque contourne-t-elle les outils de sécurité traditionnels ?

   Cette attaque contourne les outils de sécurité traditionnels pour deux raisons : le vecteur d'injection et les techniques d'évasion.

   Le script est injecté par une extension de navigateur, pas intégré dans le code source du site. Cela signifie que les en-têtes Content Security Policy ne le bloqueront pas. Les audits de balises ne le trouveront pas. Les vérifications Subresource Integrity ne s'appliquent pas. Les outils de sécurité côté serveur n'ont aucune visibilité sur ce qu'une extension de navigateur injecte dans la page à l'exécution.

   De plus, le serveur derrière msclairty[.]com filtre les requêtes de manière agressive. Les scanners de sécurité, les outils de recherche basés sur l'IA et toute requête provenant d'une adresse IP de datacenter ou d'un user-agent de bot connu reçoivent une réponse 403 Forbidden. Même si un scanner récupérait d'une façon ou d'une autre la vraie charge utile, le code source obfusqué ne contient aucune signature reconnaissable ni aucun schéma malveillant connu que l'analyse statique signalerait.

   Le script échappe également à la recherche manuelle. Il détecte les DevTools ouverts et s'arrête. Il écrase toutes les méthodes de la console. Il supprime l'iframe du DOM après 20 secondes. Il efface la console après 3 secondes.

   Le chargeur ajoute une autre couche : il accroche history.pushState, history.replaceState et popstate pour se redéclencher à chaque navigation côté client dans les applications monopages. Chaque changement de route envoie la nouvelle URL au serveur pour un ciblage actualisé. Et comme le serveur décide quelle variante de charge utile délivrer en fonction de l'URL de la page et du référent, l'analyse statique d'une seule charge utile capturée ne peut pas révéler l'étendue complète des attaques dont l'infrastructure est capable.

   Comment détecter les attaques de cookie stuffing d'affiliation comme celle-ci ?

   La détection par liste de blocage ne fonctionne pas contre ce type d'attaque. Le domaine est trop récent pour qu'un flux de menaces l'ait indexé. L'obfuscation met en échec l'analyse statique. Le serveur bloque les scanners automatisés et les outils d'IA avec des réponses 403.

   La seule méthode de détection fiable est l'analyse comportementale à l'exécution : surveiller ce que font les scripts dans le navigateur plutôt que d'analyser leur code source ou de vérifier leur domaine par rapport à une liste de blocage. La suppression de cookies, l'injection d'iframes cachés, le détournement de l'API Fetch et la suppression de la console sont tous des comportements observables clairement malveillants, quel que soit l'aspect du code source ou l'origine du script.

   C'est précisément pour cela qu'existe la surveillance de sécurité côté client en temps réel.

   Que signifie le paramètre ?type= ?

   L'URL prend un paramètre de requête ?type= qui sélectionne la charge utile d'attaque que le serveur renvoie. Nous avons confirmé cinq variantes. Chacune escalade en agressivité. Les cinq partagent le même noyau d'évasion : détection des DevTools (s'arrête si ouverts, seuil de 150 px), détournement de la console (7 méthodes écrasées), suppression de cookies (_ga, _gid, rtkclickid-store au niveau du chemin et du domaine racine), cookie d'attribution de l'attaquant (__tr_luptv = Date.now() - 300000), suppression du référent via une balise meta, et la même cible d'affiliation (discounthero[.]org avec pub=twsc et s=287).

   La valeur du paramètre ?type= (de 1 à 5) est séquentielle, mais les noms de fonctions internes ne le sont pas. Ce décalage révèle la véritable échelle de l'infrastructure.

   ?type=1 (fonction type1()) - Cookie stuffing d'affiliation silencieux

   Injecte un iframe caché de 1x1 pixel vers discounthero[.]org avec pub=twsc. L'iframe charge la chaîne de redirection d'affiliation, dépose le cookie de l'attaquant et s'autodétruit après 20 secondes. L'API Fetch est détournée pour bloquer les requêtes vers nivtrck[.]com. Le visiteur ne voit rien.

   ?type=2 (fonction type2()) - Cookie stuffing + injection de contenu

   Fait tout ce que fait type=1. Ensuite, il récupère une deuxième URL depuis une variable de modèle côté serveur {{link2}}, crée un deuxième iframe caché de 0x0, écrit le HTML récupéré dedans en utilisant contentWindow.document.write() et usurpe l'URL de l'iframe avec history.replaceState. Le deuxième iframe s'autodétruit après 15 secondes. L'espace réservé {{link2}} est rempli côté serveur par cible et pourrait délivrer des superpositions de phishing, de l'injection de publicités ou de la manipulation de page.

   ?type=3 (fonction type8()) - Détournement de clics (en piggyback)

   Pas d'iframe. Installe un écouteur d'événements de clic sur document.body. Lorsqu'un visiteur clique sur une balise `` avec un attribut href commençant par « http », le script appelle preventDefault(), puis redirige le navigateur vers l'URL d'origine avec la redirection d'affiliation discounthero[.]org ajoutée en paramètre de requête. L'utilisateur atteint toujours sa destination prévue, mais la navigation passe par la chaîne de redirection de l'attaquant en chemin.

   ?type=4 (fonction type9()) - Détournement de clics (redirection directe)

   Même interception de clics que type=3, mais la direction de redirection est inversée. Au lieu d'ajouter l'URL d'affiliation à la destination d'origine, il envoie l'utilisateur directement vers discounthero[.]org avec l'URL d'origine encodée en paramètre via encodeURIComponent(). L'utilisateur navigue visiblement d'abord à travers l'infrastructure de l'attaquant, puis est renvoyé vers sa destination prévue après le dépôt du cookie d'affiliation.

   ?type=5 (fonction type11()) - Redirection automatique (aucun clic requis)

   La variante la plus agressive. Pas d'iframe. Pas d'interception de clics. Après un délai de 400 millisecondes, le script redirige de force la page entière en utilisant window.location.search. L'utilisateur est automatiquement redirigé depuis la page qu'il consultait vers la chaîne d'affiliation discounthero[.]org. Aucune interaction requise. Le délai de 400 ms est juste suffisant pour que la suppression des cookies et le cookie __tr_luptv soient définis avant le déclenchement de la redirection.

   Les noms de fonctions ne sont pas séquentiels. Le paramètre ?type= va de 1 à 5, mais les fonctions sont nommées type1, type2, type8, type9 et type11. Les valeurs supérieures à 5 renvoient des réponses vides. Les lacunes dans la numérotation des fonctions (type3 à type7, type10) reflètent probablement des variantes retirées ou dépréciées d'itérations antérieures de cette infrastructure. Cinq types de charges utiles actives, escaladant du silencieux au forcé.