Claude Code Security y Magecart: Cómo definir bien el modelo de amenazas...

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 repositorios la detectará, ya que el código malicioso nunca llega a tu repositorio. A medida que los equipos adoptan Claude Code Security para el análisis estático, este es el límite técnico exacto en el que se detiene el escaneo del código con IA y comienza la ejecución del tiempo de ejecución por parte del cliente.

Está disponible un análisis detallado de dónde se detiene Claude Code Security y qué cubre la supervisión del tiempo de ejecución aquí .

UN Espumador Magecart recently found in the wild utilizó una cadena de carga de tres etapas para ocultar su carga útil dentro de los metadatos EXIF de un favicon: nunca tocó el código fuente del comerciante, nunca apareció en un repositorio y se ejecutó completamente en el navegador del comprador al finalizar la compra. El ataque plantea una pregunta sobre la que merece la pena precisar: ¿qué categoría de herramienta se supone que es capaz de detectar esto?

Magecart vive fuera de tu base de código

Los ataques al estilo de Magecart rara vez tienen que ver con las vulnerabilidades clásicas de tu propio código fuente. Son infiltraciones en la cadena de suministro. El JavaScript malintencionado suele llegar a través de activos de terceros comprometidos: administradores de etiquetas, widgets de pago/pago, herramientas de análisis, scripts alojados en una CDN e imágenes que se cargan en el navegador durante el tiempo de ejecución. La organización víctima no escribió ese código, no lo revisa en relaciones públicas y, a menudo, no existe en absoluto en su repositorio.

Esto significa que una herramienta de análisis estático basada en repositorios, como Claude Code Security, tiene un diseño limitado en este escenario, ya que solo puede analizar lo que hay en el repositorio o lo que se le suministra de forma explícita. Cualquier skimmer que viva únicamente en recursos modificados de terceros o en binarios cargados dinámicamente en producción nunca entra en su campo de visión. No se trata de un error del producto, sino de una falta de coincidencia en el alcance.

El flujo de ataque: cómo se esconde el Skimmer

Este es 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 legítima de Shopify CDN. Luego, el script cargado construye la URL maliciosa real utilizando matrices de índices ofuscadas:

Una vez descodificado, esto apunta a //b4dfa5 [.] xyz/favicon.ico. Lo que sucede a continuación es cuando la técnica se vuelve interesante: el script recupera el favicon en forma de datos binarios, analiza los metadatos EXIF para extraer una cadena maliciosa y la ejecuta mediante la nueva función (): la carga se encuentra dentro de los metadatos de la imagen, por lo que es invisible para todo lo que no esté viendo el navegador en tiempo de ejecución.

La última llamada de exfiltración POST robó datos de pago de forma silenciosa a un servidor controlado por un atacante:

La cadena tiene cuatro propiedades que son importantes para el análisis de las herramientas que sigue: el cargador inicial parece una inclusión benigna de terceros; la carga útil está oculta en los metadatos de las imágenes binarias; la exfiltración se produce directamente desde el navegador del comprador; y ninguna de ellas 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 los flujos de datos y sugerir soluciones para las vulnerabilidades del código que escribes tú o tus equipos. Esto hace que sea útil para proteger aplicaciones propias, pero también define los puntos ciegos para esta clase de ataque.

En este escenario, no tiene visibilidad práctica del código malintencionado que solo se inyecta en scripts de terceros, de CDN o alojados por administradores de etiquetas que nunca se almacenan en sus repositorios. Tampoco puede interrogar las cargas útiles ocultas en activos binarios, como los iconos de favoritos o las imágenes, que tampoco forman parte del árbol de fuentes. No puede evaluar el riesgo ni la reputación real de los dominios controlados por atacantes que solo aparecen durante el tiempo de ejecución, y tampoco permite detectar en tiempo real las solicitudes anómalas de la red desde el navegador durante el proceso de compra.

En lo que podría contribuir (aunque no como control principal) sería en los casos en que tu propio código contenga una 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 de forma rígida puntos finales de exfiltración sospechosos o utiliza una lógica de recopilación de datos no segura, el análisis estático puede poner de manifiesto esos flujos para revisarlos.

Las cuatro filas superiores son lo que más importa 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 aspecto malintencionado en su propio repositorio.

Magecart es un vector, no toda la superficie de ataque

La técnica de esteganografía con favicones anterior es sofisticada, pero es un ejemplo de un patrón más amplio. Los ataques a la cadena de suministro web se producen a través de varios mecanismos distintos, cada uno con la misma característica distintiva: la actividad maliciosa se produce 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 las pulsaciones del teclado se envían al atacante. No cambia nada en el repositorio del vendedor.

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 externas. Cuando esas CDN se ven comprometidas o se infringe la seguridad del propio proveedor de píxeles, el código de seguimiento que se encuentra en cada página se convierte en un canal de filtración. El código del vendedor sigue llamando al mismo punto final de aspecto legítimo de siempre.

Recolección de credenciales basada en el DOM. Un script cargado mediante un administrador de etiquetas escucha silenciosamente los eventos de los campos del formulario en las páginas de inicio de sesión o de pago, capturando los datos antes de que se envíen. El ataque reside exclusivamente en el controlador de eventos registrado en tiempo de ejecución, no en nada que pueda ver un escáner estático.

Cada uno de ellos sigue la misma lógica que en el caso de Magecart: la amenaza reside fuera del repositorio, se ejecuta en un contexto que el análisis estático no puede observar y se centra en la brecha entre lo que se envía y lo que realmente se ejecuta en los navegadores de los usuarios. Puede encontrar el desglose completo En la guía vinculada a continuación, podrás ver cómo cada vector se corresponde con la cobertura de las herramientas (y cómo es un programa de defensa en profundidad en todos ellos).

Por qué la supervisión del tiempo de ejecución es fundamental (pero no es el único control)

Para amenazas a la cadena de suministro web Al igual que en 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 supervisión 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 solo 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 la supervisión del tiempo de ejecución detecta lo que se escapa y lo que se encuentra completamente fuera de sus repositorios.

Reformulando la «prueba»: categoría, no capacidad

La evaluación de una herramienta centrada en los repositorios, como Claude Code Security, contra un ataque en tiempo de ejecución es un error de categoría, no un error de 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 que un edificio esté protegido contra incendios, necesitas detectores de humo y extintores de incendios, y para tener un sitio web seguro, necesitas contar con Claude Code Security y monitorización del tiempo de ejecución. Para Magecart y otros ataques similares de robo de información desde el lado del cliente, necesitas esa ventana de tiempo de ejecución en el navegador. El análisis estático de los repositorios, por sí solo, simplemente no permite ver dónde se encuentran realmente estos ataques.

Si está asignando herramientas a clases de amenazas a nivel de CISO, hemos elaborado una breve guía sobre cómo la seguridad del código y la supervisión del tiempo de ejecución se combinan en toda la gama de vectores de la cadena de suministro web, y dónde cada uno de ellos deja de ser útil.

Guía del CISO sobre la seguridad de Claude Code →