Înapoi la Noutăți
Amenințări

Campanie de skimming pe Magento: 953 de magazine infectate cu cod care se ascunde de scanere

O operațiune de furt de date de card, activă de peste un an, a plantat un loader JavaScript în tabelele de conținut a aproape o mie de magazine Magento. Codul verifică dacă vizitatorul este un cumpărător real înainte să facă ceva, așa că scanările de rutină ies curate în timp ce clienții rămân expuși.

Campanie de skimming pe Magento: 953 de magazine infectate cu cod care se ascunde de scanere

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 și cms_page după tipare precum fpCode, se_referrer și localStorage.getItem. Uită-te în special la cms_block.content.
  • Verifică persistența. Revizuiește tabela admin_user pentru conturi necunoscute, caută procese nefamiliare pe server și inspectează directoarele de upload precum pub/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.

DISTRIBUIE