Resumen: cómo funcionan los ataques Magecart
- Víctimas reales, grupos reales: Al menos siete grupos de atacantes inyectando JavaScript en páginas de pago. British Airways (380k registros), Ticketmaster, Newegg, Warner Music.
- Corre tras el WAF: El ataque corre después de que tu WAF aprueba la página, en el mismo contexto de JavaScript que tu formulario de checkout.
- Las reglas que lo cierran: 6.4.3 y 11.6.1 lo cierran. Obligatorios desde el 31 de marzo de 2025 para cualquiera que toque una página de pago.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
El ataque en tres movimientos
Toda campaña de skimming, sin importar qué grupo la ejecute, se reduce al mismo ciclo de vida. Quita el branding y quedan tres movimientos.
| Movimiento | Qué pasa | Dónde vive |
|---|---|---|
| Inyectar | El atacante consigue que su JavaScript cargue en tu página | Un archivo propio comprometido, una etiqueta de terceros o un tag manager |
| Capturar | El script lee datos de tarjeta o credenciales del formulario | El DOM y los listeners de eventos del formulario en el navegador |
| Exfiltrar | Una copia de los datos se envía al servidor del atacante | Una solicitud saliente del navegador a un dominio del atacante |
El resto de este artículo recorre cada movimiento en orden, porque ese orden es lo que hace invisible el ataque.
Movimiento 1: cómo llega el código a la página
El atacante necesita que su JavaScript se ejecute en el navegador del visitante. Tiene tres rutas habituales hacia la página, ninguna de las cuales exige tocar la lógica de tu servidor de origen.
- Un archivo autoalojado. Obtiene acceso de escritura mediante un plugin vulnerable, un CMS desactualizado o un login de administrador robado, y añade unas líneas a un archivo JavaScript que ya sirves. El cambio es pequeño y suele esconderse dentro de código legítimo, así que un diff parece normal.
- Un script de terceros. Compromete a un vendor cuyo script cargas directamente con
<script src>, como una analítica, un chat o un widget de pruebas A/B. Ahora el skimmer sale desde el dominio del vendor a cada cliente que carga tu página, y nunca está en tu repositorio para encontrarlo, por lo que proteger los scripts de terceros es una disciplina en sí misma. - Un tag manager. Toma control de un contenedor de Google Tag Manager o similar y añade una etiqueta que contiene el skimmer. Cada sitio y página que usa ese contenedor ejecuta ahora el código, incluidas páginas de checkout donde esa etiqueta no debería cargar.
Las rutas de terceros y de tag manager son las que escalan, y por eso son las peligrosas. Un vendor comprometido siembra skimmers en cada sitio que confía en él, y un script que aprobaste puede traer otro script que nunca revisaste: el problema de cuarta parte. Esta es la forma de cadena de suministro que el requisito 6.4.3 y el 11.6.1 de PCI DSS 4.0.1 buscan cubrir al exigir un inventario y la autorización de cada script en una página de pago. La brecha de Ticketmaster de 2018 siguió exactamente este camino: el skimmer llegó al checkout a través del script de chatbot de un proveedor comprometido, no por código propio de Ticketmaster (resumen de Wikipedia del incidente de 2018).
Movimiento 2: cómo el skimmer lee tu formulario
Una vez que el script se ejecuta, leer el formulario es desarrollo web ordinario usado en tu contra. Leer y modificar el DOM es cómo funciona cualquier framework moderno, así que las acciones del skimmer parecen comportamiento normal de la página. Un skimmer suele hacer una o varias de estas cosas:
- Lee los valores de los campos directamente. Selecciona los campos de número de tarjeta, caducidad, CVV y nombre por sus atributos
id,nameoautocomplete, y lee.valuedirectamente del DOM. - Adjunta event listeners. Engancha
input,keyup,changeobluren los campos de pago, para capturar cada pulsación aunque el usuario nunca llegue a enviar el formulario. - Secuestra el camino de envío. Envuelve el handler de submit del formulario o engancha el botón de "pagar", ensamblando el payload completo en el momento en que el usuario confirma.
- Parchea primitivas de red. Los skimmers avanzados sobrescriben
fetch,XMLHttpRequest.prototype.sendonavigator.sendBeaconpara leer la solicitud de pago real en el momento en que tu propio código la envía. - Superpone un campo falso. Algunos inyectan un iframe de pago falso encima del real, de modo que el comprador escribe los datos de la tarjeta directamente en el input del atacante. El propio análisis de cside de una campaña Magecart encontró un frame de pago falso insertado en el checkout mediante una sola línea de JavaScript ofuscado, el tipo de sustitución que un escaneo del lado del servidor nunca detecta.
La entrega condicional es lo que lo mantiene en silencio
El skimmer no se dispara para todo el mundo. Se filtra a sí mismo para que las personas con más probabilidades de detectarlo, es decir, equipos de seguridad, escáneres y bots, nunca vean el comportamiento malicioso:
- Filtrado por ruta. Muchos skimmers solo se arman en URLs que coinciden con un patrón de checkout o login, así que el código permanece inactivo en el resto.
- Detección de automatización. Leer
navigator.webdriverdevuelvetrueen navegadores headless y automatizados, así que el skimmer puede servir código limpio a un escáner y el payload real a un comprador. Las variantes más avanzadas buscan globales de Selenium o fugas deRuntimedel Chrome DevTools Protocol (CDP) para detectar navegadores instrumentados. - Disparo una vez por sesión. Exfiltrar una sola vez evita el ruido de red duplicado que podría destacar en un log.
Esa carrera armamentista también escala del lado del atacante: el informe de investigación Future of Web Security 2026 de cside registró un crecimiento de playwright-stealth de aproximadamente diez veces a lo largo de 2025, automatización creada para vencer navigator.webdriver y comprobaciones similares. La misma evasión que oculta las herramientas de un atacante a los defensores es la que oculta un skimmer de las tuyas. Encima de todo esto, el código suele estar ofuscado, lo que entierra la intención durante una revisión manual.
Movimiento 3: cómo salen los datos
La captura no le sirve de nada al atacante hasta que los datos le llegan. La exfiltración es una única solicitud saliente desde el navegador, y el atacante tiene varias formas silenciosas de enviarla.
| Método | Cómo se ve en la red |
|---|---|
navigator.sendBeacon() | Un POST pequeño que se dispara de forma fiable al salir de la página, diseñado para analítica, así que se mezcla con el resto |
fetch() / XMLHttpRequest | Una solicitud asíncrona estándar, a menudo hacia un dominio parecido que imita un CDN o un host de analítica |
| Solicitud de imagen | El payload se añade al src de un <img> como query string; el navegador "carga" una imagen que en realidad es un envío de datos |
| WebSocket | Un canal persistente para transmitir las pulsaciones capturadas casi en tiempo real |
Tres propiedades hacen que esta fuga sea casi imposible de detectar desde fuera. La solicitud usa HTTPS, así que está cifrada como el resto de tu tráfico. El destino suele ser un dominio typosquatted o recién registrado que parece un vendor real. El skimmer de British Airways exfiltró hacia baways.com, así que no salta a la vista en un log. Y el payload es pequeño y a menudo está codificado en base64, por lo que parece un ping rutinario de telemetría. Lo crítico es que esta solicitud va del navegador directo al atacante; nunca pasa por tu origen, tu WAF ni tu pasarela de pago. Esa es la razón por la que el robo es invisible para el servidor.
Por qué tu servidor, tu WAF y tu procesador nunca lo ven
Junta los tres movimientos y el punto ciego resulta obvio. El código cargó en el navegador, leyó el campo en el navegador y envió la copia desde el navegador a un tercer dominio. Tu backend solo llegó a ver la transacción legítima y autorizada.
- Un firewall de aplicaciones web (WAF) inspecciona las solicitudes que llegan a tu origen. La solicitud de exfiltración nunca llega ahí, así que el WAF no tiene nada que inspeccionar.
- Un SIEM agrega logs de servidor e infraestructura, y el skimmer no genera ningún evento de servidor. La monitorización de fraude marca anomalías de compra, pero la compra real se completó exactamente como se esperaba.
- Un procesador de pagos como Stripe o Adyen protege la transacción que recibe. Si los campos de tarjeta están en tu propia página, un skimmer los lee antes de que el procesador entre en juego, y tu página sigue debiendo su propia evidencia de PCI DSS 4.0.1 6.4.3 y 11.6.1 al margen del procesador.
El ataque vive en un runtime al que tu stack del lado del servidor no puede llegar. Un problema del lado del cliente necesita una defensa del lado del cliente.
Cómo la monitorización en el navegador detecta cada movimiento
La detección tiene que situarse donde corre el skimmer. cside monitoriza scripts y comportamiento en el navegador, así que cada movimiento deja una señal sobre la que puede actuar.
- Inyectar aparece como un script nuevo o modificado. cside mantiene un inventario de scripts y marca altas, cambios y etiquetas de terceros manipuladas en cuanto aparecen, no semanas después en un informe de fraude.
- Capturar aparece como comportamiento. Listeners inesperados en campos de pago, código que lee inputs que no debería y overrides de
fetchosendBeaconson anomalías de runtime frente a una línea base conocida como buena. - Exfiltrar aparece como un destino. cside pone de manifiesto las solicitudes salientes hacia dominios que no están en tu allowlist, el movimiento característico de un skimmer que intenta salir.
Como cside corre en navegadores reales en lugar de un escáner de sala limpia, la entrega condicional no oculta el skimmer como sí lo oculta de un crawler headless. Esa misma visibilidad produce la evidencia que espera PCI DSS 4.0.1: un inventario autorizado de los scripts de la página de pago para 6.4.3, y alertas sobre cambios no autorizados en el contenido de los scripts y las cabeceras para 11.6.1, ambos obligatorios desde el 31-03-2025.
Más lecturas en cside
- ¿Qué es el skimming de tarjetas en línea?
- Qué es Magecart: guía completa y estrategia de prevención
- Formjacking vs Magecart vs digital skimming
- ¿Qué son los skimmers digitales?
- Los mayores ataques Magecart de la historia (hasta ahora)
- Seguridad del lado del cliente de cside
Incidentes Magecart identificados (2018 a 2024)
El ecosistema Magecart es una federación laxa de al menos siete grupos distintos (numerados del Group 1 al Group 12 por RiskIQ) que usan TTPs compartidos. Las divulgaciones públicas siguientes son los casos de referencia que clientes y QSAs citan al definir el alcance de los controles de PCI DSS 4.0.1 §6.4.3 y §11.6.1.
- British Airways (2018). Alrededor de 380.000 registros de tarjetas de pago exfiltrados durante 15 días desde un script comprometido servido en las páginas de checkout y de la app móvil. La multa del ICO del Reino Unido se redujo de £183M a £20M.
- Ticketmaster UK (2018). Datos de tarjeta de ~40.000 clientes expuestos después de que el script de soporte al cliente de Inbenta, servido desde un CDN de terceros, fuera modificado para skimear la página de pago. Multa del ICO de £1,25M.
- Newegg (2018). 15 líneas de JavaScript inyectado capturaron todos los datos de tarjeta enviados a
checkout/payment.aspxdurante 35 días. Atribuido a Magecart Group 4 por RiskIQ. - Warner Music Group (2020). Varios sitios de e-commerce operados por WMG en EE.UU. y Reino Unido comprometidos durante tres meses, apuntando a los datos de checkout en la plataforma Volusion.
- Segway (2022). Los atacantes usaron una extensión maliciosa de Magento para skimear formularios de pago, divulgado por Malwarebytes.
- Kaiser Permanente (2024). 13,4 millones de miembros notificados después de que scripts de analítica y rastreo de terceros en páginas orientadas a los miembros expusieran información sensible, adyacente a la misma clase de TTP de Magecart.
- Cadena de suministro de Polyfill.io (2024). Tras un cambio de propiedad,
cdn.polyfill.ioempezó a servir código malicioso a más de 100.000 sitios que incrustaban la librería, divulgado por Sansec. Fastly, Cloudflare y Google intervinieron a nivel de red. - Adobe Commerce / Magento Cosmicsting (CVE-2024-34102). Fallo de deserialización XML del lado del servidor usado para plantar skimmers del lado del cliente en cientos de comerciantes Magento durante 2024 y hasta 2025.
Todos los casos anteriores eludieron las defensas del lado del servidor del comerciante y manipularon código que ejecutaba el navegador. Esa es exactamente la brecha que PCI DSS 6.4.3 (autorización e integridad de scripts) y 11.6.1 (detección de cambios en la página de pago) se escribieron para cerrar.
