Skimmer WebRTC: Cómo Roba Datos de Pago

Sansec descubrió un skimmer WebRTC que roba datos de pago en tiendas online usando canales WebRTC para eludir completamente la Content Security Policy (CSP). El malware infectó el sitio ecommerce de un fabricante de autos valuado en más de 100 mil millones de dólares, marcando la primera vez documentada de WebRTC usado como canal de exfiltración de datos de tarjetas. Lo preocupante: los skimmers tradicionales ya son difíciles de detectar, pero este usa técnicas que hacen invisible el robo incluso a herramientas de monitoreo de red (spoiler: esto es un nuevo nivel de peligro para cualquier tienda online).

Sansec es una empresa de ciberseguridad especializada en investigar y detectar malware en sitios de comercio electrónico, incluyendo skimmers de pago y código inyectado. Proporciona servicios de análisis forense e inteligencia de amenazas para proteger infraestructuras de e-commerce.

Qué descubrió Sansec y por qué es un hito en ciberseguridad

Estamos hablando de un cambio de juego. Hasta ahora, la mayoría de los skimmers ecommerce usaban solicitudes HTTP normales, beacons de imagen, o WebSockets para robar datos. Sansec identificó un skimmer que usa WebRTC DataChannels tanto para cargar su payload maligno como para exfiltrar información robada. Primera vez documentada. Punto.

El contexto que le da peso: Sansec detectó skimmers en cinco empresas multimillonarias en apenas dos meses. No estamos hablando de sitios chicos. Una de ellas es una cadena de supermercados top-10 a nivel global. Otra es un fabricante de autos valorado en más de 100 mil millones de dólares (sí, los números que ves ahí son correctos). El mensaje está claro: los atacantes están yendo por los blancos gordos, con técnicas cada vez más sofisticadas.

Cómo funciona el ataque: WebRTC DataChannels como canal de exfiltración

Ponele que actualizás un plugin, metés mal la configuración (o peor, alguien metió un script malicioso en tu código), y sin querer dejaste una puerta abierta. El skimmer entra. Normalmente, carga su payload vía HTTP y manda los datos robados por la misma ruta. Fácil de detectar si tenés un WAF (Web Application Firewall) o CSP bien configurada.

Pero este skimmer es distinto.

Usa WebRTC DataChannels. Esto significa que en vez de hacer un GET o POST HTTP tradicional, establece una conexión punto a punto entre el navegador del usuario y el servidor del atacante. Los datos viajan sobre UDP (no TCP) y están cifrados con DTLS (Datagram TLS). ¿Resultado? Tu herramienta de monitoreo de red mira el tráfico y no ve nada malicioso. Es como si un intruso entrara a tu casa por la ventana mientras vos estás mirando la puerta principal (y la puerta tiene alarma).

La brecha en CSP que abre la puerta a este ataque

Content Security Policy existe justamente para bloquear esto. Las directivas como connect-src, script-src y img-src controlan a dónde pueden conectarse y qué pueden cargar los scripts de tu página. Tema relacionado: en nuestro análisis sobre código seguro.

Pero tiene una brecha enorme: RTCPeerConnection no está cubierta por ninguna directiva CSP estándar (ojo con esto).

Imagina que configuraste una CSP súper estricta. Bloqueaste todos los dominios externos, solo permitís scripts de tu propio dominio. Instalaste un WAF que rechaza cualquier conexión sospechosa. Perfecto, ¿no? Bueno, no. Un atacante puede seguir usando WebRTC para sacarte los datos porque CSP no tiene forma de restringir RTCPeerConnection. Chrome tiene soporte experimental para una directiva CSP de WebRTC, pero el nivel de adopción es mínimo. Casi nadie la usa.

El resultado es que tu política de seguridad, que se ve impenetrable en papel, sigue completamente abierta a este tipo de ataques.

El robo del nonce CSP: cómo el malware se disfraza

Acá viene lo técnico. Cuando usás nonces en tu CSP (eso que hacen algunos desarrolladores para whitelist scripts dinámicos sin confiar en todas las conexiones externas), el malware tiene un truco más: roba el nonce de scripts legítimos y lo usa para inyectarse a sí mismo sin disparar alarmas.

En conclusión, el script malicioso se presenta como si fuera legítimo, con credenciales reales. Las herramientas de monitoreo lo dejan pasar. Y después, abre el canal WebRTC para cargarse y exfiltrar datos. Sin HTTP requests sospechosos. Sin beacons de imagen. Sin nada que un WAF o un monitor de red tradicional pueda detectar. Para más detalles técnicos, mirá como explicamos sobre seguridad GitHub.

Vector de entrada: la vulnerabilidad PolyShell en Magento

Sansec advirtió sobre PolyShell hace poco, una vulnerabilidad crítica en Magento y Adobe Commerce que permite subir archivos maliciosos y ejecutar código sin autenticación. La explotación masiva comenzó el 19 de marzo de 2026. Dos semanas después, Sansec detectó que el 56.7% de todas las tiendas vulnerables ya habían sido comprometidas.

¿Cómo entra el skimmer WebRTC? Eso es PolyShell. El atacante sube un script maligno, ejecuta código sin credenciales, inyecta el skimmer en los scripts de checkout de la tienda. Y ahí quedó. Invisible. Robando tarjetas.

La evolución de Magecart: de ataques básicos a evasión de defensas modernas

Magecart no es un grupo, es una categoría de ataques. Desde hace años, grupos criminales están enfocados específicamente en robar datos de pago de ecommerce. La tendencia ha sido preocupante: la sofisticación aumenta, los ataques son más dirigidos, y ahora estamos viendo métodos que eluden defensas que se supone debería ser moderna.

La progresión técnica es clara: primero fueron HTTP requests simples, fácil de bloquear con un WAF. Después evolucionaron a image beacons (cargar un “gif” falso que contiene los datos robados). Más tarde vinieron los WebSockets. Y ahora, WebRTC DataChannels. Cada paso es una respuesta directa a las defensas que la industria implementó. Es casi como un juego de ajedrez: atacante hace un movimiento, la industria cierra esa puerta, el atacante encuentra otra.

Comparativa: skimmers tradicionales vs WebRTC

Cómo proteger tu ecommerce contra skimmers WebRTC

Bueno, ¿y ahora qué hacés? No es que estés desamparado, pero sí tenés que ser más proactivo.

1. Parchear Magento inmediatamente

Si usás Magento o Adobe Commerce, actualiza AHORA. PolyShell tiene parches disponibles. No es opcional. Sabemos que el 56.7% de tiendas vulnerables fueron explotadas. ¿Vos estás en ese porcentaje? Relacionado: en análisis de amenazas previos.

2. Monitoreo de integridad de scripts

Herramientas como Sansec, Sucuri, Wordfence, o soluciones similares monitorizan cambios no autorizados en tu código JavaScript. Si alguien inyecta un skimmer, estas herramientas lo detectan. No es perfect (porque nada lo es), pero es el mejor escudo que tenés ahora.

3. Implementar directiva CSP para WebRTC (si es posible)

Chrome tiene soporte experimental para una directiva CSP que restringe WebRTC. Si tenés control sobre tu sitio y tu audience usa navegadores modernos, vale la pena implementarlo. Pero es experimental, así que no confíes ciegamente en esto solo.

4. Auditorías regulares de scripts de terceros

Cualquier script que no controles directamente (analytics, widgets, integraciones de servicios) es un riesgo. Hacé auditorías cada 3 meses. Eliminá lo que no necesites. Si tenés 20 scripts corriendo, el atacante tiene 20 puntos de entrada potenciales.

5. Monitoreo de comportamiento en tiempo real del formulario de pago

Monitorizá qué información se envía desde tu página de checkout. Si detectás que alguien está intentando hacer requests a dominios extraños o usar WebRTC, cortá la sesión. Algunos hosts como donweb.com ofrecen herramientas de seguridad que pueden ayudarte con esto, dependiendo de tu plan.

Errores comunes

1. Pensar que una CSP estricta te protege de todo

CSP es buena. Pero no es una solución completa. Como vimos, WebRTC no está controlado por CSP. Necesitás capas adicionales de defensa (WAF, monitoreo de scripts, logs de seguridad).

2. No parchear vulnerabilidades conocidas rápidamente

PolyShell tiene parche disponible. Si no lo aplicaste en los primeros días, probablemente ya te comprometieron. El 56.7% de tiendas vulnerables después de una semana no es coincidencia. Es que los atacantes automatizaron el exploit. Ya lo cubrimos antes en como sucede con vulnerabilidades npm.

3. Confiar exclusivamente en herramientas de red para detectar amenazas

Tu WAF mira HTTP. Tu firewall mira conexiones TCP. Pero WebRTC usa UDP cifrado. Es invisible. Necesitás monitoreo de integridad de scripts además de infraestructura de red. Nuestros colegas de seguridadenwordpress.com lo analizan en tal como ocurrió en WordPress.

Esto se conecta con Nuevo skimmer usa WebRTC para robar datos de pago eludiendo defensas convencionales.

Qué está confirmado / Qué no

Confirmado

Sansec confirma el descubrimiento de un skimmer WebRTC en la tienda online de un fabricante de autos. La explotación de PolyShell comenzó el 19 de marzo de 2026. El 56.7% de tiendas vulnerables fueron atacadas. WebRTC DataChannels no están cubiertos por CSP estándar.

No confirmado (pero probable)

Si otros sitios ecommerce grandes fueron comprometidos con este método. Sansec reportó 5 empresas multimillonarias atacadas en 2 meses, pero no reveló todas. Tampoco sabemos si el método WebRTC se está propagando masivamente o si es específico de algunos grupos. Los detalles técnicos completos del exploit también siguen siendo limitados públicamente. Cobertura relacionada: herramientas como Wordfence lo detectan.

Preguntas Frecuentes

¿Cómo sé si mi tienda online tiene un skimmer instalado?

Herramientas como Sansec, Sucuri o Wordfence escanean tu código en busca de scripts sospechosos. Si sos cliente de un host que ofrece monitoreo de seguridad incluido, correé un scan ahora. Para PolyShell específicamente, verifica que tengas los parches aplicados en Magento/Adobe Commerce. Si tenés dudas, paga una auditoría profesional. Vale la pena.

¿Por qué WebRTC se puede usar para esto si es un estándar web?

Porque WebRTC fue diseñado para comunicación punto a punto (videollamadas, chat, streaming). Nadie imaginó que un atacante lo usaría para robar datos de tarjetas. La especificación de CSP simplemente no contemplaba este caso de uso. Es un gap de seguridad, no un bug. Ahora que se conoce, hay trabajos para cerrarlo (como la directiva CSP experimental que Chrome está testeando).

¿El monitoreo de red tradicional puede detectar este ataque?

No directamente. El tráfico WebRTC está cifrado con DTLS y usa UDP, no HTTP. Tu WAF mira HTTP. Tu firewall mira conexiones de aplicación. Necesitás monitoreo de integridad de scripts (que detecta inyecciones de código) o behavioral monitoring (que detecta intentos de establecer conexiones WebRTC no autorizadas). Es un nivel diferente de detección.

¿Afecta esto solo a Magento o también a WordPress?

El vector de entrada reportado es PolyShell, que es específico de Magento y Adobe Commerce. Pero la técnica del skimmer WebRTC (bypass de CSP, uso de DataChannels) aplica a cualquier ecommerce. Si tenés una tienda WordPress con WooCommerce y alguien logra inyectar un script maligno en tu página de checkout, el mismo ataque funciona. El riesgo es universal.

Conclusión

Un skimmer WebRTC que roba datos de pago mientras evade CSP y herramientas de red tradicionales es un cambio significativo en cómo piensan los atacantes. No estamos hablando de un exploit aislado. Sansec encontró este método en cinco empresas multimillonarias en dos meses. PolyShell fue explotado en el 56.7% de tiendas vulnerables. Los números dicen que esto está sucediendo ahora, a escala.

Lo que tenés que hacer: parchear PolyShell hoy, implementar monitoreo de integridad de scripts, auditar tus dependencias de terceros, y no confiar exclusivamente en CSP. Una sola capa de defensa no es suficiente. El ataque es sofisticado, así que tu defensa tiene que serlo también.

El juego entre atacantes y defensores continúa. Esta ronda la ganaron los atacantes. Ahora te toca defenderte.

Fuentes

• Novel WebRTC skimmer bypasses security controls at $100+ billion car maker — Sansec Forensics Team
• Researchers uncover WebRTC skimmer bypassing traditional defenses — Security Affairs
• WebRTC Skimmer Bypasses CSP to Steal Payment Data — The Hacker News