Skimmer amb WebRTC: el nou enemic dels pagaments en línia

Els skimmers amb WebRTC s'han convertit en un dels mals de cap més seriosos per a les botigues en línia modernes. Ja no parlem del típic JavaScript que envia dades de targetes per HTTP a un domini sospitós, sinó de codi capaç d'usar canals de dades WebRTC xifrats per treure la informació sense que els controls habituals se n'assabentin. Si gestiones un e‑commerce i segueixes pensant que amb tenir un bon WAF i una CSP estricta vas servit, aquest escenari t'interessa, i molt.

En els darrers incidents analitzats per firmes especialitzades com Sansec, s'ha vist com un skimmer WebRTC explotava vulnerabilitats crítiques com PolyShell a Magento i Adobe Commerce per colar-se a servidors, injectar scripts al checkout i muntar un canal WebRTC directe amb la infraestructura de l'atacant. El resultat és una barreja perillosa: entrada senzilla, persistència silenciosa i exfiltració opaca de dades de pagament, aprofitant buits de disseny en estàndards tan estesos com la Content Security Policy (CSP).

Què és un skimmer amb WebRTC i per què és diferent

Quan parlem d'un skimmer a e-commerce ens referim a un script maliciós que roba dades del formulari de pagament (número de targeta, data de caducitat, CVV, adreces, etc.) mentre el client finalitza la compra. El nou de l'skimmer amb WebRTC és el canal de comunicació que utilitza: en lloc de llençar peticions HTTP POST, imatges trampa o WebSockets, es recolza en WebRTC DataChannels sobre UDP xifrat amb DTLS.

WebRTC va néixer per permetre comunicació en temps real entre navegadors: videotrucades, xat de veu, compartir pantalla o enviar fitxers. L'estàndard inclou mecanismes com ara RTCPeerConnection i canals de dades que permeten establir connexions punt a punt. El skimmer descobert aprofita precisament aquestes capacitats per crear un túnel encobert que treu les dades de targetes fora del lloc, saltant controls pensats gairebé exclusivament per a trànsit HTTP o WebSocket.

El més cridaner és que Sansec documenta per primera vegada l'ús de WebRTC DataChannels com a canal d'exfiltració específic per a skimming a botigues en línia. Fins ara, els grups tipus Magecart solien decantar-se per peticions web clàssiques o, en escenaris una mica més avançats, per WebSockets. Aquest gir cap a WebRTC suposa un salt qualitatiu a la sofisticació de les campanyes.

L'impacte no es queda a petites botigues. Entre les víctimes confirmades es troba un fabricant d?automòbils valorat en més de 100.000 milions, a més d'una gran cadena de supermercats del top 10 global i altres companyies multimilionàries. Els investigadors han detectat skimmers d'aquest tipus en, almenys, cinc grans organitzacions en només dos mesos, cosa que suggereix que no es tracta d'una prova aïllada, sinó d'una tendència clara cap a tècniques més discretes.

Com funciona el skimmer amb WebRTC pas a pas

El cor de l'atac és un script autoexecutable en JavaScript que s'injecta a les pàgines de pagament compromeses. Aquest script, un cop carregat al navegador de la víctima, prepara tota la infraestructura WebRTC necessària per parlar amb el servidor de comandament i control (C2) de l'atacant i rebre més codi maliciós.

En primer lloc, l'skimmer crea un RTCPeerConnection i un DataChannel. El canal de dades s'etiqueta amb l'URL actual de la pàgina, cosa que permet a l'atacant saber exactament en quin pas del lloc es troba l'usuari quan es produeix la comunicació. Aquesta informació contextual es pot utilitzar per adaptar el payload al flux de compra.

A continuació, el codi maliciós (malware) construeix i manipula la negociació SDP (Session Description Protocol) localment. Genera un fragment d'usuari ICE (ice-ufrag) aleatori i fixa de forma estàtica una contrasenya ICE concreta (05l0TstonL9bYAdB04I6x2) a l'oferta que es crea. Després modifica la descripció remota per simular una resposta vàlida que apunta al servidor C2 amb IP 202.181.177.177, utilitzant el port UDP 3479 i un fingerprint DTLS predefinit.

El més interessant és que tot aquest intercanvi SDP es fa sense necessitat d'un servidor de senyalització, que és l'habitual a WebRTC legítim. L'atacant ha precuinat tots dos extrems de la negociació, de manera que el navegador de la víctima pot establir la sessió directament amb la IP del C2, i s'ha saltat la infraestructura de senyalització que, en un entorn defensat, podria estar vigilada o filtrada.

Un cop el canal queda establert, el servidor de l'atacant envia el segon estadi de l'atac, és a dir, el payload complet, en petits fragments. L'onmessage del DataChannel s'encarrega de acumular els trossos rebuts, tant si vénen com a cadena de text com si ho fan en format binari, usant TextDecoder quan cal per reconstruir-los correctament.

Quan el canal es tanca, o transcorren uns 10 segons, entra en acció la funció interna encarregada de executar el payload. Aquí és on el disseny es torna especialment recargolat: el codi intenta executar-se de diferents maneres, prioritzant sempre l'opció que permeti esquivar la Content Security Policy configurada a la web.

Com l'skimmer burla la Content Security Policy i l'ús de nonces

Una de les peces més delicades de l'atac és la manera com l'skimmer s'aprofita de les polítiques CSP i de l'ús de nonces. Molts desenvolupadors confien en CSP per limitar quins scripts es poden executar i, en entorns més avançats, afegeixen nonces aleatoris als scripts legítims perquè únicament aquests blocs de codi autoritzats es carreguin al navegador.

El JavaScript maliciós analitza el DOM a la recerca de etiquetes que ya tengan un atributo nonce. Si en trobeu alguna, crea un nou element script i li copia exactament aquest mateix nonce. Després introdueix dins el payload reconstruït i l'insereix al document, per exemple al head. En compartir nonce amb un script legítim, el navegador considera que aquest bloc també és permès per la CSP.

Si no aconsegueix localitzar cap nonce vàlid, l'skimmer prova una altra via: intenta executar el codi mitjançant Function(payload)(), confiant que la política habiliti unsafe-eval o configuracions similars. En aquells casos on tampoc no sigui possible, recorre a una tercera opció: injectar un tag script tradicional amb el contingut del payload i afegir-lo temporalment al DOM per forçar-ne l'execució.

Per rematar, el codi utilitza requestIdleCallback quan està disponible, o un fallback amb setTimeout, de manera que lexecució de la càrrega maliciosa es produeixi en moments dinactivitat del navegador. Aquest detall redueix limpacte en el rendiment i dificulta que eines d'anàlisi basades en IA detectin el comportament estrany.

El gran punt feble que aprofita l'skimmer és que WebRTC, a diferència d'HTTP, no està cobert per les directives CSP estàndard. Mentre connect-src controla fetch, XHR i WebSockets, l'API RTCPeerConnection queda fora de l'abast d'aquestes regles. Chrome ha arribat a incloure una directiva experimental específica per a WebRTC, però el seu ús és marginal i encara no forma part de la caixa de ferramentes que la majoria de llocs despleguen en producció.

Per què WebRTC es cola pels buits de defensa

La majoria de botigues en línia amb cert nivell de maduresa de seguretat ja compten amb WAF, IDS/IPS i fins i tot inspecció profunda de HTTP i WebSockets. Aquests sistemes se centren en veure quines peticions surten del servidor o dels servidors intermediaris, quins dominis s'assoleixen, quins paràmetres s'envien i si hi ha patrons recognoscibles d'exfiltració.

En el cas de l'skimmer amb WebRTC, tot aquest arsenal es queda gairebé cec, perquè els DataChannels funcionen sobre UDP xifrat amb DTLS. No hi ha peticions HTTP visibles, ni capçaleres sospitoses, ni URLs estranyes a què el WAF pugui agafar-se per llançar una alerta. El que s'observa és bàsicament trànsit UDP xifrat cap a una IP externa, cosa que moltes organitzacions no monitoren amb el mateix detall que el trànsit web clàssic.

A més, les pròpies regles de CSP, que en teoria actuen com a xarxa de seguretat davant de scripts externs i connexions no autoritzades, no contemplen RTCPeerConnection en el disseny actual. Per tant, un lloc amb una política molt restrictiva per a HTTP pot continuar permetent que un JavaScript creï un canal WebRTC directe cap a un servidor d'atac i enviï des d'allà les dades de targetes robades.

Aquest buit de disseny crea el que molts administradors consideren una falsa sensació de seguretat: creuen que, gràcies a CSP ia les llistes blanques de dominis, res estrany sortirà del navegador cap a llocs no autoritzats. Tot i això, mentre no s'estenguin i estandarditzin directives específiques per a WebRTC, aquesta confiança està injustificada davant d'amenaces que saben treure partit de RTCPeerConnection.

Per fer les coses encara més difícils, el trànsit WebRTC sol barrejar-se a la xarxa amb aplicacions legítimes de videotrucada, xat o col·laboració, cosa que fa complicat distingir entre usos benignes i maliciosos només a partir de patrons de xarxa. Sense una anàlisi més fina del comportament de JavaScript en el client, l'skimmer té molt marge per operar a plaer.

PolyShell a Magento i Adobe Commerce: la via d'entrada

Tot l'enginy a l'exfiltració seria irrellevant si els atacants no tinguessin una forma eficaç de col·locar l'script maliciós a la botiga. Aquí és on entra en joc la vulnerabilitat coneguda com a PolyShell, que afecta Magento Open Source i Adobe Commerce i que s'ha convertit en la porta d'entrada estrella per a aquest tipus d'atacs.

PolyShell permet a un atacant remot no autenticat pujar fitxers potencialment executables a rutes sensibles del servidor, generalment a través de l'API REST o de directoris mal protegits, com certs paths dins de pub/media/custom_options. Un cop aconsegueixen aquesta càrrega, poden desplegar web shells, backdoors i els scripts de skimming necessaris per comprometre el flux de checkout.

Els investigadors situen l'inici de la explotació massiva de PolyShell al voltant del 19 de març de 2026, data en què es va observar un bec molt acusat d'escaneigs automatitzats des de més de 50 adreces IP diferents. Aquests escanejats anaven buscant instàncies vulnerables de Magento i Adobe Commerce per llançar la intrusió de manera industrialitzada.

Les dades recopilades indiquen que al voltant del 56,7% de les botigues identificades com a vulnerables van acabar efectivament compromeses en un període curt. Aquesta xifra dóna una idea clara de com de ràpid reaccionen els delinqüents quan apareix una fallada explotable de forma remota i de com és d'arriscat endarrerir el pegat en entorns de producció.

Un cop s'ha aconseguit l'execució de codi al servidor, el pas següent és injectar el JavaScript de skimming en plantilles o mòduls vinculats al procés de pagament. Així es garanteix que l'script s'executarà cada cop que un client accedeixi al checkout, capturant les dades introduïdes i enviant-les pel seu canal WebRTC invisiblement fins que l'equip de seguretat descobreixi la bretxa i netegi a fons l'entorn.

De Magecart clàssic a l'skimmer amb WebRTC

Sota el nom de Mageccart s'engloba des de fa anys un conjunt ampli de grups i campanyes dedicats al robatori de dades de pagament a botigues online. No és una banda única, sinó tot un ecosistema d?actors que comparteixen tàctiques i evolucionen a mesura que les defenses també pugen de nivell.

En les primeres iteracions, els skimmers Magecart es conformaven amb enviar les dades per peticions HTTP directes a dominis controlats pels atacants. Només cal revisar logs d'accés o desplegar un WAF amb regles raonables per començar a identificar aquestes exfiltracions. Amb el temps, i davant de la millora de les defenses, els criminals es van veure empesos a buscar vies més discretes.

Així van sorgir tècniques com els image beacons, on la informació robada es codificava dins de paràmetres de càrrega d'imatges aparentment innocents, com ara GIFs o PNGs. Encara que més subtil, aquest enfocament també es podia detectar amb una combinació dinspecció de trànsit sortint i anàlisi de patrons.

En una fase posterior, alguns grups van començar a experimentar amb endolls web, mantenint canals persistents entre el navegador de la víctima i el servidor de comandament i control. Això complicava la detecció basada en peticions HTTP convencionals, però seguia sent visible per a qui monitoritzés bé les capçaleres i les destinacions d'aquestes connexions.

El pas cap a WebRTC DataChannels és, en aquest context, un moviment lògic dins de la carrera armamentística entre atacants i defensors. En amagar-se darrere d'un estàndard pensat per a aplicacions de temps real i treure partit dels seus buits de cobertura a CSP i eines de xarxa, els skimmers aconsegueixen un nivell de sigil superior al de les generacions anteriors.

Diferències entre skimmers tradicionals i skimmers amb WebRTC

Comparar un skimmer clàssic amb un basat en WebRTC ajuda a entendre per què aquest últim representa una amenaça tan seriosa per a l'ecosistema d'e-commerce. La primera diferència òbvia és al canal de sortida de dades: mentre els anteriors usen HTTP/HTTPS o, com a màxim, WebSockets, el nou enfocament empra UDP xifrat amb DTLS a través de DataChannels.

La segona gran diferència té a veure amb la visibilitat de les eines de seguretat. Un WAF, un servidor intermediari invers o un IDS dissenyats per inspeccionar trànsit web reconeixen bé patrons maliciosos a HTTP, però tenen més dificultats per inspeccionar el contingut real d'un canal WebRTC xifrat, sobretot si no s'han desplegat solucions específiques per fer-ho.

El tercer punt clau és el paper de CSP. En el cas dels skimmers tradicionals, una Content Security Policy ben plantejada pot bloquejar molts intents d'exfiltració restringint connexions a dominis desconeguts. Amb WebRTC en canvi, la CSP estàndard no controla la creació de RTCPeerConnection, així que l'skimmer pot establir el canal sense que la política intervingui.

Finalment, hi ha un factor de maduresa defensiva: la indústria fa anys que afina firmes, regles i mecanismes de protecció davant de trànsit HTTP anòmal. En canvi, l'abús de WebRTC per a skimming és relativament recent, de manera que encara no hi ha el mateix nivell d'especialització ni de regles polides per detectar-lo en entorns de comerç electrònic.

Tot això col·loca els skimmers amb WebRTC en una posició d'avantatge temporal: els atacants van per davant, aprofitant que moltes organitzacions encara no miren amb lupa el que fa el codi JavaScript amb l'API de WebRTC dins del navegador.

Mesures de protecció davant de skimmers amb WebRTC

Encara que la foto pugui semblar descoratjadora, hi ha diverses mesures que, combinades, permeten reduir significativament el risc que un skimmer d'aquest tipus s'instal·li i estigui actiu a la teva botiga online. No hi ha la bala de plata, però sí un conjunt coherent de bones pràctiques.

La primera i més òbvia és aplicar sense demora els pegats de seguretat de Magento i Adobe Commerce que corregeixen PolyShell i qualsevol altra vulnerabilitat dexecució remota. Mantenir instàncies desactualitzades quan ja se sap que hi ha un exploit en circulació —especialment si apareix en llistes de vulnerabilitats explotades de manera habitual— és, sincers, jugar amb foc.

Una altra línia de defensa fonamental és desplegar monitorització d'integritat de JavaScript, sobretot en pàgines sensibles com el checkout. Solucions específiques per a e-commerce poden comparar l'estat actual dels scripts amb versions de referència i avisar quan es detecten blocs nous, ofuscats o que fan trucades a dominis inusuals.

També convé revisar periòdicament els scripts de tercers carregats al flux de pagament: widgets de xat, analítica, anuncis, eines de personalització, etc., ja que poden mostrar senyals de botiga online fraudulenta. Cada dependència és una porta potencial si aquest proveïdor és compromès. Reduir el nombre de seqüències externes al mínim imprescindible ajuda a disminuir la superfície d'atac.

En paral·lel, algunes organitzacions comencen a explorar l'ús de directives CSP orientades a WebRTC en navegadors que les suporten de manera experimental, com Chrome. Tot i que encara no són un estàndard consolidat, poden aportar una capa extra de protecció en entorns controlats, sempre que no es converteixin en l'única línia de defensa.

Finalment, és molt recomanable implantar mecanismes de monitorització del comportament del formulari de pagament en temps real. Això inclou registrar a quins dominis intenten enviar dades des del navegador, si s'obren connexions inesperades o si s'inicialitzen RTCPeerConnections sense una justificació funcional clara. Quan es detecta una exfiltració a una destinació no autoritzada, es poden tallar sessions, aplicar autenticació multifactor, bloquejar IPs i activar els procediments de resposta a incidents.

Errors habituals que deixen l'e-commerce venut

En analitzar incidents d'aquest tipus, es repeteixen una sèrie de patrons de fallada organitzativa que faciliten molt la vida als atacants. Identificar-los és el primer pas per evitar-los a la teva pròpia infraestructura.

Un dels més freqüents és confiar cegament en una CSP molt estricta, pensant que ella sola n'hi haurà prou per bloquejar qualsevol exfiltració des del navegador. Com hem vist, l'absència de cobertura de RTCPeerConnection a les directives estàndard deixa un forat que skimmers com el de WebRTC exploten sense gaire esforç.

Un altre error recurrent és endarrerir el pegat de vulnerabilitats crítiques quan ja hi ha exploit públic i s'han reportat campanyes actives. PolyShell és un bon exemple de com una fallada coneguda es pot convertir en una porta d'entrada massiva si les botigues triguen setmanes o mesos a actualitzar els seus sistemes.

També és molt comú dependre en excés de la monitorització de xarxa tradicional centrada en HTTP/HTTPS, sense complementar amb anàlisi d'integritat del codi JavaScript i sense vigilar APIs específiques del navegador com WebRTC. Això produeix panells de control molt bonics on “tot està en verd”, mentre el skimmer segueix enviant dades per un canal que ningú no està inspeccionant.

Per acabar, molts equips tècnics s'obliden de revisar amb certa regularitat rutes com pub/media/custom_options o directoris equivalents, que són precisament els que els atacants aprofiten en escenaris similars a PolyShell per pujar fitxers maliciosos i mantenir accés persistent al servidor.

Què se sap de l'skimmer i què segueix a l'aire

La informació pública disponible permet traçar una imatge força clara d'alguns aspectes de l'skimmer amb WebRTC, encara que encara queden zones grises que els investigadors continuen intentant aclarir.

Entre les dades confirmades hi ha el ús de la IP 202.181.177.177 com a servidor C2, el port UDP 3479 pels DataChannels, les credencials ICE hardcodeadas (inclosa la contrasenya del client 05l0TstonL9bYAdB04I6x2), el fingerprint DTLS específic i el patró de SDP que s'utilitza per aixecar el canal webrtc-datachannel amb un port5000 també s'ha verificat. més de la meitat de les botigues vulnerables a PolyShell van acabar compromeses en un període curt.

Al costat de les incògnites es troba la llista completa de grans empreses afectades, ja que no totes han estat nomenades públicament. Tampoc no és clar fins a quin punt l'ús de WebRTC com a canal d'exfiltració s'ha estès de manera generalitzada entre tots els grups Magecart, o si de moment es limita a un subconjunt més avançat des del punt de vista tècnic.

Igualment, es desconeix el catàleg complet de mòduls i funcionalitats addicionals que aquest codi maliciós pugui incorporar, per exemple per moure's lateralment a la infraestructura, robar cookies de sessió o manipular altres aspectes del frontend. És raonable pensar que proveïdors de solucions de seguretat especialitzades per a Magento, WordPress i altres CMS estiguin afinant els seus motors per detectar aquests patrons concrets i oferir regles de signatures més completes.

El que sí que està fora de dubte és que el salt a WebRTC canvia les regles del joc per a l'skimming a e‑commerce, obligant botigues i proveïdors de seguretat a mirar molt més enllà del trànsit HTTP ia posar el focus en el que fa realment el JavaScript al navegador del client, sobretot en el moment crític del pagament.

A la vista de tot això, queda força clar que els skimmers amb WebRTC són la següent volta de rosca en el robatori de dades de pagament en línia: combinen vulnerabilitats crítiques en plataformes com Magento i Adobe Commerce, aprofiten buits en estàndards com CSP i s'escuden en canals xifrats difícils de vigilar; si una botiga vol evitar acabar amb les dades dels seus clients circulant per aquest canal lateral gairebé invisible, toca prendre's molt seriosament el pegat ràpid, la reducció de scripts de tercers, la monitorització de la integritat del codi i l'observació constant del comportament real del navegador, en lloc de confiar únicament en el que compten els logs de HTTP.