Una campagna malware Magento infetta 953 negozi online
Il malware Magento ha infettato 953 negozi online, per la maggior parte basati su Magento, nell’ambito di una campagna che, secondo Sansec, è attiva da luglio 2025. L’aggressore non identificato inserisce un loader compatto nelle pagine dei negozi tramite i CMS block del content management system (CMS) di Magento, sezioni gestite nel database e utilizzate per pubblicare contenuti statici nelle pagine del negozio. Quando un acquirente apre una pagina interessata, il codice aggiunto contatta un’infrastruttura controllata dall’aggressore per ricevere ulteriori istruzioni.
Sansec ha scoperto che il sistema remoto tenta di distinguere gli acquirenti reali dagli scanner di sicurezza automatizzati. Le richieste ritenute provenienti da scanner non ricevono nulla, mentre a determinati visitatori può essere fornito JavaScript dannoso, ossia codice eseguito all’interno del web browser. Questa distribuzione selettiva riduce la probabilità che i controlli automatizzati di routine vedano la stessa risposta ricevuta da un cliente. Il payload finale preciso rimane sconosciuto, quindi non è stato confermato che cosa faccia effettivamente l’aggressore nei browser degli acquirenti.
Nel tempo, cinque domini sono stati collegati alla campagna. Sansec ha osservato per la prima volta manulfie[.]click nel luglio 2025, neswnsssn[.]click nel dicembre 2025, lanhd6549tdhse[.]top nel marzo 2026, additionalver[.]com nel giugno 2026 e deepveindrilling[.]com nell’ottobre 2026. L’azienda di sicurezza ha trovato deepveindrilling[.]com nei CMS block di 83 negozi dopo che il dominio era stato registrato il 6 ottobre 2026. Il dominio è ospitato dietro Cloudflare e risponde soltanto alle richieste di script associate a visitatori reali di negozi compromessi.
Il loader viene inserito nella tabella cms_block del database di Magento. Quando Magento esegue il rendering del CMS block interessato come parte di una pagina, il browser esegue il codice controllato dall’aggressore. Sansec non ha stabilito se l’aggressore modifichi CMS block esistenti, come un header, un footer o una sezione promozionale, oppure ne crei di nuovi. Entrambi i metodi possono far comparire lo script nelle pagine rivolte ai clienti. Gli amministratori dei siti devono quindi controllare sia i CMS block conosciuti che potrebbero essere stati modificati, sia quelli sconosciuti che non dovrebbero esistere.
Sansec ha identificato due versioni del loader. Una scarica JavaScript esterno e salva il payload in localStorage, uno spazio in cui un sito web può conservare dati nel browser di un visitatore. In questo modo, il codice salvato può essere eseguito durante visite successive anche quando il dominio esterno dell’aggressore non è più disponibile. Una seconda versione aggiunge browser fingerprinting, che esamina le caratteristiche del browser per distinguere i probabili acquirenti da bot e strumenti di sicurezza. Questo filtraggio ha lo scopo di esporre un numero minore di sistemi automatizzati alla risposta dannosa.
Le attività precedenti della campagna utilizzavano Keitaro, una piattaforma di monitoraggio e analisi pubblicitaria, come traffic distribution system (TDS). Un traffic distribution system (TDS) decide quale risposta fornire a un visitatore in base alle caratteristiche osservate. In questa campagna, ciò poteva significare restituire un payload, reindirizzare il visitatore oppure non restituire nulla. Quando Sansec ha richiesto lo script di additionalver[.]com presentandosi come un visitatore da desktop Windows, il server ha restituito “QWE=123;”. La risposta non ha eseguito altre azioni oltre all’impostazione di un cookie, un piccolo record del browser che contrassegnava il visitatore per 24 ore. Il loader più recente di deepveindrilling[.]com non utilizza più il componente Keitaro ed esegue invece direttamente il filtraggio dei bot.
Sansec stima che 471 negozi Magento abbiano ricevuto il loader tramite PolyShell, identificato anche come CVE-2026-48356. In altri 102 negozi erano stati caricati file tramite PolyShell oppure SessionReaper, identificato come CVE-2025-54236. In un negozio esaminato che utilizzava Magento 2.4.7-p1, alcuni file webshell PolyShell erano camuffati da file immagine PNG nel percorso pub/media/custom_options/quote/. Un webshell è un file dannoso che consente a un aggressore di inviare comandi tramite un sito web compromesso. Lo stesso negozio conteneva il loader di additionalver[.]com in un CMS block, poi sostituito da deepveindrilling[.]com il 7 ottobre. Sansec ha dichiarato che nel negozio mancava ancora APSB26-73, la correzione di Adobe per PolyShell destinata alle linee di release supportate.
Un’altra compromissione ha interessato un negozio che utilizzava Magento 2.4.7-p10, nonostante non mancasse alcuna patch del core di Magento. In quel caso, era stato aggiunto un account amministratore non autorizzato, poi utilizzato per inserire il codice. Questa scoperta significa che un’indagine non dovrebbe concludersi dopo aver verificato l’installazione degli aggiornamenti del core. I proprietari dovrebbero controllare anche gli account amministratore, i contenuti del database e le modifiche inattese alle pagine del negozio.
Sansec consiglia di cercare account sospetti e di esaminare entrambe le tabelle cms_block e cms_page per individuare contenuti inattesi. Le installazioni Magento devono essere mantenute aggiornate e gli account amministratore devono utilizzare password robuste. Poiché il loader può conservare codice nella localStorage di un acquirente, la rimozione dell’injection nel database e la disattivazione del dominio di un aggressore potrebbero non eliminare immediatamente il codice già memorizzato nei browser che avevano visitato in precedenza il negozio interessato.
La divulgazione coincide con attività di exploitation riguardanti PHP2Shell, una coppia di vulnerabilità critiche di PHP identificate come CVE-2026-109618 e CVE-2026-109619. Dopo la loro divulgazione nella settimana precedente, sono stati osservati tentativi di exploitation su vasta scala. Un ricercatore di Perplexity ha inoltre registrato quello che sembrava essere il primo caso riuscito di in-the-wild exploitation su honeypot servers, sistemi deliberatamente monitorati e utilizzati per osservare gli attacchi. I comandi utilizzavano wget, curl o la PHP command-line interface per richiedere ulteriori payload a 162.35.99[.]94:80, anche se non sono stati osservati file del secondo stadio scaricati.
Per le organizzazioni responsabili di ambienti e-commerce, AEU-I fornisce servizi IT, infrastrutture e consulenza con la sicurezza come priorità. Indipendentemente dal fornitore, i proprietari dei negozi dovrebbero considerare CMS block inspiegabili, amministratori sconosciuti e file camuffati da immagini come motivi per avviare immediatamente un’indagine di sicurezza.