Resumen: detección de skimmers digitales en el checkout
- La monitorización avisa tarde: La mayoría de las herramientas de seguridad client-side aseguran detectar skimmers digitales, pero solo inspeccionan los scripts después de que el navegador ya los ha cargado, así que la alerta llega justo en el mismo instante en que los datos de la tarjeta abandonan la página.
- cside bloquea antes de renderizar: El agente JavaScript de origen de cside observa el comportamiento en runtime de cada script de terceros en el navegador, lecturas del DOM, llamadas de red, mutaciones, y bloquea el comportamiento de skimmer antes de que el payload malicioso pueda renderizar el formulario falso de tarjeta, sin muestreo y con bloqueo autónomo por encima.
- Dónde recae la responsabilidad: Antes de que los evaluadores de PCI DSS 4.0 pregunten por los scripts de terceros en tus páginas de pago, decide si las herramientas de solo monitorización que alertan tras la ejecución realmente trasladan la responsabilidad fuera de tu cuenta comercial.
¿Poco tiempo? Consulta el bloqueo de Magecart y skimmers en el navegador de cside. Cubre todo lo de abajo en un solo despliegue.
Recientemente, conocimos una nueva campaña de ciberataques de gran envergadura que afectó a cientos de tiendas en línea, aprovechando vulnerabilidades en scripts y plugins de terceros.
Este es un ejemplo perfecto de un 'skimmer digital'.
Los skimmers digitales son fragmentos de código inyectados de forma maliciosa en sitios web legítimos. Su objetivo es obtener información personal y de tarjetas de crédito.
Este problema está en aumento y es parte de la razón por la que se creó cside. cside es capaz de detectar este código malicioso y evitar que afecte a los usuarios de los sitios web.
Este código se carga en el lado del cliente (el navegador) del usuario, en lugar de en el servidor del sitio web. Esto lo hace especialmente difícil de detectar, ya que la mayoría de los sitios web no cuentan con una herramienta como cside para proteger la experiencia del lado del cliente de sus usuarios.
La mayoría de nuestros competidores analizan este código después de que se ha cargado en el navegador del usuario, sin prevenir el ataque, sino simplemente alertando al sitio web que lo facilita. Nosotros cargamos todos los scripts primero en un proxy y, una vez que se consideran seguros, los servimos al usuario. También optimizamos los scripts cuando es posible para servirlos más rápido que una red de distribución de contenidos (CDN), mitigando cualquier problema de latencia. De hecho, a menudo aumentamos la velocidad de entrega de estos scripts.
Qué ocurrió en este ataque
Este ataque fue divulgado por MalwareBytes y era, hasta ahora, el más reciente de una serie de ataques ejecutados en sitios de comercio electrónico que utilizan Magento.
No informamos sobre esto ya que ninguno de nuestros usuarios utiliza Magento actualmente.
En otras noticias, recientemente notamos que Malwarebytes(.)fr fue configurado como una página de venta de dominio, con un registrador de IP. Esto enviaba esa información a un webhook de Discord. Fue eliminado o baneado rápidamente de Discord. Lee aquí por qué los dominios caducados pueden ser un problema enorme y se utilizan con frecuencia en este tipo de ataques.
Aquí tienes una prueba de ese webhook:
Volviendo al tema.
Un ataque a la cadena de suministro web como este ocurre porque los atacantes vulneran Magento (o un plugin de Magento) e insertan de forma remota una sola línea de JavaScript. En la mayoría de estos casos, y también en este más reciente, los atacantes modifican un script legítimo para pasar desapercibidos el mayor tiempo posible.
El código también está ofuscado para dificultar aún más la comprensión de lo que se está ejecutando exactamente. Esta es una forma legítima de proteger código, y las empresas la utilizan continuamente para evitar que su código sea copiado o manipulado.
A partir de ahí, el ataque es bastante sencillo. El código carga una función que extrae información del sitio en el que se ha insertado y la envía a todo tipo de formularios. El dominio dentro del código malicioso la recibe, y ahora los atacantes tienen esa información.
En este ataque, el objetivo era la información de tarjetas de crédito de personas que realizaban compras en línea sin sospechar nada. Esas personas tienen muy poco margen de acción, pero los sitios web donde ocurre el ataque son responsables y suelen recibir multas de PCI DSS y, en ocasiones, demandas judiciales.
En este caso, el flujo de pago fue interrumpido durante el proceso de compra. Se insertó un marco falso de métodos de pago y los usuarios completaron ese formulario en lugar del real. Esto se logró mediante una simple etiqueta de imagen incluida en una única línea de JavaScript.
Esto tendría el siguiente aspecto: {domain}.{shop|online)/img/
Los dominios maliciosos identificados en estos ataques hasta ahora incluyen:
- codcraft(.)shop
- codemingle(.)shop
- datawiz(.)shop
- deslgnpro(.)shop
- happywave(.)shop
- luckipath(.)shop
- pixelsmith(.)shop
- salesguru(.)online
- statlstic(.)shop
- statmaster(.)shop
- trendset(.)website
- vodog(.)shop
- artvislon(.)shop
- statistall(.)com
- analytlx(.)shop
Este es otro ejemplo más de un ataque que demuestra por qué las empresas necesitan proteger la experiencia del lado del cliente de sus usuarios. Si los sitios hubieran instalado una herramienta como cside, sus usuarios habrían estado protegidos.
La regulación ya está aquí
A partir de marzo de 2025, PCI DSS 4.0 exige que los sitios web con procesos de pago en línea supervisen los scripts de terceros en sus páginas de pago.
Abogamos por monitorizar y proteger estos scripts para estar completamente seguros. Escribimos aquí sobre el riesgo de proteger únicamente las páginas de pago y no el sitio web completo. Los atacantes simplemente se adaptarán y, con una respuesta rápida, es probable que los ataques sigan ocurriendo.
Ten en cuenta que al usar cside, la totalidad de tu sitio web está protegida.
Puedes empezar gratis y estar protegido en minutos.
