Comment un simple script de suivi a détourné des paiements en cryptomonnaie sur le Web

La technologie publicitaire est la matière noire de l'Internet moderne. Elle est invisible pour l'utilisateur moyen, pourtant elle exerce une influence massive sur la manière dont les données circulent sur le web. Lorsque cette couche invisible défaille, l'impact se propage instantanément sur des milliers de sites web sans lien entre eux. Le 27 juillet 2026, Adform a découvert que l'un de ses principaux scripts de suivi avait été retourné contre ses utilisateurs. Une compromission de la chaîne d'approvisionnement a permis à des attaquants d'injecter du code malveillant dans un fichier JavaScript largement utilisé, le transformant en un outil qui réécrit les adresses de portefeuilles de cryptomonnaies en temps réel.

J'ai passé ma matinée à analyser les échantillons capturés du script malveillant. La compromission cible trackpoint-async.js, un fichier servi depuis l'infrastructure d'Adform. Comme ce script est intégré dans les en-têtes d'environ 1 800 sites clients pour faciliter l'analyse publicitaire, les attaquants n'ont pas eu besoin de s'introduire dans ces entreprises individuellement. Ils ont simplement empoisonné le puits. Une fois le script altéré chargé dans le navigateur d'un visiteur, il a commencé à surveiller le modèle d'objet de document (DOM) pour détecter des motifs spécifiques ressemblant à des adresses Bitcoin, Ethereum ou Tron.

Le risque invisible des dépendances tierces

L'architecture web moderne repose sur la confiance implicite accordée aux ressources tierces. Lorsqu'un développeur ajoute une ligne de code pour appeler un script provenant d'un fournisseur mondial, il accorde à ce fournisseur un contrôle significatif sur l'expérience utilisateur. Cet incident est un exemple d'école d'une attaque de la chaîne d'approvisionnement où la relation de confiance est exploitée. Le script en question, trackpoint-async.js, est conçu pour s'exécuter sur l'ensemble des sites web ou sur des sections spécifiques. Dans ce cas, les attaquants ont ajouté deux blocs de code malveillants à la fin de la bibliothèque légitime.

Du point de vue du risque, c'est un scénario de cauchemar pour tout administrateur de site. Vous pouvez avoir une posture de sécurité parfaite, un serveur durci et un processus rigoureux de révision interne du code, pourtant un seul script externe peut toujours compromettre vos utilisateurs. Les attaquants ont contourné le périmètre réseau en passant par une porte dérobée qui est presque toujours laissée ouverte pour les outils de marketing et d'analyse. Cela démontre pourquoi le concept de périmètre réseau est un fossé de château obsolète. Si vous autorisez des scripts externes à s'exécuter avec des privilèges élevés sur votre site, vous avez effectivement invité un étranger à gérer votre sécurité.

Anatomie de la compromission de Trackpoint

L'analyse technique des blocs malveillants révèle un effort ciblé pour détourner les transactions financières. Le code utilise une clé XOR de six octets pour obfusquer les adresses de portefeuilles de remplacement, une tactique courante pour échapper à la détection basique basée sur les signatures. Une fois que le script s'exécute, il lance deux chemins d'attaque distincts. Le premier bloc se concentre sur le presse-papiers du système. Il surveille l'événement de copie et tente de lire le presse-papiers toutes les quatre secondes. S'il identifie une chaîne correspondant à un modèle de portefeuille de cryptomonnaie, il remplace cette chaîne par une adresse de portefeuille appartenant à l'attaquant.

En coulisses, le deuxième bloc de code est encore plus invasif. Il parcourt les nœuds de texte du document et surveille chaque champ de saisie, zone de texte et élément éditable. Lorsqu'un utilisateur tape ou colle une adresse dans un champ de formulaire, le script intercepte l'événement et réécrit la valeur. Il va même jusqu'à restaurer la position du curseur après la réécriture pour s'assurer que l'utilisateur ne remarque pas le changement. Ce niveau de manipulation granulaire garantit que même si un utilisateur contourne le presse-papiers en tapant une adresse manuellement, la transaction reste vulnérable au détournement.

Le presse-papiers est un environnement contesté

Le chercheur indépendant Kevin Beaumont a noté un trait particulièrement agressif de ce logiciel malveillant. Même si un utilisateur remarque que l'adresse est incorrecte et tente de copier à nouveau l'adresse du portefeuille original, le script continue de la remplacer. Cette persistance rend l'environnement du navigateur lui-même indigne de confiance. Lors d'une brèche comme celle-ci, le navigateur devient un agent malveillant agissant contre les intérêts de l'utilisateur.

Du point de vue de l'utilisateur final, l'attaque est presque entièrement silencieuse. Il n'y a pas de fenêtres contextuelles, pas de ralentissements, ni de signes évidents d'infection du système. Le logiciel malveillant ne tente pas d'installer de logiciel ou d'établir une persistance sur le disque dur. Il n'existe que dans la mémoire volatile de l'onglet du navigateur. Une fois que l'utilisateur ferme la page concernée, le processus malveillant s'arrête. Cependant, les dommages surviennent dans les secondes nécessaires pour cliquer sur un bouton d'envoi. Une seule adresse modifiée au moment du paiement suffit à rediriger des milliers de dollars d'une manière qui est fonctionnellement irréversible sur une blockchain décentralisée.

Réconcilier le conflit de calendrier

Il existe une divergence entre le rapport d'incident officiel et les observations indépendantes. Adform identifie le 27 juillet comme la date de l'incident et affirme avoir supprimé le code rapidement. Kevin Beaumont a rapporté avoir vu une activité malveillante via Adform pendant au moins une semaine avant cette date. Cet écart de durée est un problème important pour l'évaluation des risques. Si le script a été actif pendant sept jours au lieu d'un, le nombre de visiteurs exposés augmente de plusieurs ordres de grandeur. Adform sert environ 1,5 milliard de publicités quotidiennement dans 180 pays. Même si seule une petite fraction de ces publicités portait la charge utile malveillante, le pool de victimes potentielles est énorme.

À titre de contre-mesure, Adform a conseillé à tous les utilisateurs de vider le cache de leur navigateur. C'est une étape vitale car la version malveillante de trackpoint-async.js peut rester stockée localement sur l'ordinateur d'un utilisateur même après le correctif côté serveur. Si le navigateur charge la version en cache du script, l'attaque reste active. Cela met en évidence une faille persistante dans la sécurité web où la longévité d'un cache peut prolonger la vie d'une menace de sécurité longtemps après le déploiement d'un correctif.

Évaluation des capacités d'exfiltration

L'un des aspects les plus préoccupants du code est sa communication avec un serveur externe. Le script tente d'envoyer une requête HTTP à une adresse IP (84.32.102[.]230) lors du chargement de la page. Cette requête inclut le nom d'hôte et le chemin spécifique de la page que le visiteur consulte actuellement. Adform a déclaré n'avoir trouvé aucune preuve que les adresses IP ou l'historique de navigation des visiteurs aient atteint les attaquants. Cependant, l'avis d'incident admet qu'une telle transmission était techniquement possible compte tenu de la construction du code.

D'après mon expérience dans l'analyse des APT et des brèches de la chaîne d'approvisionnement, les attaquants incluent rarement des capacités d'exfiltration de données sans l'intention de les utiliser. Les données de nom d'hôte et de chemin fournissent aux opérateurs une carte en direct des sites qui servent avec succès leur logiciel malveillant. Cela les aide à prioriser leurs cibles et à mesurer l'efficacité de leur compromission. De manière proactive, nous devons supposer que toute donnée à laquelle le script pouvait accéder a potentiellement été enregistrée par le serveur de commande et de contrôle de l'attaquant.

Mesures défensives pour le web moderne

Cet incident sert de rappel brutal que les scripts tiers sont un vecteur majeur de risque systémique. Pour s'en défendre, les organisations doivent s'orienter vers un modèle de sécurité granulaire. L'utilisation des hachages d'intégrité des sous-ressources (SRI) est une défense de premier ordre. Le SRI permet à un navigateur de vérifier qu'un script récupéré n'a pas été manipulé. Si le hachage du fichier sur le serveur ne correspond pas au hachage défini dans le code du site web, le navigateur refuse de l'exécuter. Si les clients d'Adform avaient implémenté le SRI pour trackpoint-async.js, la version malveillante aurait été bloquée automatiquement.

Une autre défense critique est la politique de sécurité du contenu (CSP). Une CSP bien configurée peut restreindre les domaines à partir desquels les scripts peuvent être chargés et les empêcher d'envoyer des données à des adresses IP externes non autorisées. Si une CSP avait été en place pour bloquer explicitement les connexions à l'adresse IP de l'attaquant, la tentative d'exfiltration de données aurait échoué. La sécurité n'est pas un outil unique mais une série de couches superposées. Lorsqu'une couche est compromise, les autres doivent être prêtes à pallier la défaillance.

En fin de compte, la responsabilité de vérifier une transaction incombe à l'utilisateur. La défense la plus efficace dans ce cas précis est la plus simple : vérifiez toujours l'adresse de destination via un second canal ou en vérifiant chaque caractère avant de cliquer sur envoyer. Dans un monde où le code même que vous utilisez pour naviguer sur le web peut se retourner contre vous, une paranoïa saine est une exigence fonctionnelle pour la vie numérique.

Points clés pour les responsables informatiques

• Auditez tous les scripts tiers s'exécutant actuellement sur vos environnements de production et supprimez tous ceux qui ne sont pas critiques pour la mission.
• Implémentez des hachages d'intégrité des sous-ressources (SRI) pour toutes les dépendances JavaScript externes afin d'empêcher l'exécution de code non autorisé.
• Renforcez les politiques de sécurité du contenu (CSP) pour restreindre l'exécution des scripts et l'exfiltration de données vers des domaines connus et de confiance.
• Appliquez une approche "Zero Trust" aux ressources côté client en supposant que toute dépendance externe peut être compromise à la source.

Sources

• Adform Incident Notice (July 2026)
• MITRE ATT&CK Framework: Supply Chain Compromise (T1195)
• NIST Special Publication 800-161: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations

Avertissement : Cet article est fourni à des fins d'information et d'éducation uniquement et ne remplace pas un audit de cybersécurité professionnel ou un service de réponse aux incidents.