Una nueva campaña de Magecart está utilizando la infraestructura de la API de Stripe para alojar tanto el código malicioso de robo de tarjetas como los datos exfiltrados de las páginas de pago. Toda la actividad maliciosa se basa en dominios de Google Tag Manager (GTM) y Stripe (googletagmanager.com y api.stripe.com), que son implícitamente confiables por las tiendas en línea.
La nueva familia de malware fue descubierta por investigadores de la empresa de seguridad para comercio electrónico Sansec, quienes encontraron que el código malicioso se carga desde un contenedor de Google Tag Manager y se ejecuta en cada página que lo carga. Según Sansec, tanto el payload como las tarjetas robadas se mueven a través de api.stripe.com. Las tiendas permiten ese dominio por defecto, por lo que el skimmer evade las reglas de Política de Seguridad de Contenido y los filtros de red que de otro modo marcarían el tráfico hacia un dominio de skimmer desconocido.
GTM es un sistema de gestión que permite a los propietarios de sitios web agregar y administrar scripts utilizados para análisis, anuncios y seguimiento, sin modificar el código fuente del sitio. Stripe es una plataforma de procesamiento de pagos ampliamente utilizada por las tiendas en línea para aceptar tarjetas de crédito, gestionar pedidos de clientes y manejar facturación.
Sansec explica que el código malicioso está incrustado en contenedores de GTM de aspecto legítimo, que se activan cuando un comprador llega a una página de pago, poniendo en cola la API de Stripe para un registro de cliente específico (cus_TfFjAAZQNOYENR). A partir de los campos de metadatos del registro, lee código JavaScript que reensambla y luego ejecuta usando new Function().
El skimmer de tarjetas se dirige a las páginas de pago de Magento/Adobe Commerce e intenta capturar datos de pago (número de tarjeta de crédito, fecha de vencimiento, código CVV, nombre del cliente), así como direcciones de facturación y correo electrónico, y número de teléfono. Los datos robados se concatenan en una sola cadena, se ofuscan mediante la operación XOR y se almacenan localmente en lugar de exfiltrarse inmediatamente.
La recuperación de los datos se realiza a través de una rutina separada, que se ejecuta justo después de cargar la página y cada minuto después, dividiendo el blob de datos por la mitad, creando un nuevo objeto de cliente de Stripe y almacenando los datos robados en campos de metadatos. Cada tarjeta de pago robada se convierte en un registro de cliente falso en la cuenta de Stripe del atacante, convirtiendo a Stripe en un backend de almacenamiento para datos robados. Una vez copiados los datos, el archivo local se elimina para eliminar rastros del ataque y evitar cargas duplicadas.
Sansec también descubrió una variante del ataque donde se utiliza Google Firestore, un servicio de base de datos en la nube para almacenamiento y recuperación de datos en tiempo real, en lugar de Stripe. En esa versión de la campaña, el payload se recupera de un documento de Firestore llamado tracking/captcha en un proyecto llamado braintree-payment-app. Los datos robados se almacenan en una clave diferente de localStorage (_d_data_customer_). Los nombres del documento y del proyecto ayudan al malware a mezclarse con el tráfico legítimo de pagos y protección contra bots.
El registro de cliente de Stripe que contiene el skimmer fue creado el 24 de diciembre de 2025, lo que sugiere que la operación podría haber estado activa desde al menos esa fecha. Los clientes pueden protegerse de tales riesgos utilizando tarjetas virtuales de un solo uso con límites establecidos.
Deja una respuesta