Cloudflare detecta 4 ataques JS en e-commerce con ML

¿Por qué un storefront puede parecer sano y estar comprometido?

Un atacante ya no necesita tumbar tu tienda para robarte. Hoy basta con meter un fragmento de JavaScript en el navegador del visitante mientras todo en el checkout sigue funcionando. El minorista cobra, el cliente compra y, debajo, un script redirige comisiones, apaga tu analítica o deja una puerta abierta para ejecutar código remoto. Ese es exactamente el ángulo ciego que la nueva oleada de Page Shield ML de Cloudflare salió a cazar: cuatro operaciones activas, ocho payloads en total, descubiertos en tráfico real de minoristas en línea.

Cloudflare publicó el caso este 16 de septiembre de 2026 en su blog. El dato más incómodo para cualquier equipo de seguridad no son las técnicas, sino el veredicto de los scanners clásicos: siete de los ocho payloads estaban completamente ausentes de VirusTotal, y URLScan no devolvió un veredicto malicioso para ninguno. Uno de ellos llevaba casi dos años y medio indexado en URLScan con la etiqueta «No classification» antes de que el modelo de Cloudflare lo identificara en vivo sobre un retailer real. Si tu defensa espera a que la firma aparezca en esos índices, llegas tarde.

¿Qué detectó exactamente Cloudflare en tráfico real?

Cuatro operaciones distintas que el ML de Page Shield capturó en producción. Comparten un patrón: ninguna tiene una firma universal ni una técnica común de ocultamiento. Cada una aplica sus propias compuertas para activarse y luego se queda dormida ante visitantes que no encajan con su perfil objetivo. Una requiere dispositivo móvil y franja horaria específica; otra opera sin clic del usuario; una tercera es un malware de extensiones reconvertido en backdoor; la cuarta ceba al visitante que el propio minorista pagó por adquirir.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

El modelo está construido sobre una Graph Neural Network (GNN) que no analiza JavaScript como texto plano sino como un grafo: un árbol de sintaxis que conecta símbolos y muestra qué llama a qué, qué intenta enterrar el atacante y qué sigue contactando a un servidor externo. Esa estructura le permite reconocer patrones sospechosos incluso cuando el código está minificado, con variables renombradas o parcialmente ofuscado, sin depender de una URL o un hash conocido.

Bajo el capó, el sistema tiene tres capas:

GNN primaria que marca como malicioso menos del 0,3 % del tráfico analizado.
Un LLM ligero sobre Workers AI que actúa como segunda opinión para reducir falsos positivos.
Un colegiado de modelos frontier (alrededor de seis familias, incluyendo modelos open-weight en Workers AI) que ejecuta cada script sospechoso en sesiones independientes. Sus veredictos se ponderan por el puntaje en el Artificial Analysis Intelligence Index y se agregan en una distribución sobre cuatro etiquetas: benigno, skimming de pagos (Magecart), otro malware y cryptomining. Solo cuando hay disputa o falta una mayoría de dos tercios entra un revisor humano.

Operación 1: el ladrón silencioso de comisiones por afiliados

Un domingo por la tarde, un shopper en el móvil toca un producto. En lugar de seguir el enlace, el script abre una pestaña nueva con una landing elegida por el atacante y manda la pestaña original por una ruta de afiliado del propio criminal. Si el cliente completa la compra, la comisión se acredita a una cuenta que no trajo al visitante. Si el referido venía de un socio legítimo, encima se le roba la atribución y el pago.

El script usa un MutationObserver para enganchar clicks en productos que aparecen dinámicamente tras la carga inicial, escribe un cooldown de tres días en localStorage, ejecuta el desvío en doble pestaña y enmascara sus mensajes en la consola. Algunas variantes se «pausaron» temporalmente después del Black Friday. Para colarse en la primera revisión de marketing, el dominio de entrega era un typosquat: adtargett[.]com (registrado en 2025) frente a adtarget[.]com (registrado en 1998). La ruta de entrega confirmada pasaba por Google Tag Manager → otro tag manager → script malicioso.

Operación 2: el afiliado fantasma que no necesita clics

Esta operación es más osada. El visitante abre una página de reservas, hojea opciones y nunca toca un anuncio. Mientras tanto, el script ya disparó una solicitud de afiliado dentro de un iframe invisible o mediante un enlace que se autoclickea como fallback. El navegador del usuario nunca ve nada.

La técnica combina: una puerta de red previa que llama a un servicio de geolocalización público pero ignora completamente su respuesta (probable medida anti-sandbox), tres bloques de configuración de TradeDoubler etiquetados AU/US/UK con ventanas horarias calculadas en Asia/Kolkata, una cookie throttle de una hora llamada affiliateClicked_<market> y el iframe oculto con referrer suprimido. Si el iframe falla, el script crea un <a> sin atributo target y lo pulsa programáticamente para abrir la pestaña activa del usuario. La ofuscación es simple pero efectiva: cada nombre de propiedad se construye carácter por carácter.

Operación 3: del malware de extensiones al backdoor del storefront

La familia Lnkr se hizo famosa hace años por esconderse en extensiones de navegador y redirigir resultados de Google y Bing para cobrar publicidad. Ahora, alguien reconvirtió ese código y lo plantó directamente en el HTML de un minorista online. Sobre el storefront, los módulos viejos (overlays, interceptores de búsqueda, reescritores de enlaces) se quedaron dormidos porque solo se activaban en sitios concretos. Lo que sí quedó activo fue un módulo de telemetría y ejecución remota de código que pedía instrucciones a scrprime[.]com, youronlinesearches[.]com y jullyambery[.]net, y se descargaba JavaScript arbitrario para correr en el navegador del visitante.

El script incluso conservó un truco de sus días como extensión: si alguien buscaba palabras como «virus» o «popup» en Google, el módulo se desactivaba; al segundo intento, escribía un opt-out persistente en localStorage para silenciarse definitivamente en esa máquina. El control del código que corre en los navegadores de tus clientes ya no estaba en el servidor del retailer, sino en la infraestructura del atacante.

Operación 4: el visitante que tú pagaste y el atacante te apaga

Esta es la operación más trabajada. Apunta al tráfico de pago que el minorista ya compró: campañas con UTM ppc, cpc, sms, paid, flow o campaign, en pantallas menores a 477 píxeles de ancho, dentro de las dos primeras páginas de la sesión, desde IPs móviles residenciales de EE. UU. (descarta redes corporativas, cloud, VPN, Tor, proxy y threat intel), fuera de regiones como US-NY, US-CA y US-NHDD, y fuera de ciudades como San Francisco, Plymouth o Compton. Para rematar, compara el prefijo IPv4 del visitante contra una denylist de 325 cadenas hardcodeadas (313 direcciones únicas en 249 prefijos /24), pero sin hacer matching CIDR: hace una búsqueda de substring sobre el prefijo.

Si todo encaja, el script:

Elimina del DOM los tags de nueve herramientas de observabilidad: Lucky Orange, Segment, Optimizely, New Relic, Bugsnag, LogRocket, Hotjar, Microsoft Clarity y el contenedor de Google Tag Manager.
Reemplaza las referencias a esas herramientas por un identificador dummy (hji0) para que las llamadas fallen silenciosamente.
Inyecta CSS para ocultar el chat de soporte y el formulario de contacto, cortando la línea directa con el cliente.
Purga los globales de Google Ads, derriba los slots existentes y carga Google Ads con un publisher ID del atacante (ca-pub-<reemplazo>), además de inyectar Microsoft Clarity con un project ID propio.
Como baliza secundaria, escribe una cookie _cart_dr=1 con expiración de 600 días y dispara un pixel invisible a maper[.]info que loguea IP y User-Agent.

El dominio de entrega era sdk-amazonaws[.]com (registrado en 2024), un lookalike de amazonaws.com (registrado en 2005), con un subdominio imitando a una plataforma popular de marketing para e-commerce. Ni AWS ni la plataforma suplantada estaban comprometidos: el atacante solo apilaba marcas reconocidas para superar revisiones rápidas de tags.

¿Qué significa esto para tu startup?

Para un founder con un e-commerce o un SaaS con checkout, el caso deja tres lecciones operativas:

Las firmas y los scanners reactivos no alcanzan. Siete de ocho payloads no estaban en VirusTotal. Si tu proveedor de seguridad solo compara contra bases de firmas, está viendo una foto vieja. Necesitas telemetría en el navegador del visitante final, no solo del lado del servidor.
Tu cadena de suministro de marketing es el vector. En al menos dos operaciones el script entró vía Google Tag Manager → otro tag manager → payload, y en la cuarta se disfrazó de plataforma de marketing apilando marcas reconocidas. Audita qué scripts corren en producción, quién los cargó y con qué permisos. Un tag manager mal configurado es un RCE sin tocar tu código.
Cloaking dirigido te puede dejar ciego justo en el tráfico que pagaste. Una operación capaz de apagar nueve herramientas de analítica y reescribir IDs publicitarios sobre el segmento de paid mobile significa que puedes estar viendo conversiones infladas y atribución robada sin notarlo. Revisa discrepancias entre tu ad platform y tu analytics, sobre todo en mobile de pago.

Acciones concretas que puedes aplicar esta semana:

Inventario de todos los scripts de terceros que cargan en tus páginas de checkout y thank-you, con su dominio de origen y quién los aprobó.
Política de revisión de tags: nadie sube un script nuevo al tag manager sin ticket de seguridad asociado y diff visible.
Activar una solución de monitorización client-side (tipo Page Shield, Jscrambler, Source Defense o un CSP estricto) que inspeccione lo que el navegador realmente ejecuta, no solo lo que el servidor sirve.
Comparar ID de publisher de Google Ads y project ID de Clarity entre el HTML que sirves y lo que reporta el navegador en una visita real pagada desde móvil.

Conclusión

El caso de Cloudflare es el mejor argumento que vas a leer este año para tomarte en serio la seguridad del lado del cliente. No estamos hablando de robos de tarjetas en checkout (eso es Magecart clásico, que sigue activo y según Sansec llegó a infectar el 38 % de los sitios Magento/Adobe Commerce con la variante TrojanOrders); estamos hablando de JavaScript que roba comisiones de afiliados, apaga tu analítica, suplanta tus IDs publicitarios y abre puertas traseras para ejecutar código remoto, todo mientras el storefront vende sin tropiezos. Si tu modelo de negocio depende de la atribución de marketing o de la confianza en lo que tu sitio le entrega al navegador, esta nota es una llamada a invertir en visibilidad del lado del cliente, no solo en el servidor.