Resposta rápida: a OFAC sancionou a Funnull Technology Inc. em 2025-05-29, juntamente com o administrador Liu Lizhi. Essa ação reformula o incidente Polyfill[.]io: o que parecia uma campanha de redirecionamento contra sites que ainda carregavam uma antiga utilidade JavaScript foi, na realidade, uma falha de supply chain no navegador, ligada a uma operação maior de lavagem de infraestrutura.
A lição para equipas de segurança é direta: scripts de terceiros não podem ser tratados como fiáveis para sempre só porque já foram fiáveis uma vez. Mudanças de proprietário, mudanças de encaminhamento de CDN e payloads de segunda fase podem transformar uma dependência normal do navegador num vetor de ataque.
TL;DR: sanções à Funnull e branqueamento via Polyfill
- Sanções da OFAC: A OFAC sancionou a Funnull Technology Inc. e o administrador Liu Lizhi em 2025-05-29
- 200M USD em perdas: O Treasury ligou a Funnull a mais de 200 milhões de dólares em perdas reportadas por vítimas nos EUA
- 548 CNAMEs mapeados: O FBI identificou 548 CNAMEs da Funnull ligados a mais de 332.000 domínios únicos
- Repositório comprado e alterado: O Treasury afirmou que a Funnull comprou e alterou em 2024 um repositório de código usado por programadores web para redirecionar visitantes
- Verificações em runtime necessárias: O caso Polyfill[.]io mostra por que as defesas no navegador precisam de verificações de comportamento de scripts em runtime, não apenas confiança no fornecedor
Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.
O que mudou: a Funnull é agora um fornecedor de infraestrutura sancionado
O Departamento do Tesouro dos EUA sancionou a Funnull como uma empresa sediada nas Filipinas que fornecia infraestrutura informática a centenas de milhares de sites envolvidos em esquemas de investimento com moeda virtual. O Treasury descreveu esses esquemas como pig butchering e disse que a Funnull facilitou diretamente esquemas ligados a mais de 200 milhões de dólares em perdas reportadas por vítimas nos EUA.
A mesma ação sancionou Liu Lizhi, descrito pelo Treasury como administrador da Funnull. O Treasury disse que Liu estava envolvido em documentos operacionais e tarefas que incluíam atribuir domínios a cibercriminosos para fraude de investimento, phishing e sites de apostas online.
A escala importa. O aviso do FBI publicado no mesmo dia disse que os investigadores tinham identificado 548 CNAMEs únicos da Funnull ligados a mais de 332.000 domínios únicos desde janeiro de 2025. Isto não é um único domínio mau. É uma camada de infraestrutura.
Como Polyfill[.]io se encaixa no padrão maior da Funnull
Em 2024, Polyfill[.]io já era um aviso claro sobre a supply chain do navegador. Um serviço JavaScript amplamente incorporado mudou de mãos e depois serviu redirecionamentos maliciosos a uma percentagem de utilizadores com base em condições de runtime. A empresa de segurança Sansec documentou o payload. (O CVE-2024-38526 relacionado foi atribuído ao pdoc, a ferramenta de documentação Python que carregava o polyfill.io, e não ao incidente como um todo.) A cside cobriu o caso em The Polyfill[.]io attack explained, relatou a dimensão real na nossa linha do tempo completa do Polyfill.io e explicou por que foi mais do que um ataque de redirecionamento.
A ação do Treasury contra a Funnull torna a ligação mais clara. O Treasury disse que em 2024 a Funnull comprou um repositório de código usado por programadores web e alterou o código de forma maliciosa para redirecionar visitantes de sites legítimos para sites de fraude e apostas online.
Em 2026-05-18, o PublicWWW ainda listava 61.593 páginas web que continham "polyfill.io", embora a Namecheap já tivesse tomado medidas contra o domínio malicioso depois do ataque de supply chain de 2024. Esse resíduo é o problema operacional: dependências do navegador podem continuar incorporadas muito depois de um domínio ter sido suspenso, bloqueado ou identificado publicamente como inseguro.
Esse é o padrão operacional que as equipas de segurança devem reconhecer. Um script pode ser inofensivo quando aprovado, arriscado quando muda de proprietário e malicioso quando o caminho de código muda. O proprietário do site pode não mudar uma única linha de código. O navegador do utilizador continua a executar o novo payload.
O que a lavagem de infraestrutura significa para equipas de segurança
Lavagem de infraestrutura é o uso de infraestrutura credível para ocultar ou legitimar atividade maliciosa. Em vez de alojar cada site fraudulento em servidores óbvios de baixa reputação, um operador pode encaminhar através de fornecedores cloud, CDNs, cadeias DNS e marcas de fachada que parecem normais à distância.
Para a segurança do navegador, o mais importante não é o rótulo. É a falha de controlo. Um site pode confiar numa URL de CDN porque funcionou ontem. Uma revisão de fornecedor pode aprovar um domínio porque o fornecedor era legítimo na altura. Um tag manager pode mostrar o mesmo script principal enquanto esse script carrega um recurso secundário diferente em runtime.
É por isso que a confiança baseada apenas na origem falha. O navegador não executa um questionário de fornecedor. Executa JavaScript.
| Controlo | Em que ajuda | Onde falha |
|---|---|---|
| Inventário de scripts | Mostra que scripts deveriam estar presentes | Perde comportamento em runtime e mudanças rápidas do lado do fornecedor |
| Revisão de fornecedor | Regista proprietário do negócio e aprovação | Fica desatualizada após aquisições, rebrands e mudanças de subprocessadores |
| Subresource Integrity | Bloqueia ficheiros estáticos alterados quando os hashes estão fixos | Falha com scripts dinâmicos e não cobre sub-scripts em runtime |
| Content Security Policy | Limita de onde scripts e recursos podem carregar | Exige allowlists precisas e pode falhar comportamento dentro de domínios permitidos |
| Monitorização de comportamento em runtime | Observa o que os scripts realmente carregam, mudam e fazem | Exige instrumentação na camada do navegador e revisão operacional |
Porque as sanções não acabam com o risco no navegador
As sanções podem perturbar uma empresa nomeada, congelar ativos sob jurisdição dos EUA e tornar negócios com a parte sancionada legalmente arriscados para pessoas dos EUA. Não removem automaticamente da internet todos os domínios, scripts, rotas de CDN ou empresas de fachada relacionados.
O risco pós-sanções já é visível na investigação de ameaças. A Silent Push reportou que a infraestrutura associada ao ecossistema mais amplo Triad Nexus e Funnull continuou a evoluir após as sanções de 2025, incluindo bloqueio geográfico, rotação de CNAMEs e empresas de fachada com aparência limpa.
A ação posterior do Treasury e do Reino Unido contra redes cibercriminosas do Sudeste Asiático também mostra o contexto mais amplo de aplicação da lei. A OFAC sancionou 146 alvos dentro da Prince Group Transnational Criminal Organization, enquanto a FinCEN finalizou uma regra que corta a Huione Group do sistema financeiro dos EUA. São redes grandes e adaptativas. Remover uma marca não remove o modelo de negócio.
O que fazer esta semana
Comece pelos scripts que podem tocar login, checkout, criação de conta, pagamento e fluxos com dados pessoais.
- Procure
polyfill[.]io,bootcdn[.]net,bootcss[.]com,staticfile[.]net,staticfile[.]orgeunionadjs[.]comem código fonte, tag managers, templates de CMS e snippets antigos - Remova scripts de compatibilidade mortos que os navegadores modernos já não precisam
- Mapeie cada script de terceiros para um proprietário, finalidade, âmbito de página e nível de acesso a dados
- Identifique scripts que carregam scripts adicionais, constroem URLs dinamicamente ou executam código diferente consoante o user agent, a geografia, o referrer ou o estado da sessão
- Use SRI apenas quando o script é estático e o fornecedor suporta hashes estáveis
- Reforce o CSP em fluxos sensíveis e monitorize violações antes de passar de report-only para enforcement
- Adicione monitorização em runtime para que mudanças de scripts, redirecionamentos, acesso a dados e chamadas de rede inesperadas sejam visíveis quando os utilizadores carregam a página
Trate isto como um exercício de governação de scripts de terceiros, não como uma limpeza pontual do Polyfill.
Como a cside ajuda a monitorizar o risco de scripts de terceiros
A cside trabalha na camada do navegador, onde os scripts de terceiros realmente executam. Isto importa porque logs de servidor, revisões de fornecedor e inventários estáticos perdem comportamento em runtime importante.
Com a cside, as equipas conseguem ver que scripts carregam em páginas reais, o que esses scripts chamam, como mudam e se tentam comportamento suspeito, como redirecionamentos inesperados ou acesso a dados. Essa visibilidade ajuda as equipas de segurança e conformidade a passar de "aprovámos este fornecedor uma vez" para "sabemos o que este código está a fazer agora".
As sanções contra a Funnull são um ponto de pressão útil. Mostram que o risco de supply chain do lado do cliente não é teórico e não se limita a domínios obviamente maliciosos. O risco encontra-se no espaço entre a inclusão confiável e a execução em runtime.
Em 2026-05-18, designações de sanções, indicadores de infraestrutura e fachadas ativas podem mudar. Trate os domínios e CNAMEs nomeados como pistas de investigação, não como uma blocklist completa.
Leitura adicional
- Ataque à cadeia de suprimentos do Polyfill.io: linha do tempo e análise completas
- Treasury Takes Action Against Major Cyber Scam Facilitator
- Aviso do FBI sobre infraestrutura Funnull
- Análise forense da Sansec sobre o payload do Polyfill.io
- Investigação da Silent Push sobre infraestrutura Funnull pós-sanções
- The Polyfill[.]io attack explained
- The Polyfill[.]io attack: more than just a redirect attack
- Script integrity management for ecommerce brands
