En bref

  • Une campagne baptisée BlobPhish génère ses pages de phishing directement dans la mémoire du navigateur via les Blob URL JavaScript
  • Aucune URL externe à analyser, aucun fichier sur disque : les passerelles SWG et la plupart des EDR ne voient rien passer
  • Cible prioritaire : comptes Microsoft 365, OneDrive, SharePoint, mais aussi banques US (Chase, Capital One, Schwab, AmEx)

Ce qui s'est passé

Points clés à retenir

  • Ce qui s'est passé
  • Pourquoi c'est important
  • Ce qu'il faut retenir

Les chercheurs d'ANY.RUN ont publié mardi une analyse détaillée de BlobPhish, une campagne active depuis octobre 2024 et restée jusqu'ici largement sous les radars. Le mode opératoire de ce BlobPhish phishing Microsoft 365 rompt avec les kits classiques : aucune fausse page de connexion n'est hébergée sur un serveur attaquant. La page est reconstruite intégralement côté client, à partir d'un simple loader JavaScript. Le code décode un payload encodé en base64 via atob(), instancie un objet Blob contenant le HTML du faux portail, puis génère une URL locale avec URL.createObjectURL() avant de rediriger la victime vers ce contenu. Résultat : la barre d'adresse affiche une URL blob:, le trafic réseau ne trahit aucun téléchargement de page malveillante, et les passerelles de messagerie comme les proxys web n'ont pratiquement rien à analyser. Une technique redoutablement discrète.

Conséquence : la page de phishing n'existe nulle part en tant que ressource HTTP autonome. Les moteurs de réputation d'URL ne peuvent rien scanner. Les caches de proxy ne montrent aucune réponse suspecte. Et puisque l'origine de la page est blob:https:// suivi du domaine légitime parent, plusieurs indicateurs de phishing classiques (TLS, domaine, certificat) sont court-circuités.

Les marques usurpées sont nombreuses : Microsoft 365, OneDrive, SharePoint, Chase, Capital One, FDIC, E*TRADE, Charles Schwab, Morgan Stanley, Merrill Lynch, American Express, PayPal, Intuit. Géographiquement, environ un tiers des victimes observées sont aux États-Unis, mais la campagne touche aussi Allemagne, Pologne, Espagne, Suisse, Royaume-Uni, Australie, Corée du Sud, Arabie saoudite, Qatar, Jordanie, Inde et Pakistan.

Pourquoi c'est important

BlobPhish illustre une mutation des kits de phishing : passer du serveur au navigateur, c'est priver d'efficacité une bonne partie de la chaîne de défense périmétrique. Les SWG, les filtres de mail post-clic et les bases de réputation URL n'ont pas grand-chose à analyser quand la page n'a jamais été servie en HTTP. Les équipes SOC doivent désormais composer avec une menace dont les artefacts vivent uniquement en mémoire navigateur, et qu'on ne peut détecter qu'en regardant le DOM côté endpoint ou en s'appuyant sur des signaux comportementaux. Côté risques aval : compromission de tenant M365, BEC, virements frauduleux, mouvement latéral et déploiement de ransomware.

Ce qu'il faut retenir

  • Les Blob URL transforment le navigateur en moteur de rendu pour des pages de phishing invisibles aux proxys
  • La détection passe par l'endpoint et l'analyse comportementale, pas par les passerelles classiques
  • Imposer FIDO2 ou passkeys reste la parade la plus efficace : un credential interceptable ne sert à rien sans clé matérielle

Comment bloquer un blob:https:// hostile en entreprise ?

Les CSP (Content Security Policy) permettent d'interdire l'usage des blob: comme source iframe ou navigation, mais cela suppose de contrôler les sites visités. Côté gestion centrale, les politiques navigateur (Chrome Enterprise, Edge) peuvent restreindre createObjectURL pour les sites non-corporate. Le levier le plus robuste reste cependant l'authentification résistante au phishing : passkeys ou clés FIDO2 sur les comptes M365, qui invalident le credential même intercepté.

Besoin d'un accompagnement expert ?

Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.

Articles connexes :

Prendre contact

📎 Articles complémentaires

Sources et références