Campanie de skimming pe Magento: 953 de magazine infectate cu cod care se ascunde de scanere
O operațiune criminală care plantează în liniște JavaScript malițios în magazine Magento încă de la mijlocul lui 2025 a ajuns la 953 de magazine online și este în continuare activă. Campania iese în evidență nu atât prin amploare, cât prin metodă: codul injectat decide, la fiecare încărcare de pagină, dacă vizitatorul este un cumpărător real sau un scaner automat, și livrează payload-ul doar oamenilor.
Ce s-a întâmplat
Atacatorii păstrează un loader mic direct în baza de date Magento, nu într-un fișier de temă sau de modul. Acesta stă în tabela cms_block, locul în care Magento ține blocurile de conținut static afișate pe paginile magazinului. Pentru că loader-ul face parte din conținutul obișnuit al paginii, el supraviețuiește verificărilor de integritate a fișierelor și redeploy-urilor care se uită doar la cod.
Înainte să facă orice, loader-ul contactează un server de distribuție a traficului și întreabă dacă vizitatorul curent ar trebui să primească scriptul real. Cumpărătorii autentici primesc payload-ul de skimming; orice seamănă cu un crawler, un browser headless sau un scaner de securitate primește în schimb o instrucțiune inofensivă care nu face nimic. Un proprietar de magazin care rulează o scanare externă rapidă va vedea adesea un rezultat curat pe un magazin deja compromis.
Grupul își rotește infrastructura la câteva luni. Domeniul folosit din octombrie 2026 a fost găsit în blocurile de conținut a 83 de magazine. Dintre acestea, 60 rulaseră anterior un loader mai vechi al acelorași operatori, iar 34 fuseseră infectate intermitent încă din octombrie 2025. Cu alte cuvinte, mulți comercianți au fost loviți și înainte, au „curățat” scriptul vizibil și au fost reinfectați pentru că accesul de bază nu a fost niciodată eliminat.
Loader-ul în sine a evoluat. Versiunea timpurie citea o valoare stocată numită fpCode din storage-ul browserului vizitatorului și o reexecuta la vizualizările ulterioare, ceea ce ținea skimmer-ul în viață chiar și când domeniul atacatorului era offline. La sfârșitul lui octombrie, operatorii l-au rescris ca să trimită serverului o amprentă completă a browserului: verifică markeri de automatizare precum navigator.webdriver, variabile globale Selenium și proprietăți ChromeDriver și colectează numele GPU-ului, dimensiunea ecranului și fusul orar pentru a deosebi browserele reale de mediile de testare.
Cum au fost compromise magazinele
Este o injecție în stil Magecart, iar accesul inițial a venit în mare parte prin slăbiciuni de încărcare de fișiere din Magento. În martie 2026, grupul a împins loader-ul în 471 de magazine într-o singură oră, după ce a plasat web shell-uri prin PolyShell, vulnerabilitatea de upload nerestricționat de fișiere identificată ca CVE-2026-48356.
Loader-ul a fost găsit și pe 169 de instalări Magento 2 cărora le lipsea cel puțin un patch de securitate de bază. 102 dintre ele prezentau și fișiere încărcate prin PolyShell sau prin SessionReaper (CVE-2025-54236), o vulnerabilitate critică ce permite preluarea sesiunilor clienților. Nici magazinele complet actualizate nu au fost imune: un magazin pe o versiune curentă a primit loader-ul la o oră după o scanare ieșită curată, ceea ce indică mai degrabă credențiale furate sau backdoor-uri rămase decât un exploit nou.
De ce contează
Skimmer-ele de checkout fură numerele de card direct din browserul clientului, așa că de obicei comerciantul află de la rețelele de carduri sau de la clienți nemulțumiți, nu din propria monitorizare. Această campanie agravează situația pentru că învinge activ exact verificarea pe care se bazează majoritatea proprietarilor de magazine: o scanare externă a vitrinei. O scanare curată de la un instrument automat nu mai este o dovadă că un magazin Magento este sigur.
Cifrele de reinfectare sunt celălalt semnal de alarmă. Eliminarea unui script injectat fără a închide breșa prin care a intrat și fără a schimba credențialele pe care atacatorul le deține deja câștigă cel mult câteva săptămâni.
Ce e de făcut
Dacă administrezi un magazin Magento, tratează lista de mai jos ca pe o listă de verificare obligatorie, nu ca pe o sugestie:
- Caută în baza de date, nu doar în fișiere. Interoghează tabelele
cms_blockșicms_pagedupă tipare precumfpCode,se_referrerșilocalStorage.getItem. Uită-te în special lacms_block.content. - Verifică persistența. Revizuiește tabela
admin_userpentru conturi necunoscute, caută procese nefamiliare pe server și inspectează directoarele de upload precumpub/media/custom_options/pentru web shell-uri. - Schimbă tot. După curățare, schimbă credențialele bazei de date, ale contului de admin și ale API-urilor. Ștergerea scriptului nu revocă accesul atacatorului.
- Aplică patch-urile. Buletinul Adobe APSB26-73 rezolvă PolyShell, iar APSB25-88 acoperă SessionReaper. Dacă nu poți face upgrade imediat, pune un firewall pentru aplicații web în fața magazinului ca să blochezi tentativele de exploatare cunoscute până atunci.
- Testează ca un om. Când verifici un magazin, folosește o sesiune de browser normală cu storage activat, nu doar un scaner headless, și compară scripturile primite de un vizitator real cu ceea ce vede tooling-ul tău.
Indicatori de urmărit (defanged)
- Domeniul loader-ului:
deepveindrilling[.]com(căile/?s=d35c5031și/?s=49b7ca5f&fp=) - Domenii de distribuție a traficului:
additionalver[.]com,lanhd6549tdhse[.]top,neswnsssn[.]click,manulfie[.]click,hdfdsi84j3h[.]top,c85grt98sd[.]com - Gazde de payload văzute în decembrie 2025:
leqdger[.]click,crypto-insider[.]top - Răspuns-momeală servit scanerelor:
QWE=123; - Chei din storage-ul browserului:
fpCode,136c1e07507f4a97,136c1e07507f4a98
Campanii ca aceasta intră prin vulnerabilități cunoscute, pentru care există patch-uri, apoi se bazează pe faptul că nimeni nu se uită atent. Serviciul nostru de scanare de vulnerabilități verifică platformele de e-commerce exact pentru această clasă de expuneri, de la buletine de securitate Magento neaplicate până la căi de upload cu drept de scriere, astfel încât breșa să fie închisă înainte s-o găsească altcineva.
