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 n'était pas seulement une campagne de redirection contre des sites qui chargeaient encore un ancien utilitaire JavaScript. C'était 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 simple : les scripts tiers ne peuvent pas rester fiables indéfiniment parce qu'ils l'ont été une fois. Les propriétaires changent, le routage CDN change et les payloads secondaires changent.
TL;DR
- L'OFAC a sanctionné Funnull Technology Inc. et l'administrateur Liu Lizhi le 2025-05-29
- Treasury a lié Funnull à plus de 200 millions de dollars de pertes déclarées par des victimes aux États-Unis
- Le FBI a identifié 548 CNAMEs Funnull liés à plus de 332 000 domaines uniques
- Treasury affirme que Funnull a acheté et modifié en 2024 un dépôt de code utilisé par des développeurs web
- Les défenses côté navigateur doivent vérifier le comportement runtime des scripts, pas seulement la confiance fournisseur
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 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. cside a couvert l'incident dans The Polyfill[.]io attack explained, puis a expliqué pourquoi il était 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. Le navigateur de l'utilisateur exécute quand même le nouveau payload.
Ce que le blanchiment d'infrastructure signifie pour les équipes 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 clé n'est pas le nom de la technique. 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 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 | Documente le propriétaire, le but 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 ne voit pas tout le comportement dans les domaines autorisés |
| Surveillance 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 chaque domaine, script, route CDN ou société de façade liée d'internet.
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.
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 user agent, géographie, referrer ou é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
Ce n'est pas seulement un nettoyage Polyfill. C'est un exercice de gouvernance des scripts tiers.
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 client-side n'est pas théorique et ne se limite pas aux domaines manifestement malveillants.
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
- Treasury Takes Action Against Major Cyber Scam Facilitator
- Avis du FBI sur l'infrastructure Funnull
- Recherche Silent Push sur l'infrastructure Funnull après sanctions
- The Polyfill[.]io attack explained
- The Polyfill[.]io attack: more than just a redirect attack
- Script integrity management for ecommerce brands
