- Un nuevo skimmer usa WebRTC DataChannels para robar datos de pago y evadir CSP y defensas centradas en HTTP.
- La vulnerabilidad PolyShell en Magento y Adobe Commerce facilita la inyección del código malicioso en el checkout.
- La monitorización clásica de red y una CSP estricta no bastan: hace falta control de scripts y del comportamiento del navegador.
- Parcheo ágil, reducción de scripts de terceros e IA aplicada a detección son claves para mitigar este tipo de ataques.
La seguridad en tiendas online se ha complicado un poco más con la aparición de un skimmer de tarjetas que utiliza WebRTC para robar y sacar datos de pago de forma casi invisible. Lo que hace unos años se solucionaba vigilando peticiones HTTP sospechosas, hoy se complica con canales cifrados sobre UDP que apenas dejan rastro en los sistemas de defensa tradicionales.
Este nuevo enfoque está siendo explotado en incidentes reales contra empresas gigantes: fabricantes de coches valorados en más de 100.000 millones, bancos del top estadounidense y cadenas de supermercados globales. No se trata de una prueba de concepto en un laboratorio, sino de ataques en producción que aprovechan vulnerabilidades críticas como PolyShell en Magento y Adobe Commerce, combinadas con lagunas en la Content Security Policy (CSP) y una supervisión insuficiente del código JavaScript que corre en el navegador de los clientes.
Qué es un skimmer con WebRTC y por qué es tan problemático
En el mundo del fraude en comercio electrónico, un skimmer es básicamente un código JavaScript malicioso que intercepta los datos introducidos en el formulario de pago (número de tarjeta, CVV, nombre, etc.) y los envía a servidores controlados por los atacantes. Hasta ahora, lo habitual era que esa información se exfiltrase a través de peticiones HTTP o, en variantes algo más avanzadas, mediante WebSockets o trucos como las llamadas image beacons.
El salto cualitativo de esta nueva familia está en que usa WebRTC DataChannels como canal de comunicación. WebRTC nació para habilitar comunicaciones en tiempo real entre navegadores (videollamadas, voz, chat, envío de ficheros), pero los atacantes han visto en sus canales de datos cifrados sobre UDP una autopista perfecta para mover información sensible, de forma que pase por debajo del radar de muchos WAF, IDS/IPS y herramientas de inspección de tráfico orientadas a HTTP/HTTPS.
Sansec, una firma especializada en la protección de plataformas de comercio electrónico frente a campañas tipo Magecart, ha sido quien ha documentado por primera vez el uso de WebRTC DataChannels como vehículo específico para skimming de tarjetas en tiendas online. En apenas dos meses localizaron este tipo de código en cinco organizaciones multimillonarias, lo que indica que no es una rareza aislada, sino el inicio de una tendencia hacia técnicas de exfiltración más discretas y difíciles de rastrear.
Lo realmente preocupante es que muchas tiendas que creen estar “blindadas” gracias a políticas CSP muy restrictivas siguen completamente expuestas a este vector: el estándar CSP actual no controla las conexiones RTCPeerConnection ni sus DataChannels, por lo que el skimmer puede establecer un canal punto a punto con el servidor del atacante aunque todo el tráfico HTTP hacia dominios no autorizados esté bloqueado.
Cambio de juego frente a los skimmers tradicionales
Hasta hace no mucho, la mayoría de campañas de skimming seguían un patrón bastante predecible: inyectar un script en el checkout y mandar la información por HTTP POST a un dominio sospechoso. Esta estrategia, aun siendo dañina, resultaba relativamente detectable con un WAF mínimamente afinado, reglas en un IDS/IPS o una buena revisión de logs de acceso y de tráfico saliente.
Para esquivar esas defensas, los grupos asociados bajo el paraguas de Magecart fueron evolucionando sus tácticas. Primero se vieron image beacons donde los datos iban camuflados como parámetros en la carga de una imagen, luego conexiones via WebSockets para mantener canales persistentes que complicaran la inspección, siempre dentro del terreno HTTP(S). Cada avance obligaba a refinar reglas de detección y a endurecer las políticas de contenido.
Con WebRTC, el guion cambia por completo: el canal de exfiltración ya no es HTTP ni WebSocket, sino DTLS sobre UDP a través de DataChannels. A ojos de multitud de soluciones de seguridad, ese tráfico no es más que ruido cifrado que no encaja en los patrones habituales de navegación web. Si tu infraestructura está centrada en analizar únicamente lo que sale por los puertos clásicos de HTTP/HTTPS, gran parte de estas conexiones quedará fuera del foco.
Otro factor diferenciador es que este skimmer no solo aprovecha WebRTC para sacar los datos, sino también para recibir su propio payload dañino a través del mismo canal. De esta forma evita tener que descargar scripts adicionales por HTTP, algo que muchas CSP y soluciones de monitorización de integridad del lado del servidor sí habrían podido bloquear o, al menos, registrar como actividad anómala.
Por si fuera poco, el código está diseñado con inteligencia para engañar a los controles de CSP que usan nonces, robando o reutilizando el nonce de un script legítimo presente en la página y haciéndose pasar así por código autorizado. El navegador ve un script con un nonce válido y lo ejecuta sin levantar la ceja, mientras el contenido real lo ha suministrado el atacante a través del canal WebRTC.
CSP, WebRTC y el agujero que muchos no ven
La Content Security Policy es hoy uno de los pilares de la defensa en profundidad de aplicaciones web modernas. Gracias a directivas como script-src, img-src o connect-src, los responsables de seguridad pueden limitar qué scripts se cargan, hacia qué dominios se realizan conexiones salientes o de dónde se permiten imágenes, fuentes y otros recursos potencialmente peligrosos.
En escenarios de skimming clásico, una CSP estricta puede cortar de raíz buena parte de los intentos de exfiltración: si únicamente se permite conectarse a unos pocos dominios de confianza, los POST a servidores de mando y control externos tienden a ser bloqueados. Además, el uso de nonces por página ayuda a que solo se ejecuten scripts explícitamente autorizados por el servidor, mitigando muchos ataques de inyección.
El problema es que el estándar CSP no cubre de manera efectiva las conexiones WebRTC. Las directivas como connect-src aplican a fetch, XHR y WebSockets, pero no restringen la creación de RTCPeerConnection ni el tráfico que se mueve por sus DataChannels. Chrome ha introducido de forma experimental una directiva específica para WebRTC, pero su uso es anecdótico y está lejos de ser una práctica extendida en tiendas reales.
En la práctica, esto significa que una tienda que presume de CSP súper cerrada —sin comodines, con dominios hipercontrolados y nonces rotando en cada carga— puede seguir estando expuesta a un script inyectado que establezca un peer-to-peer WebRTC hacia la infraestructura del atacante. Mientras se limiten a vigilar conexiones HTTP y WebSockets, ese canal alternativo quedará sin supervisión.
Para rizar el rizo, el skimmer analizado aprovecha el propio entorno del navegador para localizar scripts legítimos que portan un nonce válido y copiar ese valor. Una vez que el malware replica el nonce en su propio elemento <script>, a ojos de CSP está cumpliendo las reglas. Después, simplemente inyecta en ese script el payload descargado por WebRTC o, si el contexto lo permite, lo ejecuta mediante Function(payload)() cuando la política autoriza unsafe-eval.
PolyShell en Magento y Adobe Commerce: la puerta de entrada
Todo este despliegue técnico sería inútil si los atacantes no tuvieran una forma confiable de meter su código en el flujo de pago. En los incidentes investigados por Sansec, el vector más probable ha sido PolyShell, una vulnerabilidad crítica en Magento Open Source y Adobe Commerce que permite a usuarios no autenticados subir archivos peligrosos a rutas controladas del servidor.
La explotación de PolyShell facilita la creación de web shells y backdoors con los que los atacantes ejecutan código arbitrario y modifican la lógica del checkout. Desde ahí, inyectan el skimmer JavaScript en las plantillas o módulos que se ejecutan justo cuando el cliente introduce los datos de su tarjeta, garantizando que el malware se active en el momento más sensible de la compra.
Los primeros indicios de explotación masiva de PolyShell se remontan al 19 de marzo de 2026, fecha a partir de la cual se detectó un volumen enorme de escaneos automatizados procedentes de más de 50 direcciones IP distintas buscando instancias vulnerables. Los datos recopilados muestran que aproximadamente el 56,7 % de las tiendas catalogadas como vulnerables terminaron siendo comprometidas, una cifra altísima que evidencia hasta qué punto el exploit se industrializó.
En muchos casos, los servidores afectados tenían directorios de medios mal endurecidos o configuraciones permisivas en rutas como pub/media/custom_options/, lo que facilitó la subida de archivos ejecutables. Una vez dentro, los atacantes solo tuvieron que desplegar su kit: web shell para control remoto, skimmer WebRTC en la página de pago y mecanismos para intentar aguantar el máximo tiempo posible sin ser detectados.
El vínculo temporal entre el inicio de los escaneos masivos de PolyShell y el hallazgo del skimmer en grandes empresas sugiere de forma bastante sólida que el compromiso de estas tiendas está directamente relacionado con esa vulnerabilidad, aunque no se hayan hecho públicos todos los detalles finos de cada intrusión ni la identidad completa de todas las víctimas.
Código del skimmer y análisis técnico paso a paso
El skimmer descubierto se presenta como una función autoejecutable en JavaScript que levanta una conexión WebRTC contra una IP concreta. Una vez desofuscado, el código revela una secuencia de pasos muy calculada, sin depender de los mecanismos de señalización habituales que utilizan las aplicaciones WebRTC legítimas.
En primer lugar, el script crea un objeto RTCPeerConnection y un DataChannel cuya etiqueta incluye la URL actual de la página. Esa etiqueta le indica al servidor atacante en qué página se encuentra la víctima, lo que permite adaptar el comportamiento del payload recibido según si se trata de un checkout, una página de confirmación u otra parte del flujo de compra.
A continuación, el malware genera una oferta SDP, pero en lugar de enviar esa información a un servidor de señalización, modifica de forma local valores clave como el ice-ufrag y fija un ice-pwd concreto (05l0TstonL9bYAdB04I6x2). Después construye un SDP “answer” completamente forjado que apunta a la IP 202.181.177.177 en el puerto UDP 3479, incluyendo un fingerprint DTLS precompartido y la definición del canal como webrtc-datachannel con puerto SCTP 5000.
Con este truco, el código consigue saltarse por completo la fase de señalización clásica de WebRTC. No hace falta que otro lado le envíe la respuesta: el propio malware se la fabrica y la establece como remoteDescription. El resultado es que el navegador termina creando una conexión cifrada punto a punto con el servidor de mando y control, sin que haya tráfico HTTP de negociación que pueda delatar la maniobra.
Una vez establecido el canal, el DataChannel se utiliza para recibir el payload malicioso en pequeños fragmentos que se van acumulando. El manejador onmessage se encarga de convertir a texto cualquier dato binario usando TextDecoder, concatenando todo en un array. Cuando el canal se cierra o transcurre un tiempo máximo de unos diez segundos, se ejecuta una función que junta todos los trozos en una cadena única lista para ser interpretada como JavaScript.
La ejecución del payload se realiza de manera escalonada y con varias rutas de fuga: primero, el código lanza su lógica en un momento de baja carga del navegador (requestIdleCallback o un setTimeout de reserva), y después intenta inyectar el script con el payload copiando el nonce de algún <script> legítimo existente. Si esto no es posible o falla, recurre a Function(payload)() cuando la política lo permite o crea un nuevo script en el head del documento y lo elimina al instante tras ejecutarlo, minimizando las huellas visibles.
Por qué las defensas actuales no son suficientes
El éxito de este tipo de skimmers se apoya en varios puntos débiles muy comunes en la mayoría de infraestructuras de comercio electrónico. El primero es la falsa sensación de seguridad basada únicamente en CSP y en la inspección de tráfico HTTP. Mientras muchas organizaciones han invertido en endurecer cabeceras, WAF y filtros hacia dominios externos, apenas han prestado atención a lo que puede ocurrir a través de APIs poco monitorizadas como WebRTC.
En segundo lugar, la lentitud a la hora de aplicar parches críticos como los relacionados con PolyShell deja una ventana enorme para la explotación masiva. Cuando una vulnerabilidad entra en listas como el catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA, el reloj corre en contra: los atacantes automatizan escaneos y exploits, y las tiendas que no reaccionan a tiempo acaban, en muchos casos, comprometidas sin ni siquiera enterarse.
Otro error frecuente consiste en depender exclusivamente de la monitorización de red sin complementar con herramientas de integridad de código JavaScript ni análisis de comportamiento del lado del cliente. Un firewall puede ver tráfico UDP cifrado saliendo, pero si no está preparado para identificar patrones concretos de WebRTC DataChannels o asociar esa actividad a scripts modificados en el checkout, es probable que pase por alto el incidente.
Además, en muchas tiendas se cargan montones de scripts de terceros —widgets, analítica, publicidad, chat, etc.— sin auditorías periódicas. Cada uno de esos scripts es un posible punto por el que si el proveedor sufre una brecha o se actualiza con código comprometido. Esta complejidad de dependencias hace que los cambios maliciosos puedan camuflarse entre actualizaciones legítimas si no se vigilan con lupa.
Por último, la adopción aún muy limitada de medidas avanzadas como directivas CSP experimentales para WebRTC o soluciones específicas para monitorizar formularios de pago en tiempo real deja un hueco que los atacantes están aprovechando con soltura. A día de hoy, hay más experiencia acumulada en detectar HTTP sospechoso que en detectar el uso malicioso de RTCPeerConnection y DataChannels en entornos de e‑commerce.
Medidas de defensa frente a skimmers con WebRTC
Aunque este panorama pueda sonar bastante desalentador, hay margen de maniobra si se aborda el problema con una estrategia por capas que combine parcheo, monitorización de código y análisis de comportamiento. No existe una bala de plata, pero sí un conjunto de acciones que, en conjunto, reducen mucho el riesgo de que un skimmer de este tipo se instale y permanezca activo sin ser detectado.
El primer paso, casi de sentido común, es aplicar sin demora los parches disponibles para Magento y Adobe Commerce que corrijan PolyShell y fallos similares. Quedarse en versiones antiguas u omitir hotfixes cuando ya se conoce explotación activa es un riesgo enorme, especialmente sabiendo que más de la mitad de las tiendas vulnerables detectadas acabaron comprometidas.
En paralelo, conviene desplegar herramientas de monitorización de integridad de scripts que vigilen cambios en el JavaScript del checkout. Estas soluciones comparan el código actual con una versión de referencia, identificando bloques ofuscados nuevos, modificaciones en funciones críticas o referencias a dominios extraños. No son perfectas, pero reducen al mínimo la ventana de tiempo en la que un skimmer puede actuar sin levantar sospechas.
También es recomendable explorar el soporte de directivas CSP específicas para WebRTC en navegadores modernos como Chrome, siempre entendiendo que se trata de una capa adicional, todavía experimental, y no de un sustituto de otras defensas. En proyectos donde se tiene control completo del stack y del navegadores objetivo, puede aportar un grado más de contención.
Otra línea de trabajo es la reducción sistemática de scripts de terceros cargados en páginas sensibles como el formulario de pago. Hacer un inventario exhaustivo cada cierto tiempo, eliminar lo que no sea estrictamente necesario y revisar las políticas de actualización de proveedores ayuda a recortar superficie de ataque. Menos piezas externas, menos posibles puertas de entrada.
Por último, y cada vez más importante, resultan muy valiosas las soluciones que monitorizan en tiempo real el comportamiento del formulario de pago: qué dominios reciben datos, si se abren conexiones inesperadas, si se inician RTCPeerConnections sin justificación funcional, etc. Estas herramientas permiten bloquear sesiones anómalas, disparar alertas tempranas y facilitar la respuesta ante incidentes y el análisis forense posterior.
Qué se sabe seguro, qué queda por esclarecer y papel de la IA
La información disponible sobre este skimmer permite separar con cierta claridad los hechos ya confirmados de los puntos que aún se mueven en la zona gris. Entre lo contrastado está la detección de un skimmer basado en WebRTC operativo en la tienda online de un gran fabricante de automóviles, el arranque de la explotación masiva de PolyShell el 19 de marzo de 2026 y ese porcentaje del 56,7 % de tiendas vulnerables que terminaron comprometidas.
También se ha validado que los WebRTC DataChannels quedan fuera del alcance de las directivas CSP estándar, que el canal se establece hacia la IP 202.181.177.177 en el puerto UDP 3479 con unas credenciales ICE y un fingerprint DTLS concretos, y que el código realiza técnicas activas de evasión, como la reutilización de nonces de scripts legítimos para saltarse políticas de script-src ‘nonce‑…’.
En el lado menos claro están aspectos como la identidad de todas las empresas afectadas (no todas han sido nombradas de forma pública), el grado exacto de adopción de WebRTC por parte de otros grupos de skimming más allá de los incidentes investigados por Sansec, o la posible existencia de módulos adicionales integrados en el malware que amplíen su funcionalidad más allá del robo de tarjetas.
Es razonable suponer que los principales fabricantes de soluciones de seguridad para e‑commerce, así como los proveedores de hosting especializados, están ya incorporando patrones de detección específicos para este tipo de comportamiento, ajustando firmas basadas en SDP, monitorización de RTCPeerConnection o análisis de integridad de JavaScript orientado a checkout. No obstante, todavía llevará un tiempo que estas capacidades se estandaricen y lleguen a la mayoría de tiendas.
En este contexto, tecnologías como la inteligencia artificial aplicada a ciberseguridad y análisis masivo de transacciones pueden jugar un papel interesante. Sistemas basados en IA, desplegados sobre infraestructuras en la nube como AWS o Azure, permiten revisar en tiempo real grandes volúmenes de solicitudes, identificar patrones inusuales de comportamiento del navegador, correlacionar anomalías en conexiones WebRTC y ayudar a detectar antes este tipo de fraudes.
Herramientas de análisis de negocio y visualización de datos como Power BI también resultan útiles para entender tendencias en los patrones de uso, tasas de abandono en el checkout o picos anómalos en determinados flujos que podrían estar relacionados con actividades de skimming. Combinando esa capa de business intelligence con datos técnicos de seguridad, las empresas pueden tener una visión mucho más rica de lo que pasa en sus tiendas.
Al final, la aparición de skimmers que se apoyan en WebRTC y en vulnerabilidades como PolyShell evidencia que la seguridad de un e‑commerce ya no puede basarse solo en mirar tráfico HTTP y confiar ciegamente en una CSP estricta. Quien gestione una tienda online tiene que asumir que el navegador del cliente es hoy un terreno de juego extremadamente atractivo para los atacantes, y que toca reforzar tanto el código que se ejecuta ahí como la capacidad de ver qué está haciendo realmente en tiempo real.
