Source du dumping illicite que l'arme exécutable dans le navigateur et empêche la détection de signature

L'opération antidumping surnommée Source représente une variante technique intéressante et inquiétante: au lieu de servir un exécutable malveillant complet à partir d'une URL fixe, il force le navigateur de la victime à construire le binaire final du côté du client combinant un temps d'exécution légitime (Bun) avec des fragments contrôlés par l'attaquant et des données pseudo-aléatoire. Selon l'analyse publique, la campagne est active depuis la fin de 2024 et a utilisé des supplantations convaincantes (TradingView, Solana, Luno) pour attirer les commerçants de détail et les utilisateurs de cryptomonedas dans plusieurs pays et langues.

La nouveauté d'un point de vue technique n'est pas une opération de défaillance du navigateur, mais une orchestration web standard des API : la page d'atterrissage enregistre un ServicWorker, crée un SharedWorker intégré et demande un paramètre / config un modèle et des valeurs de session. De là, le navigateur télécharge un Bun "propre" et les fragments exécutables (en-tête PE, tables de section et une section .bun avec octecode) sur Base64; le travailleur génère un flux d'octet avec AES-CTR et réassemble l'exécutable suivant le modèle, en passant finalement le fichier au ServiceWorker pour être utilisé comme téléchargement avec un Contenu-Disposition. Le résultat pratique est que il n'y a pas de "malware fini" passant avec un hasch stable, ce qui complique les détections basées sur des signatures statiques.

Il y a des contre-mesures et des limitations techniques à souligner. Tout d'abord, la technique ne supprime pas la marque du Web, de sorte que Windows continuera à enregistrer la page d'accueil comme source du téléchargement; cela maintient une piste médico-légale, bien qu'il puisse cacher le domaine qui a fourni l'exécution. Deuxièmement, la campagne n'a pas besoin d'une vulnérabilité du navigateur : son succès dépend du téléchargement ou de l'exécution du binaire livré à partir de la page malveillante, et en s'appuyant sur un installateur obtenu par une annonce supplantée.

Les implications pour les défenseurs et les utilisateurs sont claires: Le problème est la chaîne complète. Bloquer ou surveiller uniquement le fichier final - lorsqu'il n'existe pas entièrement sur le réseau - est insuffisant. L'équipement de réponse et de détection doit instruire et corréler les signaux de tout le flux: note référence, comportement d'empreintes digitales sur la page d'atterrissage, enregistrement ServicWorker / Shareworker, requêtes à / config, fiches aux domaines secondaires qui fournissent des runtimes (par exemple, les domaines qui hébergent Bun binaire dans les incidents examinés) et l'émergence de grands blobs Base64 ou des modèles de streaming de téléchargements.

Dans la pratique, pour les utilisateurs et les gestionnaires, les recommandations prioritaires ne diffèrent pas d'autres campagnes antidumping axées sur le téléchargement : installer des logiciels de négociation ou des portefeuilles uniquement à partir des sites officiels du fournisseur, méfiance envers les annonces qui promettent des téléchargements rapides ou des raccourcis, et préfèrent les signatures numériques et les canaux officiels. Pour les organisations, il convient d'appliquer des politiques d'isolement de téléchargement (p. ex., des téléchargements audités ou exécutés dans des environnements contenorisés ou des bacs à sable), des politiques de liste blanche pour les installateurs et des contrôles EDR / NDLP qui enregistrent les exécutions initiées par des processus « inhabituels » ou par des fichiers téléchargés à partir de pages externes.

De la couche technique avancée, il y a des mesures concrètes que les défenses peuvent mettre en œuvre : pour implémenter des journaux pour détecter les enregistrements de ServiceWorker / Shareworker et les réponses à / config, pour bloquer l'hébergement d'exécutions non autorisées sur le réseau sortant, et pour créer des règles qui corrélent la navigation des annonces aux téléchargements desservis via Streams avec des en-têtes Content-Disposition. Il est également utile de générer des règles de détection qui cherchent des fragments massifs de Base64 dans les réponses de configuration ou l'utilisation de noms de messages caractéristiques de bibliothèque en streaming (comme l'architecture StreamSaver) que la campagne a utilisés dans ses itérations précédentes. Ces signaux ne sont pas infaillibles, mais ils permettent de tracer la chaîne complète qui reste sur le réseau même si le binaire final varie par session.

Il n'y a pas de "patch" de navigateur pour ce modèle: la défense technique efficace combine les politiques de navigation, la formation des utilisateurs et la télémétrie complète. L'adoption de l'isolement de navigation (isolement de navigateur), les restrictions de téléchargement de politiques de groupe dans les environnements d'entreprise et l'analyse automatique des artefacts enregistrés par MotW et les ServicWorkers sont des leviers pratiques. Pour comprendre les limites techniques du Web Mark, veuillez consulter la documentation Microsoft sur MotW : https: / / learn.microsoft.com / fr-us / windows / win32 / windust / marque-of-the-web.

Pour ceux qui enquêtent ou construisent des détections, il est pertinent de connaître le temps d'exécution en cause: Bun est un environnement JavaScript / TypeScript avec la possibilité de compiler et d'emballer des applications, et son utilisation légitime explique pourquoi les attaquants l'utilisent comme base pour assembler des exécutables dans le navigateur; plus d'informations techniques sur Bun est disponible sur leur site officiel: https: / / bun.sh. De plus, l'architecture de téléchargement en streaming utilisée dans les phases précédentes est basée sur des modèles connus (StreamSaver), dont la mise en œuvre publique peut aider à identifier les variations: https: / / github.com / jimmywarting / StreamSaver.js.

Enfin, pour l'équipement d'intervention : préserver et corréler les artefacts est essentiel. Si des captures réseau et des enregistrements de navigateur sont disponibles, recherchez des demandes de / config, les domaines secondaires qui ont servi les runtimes, les blobs de base64 possibles et la chaîne de messages entre la page, le SharedWorker et le ServicWorker vous permettra de reconstruire l'échantillon même si chaque session produit un hash différent. La réalité opérationnelle est que cette technique complique les indicateurs statiques, mais laisse plusieurs pistes dynamiques et d'infrastructure qui, bien instrumentées, permettent la détection et l'atténuation.