Cuando una carga útil de Magecart se esconde dentro de los datos EXIF de un favicon de terceros cargado dinámicamente, ningún escáner de repositorio la detectará, porque el código malicioso nunca toca su repositorio. A medida que los equipos adoptan Claude Code Security para el análisis estático, este es el límite técnico exacto donde se detiene el escaneo del código de IA y comienza la ejecución del tiempo de ejecución del lado del cliente.
Está disponible un análisis detallado de dónde se detiene Claude Code Security y qué cubre el monitoreo del tiempo de ejecución. aquí.
A Desnatador de carro mágico descubierto recientemente en la naturaleza utilizaba una cadena de carga de tres etapas para ocultar su carga útil dentro de los metadatos EXIF de un favicon: nunca tocaba el código fuente del comerciante, nunca aparecía en un repositorio y se ejecutaba completamente en el navegador del comprador al momento de pagar. El ataque plantea una pregunta que vale la pena precisar: ¿qué categoría de herramienta se supone que debe detectar esto?
Magecart vive fuera de su código base
Los ataques al estilo Magecart rara vez se refieren a vulnerabilidades clásicas en su propio código fuente. Son infiltraciones en la cadena de suministro. El JavaScript malicioso generalmente llega a través de activos de terceros comprometidos: administradores de etiquetas, widgets de pago/pago, herramientas de análisis, scripts alojados en CDN e imágenes que se cargan en el navegador en tiempo de ejecución. La organización víctima no escribió ese código, no lo revisa en las relaciones públicas y, a menudo, ni siquiera existe en su repositorio.
Eso significa que una herramienta de análisis estático basada en repositorio, como Claude Code Security, está limitada por diseño en este escenario, porque solo puede analizar lo que hay en el repositorio o lo que usted le proporciona explícitamente. Cualquier skimmer que viva únicamente en recursos de terceros modificados o archivos binarios cargados dinámicamente en producción nunca entra en su campo de visión. Eso no es un error en el producto; es una discrepancia en el alcance.
El flujo de ataque: cómo se esconde el skimmer
Aquí está el cargador inicial que se ve en los sitios web comprometidos:
Este código auxiliar carga dinámicamente un script desde lo que parece ser una URL CDN legítima de Shopify. Luego, el script cargado construye la URL maliciosa real utilizando matrices de índice ofuscadas:
Una vez decodificado, esto apunta a //b4dfa5[.]xyz/favicon.ico. Lo que sucede a continuación es donde la técnica se vuelve interesante: el script recupera el favicon como datos binarios, analiza los metadatos EXIF para extraer una cadena maliciosa y la ejecuta a través de la nueva Función(): la carga útil se encuentra dentro de los metadatos de la imagen, por lo que es invisible para cualquier cosa que no esté observando el navegador en tiempo de ejecución.
La exfiltración final llama a POST los datos de pago robados de forma silenciosa a un servidor controlado por el atacante:
La cadena tiene cuatro propiedades que son importantes para la discusión sobre herramientas que sigue: el cargador inicial parece una inclusión benigna de terceros; la carga útil está oculta en metadatos de imágenes binarias; la exfiltración ocurre directamente desde el navegador del comprador; y nada de esto requiere tocar el código fuente del propio comerciante.
Lo que Claude Code Security puede y no puede ver
Claude Code Security está diseñado para escanear bases de código, rastrear flujos de datos y sugerir soluciones para vulnerabilidades en el código que usted o sus equipos escriben. Eso lo hace útil para proteger aplicaciones propias, pero también define sus puntos ciegos para esta clase de ataque.
En este escenario, no tiene visibilidad práctica del código malicioso que solo se inyecta en scripts hospedados por terceros, CDN o administradores de etiquetas que nunca se almacenan en sus repositorios. Tampoco puede interrogar cargas útiles ocultas en activos binarios como favicons o imágenes que no forman parte de su árbol de origen. No puede evaluar el riesgo o la reputación activa de los dominios controlados por atacantes que solo aparecen en tiempo de ejecución, y la detección en tiempo real de solicitudes de red anómalas del lado del navegador durante el pago también está fuera de su alcance.
Donde podría contribuir (aunque no como control principal) sería en los casos en que su propio código contenga lógica dinámica de inyección de scripts, un patrón que una herramienta de análisis de código puede marcar como riesgoso. Y si el código propio codifica puntos finales de exfiltración sospechosos o utiliza una lógica de recopilación de datos insegura, el análisis estático puede resaltar esos flujos para su revisión.
Las cuatro filas superiores son las que más importan en un escenario de Magecart, y Claude Code Security no tiene visibilidad en tiempo de ejecución de ninguna de ellas.
Los dos últimos representan una amenaza fundamentalmente diferente: un desarrollador escribe accidentalmente código de apariencia maliciosa en su propio repositorio.
Magecart es un vector, no toda la superficie de ataque
La técnica de esteganografía de favicon anterior es sofisticada, pero es un ejemplo de un patrón más amplio. Los ataques a la cadena de suministro web llegan a través de varios mecanismos distintos, cada uno con la misma característica definitoria: la actividad maliciosa ocurre en tiempo de ejecución, en el navegador, a través de activos que el comerciante no creó. Vea cómo el JavaScript polimórfico generado por IA está aumentando las apuestas →
Algunos otros que vale la pena nombrar:
Inyección maliciosa de iframe. Un widget de terceros comprometido superpone silenciosamente un formulario de pago legítimo con un iframe controlado por un atacante. El usuario ve la página real, pero sus pulsaciones de teclas se envían al atacante. Nada en el repositorio del comerciante cambia.
Abuso del rastreador de píxeles. Los píxeles de análisis y publicidad, casi universales en los sitios de comercio electrónico, se cargan desde CDN externos. Cuando esas CDN se ven comprometidas o se viola el propio proveedor de píxeles, el código de seguimiento que se ejecuta en cada página se convierte en un canal de exfiltración. El código del comerciante todavía llama al mismo punto final de apariencia legítima que siempre llamó.
Recolección de credenciales basada en DOM. Un script cargado a través de un administrador de etiquetas escucha silenciosamente los eventos de los campos de formulario en las páginas de inicio de sesión o de pago, capturando datos antes de enviarlos. El ataque reside completamente en el controlador de eventos registrado en tiempo de ejecución, no en nada que un escáner estático pueda ver.
Cada uno de estos sigue la misma lógica que el caso Magecart: la amenaza vive fuera del repositorio, se ejecuta en un contexto que el análisis estático no puede observar y apunta a la brecha entre lo que usted envió y lo que realmente se ejecuta en los navegadores de sus usuarios. Puedes encontrar el desglose completo de cómo cada vector se asigna a la cobertura de herramientas, y cómo se ve un programa de defensa en profundidad en todos ellos, en la guía vinculada a continuación.
Por qué la supervisión del tiempo de ejecución es fundamental (pero no el único control)
Para amenazas a la cadena de suministro web Al igual que esta campaña de Magecart, el monitoreo continuo de lo que realmente se ejecuta en los navegadores de los usuarios es la capa principal con visibilidad directa del ataque a medida que ocurre. Las plataformas de monitoreo del tiempo de ejecución del lado del cliente responden a un par de preguntas que las herramientas estáticas no pueden responder: «¿Qué código se está ejecutando en los navegadores de mis usuarios en este momento y qué está haciendo?»
Al mismo tiempo, la supervisión del tiempo de ejecución es sólo una parte del panorama. Funciona mejor como parte de una estrategia de defensa en profundidad. El análisis estático y la gobernanza de la cadena de suministro reducen la superficie de ataque, mientras que el monitoreo del tiempo de ejecución detecta lo que se escapa y lo que queda completamente fuera de sus repositorios.
Replantear la «prueba»: categoría, no capacidad
Evaluar una herramienta centrada en repositorios como Claude Code Security contra un ataque en tiempo de ejecución es un error de categoría, no una falla del producto. Es como esperar que un detector de humo apague un incendio. Es la herramienta equivocada para ese trabajo, pero es la ideal para lo que fue diseñada para hacer. Para un edificio a prueba de incendios, necesita detectores de humo y extintores, y para un sitio web seguro, necesita Claude Code Security y monitoreo del tiempo de ejecución en su pila. Para Magecart y ataques similares de skimming del lado del cliente, necesita esa ventana de ejecución en el navegador. El escaneo de repositorios estáticos, por sí solo, simplemente no ve dónde viven realmente estos ataques.
Si está asignando herramientas a clases de amenazas a nivel CISO, hemos elaborado una breve guía sobre cómo la seguridad del código y el monitoreo del tiempo de ejecución encajan en toda la gama de vectores de la cadena de suministro web y dónde cada uno deja de ser útil.
¿Encontró interesante este artículo?
Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en
noticias de google,
Gorjeo y
LinkedIn para leer más contenido exclusivo que publicamos.
