Skimmer amb WebRTC que evadeix controls i roba dades a e‑commerce

Informatec Digital » Recursos » Skimmer amb WebRTC que evadeix controls i roba dades a e‑commerce

Un nou tipus de skimmer de targetes basat en WebRTC està posant potes enlaire la seguretat de les plataformes de comerç electrònic . Parlem d'un codi maliciós capaç de robar dades de pagament directament des del navegador del client i treure'ls del lloc usant canals de dades WebRTC, sortejant de forma elegant mecanismes com la Content Security Policy (CSP) o els WAF tradicionals que només miren trànsit HTTP.

Aquest enfocament no només és enginyós, sinó que a més es recolza en vulnerabilitats crítiques com PolyShell a Magento i Adobe Commerce , que permeten a atacants no autenticats pujar codi maliciós i executar-lo al servidor. El resultat és un còctel molt perillós: entrada senzilla al sistema, injecció silenciosa de scripts al checkout i exfiltració de targetes mitjançant WebRTC DTLS sobre UDP, gairebé invisible per a la majoria de defenses actuals.

Qui està darrere de la troballa i per què tant importa

Sansec , una firma de ciberseguretat especialitzada en protegir plataformes de comerç electrònic, va ser la que va destapar aquest nou skimmer WebRTC. El seu treball se centra a analitzar incidències de codi maliciós en botigues en línia, localitzar injeccions de codi, skimmers de pagament i backdoors, i proporcionar intel·ligència d'amenaces centrada a e-commerce.

El que és rellevant del cas és que estem davant la primera vegada documentada en què WebRTC DataChannels s'utilitzen com a canal d'exfiltració de dades de targetes en entorns de comerç electrònic. Fins ara, els grups de tipus Magecart estiraven peticions HTTP clàssiques, beacons d'imatge o, en escenaris una mica més avançats, de WebSockets. Aquest salt de qualitat suposa un canvi de joc autèntic.

Sansec no va topar amb això en un laboratori aïllat, sinó en investigar incidents reals en grans empreses. Entre els objectius afectats hi ha un fabricant d'automòbils amb una valoració superior als 100.000 milions de dòlars , a més d'una cadena de supermercats situada al top 10 mundial i altres companyies multimilionàries. És a dir, els atacants estan afinant les seves tècniques per anar directament a buscar els objectius de més alt valor.

En un període de dos mesos, els investigadors van identificar skimmers en cinc organitzacions d'aquest nivell, cosa que reforça la idea que no es tracta d'un experiment puntual , sinó d'una tendència clara cap a tècniques més sigil·loses i difícils d'inspeccionar amb les eines de sempre.

Com funciona l'skimmer: WebRTC DataChannels com a autopista secreta

A la majoria d'incidents de skimming tradicionals, el guió és força conegut: un atacant aprofita una mala configuració, un plugin vulnerable o un script de tercers compromès per injectar codi que captura les dades del formulari de pagament i les envia fora del lloc, normalment mitjançant peticions HTTP POST cap a un servidor sota el seu control.

Aquest tipus de trànsit, encara que molest, sol ser detectable mitjançant un WAF, regles d'IDS/IPS, inspecció profunda de paquets o una CSP ben afinada. Quan de sobte apareix un JavaScript intentant enviar informació de targetes a un domini rar per HTTP, salten les alarmes. El problema és que aquest nou skimmer decideix canviar completament de canal de comunicació.

En lloc d'utilitzar HTTP o WebSockets, el codi maliciós estableix una RTCPeerConnection per crear un DataChannel WebRTC entre el navegador de la víctima i la infraestructura de l'atacant. El trànsit s'envia com a datagrames sobre UDP i es xifra amb DTLS (Datagram TLS). A ulls de moltes eines de seguretat, això és poca cosa més que soroll de xarxa xifrat, difícil d'interpretar o filtrar de manera específica.

D'aquesta manera, l'skimmer pot rebre tant el seu payload maliciós pel propi canal WebRTC (evitant així carregar scripts sospitosos mitjançant HTTP) com exfiltrar la informació de targetes capturada al checkout per aquesta mateixa via. Tot això sense generar les típiques traces de trànsit web que un analista buscaria en examinar logs de servidors, proxies o firewalls.

L'analogia seria com vigilar la porta principal de casa amb càmeres i alarmes, mentre un intrús entra i surt tranquil·lament per una finestra lateral. La seguretat centrada únicament en trànsit HTTP/HTTPS no té visibilitat real d'aquestes connexions punt a punt xifrades , llevat que es despleguin eines molt específiques d'anàlisi de WebRTC o monitorització del comportament del navegador.

Content Security Policy: què protegeix i on fa aigua amb WebRTC

La política de seguretat de continguts, o Content Security Policy (CSP) , ha esdevingut una de les peces clau per protegir aplicacions web modernes. A grans trets, permet definir des del costat del servidor a quins dominis es pot connectar el navegador i quins recursos (scripts, imatges, fonts, etc.) estan permesos.

Directives com ara connect-src, script-src o img-src ajuden a limitar peticions sortints i la càrrega de codi d'orígens no fiables. Ben utilitzada, CSP redueix de manera considerable l'impacte d'atacs d'injecció d'scripts i d'exfiltració de dades via HTTP o WebSockets, sempre que s'hagi configurat de manera estricta i sense comodins excessius.

El forat important ve quan entra en joc WebRTC. L'estàndard actual no contempla una directiva CSP àmpliament adoptada que reguli RTCPeerConnection i els seus DataChannels. A la pràctica, encara que algú hagi definit una política molt restrictiva per a les connexions HTTP, el codi maliciós segueix podent crear un peer-to-peer amb el servidor de l'atacant i enviar-hi dades xifrades.

Chrome disposa d'una directiva CSP experimental orientada a WebRTC, però el seu ús encara és minoritari i no forma part del conjunt de defenses habituals de la majoria de llocs. Això deixa un lloc evident: la seguretat basada només en CSP ofereix una sensació de blindatge que no es correspon amb la realitat quan hi ha scripts capaços d'establir connexions WebRTC directes.

En resum, moltes botigues en línia que creuen tenir una política “a prova de bales” perquè bloquegen tots els dominis externs excepte uns pocs whitelistejats segueixen exposant les dades dels seus clients a aquest tipus de skimmers que operen per un canal no cobert per les regles de sempre.

Com el malware aprofita el nonce de CSP per camuflar-se

Alguns desenvolupadors fan un pas més i utilitzen nonces a la capçalera CSP . Aquest enfocament consisteix a assignar un valor aleatori (nonze) a cada càrrega de pàgina i afegir-lo tant a la política CSP com als scripts legítims del document, de manera que només els scripts que portin aquest nonce s'executin.

Sobre el paper, això dificulta que un atacant simplement injecti un script extern a la pàgina, perquè aquest script no tindria el nonce correcte i el navegador el bloquejaria. Tot i això, l'skimmer WebRTC descobert ha demostrat que també es pot robar o reutilitzar aquest nonce des del propi entorn del navegador.

El codi maliciós analitza el codi de la pàgina, localitza un script legítim que inclogui el nonce i el copia per utilitzar-lo en el seu propi bloc de codi. D'aquesta manera, l'script maliciós es presenta davant del navegador amb les mateixes credencials que un script autoritzat.

Quan això passa, les eines de monitoratge i les pròpies polítiques del lloc no distingeixen entre el codi legítim i l'injectat , perquè tots dos compleixen aparentment les mateixes condicions de seguretat. Quan ha passat aquest filtre, l'skimmer només ha d'inicialitzar la RTCPeerConnection, obrir el DataChannel i començar a intercanviar dades xifrades sense aixecar sospites.

El gran problema aquí és que la majoria de solucions de seguretat que vigilen la xarxa estan centrades a inspeccionar HTTP i, com a molt, WebSockets. Aquest skimmer se salta aquestes capes per complet, aconseguint que no hi hagi peticions HTTP clarament anòmales que delatin el robatori , cosa que complica molt la resposta davant incidents i el forense posterior.

PolyShell a Magento i Adobe Commerce: la porta d'entrada perfecta

Tot aquest muntatge no serviria de gaire si els atacants no tinguessin una manera eficaç d'introduir el codi a les botigues. Aquí és on entra PolyShell , una vulnerabilitat crítica a Magento Open Source i Adobe Commerce que ha esdevingut el vector d'entrada principal d'aquest skimmer WebRTC.

PolyShell permet a un atacant no autenticat pujar fitxers potencialment executables a determinades rutes del servidor, especialment si la configuració dels directoris de mitjans no està ben endurida. A partir d'aquesta pujada, els adversaris poden desplegar web shells, backdoors i tota mena de seqüències dissenyades per executar codi arbitrari.

Els primers indicis d'explotació massiva es remunten al 19 de març de 2026 , data a partir de la qual es va detectar un volum molt alt d'escaneigs automatitzats provinents de més de 50 adreces IP diferents. Aquests escaneigs buscaven precisament instàncies vulnerables de Magento i Adobe Commerce amb la porta PolyShell oberta.

Les dades recopilades pels investigadors assenyalen que aproximadament el 56,7% de les botigues identificades com a vulnerables van acabar compromeses en molt poc temps. És un percentatge altíssim que revela fins a quin punt els atacants van automatitzar l'ús de l'exploit i el van convertir en una operació a gran escala.

Un cop aconseguida l'execució de codi, els criminals injecten l'script de skimming a la lògica de checkout, de manera que el codi s'executi de manera automàtica quan el client introdueix les dades de pagament. A partir d'aquí, la recol·lecció de targetes i l'exfiltració via WebRTC es mantenen actives mentre la bretxa no es detecti i es netegi completament l'entorn.

Evolució de Magecart i salt cap a WebRTC

Sota el paraigua de Magecart s'agrupen des de fa anys diferents actors i campanyes centrades en el robatori de dades de pagament a botigues en línia. No és un grup únic, sinó una categoria de tàctiques i eines que ha anat evolucionant segons ho feien també les defenses del sector.

En els primers temps, els skimmers es limitaven a llançar peticions HTTP simples a dominis controlats pels atacants . Per poc que l'empresa desplegués un WAF o revisés logs d'accés, aquests patrons podien identificar-se amb relativa facilitat, cosa que va empènyer els criminals a buscar alternatives més discretes.

Després van arribar els anomenats image beacons , on la informació robada s'incrustava en paràmetres de càrrega d'imatges aparentment innòcues (per exemple, un GIF). Encara que més subtil, aquesta tècnica també es podia detectar amb regles adequades i anàlisi de trànsit sortint.

Més endavant, alguns grups van començar a fer servir WebSockets per mantenir canals persistents entre navegador i servidor de comandament i control. Aquest mètode complicava encara més la detecció amb eines centrades en trànsit HTTP convencional, encara que seguia sent visible per als que inspeccionaven les capçaleres i el destí d'aquestes connexions.

El moviment actual cap a WebRTC DataChannels és, en realitat, una resposta lògica a aquesta carrera armamentística . En aprofitar un estàndard pensat per a videotrucades, xats o transmissions en temps real, els atacants es camuflen darrere d'un flux xifrat i descentralitzat que no sempre està ben monitoritzat en entorns corporatius.

Skimmers tradicionals vs skimmers basats en WebRTC

A l'hora de comparar un skimmer clàssic amb aquest nou enfocament WebRTC, una de les principals diferències és el canal utilitzat per treure les dades . Els primers es recolzen en HTTP/HTTPS o WebSockets, mentre que els segons usen UDP xifrat amb DTLS a través de DataChannels.

Una altra diferència clau té a veure amb la visibilitat de les eines de seguretat . Un firewall d'aplicacions web (WAF), un servidor intermediari invers, o fins i tot un sistema de detecció d'intrusions de xarxa, solen estar ben equipats per distingir i registrar trànsit HTTP maliciós, però no tant per inspeccionar el contingut d'un canal WebRTC xifrat.

La tercera gran separació és el paper de CSP. En un escenari tradicional, una política de seguretat de continguts ben plantejada pot bloquejar moltes de les sortides il·lícites de dades, en restringir connectors cap a dominis desconeguts. En el cas de WebRTC, la CSP estàndard no controla la creació de RTCPeerConnection , de manera que el skimmer pot salvar aquesta barrera gairebé sense esforç.

Finalment, hi ha una qüestió de maduresa defensiva: els equips de seguretat i els proveïdors de solucions fa anys que afinen firmes, regles i mecanismes per detectar trànsit HTTP anòmal, però encara no existeix el mateix grau d'especialització davant d'abusos de WebRTC en entorns de comerç electrònic. Aquesta asimetria temporal juga ara mateix a favor dels atacants.

Mesures de protecció davant de skimmers amb WebRTC

Davant d'un panorama així, és normal pensar que es pot fer poc, però això no és del tot cert. Hi ha una sèrie de passos que, combinats, redueixen de manera significativa les possibilitats que un skimmer d'aquest tipus s'instal·li i romangui ocult a la teva botiga en línia.

1. Aplicar sense demora els pegats de Magento i Adobe Commerce

El primer front és atacar l'arrel del problema, és a dir, la vulnerabilitat d'entrada. Si el teu negoci utilitza Magento Open Source o Adobe Commerce , és vital comprovar la versió actual i instal·lar els pegats que corregeixen PolyShell quan estiguin disponibles per a l'entorn de producció.

Els informes mostren que més de la meitat de les instal·lacions vulnerables detectades, concretament aquest 56,7% de botigues , van acabar compromeses en poc temps. Quedar-se en versions antigues o posposar el pegat és, literalment, jugar a la ruleta russa amb les dades dels teus clients.

2. Monitoritzar la integritat dels scripts

Com que l'skimmer s'injecta principalment en els scripts de checkout, una de les defenses més efectives és desplegar eines de monitoratge d'integritat de JavaScript . Solucions com les ofertes per proveïdors especialitzats en seguretat per a e-commerce permeten detectar canvis no autoritzats al codi.

Aquestes plataformes comparen l'estat actual dels vostres fitxers amb versions de referència, alertant si apareixen blocs nous, ofuscats o redirigits a dominis estranys. Cap eina és infal·lible, però disposar d'aquest tipus de vigilància redueix de forma dràstica la finestra de temps durant la qual un skimmer pot romandre actiu sense ser vist.

3. Explorar lús de directives CSP orientades a WebRTC

Encara que encara està en fase experimental, alguns navegadors com Chrome ofereixen suport per a directives CSP específiques per a WebRTC . Si la vostra audiència utilitza principalment navegadors moderns i controles bé l'stack tecnològic, pot ser interessant provar aquestes opcions.

Això sí, no convé dipositar tota la confiança en una característica que encara no està estàndard ni suportada de manera homogènia. L'ideal és considerar-la una capa addicional de defensa , mai l'únic mur, combinant-la amb pegat agressiu, anàlisi de scripts i bones pràctiques en la gestió de dependències.

4. Revisar i reduir scripts de tercers

Tot script extern que carregues a la teva botiga és un altre punt potencial de compromís . Widgets d'atenció al client, eines d'analítica, plataformes de publicitat o llibreries de tercers es poden convertir en la via per la qual s'injecta codi maliciós si algun d'aquests proveïdors pateix una bretxa.

Una mesura raonable és fer auditories periòdiques (per exemple, cada tres mesos) de tots els scripts que es carreguen en pàgines sensibles com el checkout, eliminant els que no siguin estrictament necessaris. Menys dependències implica menys superfície datac.

5. Vigilar el comportament del formulari de pagament en temps real

Més enllà de comprovar el codi en repòs, és molt útil monitoritzar què fa realment el formulari de pagament en temps d'execució . Això inclou registrar cap a quins dominis intenta enviar dades, si s'obren connexions no esperades o si s'estan iniciant RTCPeerConnections sense cap justificació funcional.

Alguns proveïdors de hosting i seguretat web ofereixen funcionalitats danàlisi de comportament en temps real per a formularis crítics. Quan es detecta un intent d'exfiltració a dominis no autoritzats o l'ús de canals de comunicació inusuals, es poden tallar sessions sospitoses, bloquejar IPs i notificar-ho immediatament a l'equip de seguretat.

Errors habituals que deixen la porta oberta

A la pràctica, molts dels incidents relacionats amb aquest tipus de skimmers comparteixen una sèrie d'errors recurrents a les organitzacions afectades. Posar focus ajuda a evitar caure en el mateix parany.

1. Confiar cegament en una CSP molt estricta

Configurar una CSP exigent és una bona idea, però no és una solució màgica ni total . El fet que la versió estàndard de CSP no controli RTCPeerConnection fa que els atacants puguin continuar traient dades via WebRTC encara que totes les connexions HTTP no autoritzades estiguin bloquejades.

Per això, és un error pensar que “com ja tinc CSP, estic cobert davant de tot el que vagi pel navegador”. Sense un enfocament per capes que inclogui WAF, monitorització de scripts, revisions de logs i auditories periòdiques de seguretat, la política de continguts per si sola es queda curta davant de tècniques com les que estem comentant.

2. Retardar el pegat de vulnerabilitats conegudes

Una altra equivocació freqüent és no actualitzar amb rapidesa quan apareix una vulnerabilitat crítica amb exploit públic . PolyShell és un exemple de llibre de com una fallada coneguda, amb informació detallada disponible, s'aprofita de manera massiva quan les organitzacions triguen a reaccionar.

Quan una fallada entra en catàlegs com el Known Exploited Vulnerabilities (KEV) de CISA, la prioritat de pedaç s'hauria de disparar. Mantenir entorns productius en versions obsoletes o sense aplicar hotfixes en aquests casos és assumir conscientment un risc molt elevat.

3. Dependre només de la monitorització de xarxa

Moltes infraestructures compten amb potents sistemes per inspeccionar trànsit HTTP, HTTPS i TCP , però amb prou feines tenen visibilitat sobre comunicacions basades en UDP xifrat com les que utilitza WebRTC. Això crea una falsa sensació de control: els panells ho mostren tot en verd, mentre l'skimmer es comunica feliçment per un altre camí.

La solució passa per complementar el monitoratge de xarxa clàssica amb vigilància d'integritat de codi i anàlisi del comportament del costat client . En altres paraules, cal mirar no només què surt per la xarxa, sinó també què fa el codi JavaScript que s'executa al navegador i com interactua amb API com WebRTC.

Què se sap amb certesa i què encara és a l'aire

La informació pública disponible sobre aquest skimmer i les campanyes associades permet diferenciar entre fets confirmats i aspectes que encara romanen a la zona grisa de l'especulació raonable.

Entre els elements confirmats hi ha el descobriment d' un skimmer WebRTC operatiu a la botiga en línia d'un gran fabricant d'automòbils , el començament de l'explotació massiva de PolyShell el 19 de març del 2026 i la xifra aproximada del 56,7% de botigues vulnerables compromeses. També està demostrat que els DataChannels de WebRTC no entren dins de les directives CSP estàndard.

Al costat del no confirmat, encara que plausible, hi ha la identitat de totes les grans empreses afectades , ja que no totes han estat nomenades públicament. Tampoc no és clar si l'ús de WebRTC com a canal d'exfiltració s'està estenent de manera massiva o si, per ara, es limita a determinats grups amb alta capacitat tècnica.

De la mateixa manera, els detalls fins de l'exploit, els possibles mòduls complementaris que pugui incloure aquest codi maliciós i el seu grau d'integració amb altres components de la cadena d'atac encara no es coneixen en profunditat. És raonable suposar que fabricants de solucions de seguretat com els orientats a WordPress o Magento estan treballant per afinar els motors de detecció sobre aquest patró concret.

Preguntes freqüents sobre skimmers WebRTC ye-commerce

L'aparició d'aquest tipus d'amenaces genera molts dubtes entre administradors de botigues en línia i responsables de seguretat. Algunes preguntes es repeteixen una vegada i una altra, així que convé donar-los resposta de forma directa.

Com puc saber si la meva botiga té un skimmer instal·lat?

El més efectiu és recórrer a , capaços de recórrer el codi del teu lloc a la recerca de patrons sospitosos, scripts ofuscats, referències a dominis maliciosos o canvis no autoritzats al checkout.

Si el vostre proveïdor de hosting inclou serveis de seguretat gestionada, és bona idea llançar un escaneig complet com més aviat millor. En el cas concret de PolyShell, a més, hauries de comprovar que les teves instàncies de Magento o Adobe Commerce estiguin actualitzades amb els pegats que corregeixen la vulnerabilitat i revisar els directoris de mitjans a la recerca d'arxius estranys o fora de lloc.

Per què es pot abusar de WebRTC si és un estàndard legítim?

WebRTC va ser dissenyat per habilitar comunicació en temps real entre navegadors : videotrucades, compartició de pantalla, xats de veu o transferència de fitxers. El problema és que qualsevol canal de comunicació prou flexible es pot utilitzar també amb finalitats no previstes originalment.

En aquest cas, l'estàndard no inclou per defecte mecanismes que l'integrin amb CSP de manera robusta, i això crea un buit de seguretat que els atacants han sabut aprofitar. No es tracta tant d'un bug concret, sinó d'una limitació de disseny i una manca de controls complementaris en moltes aplicacions web que fan ús —o no— de WebRTC.

La monitorització de xarxa tradicional pot detectar aquest atac?

Amb les eines convencionals, no és senzill detectar el contingut de les comunicacions WebRTC perquè viatgen xifrades amb DTLS sobre UDP. Un WAF que només miri HTTP/HTTPS no veurà les targetes volant per la xarxa, de la mateixa manera que un tallafoc clàssic amb prou feines registrarà que hi ha trànsit UDP xifrat sense cap context.

Per tenir opcions reals de detecció, cal combinar anàlisis d'integritat del codi JavaScript, regles de comportament que identifiquin l'ús sospitós de RTCPeerConnection i, en alguns casos, solucions avançades d'inspecció de trànsit xifrat que permetin, almenys, aplicar regles basades en patrons de connexió, destinacions i volums.

És un problema exclusiu de Magento o també afecta WordPress i altres CMS?

El vector d'entrada descrit públicament està molt lligat a PolyShell a Magento i Adobe Commerce , però la tècnica d'exfiltració mitjançant WebRTC no és ni de bon tros exclusiva d'aquestes plataformes. Qualsevol sistema que permeti la injecció d'scripts a la pàgina de pagament —inclosos WordPress amb WooCommerce o altres CMS— podria patir un atac idèntic si s'explota una altra vulnerabilitat diferent.

En altres paraules, el que és específic d'aquest cas és l'ús de PolyShell per entrar, però l'ús de WebRTC DataChannels com a canal de robatori de dades és aplicable a qualsevol entorn on s'aconsegueixi executar codi JavaScript al navegador dels clients durant el procés de pagament.

A la vista de tot això, queda clar que les tàctiques de skimming a e-commerce han fet un salt qualitatiu amb l'ús de WebRTC com a canal d'exfiltració, recolzant-se en vulnerabilitats crítiques com PolyShell i en llacunes d'estàndards com CSP. Les organitzacions que gestionen botigues en línia no poden limitar-se ja a vigilar trànsit HTTP i confiar en una sola capa de protecció: toca pegats amb rapidesa, reduir superfície d'atac, monitoritzar la integritat dels scripts i prestar atenció al comportament real del codi al navegador si no volen que les dades de pagament dels seus clients acabin sortint per aquesta “finestra lateral” que fins ara gairebé anava sortint per aquesta “finestra lateral”.