Las últimas campañas de Magecart demuestran hasta qué punto los atacantes han perfeccionado el skimming de tarjetas en aplicaciones web. Una técnica reciente esconde la carga maliciosa en los metadatos EXIF de un favicon cargado dinámicamente, ejecutando todo el JavaScript exclusivamente en el navegador del comprador, sin tocar una sola línea del código del comercio.
Nueva campaña Magecart: skimming oculto en favicon y metadatos EXIF
Los investigadores identificaron en sitios comprometidos un cargador muy breve, un script que visualmente se confunde con la inclusión habitual de un recurso externo. A primera vista parece un include inocuo hacia un proveedor de CDN legítimo, como podría ser una integración de Shopify u otro servicio popular, lo que dificulta su detección en revisiones superficiales.
Este cargador importa un segundo script remoto que, mediante índices de arrays ofuscados, reconstruye la URL real del recurso malicioso. Tras el proceso de decodificación, el código apunta a una ruta del tipo //b4dfa5[.]xyz/favicon.ico. A partir de ese momento comienza la parte más sofisticada de la cadena de ataque.
El script descarga el favicon como un objeto binario, extrae de él sus metadatos EXIF, localiza una cadena oculta que contiene JavaScript y la ejecuta mediante new Function(). La carga útil vive únicamente dentro de los metadatos de la imagen, fuera del alcance de herramientas que no observan la ejecución real en el navegador.
En la etapa final, el código roba datos de tarjetas y otra información sensible introducida en el checkout y los envía de forma oculta, normalmente por peticiones POST, a un servidor controlado por los atacantes. La técnica se caracteriza por cuatro rasgos clave: el cargador se camufla como script legítimo, el payload está embebido en EXIF de un favicon, la exfiltración se realiza desde el navegador del cliente y el código del comercio no se modifica en absoluto.
Limitaciones del análisis estático frente a ataques de web supply chain
Las herramientas de análisis estático de código se centran en lo que reside en el repositorio: código fuente, manifiestos de infraestructura, configuraciones y dependencias declaradas. Son muy eficaces para detectar vulnerabilidades en el propio desarrollo (XSS, inyecciones SQL, fallos de autenticación, validaciones débiles, etc.).
Sin embargo, los ataques Magecart pertenecen a la categoría de amenazas de web supply chain. El JavaScript malicioso llega a las páginas a través de componentes de terceros comprometidos: widgets de pago, gestores de etiquetas, scripts de analítica, CDN externos o incluso imágenes cargadas dinámicamente. Ese código, en muchos casos, nunca pasa por el repositorio ni por el proceso formal de revisión.
En consecuencia, un escáner de repositorios no puede interpretar una carga insertada en un favicon binario, no ve dominios que solo aparecen durante una sesión real de usuario y no detecta comportamientos anómalos de red en el lado cliente. No es un fallo de la tecnología, sino un desajuste entre el tipo de herramienta y la clase de amenaza a la que se le pretende hacer frente.
Pese a ello, el análisis estático sigue siendo un pilar esencial. Puede señalar como riesgosas ciertas construcciones propias, como la inserción dinámica de scripts de terceros, el uso excesivo de eval o new Function y endpoints sospechosos para envío de datos. Es decir, reduce la superficie de ataque, pero no sustituye la observación de lo que ocurre realmente en el navegador.
Vectores habituales en ataques Magecart y web supply chain
Superposición de formularios de pago mediante iframes maliciosos
Un patrón frecuente es el uso de iframes invisibles para interceptar datos de pago. Un widget de terceros comprometido dibuja una capa transparente sobre el formulario legítimo de tarjeta y envía cada pulsación de tecla a la infraestructura del atacante. El HTML del comercio apenas cambia y el código malicioso nunca aparece en el repositorio.
Abuso de píxeles de seguimiento y scripts de analítica
La mayoría de sitios de e‑commerce integran píxeles de analítica y retargeting servidos desde CDNs externos. Si el proveedor o su cadena de suministro es comprometido, ese mismo píxel se convierte en un canal de fuga de información. Desde el punto de vista de la aplicación, sigue siendo una URL “de confianza” usada durante años, mientras la lógica maliciosa reside en la parte de terceros.
Robo DOM-based a través de gestores de etiquetas y JavaScript polimórfico
Otro vector extendido son los scripts inyectados mediante tag managers. Estos se suscriben dinámicamente a eventos de entrada en campos de login o pago y capturan los datos antes de que se envíe el formulario. La lógica vive en manejadores de eventos del DOM creados en tiempo de ejecución, fuera del alcance de los escáneres estáticos. Cada vez con más frecuencia, los atacantes aplican JavaScript polimórfico generado con IA para cambiar la forma del código y evadir firmas tradicionales.
Importancia del runtime monitoring en el navegador y de la defensa en profundidad
Para esta clase de amenazas, el control decisivo es el runtime monitoring en el navegador. Estas soluciones observan qué scripts se ejecutan realmente en cada sesión, qué modificaciones realizan en el DOM y a qué dominios envían datos. En la práctica, responden a dos preguntas: “¿Qué código se está ejecutando ahora mismo en los navegadores de mis clientes?” y “¿Está intentando enviar información sensible a dominios no autorizados?”.
Las recomendaciones de referencia —como las guías de OWASP sobre seguridad en aplicaciones web y los informes de ENISA sobre riesgos de supply chain— insisten en un enfoque de defense‑in‑depth. El análisis estático y la gestión de dependencias reducen el riesgo en el código propio; políticas como CSP, SRI y listas estrictas de scripts de terceros limitan la capacidad de maniobra del atacante; y el runtime monitoring del lado cliente detecta aquellas intrusiones que solo se manifiestan durante la ejecución en el navegador.
Para las organizaciones, especialmente en el sector e‑commerce, el reto ya no es elegir entre análisis estático o monitorización cliente, sino combinar ambos con una gobernanza estricta de la web supply chain. Revisar de forma continua los proveedores externos, aplicar controles de contenido y desplegar soluciones que den visibilidad al comportamiento real del código en el navegador reduce de forma significativa el riesgo de skimming silencioso de tarjetas y refuerza la resiliencia global de las aplicaciones web.
