Magecart es web skimming que corre dentro del navegador. JavaScript malicioso aterriza en una página de checkout o login, lee lo que el visitante escribe en el formulario y envía una copia a un servidor controlado por el atacante. El pago legítimo sigue pasando, así que para tus servidores parece un día normal de transacciones limpias. Todo parece bien mientras los datos de tarjeta están saliendo, y ese hueco es todo el problema.
Este artículo explica la mecánica para alguien que se encuentra la amenaza por primera vez. No es una política de prevención ni la taxonomía formjacking-vs-Magecart. Recorre la secuencia real: cómo entra el código, cómo captura datos y cómo salen. Entiende esos tres movimientos y entiendes por qué un WAF, un SIEM y un procesador de pagos pueden estar en verde mientras corre un skimmer. cside monitoriza directamente esa capa de navegador, observa cada script mientras se ejecuta y marca el momento en que uno empieza a leer campos o llamar a un dominio que nunca tocó antes, que es la base para detectar Magecart en tiempo real en vez de después de la brecha.
El ataque en tres movimientos
Toda campaña de skimming, sin importar qué grupo la ejecute, se reduce al mismo ciclo. 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 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 el 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 comunes hacia la página, ninguna 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 admin 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 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 propia. - Un tag manager. Toma control de un contenedor de Google Tag Manager o similar y añade una etiqueta con el skimmer. Cada sitio y página que usa ese contenedor ejecuta el código, incluidas páginas de checkout donde esa etiqueta no debería cargar.
Las rutas de terceros y tag manager 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 forma de cadena de suministro es lo que el requisito 6.4.3 y 11.6.1 de PCI DSS 4.0.1 busca cubrir al exigir inventario y autorización de cada script en una página de pago. La brecha de Ticketmaster siguió exactamente este camino: el skimmer llegó al checkout por el script de chatbot de un proveedor comprometido, no por código propio de Ticketmaster.
Movimiento 2: cómo el skimmer lee tu formulario
Cuando el script corre, leer el formulario es desarrollo web normal usado contra ti. Leer y modificar el DOM es cómo funciona cualquier framework moderno, así que las acciones del skimmer parecen comportamiento normal de página. Un skimmer suele hacer una o varias de estas cosas:
- Lee valores de input directamente. Selecciona 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 envíe el formulario. - Secuestra el camino de submit. Envuelve el handler de submit del formulario o engancha el botón "pagar", ensamblando el payload completo en el momento en que el usuario confirma.
- Parchea primitivas de red. Skimmers avanzados sobrescriben
fetch,XMLHttpRequest.prototype.sendonavigator.sendBeaconpara leer la solicitud de pago real cuando tu propio código la envía. - Superpone un campo falso. Algunos inyectan un iframe de pago falso sobre el real, de modo que el comprador escribe la tarjeta directamente en el input del atacante. El análisis propio de cside de una campaña Magecart encontró un frame de pago falso insertado en checkout mediante una sola línea JavaScript ofuscada, el tipo de intercambio que un escaneo del lado del servidor nunca ve.
El serving condicional es lo que lo mantiene silencioso
El skimmer no se dispara para todo el mundo. Se filtra para que quienes más probablemente lo pillen, esto es, equipos de seguridad, escáneres y bots, nunca vean el comportamiento malicioso:
- Filtrado por ruta. Muchos skimmers se arman solo en URLs que coinciden con patrones de checkout o login, así que el código duerme 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. Variantes más avanzadas buscan globales de Selenium o fugasRuntimede Chrome DevTools Protocol (CDP) para detectar navegadores instrumentados. - Disparo una vez por sesión. Exfiltrar una sola vez evita ruido de red duplicado que destacaría en un log.
Esa carrera también escala del lado atacante: el informe Future of Web Security 2026 de cside rastreó un aumento aproximado de 10x en playwright-stealth durante 2025, automatización construida para derrotar navigator.webdriver y comprobaciones parecidas. La misma evasión que oculta el tooling del atacante a defensores es la que oculta un skimmer a los tuyos. El código suele estar ofuscado además de todo eso, lo que entierra la intención en una revisión manual.
Movimiento 3: cómo salen los datos
La captura no sirve al atacante hasta que los datos le llegan. La exfiltración es una 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, diseñado para analítica, así que se mezcla |
fetch() / XMLHttpRequest | Una solicitud asíncrona estándar, a menudo a un dominio parecido que imita un CDN o 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 drop de datos |
| WebSocket | Un canal persistente para transmitir pulsaciones capturadas casi en tiempo real |
Tres propiedades hacen que esta fuga sea casi imposible de ver 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ó a baways.com, así que no salta en un log. Y el payload es pequeño y a menudo codificado en base64, por lo que parece un ping rutinario de telemetría. Lo crítico: 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, WAF y procesador nunca lo ven
Junta los tres movimientos y el punto ciego es 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 vio la transacción legítima y autorizada.
- Un WAF inspecciona 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 evento de servidor. La monitorización de fraude marca anomalías de compra, pero la compra real se completó exactamente como debía.
- Un procesador de pagos como Stripe o Adyen protege la transacción que recibe. Si tus campos de tarjeta están en tu propia página, un skimmer los lee antes de que el procesador participe, y tu página sigue debiendo su propia evidencia PCI DSS 4.0.1 6.4.3 y 11.6.1 sin importar el procesador.
El ataque vive en un runtime que tu stack del lado del servidor no alcanza. Un problema client-side necesita una defensa client-side.
Cómo la monitorización de navegador captura cada movimiento
La detección debe sentarse 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 cuando aparecen, no semanas después en un informe de fraude.
- Capturar aparece como comportamiento. Listeners inesperados en campos de pago, código leyendo inputs que no debería y overrides de
fetchosendBeaconson anomalías runtime contra una línea base conocida. - Exfiltrar aparece como destino. cside aflora solicitudes salientes a dominios que no están en tu allowlist, el movimiento característico de un skimmer intentando salir.
Como cside corre en navegadores reales en vez de un escáner de sala limpia, el serving condicional no oculta el skimmer como lo oculta de un crawler headless. Esa misma visibilidad produce la evidencia que espera PCI DSS 4.0.1: inventario autorizado de scripts de página de pago para 6.4.3 y alertas sobre cambios no autorizados en contenido de scripts y cabeceras para 11.6.1, ambos obligatorios desde 2025-03-31.
