Skimmer con WebRTC que evade controles y roba datos en e‑commerce

Informatec Digital » Recursos » Skimmer con WebRTC que evade controles y roba datos en e‑commerce

Un nuevo tipo de skimmer de tarjetas basado en WebRTC está poniendo patas arriba la seguridad de las plataformas de comercio electrónico. Hablamos de un malware capaz de robar datos de pago directamente desde el navegador del cliente y sacarlos del sitio usando canales de datos WebRTC, sorteando de forma elegante mecanismos como la Content Security Policy (CSP) o los WAF tradicionales que solo miran tráfico HTTP.

Este enfoque no solo es ingenioso, sino que además se apoya en vulnerabilidades críticas como PolyShell en Magento y Adobe Commerce, que permiten a atacantes no autenticados subir código malicioso y ejecutarlo en el servidor. El resultado es un cóctel muy peligroso: entrada sencilla al sistema, inyección silenciosa de scripts en el checkout y exfiltración de tarjetas mediante WebRTC DTLS sobre UDP, casi invisible para la mayoría de defensas actuales.

Quién está detrás del hallazgo y por qué importa tanto

Sansec, una firma de ciberseguridad especializada en proteger plataformas de comercio electrónico, fue la que destapó este nuevo skimmer WebRTC. Su trabajo se centra en analizar incidencias de malware en tiendas online, localizar inyecciones de código, skimmers de pago y backdoors, y proporcionar inteligencia de amenazas centrada en e‑commerce.

Lo relevante del caso es que estamos ante la primera vez documentada en la que WebRTC DataChannels se usan como canal de exfiltración de datos de tarjetas en entornos de comercio electrónico. Hasta ahora, los grupos de tipo Magecart tiraban de peticiones HTTP clásicas, beacons de imagen o, en escenarios algo más avanzados, de WebSockets. Este salto de calidad supone un auténtico cambio de juego.

Sansec no se topó con esto en un laboratorio aislado, sino al investigar incidentes reales en grandes empresas. Entre los objetivos afectados figura un fabricante de automóviles con una valoración superior a los 100.000 millones de dólares, además de una cadena de supermercados situada en el top 10 mundial y otras compañías multimillonarias. Es decir, los atacantes están afinando sus técnicas para ir directamente a por los objetivos de más alto valor.

En un periodo de apenas dos meses, los investigadores identificaron skimmers en cinco organizaciones de este nivel, lo que refuerza la idea de que no se trata de un experimento puntual, sino de una tendencia clara hacia técnicas más sigilosas y difíciles de inspeccionar con las herramientas de siempre.

Cómo funciona el skimmer: WebRTC DataChannels como autopista secreta

En la mayoría de incidentes de skimming tradicionales, el guion es bastante conocido: un atacante aprovecha una mala configuración, un plugin vulnerable o un script de terceros comprometido para inyectar código que captura los datos del formulario de pago y los envía fuera del sitio, normalmente mediante peticiones HTTP POST hacia un servidor bajo su control.

Ese tipo de tráfico, aunque molesto, suele ser detectable mediante un WAF, reglas de IDS/IPS, inspección profunda de paquetes o una CSP bien afinada. Cuando de repente aparece un JavaScript intentando mandar información de tarjetas a un dominio raro por HTTP, saltan las alarmas. El problema es que este nuevo skimmer decide cambiar completamente de canal de comunicación.

En lugar de utilizar HTTP o WebSockets, el malware establece una RTCPeerConnection para crear un DataChannel WebRTC entre el navegador de la víctima y la infraestructura del atacante. El tráfico se envía como datagramas sobre UDP y se cifra con DTLS (Datagram TLS). A ojos de muchas herramientas de seguridad, eso es poco más que ruido de red cifrado, difícil de interpretar o filtrar de manera específica.

De este modo, el skimmer puede tanto recibir su payload malicioso por el propio canal WebRTC (evitando así cargar scripts sospechosos mediante HTTP) como exfiltrar la información de tarjetas capturada en el checkout por esa misma vía. Todo ello sin generar las típicas trazas de tráfico web que un analista buscaría al examinar logs de servidores, proxies o firewalls.

La analogía sería algo así como vigilar la puerta principal de casa con cámaras y alarmas, mientras un intruso entra y sale tranquilamente por una ventana lateral. La seguridad centrada únicamente en tráfico HTTP/HTTPS no tiene visibilidad real de estas conexiones punto a punto cifradas, salvo que se desplieguen herramientas muy específicas de análisis de WebRTC o monitorización del comportamiento del navegador.

Content Security Policy: qué protege y dónde hace agua con WebRTC

La política de seguridad de contenidos, o Content Security Policy (CSP), se ha convertido en una de las piezas clave para proteger aplicaciones web modernas. A grandes rasgos, permite definir desde el lado del servidor a qué dominios puede conectarse el navegador y qué recursos (scripts, imágenes, fuentes, etc.) están permitidos.

Directivas como connect-src, script-src o img-src ayudan a limitar peticiones salientes y la carga de código de orígenes no confiables. Bien utilizada, CSP reduce de forma considerable el impacto de ataques de inyección de scripts y exfiltración de datos vía HTTP o WebSockets, siempre que se haya configurado de forma estricta y sin comodines excesivos.

El agujero importante viene cuando entra en juego WebRTC. El estándar actual no contempla una directiva CSP ampliamente adoptada que regule RTCPeerConnection y sus DataChannels. En la práctica, aunque alguien haya definido una política muy restrictiva para las conexiones HTTP, el código malicioso sigue pudiendo crear un peer‑to‑peer con el servidor del atacante y enviar datos cifrados por ahí.

Chrome dispone de una directiva CSP experimental orientada a WebRTC, pero su uso es todavía minoritario y no forma parte del conjunto de defensas habituales de la mayoría de sitios. Eso deja un hueco evidente: la seguridad basada solo en CSP ofrece una sensación de blindaje que no se corresponde con la realidad cuando hay scripts capaces de establecer conexiones WebRTC directas.

En resumen, muchas tiendas online que creen tener una política “a prueba de balas” porque bloquean todos los dominios externos salvo unos pocos whitelisteados siguen exponiendo los datos de sus clientes a este tipo de skimmers que operan por un canal no cubierto por las reglas de siempre.

Cómo el malware aprovecha el nonce de CSP para camuflarse

Algunos desarrolladores dan un paso más y utilizan nonces en la cabecera CSP. Este enfoque consiste en asignar un valor aleatorio (nonce) a cada carga de página y añadirlo tanto en la política CSP como en los scripts legítimos del documento, de forma que solo los scripts que lleven ese nonce se ejecuten.

Sobre el papel, esto dificulta que un atacante simplemente inyecte un script externo en la página, porque dicho script no tendría el nonce correcto y el navegador lo bloquearía. Sin embargo, el skimmer WebRTC descubierto ha demostrado que también se puede robar o reutilizar ese nonce desde el propio entorno del navegador.

El malware analiza el código de la página, localiza un script legítimo que incluya el nonce y lo copia para usarlo en su propio bloque de código. De esta forma, el script malicioso se presenta ante el navegador con las mismas “credenciales” que un script autorizado.

Cuando esto ocurre, las herramientas de monitorización y las propias políticas del sitio no distinguen entre el código legítimo y el inyectado, porque ambos cumplen aparentemente las mismas condiciones de seguridad. Una vez que ha pasado ese filtro, el skimmer solo tiene que inicializar la RTCPeerConnection, abrir el DataChannel y empezar a intercambiar datos cifrados sin levantar sospechas.

El gran problema aquí es que la mayoría de soluciones de seguridad que vigilan la red están centradas en inspeccionar HTTP y, como mucho, WebSockets. Este skimmer se salta esas capas por completo, consiguiendo que no haya peticiones HTTP claramente anómalas que delaten el robo, algo que complica mucho la respuesta ante incidentes y el forense posterior.

PolyShell en Magento y Adobe Commerce: la puerta de entrada perfecta

Todo este montaje no serviría de mucho si los atacantes no tuvieran una forma eficaz de introducir su código en las tiendas. Ahí es donde entra PolyShell, una vulnerabilidad crítica en Magento Open Source y Adobe Commerce que se ha convertido en el vector de entrada principal de este skimmer WebRTC.

PolyShell permite a un atacante no autenticado subir archivos potencialmente ejecutables a determinadas rutas del servidor, especialmente si la configuración de los directorios de medios no está bien endurecida. A partir de esa subida, los adversarios pueden desplegar web shells, backdoors y todo tipo de scripts diseñados para ejecutar código arbitrario.

Los primeros indicios de explotación masiva se remontan al 19 de marzo de 2026, fecha a partir de la cual se detectó un volumen muy alto de escaneos automatizados provenientes de más de 50 direcciones IP distintas. Esos escaneos buscaban precisamente instancias vulnerables de Magento y Adobe Commerce con la puerta PolyShell abierta.

Los datos recopilados por los investigadores señalan que aproximadamente el 56,7% de las tiendas identificadas como vulnerables acabaron comprometidas en muy poco tiempo. Es un porcentaje altísimo que revela hasta qué punto los atacantes automatizaron el uso del exploit y lo convirtieron en una operación a gran escala.

Una vez conseguida la ejecución de código, los criminales inyectan el script de skimming en la lógica de checkout, de modo que el código se ejecute de forma automática cuando el cliente introduce sus datos de pago. A partir de ahí, la recolección de tarjetas y la exfiltración vía WebRTC se mantienen activas mientras la brecha no se detecte y se limpie por completo el entorno.

Evolución de Magecart y salto hacia WebRTC

Bajo el paraguas de Magecart se agrupan desde hace años distintos actores y campañas centradas en el robo de datos de pago en tiendas online. No es un grupo único, sino una categoría de tácticas y herramientas que ha ido evolucionando según lo hacían también las defensas del sector.

En los primeros tiempos, los skimmers se limitaban a lanzar peticiones HTTP simples a dominios controlados por los atacantes. A poco que la empresa desplegara un WAF o revisara logs de acceso, estos patrones podían identificarse con relativa facilidad, lo que empujó a los criminales a buscar alternativas más discretas.

Después llegaron los llamados image beacons, donde la información robada se incrustaba en parámetros de carga de imágenes aparentemente inocuas (por ejemplo, un GIF). Aunque más sutil, esta técnica también podía detectarse con reglas adecuadas y análisis de tráfico saliente.

Más adelante, algunos grupos comenzaron a usar WebSockets para mantener canales persistentes entre navegador y servidor de mando y control. Este método complicaba aún más la detección con herramientas centradas en tráfico HTTP convencional, aunque seguía siendo visible para quienes inspeccionaban las cabeceras y el destino de esas conexiones.

El movimiento actual hacia WebRTC DataChannels es, en realidad, una respuesta lógica a esa carrera armamentística. Al aprovechar un estándar pensado para videollamadas, chats o transmisiones en tiempo real, los atacantes se camuflan detrás de un flujo cifrado y descentralizado que no siempre está bien monitorizado en entornos corporativos.

Skimmers tradicionales vs skimmers basados en WebRTC

A la hora de comparar un skimmer clásico con este nuevo enfoque WebRTC, una de las principales diferencias es el canal utilizado para sacar los datos. Los primeros se apoyan en HTTP/HTTPS o WebSockets, mientras que los segundos usan UDP cifrado con DTLS a través de DataChannels.

Otra diferencia clave tiene que ver con la visibilidad de las herramientas de seguridad. Un firewall de aplicaciones web (WAF), un proxy inverso, o incluso un sistema de detección de intrusiones de red, suelen estar bien equipados para distinguir y registrar tráfico HTTP malicioso, pero no tanto para inspeccionar el contenido de un canal WebRTC cifrado.

La tercera gran separación es el papel de CSP. En un escenario tradicional, una política de seguridad de contenidos bien planteada puede bloquear muchas de las salidas ilícitas de datos, al restringir conectores hacia dominios desconocidos. En el caso de WebRTC, la CSP estándar no controla la creación de RTCPeerConnection, con lo que el skimmer puede salvar esa barrera casi sin esfuerzo.

Por último, hay una cuestión de madurez defensiva: los equipos de seguridad y los proveedores de soluciones llevan años afinando firmas, reglas y mecanismos para detectar tráfico HTTP anómalo, pero todavía no existe el mismo grado de especialización frente a abusos de WebRTC en entornos de comercio electrónico. Esa asimetría temporal juega ahora mismo a favor de los atacantes.

Medidas de protección frente a skimmers con WebRTC

Ante un panorama así, es normal pensar que poco se puede hacer, pero eso no es del todo cierto. Hay una serie de pasos que, combinados, reducen de forma significativa las posibilidades de que un skimmer de este tipo se instale y permanezca oculto en tu tienda online.

1. Aplicar sin demora los parches de Magento y Adobe Commerce

El primer frente es atacar la raíz del problema, es decir, la vulnerabilidad de entrada. Si tu negocio utiliza Magento Open Source o Adobe Commerce, es vital comprobar la versión actual e instalar los parches que corrigen PolyShell en cuanto estén disponibles para el entorno de producción.

Los informes muestran que más de la mitad de las instalaciones vulnerables detectadas, concretamente ese 56,7% de tiendas, terminaron comprometidas en poco tiempo. Quedarse en versiones antiguas o posponer el parcheo es, literalmente, jugar a la ruleta rusa con los datos de tus clientes.

2. Monitorizar la integridad de los scripts

Como el skimmer se inyecta principalmente en los scripts de checkout, una de las defensas más efectivas es desplegar herramientas de monitorización de integridad de JavaScript. Soluciones como las ofrecidas por proveedores especializados en seguridad para e‑commerce permiten detectar cambios no autorizados en el código.

Estas plataformas comparan el estado actual de tus archivos con versiones de referencia, alertando si aparecen bloques nuevos, ofuscados o redirigidos a dominios extraños. Ninguna herramienta es infalible, pero disponer de este tipo de vigilancia reduce de forma drástica la ventana de tiempo durante la cual un skimmer puede permanecer activo sin ser visto.

3. Explorar el uso de directivas CSP orientadas a WebRTC

Aunque todavía está en fase experimental, algunos navegadores como Chrome ofrecen soporte para directivas CSP específicas para WebRTC. Si tu audiencia utiliza principalmente navegadores modernos y controlas bien el stack tecnológico, puede ser interesante probar estas opciones.

Eso sí, no conviene depositar toda la confianza en una característica que aún no está estándar ni soportada de forma homogénea. Lo ideal es considerarla una capa adicional de defensa, nunca el único muro, combinándola con parcheo agresivo, análisis de scripts y buenas prácticas en la gestión de dependencias.

4. Revisar y reducir scripts de terceros

Todo script externo que cargas en tu tienda es otro punto potencial de compromiso. Widgets de atención al cliente, herramientas de analítica, plataformas de publicidad o librerías de terceros pueden convertirse en la vía por la que se inyecta código malicioso si alguno de esos proveedores sufre una brecha.

Una medida razonable es realizar auditorías periódicas (por ejemplo, cada tres meses) de todos los scripts que se cargan en páginas sensibles como el checkout, eliminando los que no sean estrictamente necesarios. Menos dependencias implica menos superficie de ataque.

5. Vigilar el comportamiento del formulario de pago en tiempo real

Más allá de comprobar el código en reposo, resulta muy útil monitorizar qué hace realmente el formulario de pago en tiempo de ejecución. Esto incluye registrar hacia qué dominios intenta enviar datos, si se abren conexiones no esperadas o si se están iniciando RTCPeerConnections sin justificación funcional.

Algunos proveedores de hosting y seguridad web ofrecen funcionalidades de análisis de comportamiento en tiempo real para formularios críticos. Cuando se detecta un intento de exfiltración a dominios no autorizados o el uso de canales de comunicación inusuales, se pueden cortar sesiones sospechosas, bloquear IPs y notificar de inmediato al equipo de seguridad.

Errores habituales que dejan la puerta abierta

En la práctica, muchos de los incidentes relacionados con este tipo de skimmers comparten una serie de fallos recurrentes en las organizaciones afectadas. Ponerles foco ayuda a evitar caer en la misma trampa.

1. Confiar ciegamente en una CSP muy estricta

Configurar una CSP exigente es una buena idea, pero no es una solución mágica ni total. El hecho de que la versión estándar de CSP no controle RTCPeerConnection hace que los atacantes puedan seguir sacando datos vía WebRTC aunque todas las conexiones HTTP no autorizadas estén bloqueadas.

Por eso, es un error pensar que “como ya tengo CSP, estoy cubierto frente a todo lo que vaya por el navegador”. Sin un enfoque por capas que incluya WAF, monitorización de scripts, revisiones de logs y auditorías periódicas de seguridad, la política de contenidos por sí sola se queda corta ante técnicas como las que estamos comentando.

2. Retrasar el parcheo de vulnerabilidades conocidas

Otra equivocación frecuente es no actualizar con rapidez cuando aparece una vulnerabilidad crítica con exploit público. PolyShell es un ejemplo de libro de cómo un fallo conocido, con información detallada disponible, se aprovecha de manera masiva cuando las organizaciones tardan en reaccionar.

Una vez que un fallo entra en catálogos como el Known Exploited Vulnerabilities (KEV) de CISA, la prioridad de parcheo debería dispararse. Mantener entornos productivos en versiones obsoletas o sin aplicar hotfixes en estos casos es asumir conscientemente un riesgo muy elevado.

3. Depender solo de la monitorización de red

Muchas infraestructuras cuentan con potentes sistemas para inspeccionar tráfico HTTP, HTTPS y TCP, pero apenas tienen visibilidad sobre comunicaciones basadas en UDP cifrado como las que usa WebRTC. Esto crea una falsa sensación de control: los paneles muestran todo en verde, mientras el skimmer se comunica felizmente por otro camino.

La solución pasa por complementar la monitorización de red clásica con vigilancia de integridad de código y análisis del comportamiento del lado cliente. En otras palabras, hay que mirar no solo qué sale por la red, sino también qué hace el código JavaScript que se ejecuta en el navegador y cómo interactúa con APIs como WebRTC.

Qué se sabe con certeza y qué todavía está en el aire

La información pública disponible sobre este skimmer y sus campañas asociadas permite diferenciar entre hechos confirmados y aspectos que aún permanecen en la zona gris de la especulación razonable.

Entre los elementos confirmados está el descubrimiento de un skimmer WebRTC operativo en la tienda online de un gran fabricante de automóviles, el comienzo de la explotación masiva de PolyShell el 19 de marzo de 2026 y la cifra aproximada del 56,7% de tiendas vulnerables comprometidas. También está demostrado que los DataChannels de WebRTC no entran dentro de las directivas CSP estándar.

En el lado de lo no confirmado, aunque plausible, se encuentra la identidad de todas las grandes empresas afectadas, ya que no todas han sido nombradas públicamente. Tampoco está claro si el uso de WebRTC como canal de exfiltración está extendiéndose de manera masiva o si, por ahora, se limita a determinados grupos con alta capacidad técnica.

De igual forma, los detalles finos del exploit, los posibles módulos complementarios que pueda incluir este malware y su grado de integración con otros componentes de la cadena de ataque todavía no se conocen en profundidad. Es razonable suponer que fabricantes de soluciones de seguridad como los orientados a WordPress o Magento están trabajando para afinar sus motores de detección sobre este patrón concreto.

Preguntas frecuentes sobre skimmers WebRTC y e‑commerce

La aparición de este tipo de amenazas genera muchas dudas entre administradores de tiendas online y responsables de seguridad. Algunas preguntas se repiten una y otra vez, así que conviene darles respuesta de forma directa.

¿Cómo puedo saber si mi tienda tiene un skimmer instalado?

Lo más efectivo es recurrir a , capaces de recorrer el código de tu sitio en busca de patrones sospechosos, scripts ofuscados, referencias a dominios maliciosos o cambios no autorizados en el checkout.

Si tu proveedor de hosting incluye servicios de seguridad gestionada, es buena idea lanzar un escaneo completo cuanto antes. En el caso concreto de PolyShell, además, deberías comprobar que tus instancias de Magento o Adobe Commerce estén actualizadas con los parches que corrigen la vulnerabilidad y revisar los directorios de medios en busca de archivos extraños o fuera de lugar.

¿Por qué se puede abusar de WebRTC si es un estándar legítimo?

WebRTC fue diseñado para habilitar comunicación en tiempo real entre navegadores: videollamadas, compartición de pantalla, chats de voz o transferencia de ficheros. El problema es que cualquier canal de comunicación suficientemente flexible puede utilizarse también con fines no previstos originalmente.

En este caso, el estándar no incluye por defecto mecanismos que lo integren con CSP de forma robusta, y eso create un hueco de seguridad que los atacantes han sabido aprovechar. No se trata tanto de un bug concreto, sino de una limitación de diseño y de una falta de controles complementarios en muchas aplicaciones web que hacen uso —o no— de WebRTC.

¿Puede la monitorización de red tradicional detectar este ataque?

Con las herramientas convencionales, no resulta sencillo detectar el contenido de las comunicaciones WebRTC porque viajan cifradas con DTLS sobre UDP. Un WAF que solo mire HTTP/HTTPS no verá las tarjetas volando por la red, del mismo modo que un firewall clásico apenas registrará que hay tráfico UDP cifrado sin mayor contexto.

Para tener opciones reales de detección hay que combinar análisis de integridad del código JavaScript, reglas de comportamiento que identifiquen el uso sospechoso de RTCPeerConnection y, en algunos casos, soluciones avanzadas de inspección de tráfico cifrado que permitan, al menos, aplicar reglas basadas en patrones de conexión, destinos y volúmenes.

¿Es un problema exclusivo de Magento o también afecta a WordPress y otros CMS?

El vector de entrada descrito públicamente está muy ligado a PolyShell en Magento y Adobe Commerce, pero la técnica de exfiltración mediante WebRTC no es ni mucho menos exclusiva de estas plataformas. Cualquier sistema que permita la inyección de scripts en la página de pago —incluidos WordPress con WooCommerce u otros CMS— podría sufrir un ataque idéntico si se explota otra vulnerabilidad distinta.

En otras palabras, lo específico de este caso es el uso de PolyShell para entrar, pero el uso de WebRTC DataChannels como canal de robo de datos es aplicable a cualquier entorno donde se consiga ejecutar código JavaScript en el navegador de los clientes durante el proceso de pago.

A la vista de todo lo anterior, queda claro que las tácticas de skimming en e‑commerce han dado un salto cualitativo con el uso de WebRTC como canal de exfiltración, apoyándose en vulnerabilidades críticas como PolyShell y en lagunas de estándares como CSP. Las organizaciones que gestionan tiendas online no pueden limitarse ya a vigilar tráfico HTTP y confiar en una sola capa de protección: toca parchear con rapidez, reducir superficie de ataque, monitorizar la integridad de los scripts y prestar atención al comportamiento real del código en el navegador si no quieren que los datos de pago de sus clientes acaben saliendo por esa “ventana lateral” que hasta ahora casi nadie estaba mirando.