El píxel 1x1 que roba tarjetas: el nuevo ataque Magecart en Magento

Una operación de robo de datos ha puesto en peligro a cerca de un centenar de tiendas online que funcionan con la plataforma Magento: el código malicioso que sustrae números de tarjeta está oculto en un píxel y disfrazado como un elemento Scalable Vector Graphics (SVG). La investigación que sacó a la luz esta campaña la publicó la firma de seguridad eCommerce Sansec, cuyos técnicos detallan cómo los atacantes logran inyectar y ejecutar el skimmer sin dejar referencias externas que muchas herramientas de detección sí marcan.

La técnica es aparentemente sencilla y, al mismo tiempo, ingeniosa: el skimmer vive íntegramente en línea dentro de un SVG de 1×1 píxel que incluye un atributo onload. Ese manejador contiene la carga útil codificada en base64, decodificada con atob() y ejecutada después mediante un temporizador; de este modo se evitan las etiquetas <script> externas y la mayoría de los escáneres automatizados no lo detectan fácilmente. Sansec describe esta táctica como una forma de mantener todo el malware “encapsulado” en un solo atributo, sin referencias a ficheros ajenos al sitio.

En la práctica, cuando un comprador legítimo pulsa el botón de pago en una tienda comprometida, un JavaScript malicioso intercepta esa acción y muestra una ventana emergente que simula ser un proceso de pago seguro. La superposición incluye los campos habituales para los datos de la tarjeta y la facturación y realiza comprobaciones en tiempo real —por ejemplo la verificación con el algoritmo de Luhn— para validar que los números presentados parecen correctos. Los datos capturados se empaquetan en JSON, se ofuscan con base64 y además se aplican operaciones sencillas como XOR antes de enviarse al atacante.

Sansec rastreó la exfiltración hasta seis dominios que recibían la información y comprobó que todos estaban alojados en IncogNet LLC (AS40663) en los Países Bajos, con cada dominio recibiendo datos de entre diez y quince víctimas confirmadas. En campañas relacionadas los atacantes habían empleado incluso WebRTC como canal de salida para evitar detecciones basadas en solicitudes HTTP clásicas.

Los investigadores creen que la puerta de entrada para esta oleada fueron explotaciones de la vulnerabilidad conocida como PolyShell, divulgada a mediados de marzo; esta falla afecta a instalaciones de Magento Open Source y Adobe Commerce en versiones estables 2.x y permite la ejecución de código sin autenticar y la toma de control de cuentas. Por ahora, Adobe solo ha incluido la corrección en una versión pre‑release (2.4.9‑alpha3+), por lo que muchas tiendas en producción siguen siendo potencialmente vulnerables. Para contexto sobre la gravedad y los antecedentes de estos ataques tipo “Magecart” puede consultarse la entrada general sobre el fenómeno en Wikipedia.

Sansec indica una serie de señales y acciones concretas para administradores de tiendas que pueden ayudar a detectar y mitigar este ataque. Entre las pistas más directas está la presencia de etiquetas SVG con un atributo onload que invoque atob(); esa cadena es un buen punto de partida para buscar inyecciones. Otra marca de compromiso a revisar en el navegador es la existencia de la clave _mgx_cv en localStorage, ya que su presencia puede indicar que los datos de pago han sido almacenados por la carga maliciosa. También se recomienda vigilar y bloquear solicitudes hacia rutas inusuales como /fb_metrics.php o dominios que se hagan pasar por servicios de analítica y, en caso necesario, filtrar tráfico hacia la IP 23.137.249.67 y los dominios relacionados.

Además de estas detecciones puntuales, hay medidas operativas que conviene aplicar sin demora. Si el sitio es vulnerable a PolyShell, es imprescindible aplicar todas las mitigaciones disponibles de forma inmediata y, cuando sea factible, actualizar a la versión que incluye la corrección o moverse a una rama segura. Los administradores deben revisar integridad de archivos en el servidor comparando con copias conocidas limpias, auditar cuentas y credenciales administrativas, forzar el cambio de contraseñas y claves API, y aplicar reglas en el WAF para bloquear patrones de inyección inline. También es buena práctica notificar a los proveedores de pago y preparar un plan de respuesta para clientes si se confirma el robo de datos; la normativa PCI y las leyes de protección de datos obligan a cierto tipo de respuestas coordinadas.

Para los compradores habituales hay precauciones sencillas que reducen el riesgo: usar métodos de pago externos cuando sea posible (por ejemplo, servicios que tokenizan la tarjeta), preferir tarjetas virtuales o de un solo uso para compras online y vigilar los movimientos en el extracto bancario tras comprar. Si al pagar aparece una ventana emergente que pide nuevamente los datos de la tarjeta o que parece “extraña” en el flujo de la tienda, conviene cerrar la operación y contactar con el comercio por otro canal antes de intentar pagar de nuevo.

En el plano institucional, este incidente subraya la necesidad de que los proveedores de plataformas actúen con rapidez ante vulnerabilidades críticas y de que los equipos de operaciones mantengan procesos de detección que no dependan únicamente de firmas en ficheros externos. Herramientas que inspeccionan scripts inline, controles de integridad en el servidor y una estrategia de despliegue que limite cambios directos en producción ayudan a reducir la superficie de ataque.

Si quieres profundizar en el informe técnico original, la publicación de Sansec contiene las muestras y diagramas del payload: Sansec — SVG onload Magecart skimmer. Para entender mejor el algoritmo que los skimmers usan para validar números de tarjeta en tiempo real, la explicación del algoritmo de Luhn está disponible en Wikipedia. Y para comprobar las notas de versión y documentación de Adobe Commerce puede consultarse la sección de release notes de la plataforma en Adobe Commerce release notes.

Este episodio es un recordatorio de que las amenazas en el comercio electrónico no siempre se esconden en ficheros evidentes ni en llamadas a dominios externos; a veces la amenaza cabe en un píxel y depende de la rapidez con la que administradores y proveedores apliquen parches y controles para que ese píxel deje de ser una trampa.