Tutti gli articoli

Notizie26 ottobre 20266 min di lettura

Magento: 953 negozi online con un loader che elude gli scanner

Dal luglio 2025 un gruppo ha inserito un loader JavaScript nei blocchi CMS di 953 negozi, quasi tutti Magento: domini, tecniche, indicatori e cosa fare.

Nuvola di parole sul malware con la scritta MALWARE in rosso al centro

Un gruppo criminale ha compromesso 953 negozi online dal luglio 2025, quasi tutti basati su Magento (Adobe Commerce), inserendo nelle pagine un piccolo loader JavaScript. La campagna è stata ricostruita dalla società di sicurezza per l’e-commerce Sansec e ripresa da SecurityWeek, The Hacker News, Security Affairs e Infosecurity Magazine. Le testate concordano sui numeri; i dettagli tecnici di seguito vengono dall’analisi di Sansec, così come la riportano SecurityWeek e Security Affairs.

Il loader decide visitatore per visitatore se servire il codice malevolo: i browser automatizzati e gli scanner di sicurezza ricevono una pagina pulita. Per questo il payload finale non è ancora stato catturato. Security Affairs parla di una campagna di skimming; le fonti però non descrivono un furto di dati di pagamento in questa fase, e i payload osservati in passato rimandavano a domini a tema criptovalute.

Cinque domini in 15 mesi

Il gruppo cambia dominio ogni pochi mesi. Secondo la tabella di Sansec riportata da Security Affairs:

Dominio Primo avvistamento nei negozi Negozi
manulfie.click 9 luglio 2025 863
neswnsssn.click 12 dicembre 2025 494
lanhd6549tdhse.top 30 marzo 2026 355
additionalver.com 8 giugno 2026 246
deepveindrilling.com 7 ottobre 2026 83

La somma supera 953 perché molti negozi sono stati infettati più volte. Su pochi siti sono comparsi anche hdfdsi84j3h.top e c85grt98sd.com. Sansec Watch, il servizio di monitoraggio delle Content Security Policy di Sansec, ha ricevuto segnalazioni di browser collegati a tutti e quattro i domini precedenti, circa 52.000 solo per additionalver.com.

C’è un rischio in più: manulfie.click e neswnsssn.click sono scaduti e sono stati registrati di nuovo a maggio 2026 da terzi, oggi su un servizio di parcheggio di domini. Tra agosto e ottobre il loader era ancora presente rispettivamente su 9 e su 6 negozi: i browser dei visitatori mandano al nuovo proprietario la pagina di provenienza e il titolo della pagina, ed eseguono qualsiasi script che quel dominio restituisce.

Come funziona il loader

  • Dove si nasconde: nella tabella cms_block del database di Magento, cioè nei blocchi di contenuto che il CMS inserisce nelle pagine. Lo scanner di Sansec l’ha trovato lì su 148 installazioni, mai in core_config_data né nei file del tema. Chi controlla solo i file non lo vede.
  • Infrastruttura: deepveindrilling.com, registrato il 6 ottobre 2026, è dietro Cloudflare, risponde 404 sulla home e serve script solo ai visitatori dei negozi infetti. Dei suoi 83 negozi, 60 avevano già caricato versioni precedenti, 34 dall’ottobre 2025.
  • Esecuzione senza eval(): la versione di inizio ottobre era composta da due script. Il primo legge dal browser storage un valore chiamato fpCode, lo inserisce in un div invisibile e lo “clicca”: il browser esegue il codice come gestore di eventi. Il valore lo scrive lo script remoto, e una volta salvato il payload si riesegue a ogni pagina anche se il dominio è offline o bloccato. La versione di marzo lo cancellava dopo un’esecuzione.
  • Filtro dei bot: il 23 ottobre i blocchi sono stati riscritti con un loader inline che invia un’impronta del browser a https://deepveindrilling.com/?s=49b7ca5f&fp=. L’impronta riconosce i browser automatizzati (navigator.webdriver, variabili globali di Selenium, proprietà cdc_ di ChromeDriver) e aggiunge GPU da WebGL, core della CPU, memoria, schermo, fuso orario, lingue e client hints. Una scansione automatizzata con urlscan.io ha ricevuto HTTP 200 senza contenuti aggiunti.
  • Prima di ottobre il secondo script era l’integrazione “Script (async)” di Keitaro, tracker pubblicitario commerciale usato come traffic distribution system: inviava referrer, titolo e query string a un URL codificato in base64 (per esempio additionalver.com/Mb2z8J?&se_referrer=) e decideva se restituire un payload, un reindirizzamento o niente.
  • Payload osservati: il 12 dicembre 2025 un cliente autenticato su un negozio infetto ha ricevuto da manulfie.click script provenienti da crypto-insider.top e da leqdger.click, un dominio che imita il marchio del wallet Ledger.

Per chi fa threat hunting, le tecniche si possono ricondurre (nostra classificazione) a MITRE ATT&CK T1190 (sfruttamento di applicazioni esposte), T1505.003 (web shell), T1136 (creazione di account), T1059.007 (JavaScript) e T1497 (elusione dell’analisi automatizzata).

Come entrano

L’ondata di ottobre non ha usato vulnerabilità nuove: la maggior parte dei negozi era già compromessa. A marzo il gruppo aveva infettato 471 negozi in un’ora caricando web shell tramite PolyShell (CVE-2026-48356); più di 100 negozi avevano file caricati tramite PolyShell o SessionReaper (CVE-2025-54236). Un negozio su Magento 2.4.7-p1 aveva web shell PolyShell travestite da immagini PNG e non aveva installato la correzione di Adobe APSB26-73.

Le patch da sole non bastano. Un negozio su Magento 2.4.7-p10, senza patch del core mancanti, ha ricevuto il loader il 23 ottobre alle 16:46 UTC, un’ora dopo una scansione pulita: a settembre vi erano già stati trovati un account amministratore illegittimo e una backdoor GSocket. L’accesso dell’attaccante era rimasto.

Impatto per le aziende europee e italiane

Magento è diffuso anche tra i negozi online italiani, spesso gestiti da agenzie o hosting esterni. Un loader che esegue codice arbitrario nel browser dei clienti espone dati di accesso, ordini e potenzialmente pagamenti: se c’è una violazione di dati personali si applicano gli obblighi del GDPR, con la notifica al Garante entro 72 ore. I marketplace online rientrano tra i fornitori digitali della NIS2, che richiede gestione delle vulnerabilità e valutazione degli incidenti significativi per la notifica al CSIRT Italia.

Cosa fare subito

  1. Cerca il loader nel database: controlla le tabelle cms_block e cms_page per fpCode, se_referrer, i domini elencati e stringhe in base64 che contengono domini.
  2. Confronta con gli indicatori pubblicati da Sansec in fondo alla sua analisi, anche nei log del proxy e nei report CSP. Secondo Sansec, se il negozio carica uno di quei domini l’attaccante può scrivere nel database, e cancellare lo script non toglie quell’accesso.
  3. Cerca il punto di ingresso: web shell tra i file caricati (anche finte immagini), account amministratori sconosciuti, processi sospetti come backdoor persistenti.
  4. Aggiorna: APSB26-73 per PolyShell e APSB25-88 per SessionReaper.
  5. Dopo la bonifica cambia le password del database, degli amministratori e delle integrazioni API.

Come aiuta ARXDOME

ARX Horizon permette di cercare indicatori di compromissione come i domini della campagna e segnala le corrispondenze con la threat intelligence. ARX Sentry controlla l’integrità dei file nelle cartelle stabilite: includendo quelle del negozio, una web shell caricata diventa un evento da analizzare (il loader nel database va invece cercato con le query indicate). ARX Expose mostra i servizi esposti e i prodotti riconosciuti, utile per trovare i negozi dimenticati; ARX Shield elenca le vulnerabilità aperte sulle macchine con l’agent e permette di isolare un server sospetto.

Ultimo aggiornamento:

Hai domande?

Parliamo delle esigenze della tua azienda, senza impegno.

Contattaci

Articoli correlati