Respuesta rápida: OFAC sancionó a Funnull Technology Inc. el 2025-05-29, junto con el administrador Liu Lizhi. Esa acción replantea el incidente de Polyfill[.]io: lo que parecía una campaña de redirecciones contra sitios que todavía cargaban una utilidad antigua de JavaScript era, en realidad, un fallo de cadena de suministro en el navegador conectado con una operación mayor de blanqueo de infraestructura.
La lección para los equipos de seguridad es directa: los scripts de terceros no pueden tratarse como fiables para siempre solo porque lo fueron en algún momento. Los cambios de propietario, los cambios en el enrutamiento de CDN y los payloads de segunda fase pueden convertir una dependencia normal del navegador en una vía de ataque.
TL;DR: sanciones a Funnull y blanqueo con Polyfill
- Sanciones de OFAC: OFAC sancionó a Funnull Technology Inc. y al administrador Liu Lizhi el 2025-05-29
- 200M USD en pérdidas: Treasury vinculó a Funnull con más de 200 millones de dólares en pérdidas reportadas por víctimas en EE. UU.
- 548 CNAMEs mapeados: El FBI identificó 548 CNAMEs de Funnull vinculados a más de 332.000 dominios únicos
- Repositorio comprado y alterado: Treasury afirmó que Funnull compró y alteró en 2024 un repositorio de código usado por desarrolladores web para redirigir visitantes
- Se necesitan comprobaciones en runtime: El caso de Polyfill[.]io muestra por qué las defensas del lado del navegador necesitan comprobar el comportamiento en runtime de los scripts, no solo confiar en los proveedores
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
Qué cambió: Funnull ahora es un proveedor de infraestructura sancionado
El Departamento del Tesoro de EE. UU. sancionó a Funnull como empresa con sede en Filipinas que proporcionaba infraestructura informática a cientos de miles de sitios implicados en estafas de inversión con moneda virtual. Treasury describió esas estafas como pig butchering y dijo que Funnull facilitó directamente esquemas asociados a más de 200 millones de dólares en pérdidas reportadas por víctimas en EE. UU.
La misma acción sancionó a Liu Lizhi, descrito por Treasury como administrador de Funnull. Treasury dijo que Liu participaba en documentos operativos y en la asignación de tareas, incluyendo la asignación de dominios a ciberdelincuentes para fraude de inversión, estafas de phishing y sitios de apuestas online.
La escala importa. El aviso del FBI publicado el mismo día dijo que los investigadores habían identificado 548 CNAMEs únicos de Funnull vinculados a más de 332.000 dominios únicos desde enero de 2025. No es un solo dominio malo. Es una capa de infraestructura.
Cómo encaja Polyfill[.]io en el patrón más amplio de Funnull
En 2024, Polyfill[.]io ya era una advertencia clara sobre la cadena de suministro del navegador. Un servicio JavaScript ampliamente incrustado cambió de manos y después sirvió redirecciones maliciosas a un porcentaje de usuarios según condiciones en runtime. La empresa de seguridad Sansec documentó el payload. (El CVE-2024-38526 relacionado se asignó a pdoc, la herramienta de documentación de Python que cargaba polyfill.io, no al incidente en su conjunto.) cside cubrió el incidente en El ataque de Polyfill[.]io explicado, reportó la escala real en nuestra cronología completa de Polyfill.io y explicó por qué fue mucho más que un simple ataque de redirección.
La acción de Treasury contra Funnull hace la conexión más nítida. Treasury dijo que en 2024 Funnull compró un repositorio de código usado por desarrolladores web y alteró maliciosamente el código para redirigir a visitantes de sitios legítimos hacia sitios de estafa y de apuestas online.
El 2026-05-18, PublicWWW todavía listaba 61.593 páginas web que contenían "polyfill.io", aunque Namecheap había tomado medidas contra el dominio malicioso después del ataque de cadena de suministro de 2024. Ese residuo es el problema operativo: las dependencias del navegador pueden seguir incrustadas mucho después de que un dominio haya sido suspendido, bloqueado o identificado públicamente como inseguro.
Ese es el patrón operativo que los equipos de seguridad deben reconocer. Un script puede ser inocuo cuando se aprueba, arriesgado cuando cambia de propietario y malicioso cuando cambia la ruta del código. Puede que el propietario del sitio web no cambie ni una línea de código. El navegador del usuario seguirá ejecutando el nuevo payload.
Qué significa el blanqueo de infraestructura para los equipos de seguridad
El blanqueo de infraestructura consiste en usar infraestructura creíble para ocultar o legitimar actividad maliciosa. En lugar de alojar cada sitio de estafa en servidores obvios de baja reputación, un operador puede enrutar el tráfico a través de proveedores cloud, CDNs, cadenas DNS y marcas fachada que parecen normales vistas desde lejos.
Para la seguridad del navegador, lo más importante no es la etiqueta. Es la brecha de control. Un sitio puede confiar en una URL de CDN porque funcionaba ayer. Una revisión de proveedor puede aprobar un dominio porque el proveedor era legítimo en ese momento. Un tag manager puede mostrar el mismo script de primer nivel mientras ese script carga un recurso de segunda fase distinto en runtime.
Por eso falla la confianza basada solo en el origen. El navegador no ejecuta un cuestionario de proveedor. Ejecuta JavaScript.
| Control | En qué ayuda | Dónde se queda corto |
|---|---|---|
| Inventario de scripts | Muestra qué scripts deberían estar presentes | Pierde el comportamiento en runtime y los cambios rápidos del lado del proveedor |
| Revisión de proveedor | Captura la propiedad del negocio y la aprobación | Se queda obsoleta tras adquisiciones, rebrands y cambios de subprocesadores |
| Subresource Integrity | Bloquea archivos estáticos modificados cuando los hashes están fijados | Falla con scripts dinámicos y no cubre sub-scripts en runtime |
| Content Security Policy | Limita desde dónde pueden cargar scripts y recursos | Requiere allowlists precisas y puede pasar por alto comportamiento dentro de dominios permitidos |
| Monitorización del comportamiento en runtime | Observa qué scripts cargan, cambian y hacen realmente | Necesita instrumentación en la capa del navegador y revisión operativa |
Por qué las sanciones no acaban con el riesgo del lado del navegador
Las sanciones pueden interrumpir una empresa nombrada, congelar activos bajo jurisdicción estadounidense y hacer que hacer negocios con la parte sancionada sea legalmente arriesgado para personas estadounidenses. No eliminan automáticamente todos los dominios, scripts, rutas de CDN o empresas fachada clonadas relacionadas de internet.
El riesgo posterior a las sanciones ya es visible en la investigación de amenazas. Silent Push informó de que la infraestructura asociada al ecosistema más amplio de Triad Nexus y Funnull siguió evolucionando después de las sanciones de 2025, incluyendo bloqueo geográfico, rotación de CNAMEs y empresas fachada con aspecto limpio.
La acción posterior de EE. UU. y Reino Unido contra redes ciberdelictivas del Sudeste Asiático también muestra el contexto más amplio de aplicación de la ley. OFAC sancionó 146 objetivos dentro de la Prince Group Transnational Criminal Organization, mientras FinCEN finalizó una norma que separa a Huione Group del sistema financiero estadounidense. Son redes grandes y adaptativas. Eliminar una marca no elimina el modelo de negocio.
Qué hacer esta semana
Empieza por los scripts que pueden tocar el login, el checkout, la creación de cuentas, el pago y los flujos con datos personales.
- Busca
polyfill[.]io,bootcdn[.]net,bootcss[.]com,staticfile[.]net,staticfile[.]orgyunionadjs[.]comen el código fuente, los tag managers, las plantillas del CMS y los snippets antiguos - Elimina los scripts de compatibilidad obsoletos que los navegadores modernos ya no necesitan
- Asocia cada script de terceros a un propietario, un propósito, un alcance de página y un nivel de acceso a datos
- Identifica los scripts que cargan scripts adicionales, construyen URLs dinámicamente o ejecutan código distinto según el user agent, la geografía, el referrer o el estado de la sesión
- Usa SRI solo cuando el script sea estático y el proveedor admita hashes estables
- Refuerza la CSP en los flujos sensibles y monitoriza las violaciones antes de pasar de report-only a enforcement
- Añade monitorización en runtime para que los cambios de scripts, las redirecciones, el acceso a datos y las llamadas de red inesperadas sean visibles cuando los usuarios cargan la página
Trata esto como un ejercicio de gobierno de scripts de terceros, no como una limpieza puntual de Polyfill.
Cómo ayuda cside a monitorizar el riesgo de los scripts de terceros
cside trabaja en la capa del navegador, donde los scripts de terceros realmente se ejecutan. Eso importa porque los logs del servidor, las revisiones de proveedor y los inventarios estáticos pasan por alto un comportamiento en runtime importante.
Con cside, los equipos pueden ver qué scripts se cargan en páginas reales, a qué llaman esos scripts, cómo cambian y si intentan comportamientos sospechosos como redirecciones inesperadas o acceso a datos. Esa visibilidad ayuda a los equipos de seguridad y cumplimiento a pasar de "aprobamos este proveedor una vez" a "sabemos qué está haciendo este código ahora".
Las sanciones a Funnull son un buen punto de presión. Muestran que el riesgo de cadena de suministro del lado del cliente no es teórico y que no se limita a dominios obviamente maliciosos. El riesgo se sitúa en la brecha entre la inclusión de confianza y la ejecución en runtime.
A fecha de 2026-05-18, las designaciones de sanciones, los indicadores de infraestructura y las fachadas activas pueden cambiar. Trata los dominios y CNAMEs nombrados como pistas de investigación, no como una blocklist completa.
Lecturas adicionales
- Ataque a la cadena de suministro de Polyfill.io: cronología y análisis completos
- Treasury Takes Action Against Major Cyber Scam Facilitator
- Aviso del FBI sobre la infraestructura de Funnull
- Análisis forense de Sansec del payload de Polyfill.io
- Investigación de Silent Push sobre la infraestructura de Funnull tras las sanciones
- El ataque de Polyfill[.]io explicado
- El ataque de Polyfill[.]io: mucho más que un simple ataque de redirección
- Gestión de la integridad de scripts para marcas de ecommerce
