Réponse rapide : l'OFAC a sanctionné Funnull Technology Inc. le 2025-05-29, ainsi que l'administrateur Liu Lizhi. Cette action change la lecture de l'incident Polyfill[.]io : ce qui ressemblait à une campagne de redirection contre des sites qui chargeaient encore un ancien utilitaire JavaScript était en réalité une faille de chaîne d'approvisionnement côté navigateur, liée à une opération plus large de blanchiment d'infrastructure.
La leçon pour les équipes de sécurité est directe : les scripts tiers ne peuvent pas être considérés comme fiables pour toujours simplement parce qu'ils l'ont été une fois. Les changements de propriétaire, les changements de routage CDN et les payloads de second niveau peuvent transformer une dépendance navigateur normale en chemin d'attaque.
TL;DR : sanctions Funnull et blanchiment via Polyfill
- Sanctions de l'OFAC : L'OFAC a sanctionné Funnull Technology Inc. et l'administrateur Liu Lizhi le 2025-05-29
- 200 M$ de pertes : Treasury a lié Funnull à plus de 200 millions de dollars de pertes déclarées par des victimes aux États-Unis
- 548 CNAMEs cartographiés : Le FBI a identifié 548 CNAMEs Funnull liés à plus de 332 000 domaines uniques
- Dépôt acheté et altéré : Treasury affirme que Funnull a acheté et modifié en 2024 un dépôt de code utilisé par des développeurs web pour rediriger les visiteurs
- Vérifications runtime nécessaires : Le cas Polyfill[.]io montre pourquoi les défenses côté navigateur ont besoin de vérifications du comportement runtime des scripts, pas seulement de la confiance envers le fournisseur
Peu de temps ? Découvrez le blocage Magecart et skimmer dans le navigateur de cside. Elle couvre tout ce qui suit en un seul déploiement.
Ce qui a changé : Funnull est maintenant un fournisseur d'infrastructure sanctionné
Le Département du Trésor américain a sanctionné Funnull, une société basée aux Philippines qui fournissait une infrastructure informatique à des centaines de milliers de sites impliqués dans des escroqueries d'investissement en monnaie virtuelle. Treasury a décrit ces escroqueries comme du pig butchering et a indiqué que Funnull avait directement facilité des schémas associés à plus de 200 millions de dollars de pertes déclarées par des victimes aux États-Unis.
La même action a sanctionné Liu Lizhi, décrit par Treasury comme administrateur de Funnull. Treasury a indiqué que Liu participait à des documents opérationnels et à des tâches incluant l'attribution de domaines à des cybercriminels pour de la fraude à l'investissement, du phishing et des sites de jeux d'argent en ligne.
L'échelle compte. L'avis du FBI publié le même jour indique que les enquêteurs avaient identifié 548 CNAMEs Funnull uniques liés à plus de 332 000 domaines uniques depuis janvier 2025. Ce n'est pas un seul mauvais domaine. C'est une couche d'infrastructure.
Comment Polyfill[.]io s'inscrit dans le schéma plus large de Funnull
En 2024, Polyfill[.]io était déjà un avertissement clair sur la chaîne d'approvisionnement du navigateur. Un service JavaScript largement intégré a changé de mains, puis a servi des redirections malveillantes à une partie des utilisateurs selon des conditions runtime. La société de sécurité Sansec a documenté la charge utile. (La CVE-2024-38526 associée a été attribuée à pdoc, l'outil de documentation Python qui chargeait polyfill.io, et non à l'incident dans son ensemble.) cside a couvert l'incident dans L'attaque Polyfill[.]io expliquée, a signalé l'ampleur réelle dans notre chronologie complète de Polyfill.io, et a expliqué pourquoi il était bien plus qu'une simple attaque de redirection.
L'action de Treasury contre Funnull rend le lien plus net. Treasury a déclaré qu'en 2024 Funnull avait acheté un dépôt de code utilisé par des développeurs web et l'avait modifié de manière malveillante pour rediriger les visiteurs de sites légitimes vers des sites d'escroquerie et de jeux d'argent en ligne.
Au 2026-05-18, PublicWWW listait encore 61 593 pages web contenant "polyfill.io", même si Namecheap avait pris des mesures contre le domaine malveillant après l'attaque de chaîne d'approvisionnement de 2024. Ce résidu est le problème opérationnel : les dépendances navigateur peuvent rester intégrées longtemps après qu'un domaine a été suspendu, bloqué ou publiquement identifié comme non sûr.
C'est le modèle opérationnel que les équipes de sécurité doivent reconnaître. Un script peut être inoffensif au moment de son approbation, risqué après un changement de propriétaire et malveillant lorsque le chemin de code change. Le propriétaire du site peut ne changer aucune ligne de code. Le navigateur de l'utilisateur exécute quand même le nouveau payload.
Ce que le blanchiment d'infrastructure signifie pour les équipes de sécurité
Le blanchiment d'infrastructure consiste à utiliser une infrastructure crédible pour masquer ou légitimer une activité malveillante. Au lieu d'héberger chaque site frauduleux sur des serveurs à faible réputation évidente, un opérateur peut passer par des fournisseurs cloud, des CDN, des chaînes DNS et des marques de façade qui semblent normales de loin.
Pour la sécurité du navigateur, le point le plus important n'est pas l'étiquette. C'est l'écart de contrôle. Un site peut faire confiance à une URL CDN parce qu'elle fonctionnait hier. Une revue fournisseur peut approuver un domaine parce que le fournisseur était légitime à ce moment-là. Un tag manager peut afficher le même script principal pendant que ce script charge une ressource secondaire différente au runtime.
C'est pourquoi la confiance basée seulement sur la source échoue. Le navigateur n'exécute pas un questionnaire fournisseur. Il exécute du JavaScript.
| Contrôle | Ce qu'il aide à faire | Là où il échoue |
|---|---|---|
| Inventaire des scripts | Montre quels scripts sont censés être présents | Rate le comportement runtime et les changements rapides côté fournisseur |
| Revue fournisseur | Capture la propriété commerciale et l'approbation | Devient obsolète après acquisitions, rebrands et changements de sous-traitants |
| Subresource Integrity | Bloque les fichiers statiques modifiés quand les hashes sont fixés | Casse avec les scripts dynamiques et ne couvre pas les sous-scripts runtime |
| Content Security Policy | Limite les origines de chargement des scripts et ressources | Exige des allowlists précises et peut manquer le comportement à l'intérieur des domaines autorisés |
| Surveillance du comportement runtime | Observe ce que les scripts chargent, changent et font réellement | Nécessite une instrumentation navigateur et une revue opérationnelle |
Pourquoi les sanctions ne mettent pas fin au risque côté navigateur
Les sanctions peuvent perturber une société nommée, geler des actifs sous juridiction américaine et rendre les échanges avec la partie sanctionnée juridiquement risqués pour les personnes américaines. Elles ne suppriment pas automatiquement d'Internet chaque domaine, script, route CDN ou société de façade clonée qui y est associé.
Le risque post-sanctions est déjà visible dans la recherche de threat intelligence. Silent Push a rapporté que l'infrastructure associée à l'écosystème plus large Triad Nexus et Funnull avait continué à évoluer après les sanctions de 2025, avec blocage géographique, rotation de CNAMEs et sociétés de façade à l'apparence propre.
L'action ultérieure de Treasury et du Royaume-Uni contre les réseaux cybercriminels d'Asie du Sud-Est montre aussi le contexte d'application plus large. L'OFAC a sanctionné 146 cibles au sein du Prince Group Transnational Criminal Organization, tandis que FinCEN a finalisé une règle coupant Huione Group du système financier américain. Ce sont de grands réseaux adaptatifs. Supprimer une marque ne supprime pas le modèle économique.
Que faire cette semaine
Commencez par les scripts qui peuvent toucher les parcours de connexion, checkout, création de compte, paiement et données personnelles.
- Recherchez
polyfill[.]io,bootcdn[.]net,bootcss[.]com,staticfile[.]net,staticfile[.]orgetunionadjs[.]comdans le code source, les tag managers, les modèles CMS et les anciens snippets - Supprimez les scripts de compatibilité morts dont les navigateurs modernes n'ont plus besoin
- Associez chaque script tiers à un propriétaire, un but, un périmètre de pages et un niveau d'accès aux données
- Identifiez les scripts qui chargent d'autres scripts, construisent des URLs dynamiquement ou exécutent un code différent selon le user agent, la géographie, le referrer ou l'état de session
- Utilisez SRI seulement quand le script est statique et que le fournisseur prend en charge des hashes stables
- Renforcez CSP sur les parcours sensibles, puis surveillez les violations avant de passer de report-only à enforcement
- Ajoutez une surveillance runtime afin de voir les changements de scripts, redirections, accès aux données et appels réseau inattendus au chargement des pages
Considérez cela comme un exercice de gouvernance des scripts tiers, pas comme un nettoyage Polyfill ponctuel.
Comment cside aide à surveiller le risque des scripts tiers
cside travaille à la couche navigateur, là où les scripts tiers s'exécutent réellement. C'est important parce que les logs serveur, les revues fournisseur et les inventaires statiques ratent des comportements runtime importants.
Avec cside, les équipes peuvent voir quels scripts se chargent sur les vraies pages, ce qu'ils appellent, comment ils changent et s'ils tentent des comportements suspects comme des redirections inattendues ou des accès aux données. Cette visibilité aide les équipes sécurité et conformité à passer de "nous avons approuvé ce fournisseur une fois" à "nous savons ce que ce code fait maintenant".
Les sanctions contre Funnull sont un signal utile. Elles montrent que le risque de chaîne d'approvisionnement côté client n'est pas théorique et ne se limite pas aux domaines manifestement malveillants. Le risque se situe dans l'écart entre l'inclusion approuvée et l'exécution au runtime.
Au 2026-05-18, les désignations de sanctions, les indicateurs d'infrastructure et les façades actives peuvent changer. Traitez les domaines et CNAMEs nommés comme des pistes d'enquête, pas comme une blocklist complète.
Pour aller plus loin
- Attaque de la chaîne d'approvisionnement Polyfill.io : chronologie complète et analyse
- Treasury Takes Action Against Major Cyber Scam Facilitator
- Avis du FBI sur l'infrastructure Funnull
- Analyse forensique de Sansec sur la charge utile Polyfill.io
- Recherche Silent Push sur l'infrastructure Funnull après sanctions
- L'attaque Polyfill[.]io expliquée
- L'attaque Polyfill[.]io : bien plus qu'une simple attaque de redirection
- Gestion de l'intégrité des scripts pour les marques e-commerce
