Resumen: incidentes notables de Magecart
- El patrón simple: Las brechas de marcas conocidas acaparan titulares, pero el patrón detrás es simple: un script de terceros comprometido en una página de pago, y semanas de skimming silencioso mientras la transacción se sigue completando.
- Semanas de skimming: British Airways sufrió skimming en unas 380.000 transacciones y la campaña de Ticketmaster duró meses, y cside monitoriza cada script en cada sesión de usuario real para que un cambio de comportamiento aflore en cuanto el código actúa.
- Eres el objetivo: Si asumes que tu marca es demasiado grande para ser un objetivo, eres exactamente el perfil que eligen estas campañas, así que pon monitorización en tiempo de ejecución en la página de pago antes de que el próximo script de un proveedor externo se vuelva malicioso.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
Los ataques Magecart son ataques de fraude de pago en e-commerce en los que los hackers inyectan en secreto JavaScript malicioso, normalmente comprometiendo un script de terceros de confianza, en páginas de pago para robar silenciosamente números de tarjeta, códigos CVV y direcciones mientras los clientes los escriben. El nombre combina "Magento" y "cart" (carrito), por la plataforma originalmente atacada, pero ahora cubre todo el skimming del lado del navegador sin importar el CMS.
De dónde proviene el término "Magecart"
Los ataques Magecart son un tipo de ciberataque en el que los hackers inyectan código JavaScript malicioso, a menudo llamado script de "skimming", en sitios web. Puede tratarse de cualquier tipo de sitio web, pero cuando se habla de Magecart, casi siempre son sitios de comercio electrónico, con el objetivo de capturar datos de tarjetas de crédito.
El término "Magecart" proviene de la combinación de "Magento", una popular plataforma de comercio electrónico de código abierto, y "cart" ("carrito"), que hace referencia a la función de carrito de compra de estos sitios web. La primera oleada de ataques se dirigió a sitios basados en Magento, de ahí que se acuñara el término.
Este tipo de ataques también se engloba dentro de los términos generales "ataques del lado del cliente" y "ataques a la cadena de suministro web".
Evolución hacia un término genérico
Con el tiempo, "Magecart" pasó de referirse a un grupo específico de hackers a convertirse en un término genérico usado para describir un estilo más amplio de ataques:
- A medida que los métodos del grupo original de Magecart demostraron ser efectivos, otros grupos cibercriminales adoptaron técnicas similares.
- Aunque los primeros ataques Magecart se centraban principalmente en sitios Magento, el alcance se ha ampliado de forma significativa. Los atacantes ahora atacan una variedad de sistemas de gestión de contenido (CMS) y plataformas de comercio electrónico, como WooCommerce, PrestaShop, Shopify y sitios web personalizados.
- Los ataques Magecart modernos suelen explotar vulnerabilidades en servicios de terceros integrados en los sitios web, como widgets de chat, scripts de analítica o procesadores de pago. Este cambio, de atacar directamente plataformas de comercio electrónico a atacar el ecosistema web en un sentido más amplio, es la razón por la que el término ahora abarca más terreno.
- Incidentes de alto perfil que involucraron a marcas importantes como British Airways, Ticketmaster y Newegg atrajeron una atención mediática considerable hacia los ataques Magecart. A menudo los artículos mencionan el nombre a modo de referencia, sin que se trate necesariamente de un ataque "Magecart" en el sentido original de la palabra.
En general, cuando alguien menciona Magecart, piensa en skimming digital.
Los mayores ataques Magecart hasta ahora
Estos son los ataques Magecart que conocemos hasta ahora. Es probable que estén ocurriendo muchos más en este momento. Si descubrimos ataques adicionales, actualizaremos esta publicación.
Los hemos clasificado ampliamente según las personas afectadas, las implicaciones financieras, la cobertura mediática y el daño reputacional.
1. British Airways
Este es a menudo considerado el ataque Magecart más grande y de mayor perfil. También es el que citamos con más frecuencia. En parte, porque compramos el dominio utilizado en ese ataque, baways.com (seguro ahora), y contamos la historia completa del ataque allí.
Aunque nos gustaría decir que tuvimos que pasar por algunos esquemas elaborados para obtenerlo, simplemente lo compramos en un registro público. Lee esa historia aquí.
En este ataque, el dominio fue comprado por los atacantes e insertado en un script de terceros manipulado para permanecer bajo el radar por más tiempo. Después de todo, BAWAYS suena como un dominio legítimo de British Airways.
Pero en otros casos, los dominios expirados o vendidos que aparecen en scripts de terceros tienen un camino directo para explotar muchos sitios web de una sola vez. Aunque no es un ataque Magecart, el reciente ataque de Polyfill nos mostró por qué es importante proteger tu sitio contra esto.
El hackeo de British Airways (BA) de septiembre de 2018 fue un ataque Magecart bastante sofisticado que comprometió la información personal y financiera de alrededor de 380.000 personas. Los hackers explotaron vulnerabilidades en el sistema de pago en línea de British Airways inyectando código JavaScript malicioso en el sitio web y la aplicación móvil de la aerolínea. Este código fue diseñado específicamente para capturar información de pago en tiempo real mientras los clientes introducían sus datos en la página de pago.
Los datos robados incluían nombres, direcciones de correo electrónico y datos completos de tarjetas de crédito, incluidos los códigos CVV, lo que los hacía muy valiosos para actividades fraudulentas. Y el ataque pasó desapercibido durante más de dos semanas, dando a los atacantes tiempo suficiente para recopilar información sensible de los clientes.
Esta brecha tuvo repercusiones significativas para British Airways, tanto a nivel financiero como reputacional. La Oficina del Comisionado de Información del Reino Unido (ICO) multó a British Airways con 20 millones de libras (26 millones de dólares) y la brecha también generó críticas generalizadas hacia las prácticas de ciberseguridad de British Airways.
2. Ticketmaster
Este ataque afectó a aproximadamente 40.000 clientes, pero fue significativo por la participación de un proveedor de servicios externo (Inbenta).
De nuevo, los atacantes inyectaron código JavaScript malicioso en este widget de terceros, lo que les permitió extraer los datos de tarjetas de crédito de los clientes, nombres, direcciones y otra información sensible mientras se procesaban las transacciones en el sitio de Ticketmaster. El código malicioso permaneció sin detectar durante varios meses, tiempo durante el cual los atacantes recopilaron valiosos datos de clientes.
Como resultado, Ticketmaster recibió críticas por no verificar adecuadamente a sus socios externos y por la demora en detectar y responder a la brecha.
En mayo de 2024 vivimos un poco de déjà vu cuando salió a la luz otro incidente de Ticketmaster que guardaba un parecido llamativo con la infame brecha de datos de 2018.
Este nuevo incidente fue en cierto modo similar al primero, ya que Ticketmaster confirmó actividad no autorizada dentro de un entorno de base de datos en la nube de un tercero, y afirmó que se había expuesto la información personal de más de 500 millones de clientes. Aquí tienes nuestro análisis completo de esta última brecha de Ticketmaster.
3. Newegg
El hackeo de Newegg es uno de esos ataques Magecart clásicos de los que la gente todavía habla. Este fue bastante astuto y mostró cuán ingeniosos podían llegar a ser los atacantes. También en 2018, los hackers lograron colar código JavaScript malicioso directamente en la página de pago del sitio web de Newegg. ¿Su objetivo? Lo adivinaste, extraer información de tarjetas de crédito de los clientes mientras realizaban compras. El ataque también pasó desapercibido durante más de un mes, lo que dio a los atacantes mucho tiempo para recopilar una buena cantidad de datos sensibles.
Lo que hizo especialmente interesante este ataque fue la forma en que operaron los hackers. No atacaron directamente el sitio principal de Newegg; en cambio, imitaron el propio script de procesamiento de pagos de Newegg para que su código malicioso se mezclara casi a la perfección. Fue una maniobra inteligente que les permitió pasar desapercibidos durante tanto tiempo. Los datos robados incluían nombres, direcciones, números de tarjetas de crédito y códigos CVV.
Aunque la respuesta de Newegg al ataque no fue tan rápida como algunos habrían esperado, el incidente puso de relieve la necesidad de prácticas de seguridad más vigilantes, especialmente en torno a las páginas de pago. Es una de las razones por las que los requisitos actualizados de PCI DSS 4.0 incluyen proteger los scripts en páginas de pago; infórmate al respecto si tus clientes realizan pagos en tu sitio.
4. Múltiples sitios Magento
En lugar de ir tras un pez grande, entre 2020 y 2021 los atacantes apostaron por la cantidad, explotando vulnerabilidades en más de 2.000 sitios de comercio electrónico Magento. La estrategia fue simple pero efectiva: usar fallos conocidos en instalaciones de Magento desactualizadas para inyectar scripts de skimming en páginas de pago y capturar información de tarjetas de crédito mientras los clientes desprevenidos realizaban sus compras.
Lo fascinante aquí es la magnitud pura de este ataque. Al aprovechar una vulnerabilidad muy extendida, los atacantes lograron impactar a un número masivo de negocios a la vez, no solo a un puñado de sitios.
Este tipo de ataque es particularmente preocupante para las pequeñas y medianas empresas, que a menudo no cuentan con el mismo nivel de seguridad que los grandes actores. Y para quienes seguían usando versiones antiguas de Magento, fue una llamada de atención.
Uno de los ataques Magecart en Magento más recientes y de mayor envergadura le ocurrió a Segway en 2022. Los atacantes se dirigieron a vulnerabilidades en el propio CMS o en uno de los plugins instalados en el sitio de Segway. Tras vulnerar eso, de nuevo añadieron JavaScript malicioso. Aquí, parecía mostrarse como el aviso de copyright del sitio, pero en realidad se usaba para cargar un favicon externo.
Dentro de ese archivo de favicon se colocó un dominio malicioso que cargaba código externo para extraer información de pago de clientes desprevenidos. Lee nuestro artículo completo sobre ese ataque aquí.
5. Volusion
El hackeo de Volusion en 2019-2020 es otro ataque Magecart que ilustra perfectamente los peligros de las vulnerabilidades en la cadena de suministro. Esta vez, los atacantes fueron a por Volusion, un proveedor de plataforma de comercio electrónico que impulsa miles de tiendas en línea.
Al comprometer la propia infraestructura de Volusion, los hackers pudieron inyectar su JavaScript malicioso en un archivo JavaScript servido a todos los sitios web que usaban los servicios de Volusion. No tuvieron que atacar tiendas individuales una por una; solo necesitaban colarse a través del proveedor de la plataforma, y así tenían acceso a las páginas de pago de todas esas tiendas de una sola vez.
El impacto fue enorme, afectando a innumerables pequeñas y medianas empresas que dependían de Volusion para llevar sus operaciones de comercio electrónico. A los clientes que compraban en estas tiendas les extrajeron sus datos de tarjeta de crédito, que de nuevo incluían nombres, números de tarjeta, fechas de caducidad y CVV.
Cuando tu negocio depende de un proveedor de servicios, sus vulnerabilidades se convierten en las tuyas.
Lo que hemos aprendido sobre Magecart hasta ahora
Veamos algunos temas comunes en estos tres mayores ataques Magecart:
- Siempre se dirigen a herramientas de terceros activas en los sitios (con mayor frecuencia, scripts de terceros).
- Los ataques siempre permanecen sin detectar durante un tiempo.
- Siempre van tras sitios donde compran personas normales.
Así que si administras un sitio con esas características, las alarmas deberían estar sonando ahora mismo. Puedes proteger tus scripts de terceros y evitar que estos ataques ocurran.
Más ataques Magecart
Veamos algunos ataques Magecart más notables:
Warner Music Group
El hackeo de Warner Music Group en 2020 fue otro ataque notable de estilo Magecart que se prolongó varios meses, impactando en múltiples sitios de comercio electrónico asociados con esta importante discográfica. Los hackers inyectaron scripts maliciosos en las páginas de pago de las tiendas en línea de Warner Music, lo que les permitió extraer información de pago de clientes que compraban mercancía y productos digitales.
Sitios web de Claire's e Icing
Claire's, el popular minorista de accesorios y joyería, tuvo un año difícil en 2020 cuando fue víctima no de uno, sino de dos ataques Magecart. Tras la primera brecha, la empresa pensó que tenía la situación bajo control, pero los atacantes lograron reinfectar sus sitios web poco después del primer ataque.
American Cancer Society
La brecha de la American Cancer Society en 2019 golpeó con especial dureza, y demuestra que ni siquiera las organizaciones sin ánimo de lucro están a salvo de los ataques Magecart. Cualquier organización o sitio web con información puede ser, y será, un objetivo.
Los atacantes inyectaron código JavaScript malicioso en la página de donaciones del sitio web de la organización, con el objetivo de robar información de tarjetas de crédito de los donantes.
Macy's
Los atacantes lograron comprometer el sistema de pago en línea de esta cadena de grandes almacenes estadounidense, inyectando código malicioso para robar información de pago directamente de los clientes durante el proceso de compra. Aunque el número de clientes afectados fue menor comparado con algunos de los otros ataques Magecart, el momento fue especialmente impactante, ya que ocurrió durante un periodo de ventas importante, justo cuando los compradores acudían en masa al sitio en busca de ofertas.
Regal Cinemas
El ataque Magecart a Regal Cinemas en 2022 volvió a poner el foco en el sector del entretenimiento, que hasta entonces no se asociaba comúnmente con este tipo de brechas. Los atacantes se dirigieron a la plataforma de venta de entradas online de Regal, incrustando scripts maliciosos para capturar información de pago de los clientes que compraban entradas. Bastante similar al ataque de Ticketmaster.
NutriBullet
NutriBullet, famosa por sus batidoras y utensilios de cocina, se encontró en la lista de víctimas de Magecart a principios de 2021. Los hackers inyectaron JavaScript malicioso en la página de pago del sitio web de NutriBullet, extrayendo datos de tarjetas de crédito de los clientes durante varias semanas.
Chinavasion
Chinavasion, una conocida plataforma china de comercio electrónico especializada en electrónica, sufrió un ataque Magecart en 2023. Este incidente también se dirigió a las páginas de pago para capturar datos de pago de clientes internacionales. Aunque la brecha no fue tan grande como algunas de las otras de esta lista, fue significativa por la amplia base de clientes de Chinavasion, repartida entre múltiples países.
Dick's Sporting Goods
En 2023, Dick's Sporting Goods se sumó a la lista de víctimas de Magecart cuando los atacantes lograron inyectar scripts maliciosos en su página de pago. La brecha afectó a un gran número de clientes, pero la escala y el impacto financiero fueron relativamente menos graves comparados con algunos de los ataques más extensos de esta lista.
Marriott Hotels
Marriott Hotels añadió otro capítulo a su problemático historial de brechas de datos en 2023, cuando su sistema de reservas en línea fue atacado por Magecart. Los hackers inyectaron scripts de skimming para robar información de tarjetas de crédito de los clientes que reservaban habitaciones online.
Hay una preocupación creciente por este tipo de ataques dirigidos a sitios web del sector hotelero y de ocio. El tiempo dirá si se producen más incidentes de este tipo en este ámbito.
Aquí hablamos sobre los ataques del lado del cliente específicamente en el sector hotelero.
2024: CosmicSting y la oleada de exploits de plataforma
En junio de 2024 se documentó CVE-2024-34102, una vulnerabilidad XXE (entidad externa XML) crítica y no autenticada en Adobe Commerce y Magento Open Source 2.4.7 y anteriores, denominada públicamente CosmicSting por Sansec. Es una lectura arbitraria de ficheros del servidor, no una ejecución remota de código por sí misma, y para lograr ejecución de código había que encadenarla con CVE-2024-2961 en la biblioteca iconv de glibc. La lectura de ficheros ya bastaba. A diferencia del enfoque clásico de cadena de suministro de scripts de terceros, esta vulnerabilidad permitía a los atacantes sacar la clave secreta de la aplicación directamente de la configuración del servidor, generar tokens de administrador válidos e inyectar skimmers en las plantillas de páginas de pago sin tocar ningún CDN externo. Sansec registró múltiples grupos vinculados a Magecart explotando el fallo simultáneamente mientras las tiendas se apresuraban a aplicar parches.
cside documentó una víctima con nombre propio mientras la campaña seguía activa: Carlsberg, objetivo de un ataque de malware CosmicSting en Magento, donde una sola línea de JavaScript inyectada mostraba una caja de pago falsa antes del checkout real y enviaba los datos de la tarjeta directamente al atacante.
La oleada CosmicSting marcó un cambio: la plantilla de la página de pago se convirtió en la superficie de ataque en lugar de un script de terceros cargado en ella. El resultado para el comprador es idéntico: número de tarjeta, fecha de caducidad y CVV capturados en el navegador en el momento de la entrada. El allowlisting estándar de scripts de terceros no habría detenido este vector. Solo la monitorización de lo que los scripts ejecutan realmente en sesiones de usuarios reales puede detectar ambas vías.
Billeteras digitales e intercambios de criptomonedas
De 2022 a 2024, los atacantes de Magecart cambiaron su enfoque hacia las billeteras digitales y los exchanges de criptomonedas. Al inyectar scripts maliciosos en billeteras web y plataformas de intercambio, lograron extraer tanto datos de tarjetas de crédito como activos digitales, como criptomonedas.
Durante nuestra fase beta, varias empresas de criptomonedas e intercambios nos contactaron para trabajar juntos en una versión temprana de un alcance de producto ampliado para proteger sus sitios. Es una preocupación real en esta industria.
Aquí tienes la historia del ataque event-stream de Copay, que también ocurrió en el ámbito cripto. El código malicioso ejecutaba rutinas que buscaban y extraían claves privadas y datos de billeteras de cuentas que contenían cantidades sustanciales de Bitcoin y Bitcoin Cash. Estos datos se transmitían después a un servidor remoto controlado por los atacantes.
Algunas menciones finales:
- Soccer[.]com
- Shopify
- Olympus
- Tupperware
- Fujifilm
- Boom! Mobile
- Procter & Gamble
- Smith & Wesson
- Puma
- Crucial (Micron)
- Elekta
Cómo proteger tu sitio contra ataques Magecart
Todos los ataques de esta lista siguen la misma estructura: un script de terceros se carga en una página de pago, cambia de comportamiento en algún momento tras su despliegue y exfiltra silenciosamente datos de tarjetas hasta que alguien lo detecta. Tres controles cierran esa brecha.
1. Monitorización de scripts en el navegador en tiempo real
Las defensas de capa de red y los escáneres del lado del servidor ven un script una sola vez, en el momento de su descarga. Los payloads de Magecart están diseñados precisamente para evadir esto: muestran código limpio a los crawlers y se activan solo para agentes de usuario, ubicaciones geográficas o ventanas de tiempo específicos. La única forma de detectar un skimmer es observar lo que los scripts realmente hacen en sesiones reales de usuarios.
cside se despliega como un único snippet de JavaScript de primera parte en tus páginas de pago, sin cambios de DNS ni redireccionamiento de tu tráfico. Monitoriza cada script de terceros que se ejecuta en navegadores reales y detecta cambios de comportamiento en cuanto aparecen, incluidos los payloads condicionales que solo se activan bajo condiciones específicas.
2. PCI DSS 6.4.3 y 11.6.1
Los requisitos actualizados del PCI DSS 4.0.1 (en vigor desde abril de 2025) exigen un mecanismo para detectar y alertar sobre cambios no autorizados en los scripts de páginas de pago (§6.4.3) y manipulaciones de cabeceras HTTP y contenido de la página de pago (§11.6.1). Estos requisitos existen precisamente a causa de ataques como los descritos anteriormente. La monitorización continua de la integridad de scripts es ahora una obligación de cumplimiento para todo comerciante que acepta pagos con tarjeta online. Consulta cómo cside cumple los requisitos del PCI DSS §6.4.3.
3. Content Security Policy y lista de scripts permitidos
Una lista de permisos Content-Security-Policy: script-src impide que los navegadores carguen scripts desde dominios no aprobados explícitamente. Combínala con un inventario actualizado de todos los proveedores de scripts en tu flujo de pago. La CSP por sí sola no es suficiente (la inyección inline, el compromiso de dominios de confianza y los bypasses de nonce siguen siendo riesgos), pero incrementa notablemente el coste para el atacante y es un control base del PCI DSS.
Empieza y protege tus páginas de pago gratis, o visita la página de comparación para ver cómo cside se posiciona frente a otras herramientas de seguridad del lado del cliente.
