Skimmer con WebRTC: el nuevo enemigo de los pagos online

Los skimmers con WebRTC se han convertido en uno de los dolores de cabeza más serios para las tiendas online modernas. Ya no hablamos del típico JavaScript que manda datos de tarjetas por HTTP a un dominio sospechoso, sino de código capaz de usar canales de datos WebRTC cifrados para sacar la información sin que los controles habituales se enteren. Si gestionas un e‑commerce y sigues pensando que con tener un buen WAF y una CSP estricta vas servido, este escenario te interesa, y mucho.

En los últimos incidentes analizados por firmas especializadas como Sansec, se ha visto cómo un skimmer WebRTC explotaba vulnerabilidades críticas como PolyShell en Magento y Adobe Commerce para colarse en servidores, inyectar scripts en el checkout y montar un canal WebRTC directo con la infraestructura del atacante. El resultado es una mezcla peligrosa: entrada sencilla, persistencia silenciosa y exfiltración opaca de datos de pago, aprovechando huecos de diseño en estándares tan extendidos como la Content Security Policy (CSP).

Qué es un skimmer con WebRTC y por qué es diferente

Cuando hablamos de un skimmer en e‑commerce nos referimos a un script malicioso que roba datos del formulario de pago (número de tarjeta, fecha de caducidad, CVV, direcciones, etc.) mientras el cliente finaliza la compra. Lo novedoso del skimmer con WebRTC es el canal de comunicación que utiliza: en lugar de tirar de peticiones HTTP POST, imágenes trampa o WebSockets, se apoya en WebRTC DataChannels sobre UDP cifrado con DTLS.

WebRTC nació para permitir comunicación en tiempo real entre navegadores: videollamadas, chat de voz, compartir pantalla o enviar ficheros. El estándar incluye mecanismos como RTCPeerConnection y canales de datos que permiten establecer conexiones punto a punto. El skimmer descubierto aprovecha precisamente estas capacidades para crear un túnel encubierto que saca los datos de tarjetas fuera del sitio, saltándose controles pensados casi exclusivamente para tráfico HTTP o WebSocket.

Lo más llamativo es que Sansec documenta por primera vez el uso de WebRTC DataChannels como canal de exfiltración específico para skimming en tiendas online. Hasta ahora, los grupos tipo Magecart solían decantarse por peticiones web clásicas o, en escenarios algo más avanzados, por WebSockets. Este giro hacia WebRTC supone un salto cualitativo en la sofisticación de las campañas.

El impacto no se queda en pequeñas tiendas. Entre las víctimas confirmadas se encuentra un fabricante de automóviles valorado en más de 100.000 millones, además de una gran cadena de supermercados del top 10 global y otras compañías multimillonarias. Los investigadores han detectado skimmers de este tipo en, al menos, cinco grandes organizaciones en apenas dos meses, lo que sugiere que no se trata de una prueba aislada, sino de una tendencia clara hacia técnicas más discretas.

Cómo funciona el skimmer con WebRTC paso a paso

El corazón del ataque es un script autoejecutable en JavaScript que se inyecta en las páginas de pago comprometidas. Este script, una vez cargado en el navegador de la víctima, prepara toda la infraestructura WebRTC necesaria para hablar con el servidor de mando y control (C2) del atacante y recibir más código malicioso.

En primer lugar, el skimmer crea un RTCPeerConnection y un DataChannel. El canal de datos se etiqueta con la URL actual de la página, lo que le permite al atacante saber exactamente en qué paso del sitio se encuentra el usuario cuando se produce la comunicación. Esta información contextual puede utilizarse para adaptar el payload al flujo de compra.

A continuación, el malware construye y manipula la negociación SDP (Session Description Protocol) localmente. Genera un fragmento de usuario ICE (ice-ufrag) aleatorio y fija de forma estática una contraseña ICE concreta (05l0TstonL9bYAdB04I6x2) en la oferta que se crea. Después modifica la descripción remota para simular una respuesta válida que apunta al servidor C2 con IP 202.181.177.177, utilizando el puerto UDP 3479 y un fingerprint DTLS predefinido.

Lo interesante es que todo este intercambio SDP se hace sin necesidad de un servidor de señalización, que es lo habitual en WebRTC legítimo. El atacante ha precocinado ambos extremos de la negociación, de modo que el navegador de la víctima puede establecer la sesión directamente con la IP del C2, saltándose la infraestructura de señalización que, en un entorno defendido, podría estar vigilada o filtrada.

Una vez el canal queda establecido, el servidor del atacante envía el segundo estadio del ataque, es decir, el payload completo, en pequeños fragmentos. El onmessage del DataChannel se encarga de acumular los trozos recibidos, tanto si vienen como cadena de texto como si lo hacen en formato binario, usando TextDecoder cuando hace falta para reconstruirlos correctamente.

Cuando el canal se cierra, o transcurren unos 10 segundos, entra en acción la función interna encargada de ejecutar el payload. Aquí es donde el diseño se vuelve especialmente retorcido: el código intenta ejecutarse de distintas formas, priorizando siempre la opción que permita sortear la Content Security Policy configurada en la web.

Cómo el skimmer burla la Content Security Policy y el uso de nonces

Una de las piezas más delicadas del ataque es la forma en que el skimmer se aprovecha de las políticas CSP y del uso de nonces. Muchos desarrolladores confían en CSP para limitar qué scripts se pueden ejecutar y, en entornos más avanzados, añaden nonces aleatorios a los scripts legítimos para que únicamente esos bloques de código autorizados se carguen en el navegador.

El JavaScript malicioso analiza el DOM en busca de etiquetas <script> que ya tengan un atributo nonce. Si encuentra alguna, crea un nuevo elemento script y le copia exactamente ese mismo nonce. Después introduce dentro el payload reconstruido y lo inserta en el documento, por ejemplo en el head. Al compartir nonce con un script legítimo, el navegador considera que ese bloque también está permitido por la CSP.

Si no consigue localizar ningún nonce válido, el skimmer prueba otra vía: intenta ejecutar el código mediante Function(payload)(), confiando en que la política habilite unsafe-eval o configuraciones similares. En aquellos casos donde tampoco sea posible, recurre a una tercera opción: inyectar un tag script tradicional con el contenido del payload y añadirlo temporalmente al DOM para forzar su ejecución.

Para rematar, el código utiliza requestIdleCallback cuando está disponible, o un fallback con setTimeout, de forma que la ejecución de la carga maliciosa se produzca en momentos de inactividad del navegador. Este detalle reduce el impacto en el rendimiento y dificulta que herramientas de análisis basadas en IA detecten el comportamiento extraño.

El gran punto débil que aprovecha el skimmer está en que WebRTC, a diferencia de HTTP, no está cubierto por las directivas CSP estándar. Mientras que connect-src controla fetch, XHR y WebSockets, la API RTCPeerConnection queda fuera del alcance de estas reglas. Chrome ha llegado a incluir una directiva experimental específica para WebRTC, pero su uso es marginal y todavía no forma parte de la caja de herramientas que la mayoría de sitios despliegan en producción.

Por qué WebRTC se cuela por los huecos de defensa

La mayoría de tiendas online con cierto nivel de madurez de seguridad ya cuentan con WAF, IDS/IPS e incluso inspección profunda de HTTP y WebSockets. Estos sistemas se centran en ver qué peticiones salen del servidor o de los proxies, qué dominios se alcanzan, qué parámetros se envían y si hay patrones reconocibles de exfiltración.

En el caso del skimmer con WebRTC, todo ese arsenal se queda casi ciego, porque los DataChannels funcionan sobre UDP cifrado con DTLS. No hay peticiones HTTP visibles, ni cabeceras sospechosas, ni URLs extrañas a las que el WAF pueda agarrarse para lanzar una alerta. Lo que se observa es básicamente tráfico UDP cifrado hacia una IP externa, algo que muchas organizaciones no monitorizan con el mismo detalle que el tráfico web clásico.

Además, las propias reglas de CSP, que en teoría actúan como red de seguridad frente a scripts externos y conexiones no autorizadas, no contemplan RTCPeerConnection en su diseño actual. Por tanto, un sitio con una política muy restrictiva para HTTP puede seguir permitiendo que un JavaScript cree un canal WebRTC directo hacia un servidor de ataque y envíe desde allí los datos de tarjetas robados.

Este hueco de diseño crea lo que muchos administradores consideran una falsa sensación de seguridad: creen que, gracias a CSP y a las listas blancas de dominios, nada raro saldrá del navegador hacia sitios no autorizados. Sin embargo, mientras no se extiendan y estandaricen directivas específicas para WebRTC, esa confianza está injustificada frente a amenazas que saben sacar partido de RTCPeerConnection.

Para hacer las cosas aún más difíciles, el tráfico WebRTC suele mezclarse en la red con aplicaciones legítimas de videollamada, chat o colaboración, lo que hace complicado distinguir entre usos benignos y maliciosos solo a partir de patrones de red. Sin un análisis más fino del comportamiento de JavaScript en el cliente, el skimmer tiene mucho margen para operar a sus anchas.

PolyShell en Magento y Adobe Commerce: la vía de entrada

Todo el ingenio en la exfiltración sería irrelevante si los atacantes no tuvieran una forma eficaz de colocar el script malicioso en la tienda. Aquí es donde entra en juego la vulnerabilidad conocida como PolyShell, que afecta a Magento Open Source y Adobe Commerce y que se ha convertido en la puerta de entrada estrella para este tipo de ataques.

PolyShell permite a un atacante remoto no autenticado subir archivos potencialmente ejecutables a rutas sensibles del servidor, generalmente a través de la API REST o de directorios mal protegidos, como ciertos paths dentro de pub/media/custom_options. Una vez consiguen esa carga, pueden desplegar web shells, backdoors y los scripts de skimming necesarios para comprometer el flujo de checkout.

Los investigadores sitúan el inicio de la explotación masiva de PolyShell alrededor del 19 de marzo de 2026, fecha en la que se observó un pico muy acusado de escaneos automatizados desde más de 50 direcciones IP distintas. Estos escaneos iban buscando instancias vulnerables de Magento y Adobe Commerce para lanzar la intrusión de manera industrializada.

Los datos recopilados indican que alrededor del 56,7% de las tiendas identificadas como vulnerables terminaron efectivamente comprometidas en un periodo corto. Esta cifra da una idea clara de lo rápido que reaccionan los delincuentes cuando aparece un fallo explotable de forma remota y de lo arriesgado que es retrasar el parcheo en entornos de producción.

Una vez se ha logrado la ejecución de código en el servidor, el paso siguiente es inyectar el JavaScript de skimming en plantillas o módulos vinculados al proceso de pago. Así se garantiza que el script se ejecutará cada vez que un cliente acceda al checkout, capturando los datos introducidos y enviándolos por su canal WebRTC invisiblemente hasta que el equipo de seguridad descubra la brecha y limpie a fondo el entorno.

De Magecart clásico al skimmer con WebRTC

Bajo el nombre de Magecart se engloba desde hace años un conjunto amplio de grupos y campañas dedicados al robo de datos de pago en tiendas online. No es una banda única, sino todo un ecosistema de actores que comparten tácticas y evolucionan a medida que las defensas también suben de nivel.

En sus primeras iteraciones, los skimmers Magecart se conformaban con mandar los datos por peticiones HTTP directas a dominios controlados por los atacantes. Bastaba con revisar logs de acceso o desplegar un WAF con reglas razonables para empezar a identificar esas exfiltraciones. Con el tiempo, y ante la mejora de las defensas, los criminales se vieron empujados a buscar vías más discretas.

Así surgieron técnicas como los image beacons, donde la información robada se codificaba dentro de parámetros de carga de imágenes aparentemente inocentes, como GIFs o PNGs. Aunque más sutil, este enfoque también podía detectarse con una combinación de inspección de tráfico saliente y análisis de patrones.

En una fase posterior, algunos grupos empezaron a experimentar con WebSockets, manteniendo canales persistentes entre el navegador de la víctima y el servidor de mando y control. Esto complicaba la detección basada en peticiones HTTP convencionales, pero seguía siendo visible para quien monitorizara bien las cabeceras y los destinos de estas conexiones.

El paso hacia WebRTC DataChannels es, en este contexto, un movimiento lógico dentro de la carrera armamentística entre atacantes y defensores. Al esconderse detrás de un estándar pensado para aplicaciones de tiempo real y sacarle partido a sus huecos de cobertura en CSP y herramientas de red, los skimmers logran un nivel de sigilo superior al de las generaciones anteriores.

Diferencias entre skimmers tradicionales y skimmers con WebRTC

Comparar un skimmer clásico con uno basado en WebRTC ayuda a entender por qué este último representa una amenaza tan seria para el ecosistema de e‑commerce. La primera diferencia obvia está en el canal de salida de datos: mientras los anteriores usan HTTP/HTTPS o, a lo sumo, WebSockets, el nuevo enfoque emplea UDP cifrado con DTLS a través de DataChannels.

La segunda gran diferencia tiene que ver con la visibilidad de las herramientas de seguridad. Un WAF, un proxy inverso o un IDS diseñados para inspeccionar tráfico web reconocen bien patrones maliciosos en HTTP, pero tienen más dificultades para inspeccionar el contenido real de un canal WebRTC cifrado, sobre todo si no se han desplegado soluciones específicas para ello.

El tercer punto clave es el papel de CSP. En el caso de los skimmers tradicionales, una Content Security Policy bien planteada puede bloquear muchos intentos de exfiltración restringiendo conexiones a dominios desconocidos. Con WebRTC en cambio, la CSP estándar no controla la creación de RTCPeerConnection, así que el skimmer puede establecer su canal sin que la política intervenga.

Por último, existe un factor de madurez defensiva: la industria lleva años afinando firmas, reglas y mecanismos de protección frente a tráfico HTTP anómalo. En cambio, el abuso de WebRTC para skimming es relativamente reciente, de modo que no hay todavía el mismo nivel de especialización ni de reglas pulidas para detectarlo en entornos de comercio electrónico.

Todo esto coloca a los skimmers con WebRTC en una posición de ventaja temporal: los atacantes van por delante, aprovechando que muchas organizaciones aún no miran con lupa lo que hace el código JavaScript con la API de WebRTC dentro del navegador.

Medidas de protección frente a skimmers con WebRTC

Aunque la foto pueda parecer desalentadora, hay varias medidas que, combinadas, permiten reducir significativamente el riesgo de que un skimmer de este tipo se instale y permanezca activo en tu tienda online. No existe la bala de plata, pero sí un conjunto coherente de buenas prácticas.

La primera y más obvia es aplicar sin demora los parches de seguridad de Magento y Adobe Commerce que corrigen PolyShell y cualquier otra vulnerabilidad de ejecución remota. Mantener instancias desactualizadas cuando ya se sabe que hay un exploit en circulación —especialmente si aparece en listas de vulnerabilidades explotadas de forma habitual— es, siendo sinceros, jugar con fuego.

Otra línea de defensa fundamental es desplegar monitorización de integridad de JavaScript, sobre todo en páginas sensibles como el checkout. Soluciones específicas para e‑commerce pueden comparar el estado actual de los scripts con versiones de referencia y avisar cuando se detectan bloques nuevos, ofuscados o que hacen llamadas a dominios inusuales.

También conviene revisar periódicamente los scripts de terceros cargados en el flujo de pago: widgets de chat, analítica, anuncios, herramientas de personalización, etc., ya que pueden mostrar señales de tienda online fraudulenta. Cada dependencia es una puerta potencial si ese proveedor resulta comprometido. Reducir el número de scripts externos al mínimo imprescindible ayuda a disminuir la superficie de ataque.

En paralelo, algunas organizaciones empiezan a explorar el uso de directivas CSP orientadas a WebRTC en navegadores que las soportan de forma experimental, como Chrome. Aunque todavía no son un estándar consolidado, pueden aportar una capa extra de protección en entornos controlados, siempre y cuando no se conviertan en la única línea de defensa.

Por último, es muy recomendable implantar mecanismos de monitorización del comportamiento del formulario de pago en tiempo real. Esto incluye registrar a qué dominios se intentan enviar datos desde el navegador, si se abren conexiones inesperadas o si se inicializan RTCPeerConnections sin una justificación funcional clara. Cuando se detecta una exfiltración a un destino no autorizado, se pueden cortar sesiones, aplicar autenticación multifactor, bloquear IPs y activar los procedimientos de respuesta a incidentes.

Errores habituales que dejan el e‑commerce vendido

Al analizar incidentes de este tipo, se repiten una serie de patrones de fallo organizativo que facilitan mucho la vida a los atacantes. Identificarlos es el primer paso para evitarlos en tu propia infraestructura.

Uno de los más frecuentes es confiar ciegamente en una CSP muy estricta, pensando que ella sola bastará para bloquear cualquier exfiltración desde el navegador. Como hemos visto, la ausencia de cobertura de RTCPeerConnection en las directivas estándar deja un hueco que skimmers como el de WebRTC explotan sin demasiado esfuerzo.

Otro error recurrente es retrasar el parcheo de vulnerabilidades críticas cuando ya existe exploit público y se han reportado campañas activas. PolyShell es un buen ejemplo de cómo un fallo conocido puede convertirse en una puerta de entrada masiva si las tiendas tardan semanas o meses en actualizar sus sistemas.

También es muy común depender en exceso de la monitorización de red tradicional centrada en HTTP/HTTPS, sin complementar con análisis de integridad del código JavaScript y sin vigilar APIs específicas del navegador como WebRTC. Esto produce paneles de control muy bonitos donde “todo está en verde”, mientras el skimmer sigue enviando datos por un canal que nadie está inspeccionando.

Por último, muchos equipos técnicos se olvidan de revisar con cierta regularidad rutas como pub/media/custom_options o directorios equivalentes, que son precisamente los que los atacantes aprovechan en escenarios similares a PolyShell para subir archivos maliciosos y mantener acceso persistente al servidor.

Qué se sabe del skimmer y qué sigue en el aire

La información pública disponible permite trazar una imagen bastante clara de algunos aspectos del skimmer con WebRTC, aunque todavía quedan zonas grises que los investigadores siguen tratando de aclarar.

Entre los datos confirmados está el uso de la IP 202.181.177.177 como servidor C2, el puerto UDP 3479 para los DataChannels, las credenciales ICE hardcodeadas (incluida la contraseña del cliente 05l0TstonL9bYAdB04I6x2), el fingerprint DTLS específico y el patrón de SDP que se utiliza para levantar el canal webrtc-datachannel con un puerto SCTP 5000. También se ha verificado que más de la mitad de las tiendas vulnerables a PolyShell acabaron comprometidas en un periodo corto.

En el lado de las incógnitas se encuentra la lista completa de grandes empresas afectadas, ya que no todas han sido nombradas públicamente. Tampoco está claro hasta qué punto el uso de WebRTC como canal de exfiltración se ha extendido de manera generalizada entre todos los grupos Magecart, o si de momento se limita a un subconjunto más avanzado desde el punto de vista técnico.

Igualmente, se desconoce el catálogo completo de módulos y funcionalidades adicionales que este malware pueda incorporar, por ejemplo para moverse lateralmente en la infraestructura, robar cookies de sesión o manipular otros aspectos del frontend. Es razonable pensar que proveedores de soluciones de seguridad especializadas para Magento, WordPress y otros CMS estén afinando sus motores para detectar estos patrones concretos y ofrecer reglas de firmas más completas.

Lo que sí está fuera de duda es que el salto a WebRTC cambia las reglas del juego para el skimming en e‑commerce, obligando a tiendas y proveedores de seguridad a mirar mucho más allá del tráfico HTTP y a poner el foco en lo que hace realmente el JavaScript en el navegador del cliente, sobre todo en el momento crítico del pago.

A la vista de todo lo anterior, queda bastante claro que los skimmers con WebRTC son la siguiente vuelta de tuerca en el robo de datos de pago online: combinan vulnerabilidades críticas en plataformas como Magento y Adobe Commerce, aprovechan vacíos en estándares como CSP y se escudan en canales cifrados difíciles de vigilar; si una tienda quiere evitar acabar con los datos de sus clientes circulando por ese “canal lateral” casi invisible, toca tomarse muy en serio el parcheo rápido, la reducción de scripts de terceros, la monitorización de la integridad del código y la observación constante del comportamiento real del navegador, en lugar de confiar únicamente en lo que cuentan los logs de HTTP.