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é

Les chercheurs d'ANY.RUN ont publié mardi une analyse détaillée d'une campagne baptisée BlobPhish, active depuis octobre 2024 mais passée largement sous les radars. Plutôt que d'héberger une fausse page de connexion sur un serveur attaquant, BlobPhish reconstruit la page entièrement côté client à partir d'un loader JavaScript. Le code décode un payload encodé en base64 via atob(), instancie un objet Blob de type text/html, génère une URL au format blob:https:// et y redirige le navigateur — sans aucune interaction visible pour l'utilisateur.

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