953 negozi Magento infettati: quando la patch non ferma il malware persistente

Una campagna malware attiva dal luglio 2025 ha infettato 953 negozi online, principalmente piattaforme Magento, con loader JavaScript che eludono il rilevamento tramite fingerprinting del browser. Il dato più disturbante non è il numero, ma il meccanismo: un negozio su Magento 2.4.7-p10, privo di patch mancanti, è stato reinfettato nel giro di un'ora, dimostrando che l'aggiornamento del software non elimina necessariamente la compromissione.

Nota editoriale: questo articolo si basa su un unico report primario di Sansec, ripreso da SecurityWeek, senza replicazione indipendente dei dati tecnici. I meccanismi descritti riflettono le osservazioni della fonte originale.

La catena di infezione: dalle vulnerabilità note al fingerprinting evasivo

Secondo il report di Sansec ripreso da SecurityWeek, l'attore di minaccia ha sfruttato due vulnerabilità critiche per l'accesso iniziale: CVE-2026-48356 (PolyShell) e CVE-2025-54236 (SessionReaper). A marzo 2026, 471 negozi sono stati compromessi tramite PolyShell, mentre oltre 100 presentavano file caricati tramite uno dei due vettori.

La caratteristica distintiva della campagna è il loader JavaScript che adatta il comportamento in base al visitatore. Il codice esegue fingerprinting del browser e serve il payload solo a sessioni che presentano caratteristiche di utenti reali, restituendo risposte vuote a scanner di sicurezza e bot di analisi. Questo meccanismo elude il rilevamento statico degli indicatori di compromissione.

L'infrastruttura di comando e controllo ha attraversato cinque domini: manulfie.click, neswnsssn.click, lanhd6549tdhse.top, additionalver.com, e dal mese in corso deepveindrilling.com. I primi due sono scaduti e stati ri-registrati a maggio 2026 con nameserver di abovedomains.com, un servizio di parking. Nonostante ciò, tra agosto e ottobre 2026 Sansec ha ancora rilevato manulfie.click attivo su 9 negozi e neswnsssn.click su 6, segno di mancata pulizia delle installazioni compromesse.

Il passaggio a deepveindrilling.com rappresenta un'evoluzione significativa. Il dominio è posizionato dietro Cloudflare. Secondo Sansec, risponde selettivamente: solo le richieste originate da script caricati nei browser dei visitatori dei negozi infetti ricevono il payload effettivo. Il fingerprinting client-side nel browser e la risposta selettiva server-side sono meccanismi distinti che operano in successione, non un'architettura unificata. Questa configurazione rende inefficaci i blocchi basati su IOC statici e complica l'analisi da parte dei ricercatori. Il loader è stato trovato su 83 negozi, di cui 60 presentavano versioni precedenti del codice malevolo, indicando reinfezioni multiple.

"Patched stores get the loader too. One store on Magento 2.4.7-p10, with no missing core patches, got deepveindrilling.com at 16:46 UTC on October 23, one hour after a clean scan." — Sansec, riportato da SecurityWeek

Il caso del negozio 2.4.7-p10: perché la patch non è sufficiente

L'episodio più significativo per la comprensione della minaccia riguarda un negozio su Magento 2.4.7-p10, versione che non presentava patch mancanti. Alle 16:46 UTC del 23 ottobre 2026, un'ora dopo una scansione pulita, il sistema è risultato infetto con il loader deepveindrilling.com. La tempistica esclude che la vulnerabilità del software sia stata il vettore.

Le tracce della persistenza erano disponibili da settimane: eComscan, il servizio di monitoraggio di Sansec, aveva identificato un account admin rogue il 16 settembre e una backdoor GSocket il 24 settembre. La fonte non fornisce dettagli tecnici sul funzionamento specifico di GSocket nel caso documentato. La sua presenza indica che l'attore aveva consolidato il controllo server-side indipendentemente dallo stato del codice applicativo.

Il meccanismo ha reso inefficace l'intero ciclo di gestione delle patch. Il negozio era formalmente aggiornato, con nessuna CVE aperta e scansione negativa. La backdoor ha annullato questo stato operativo.

L'evoluzione dell'infrastruttura e il problema dei domini fantasma

La gestione dei domini nella campagna rivela una strategia di longevità insolita per il settore e-commerce. I quattro domini iniziali hanno accumulato segnalazioni significative: Sansec Watch, il servizio di monitoraggio CSP dell'azienda, ha raccolto circa 52.000 segnalazioni di caricamenti per additionalver.com da parte di browser di visitatori. Il dato non specifica se si tratti di richieste totali o visitatori unici, e la fonte non quantifica il numero di negozi effettivamente esposti al payload finale.

I domini scaduti costituiscono un problema di manutenzione infrastrutturale per i merchant. La ri-registrazione su abovedomains.com li ha trasferiti a un servizio di parking, ma il codice malevolo rimasto sui negozi continua a tentare il caricamento. Questo genera fallimenti visibili nei log, ma anche rischio di reintroduzione se un nuovo acquirente del dominio ne ripristina la funzionalità originaria. La situazione è complicata dal fatto che i domini scaduti possono sfuggire al monitoraggio attivo basato su liste di IOC, che privilegiano indicatori attualmente risolvibili.

La transizione a deepveindrilling.com ha introdotto un ulteriore strato di selettività. La combinazione di Cloudflare come proxy e di logica di risposta condizionata al contesto del visitatore rende problematica qualsiasi classificazione binaria del dominio come "malevolo" o "legittimo". La risposta dipende da chi chiede, quando e da dove.

Perché è importante

Il caso documentato da Sansec solleva questioni sul modello di sicurezza predominante nell'e-commerce. La conformità patch-based, intesa come mantenimento del software aggiornato, rimane necessaria ma non sufficiente quando l'attore di minaccia ha già stabilito persistenza. Il negozio 2.4.7-p10 era formalmente protetto contro le vulnerabilità note; non lo era contro un accesso già conquistato.

La campagna mostra inoltre come l'evasione del rilevamento sia diventata centrale nelle operazioni di minaccia. Il fingerprinting dei visitatori e la risposta selettiva server-side non sono tecniche nuove, ma la loro combinazione in una campagna di lunga durata indica un investimento in operazioni di accesso resistenti alla scoperta. Sansec non ha ancora catturato il payload finale della versione attuale, il che lascia aperta la questione dell'obiettivo specifico: versioni precedenti del loader servivano script a tema criptovalute, incluso uno che imitava il brand Ledger.

La persistenza dei domini scaduti sui negozi infetti aggiunge una dimensione temporale al problema. La mancata pulizia non è solo un errore tecnico, ma crea un ponte verso futuri utilizzi degli stessi indicatori. I merchant che non rimuovono attivamente il codice loader restano esposti anche quando l'infrastruttura originale cambia proprietà o funzione.

Cosa fare adesso

Per i merchant che operano su Magento, il caso suggerisce tre priorità specifiche al contesto documentato. Primo: verificare la presenza di account amministrativi non autorizzati, dato che l'account rogue del 16 settembre ha preceduto di settimane la reinfezione del 23 ottobre. Secondo: rimuovere attivamente il codice loader anche dai negozi dove i domini di comando e controllo sembrano inattivi o scaduti, poiché 9 negozi mantenevano manulfie.click e 6 mantenevano neswnsssn.click mesi dopo la scadenza. Terzo: integrare il monitoraggio CSP con analisi del comportamento effettivo del codice caricato, non solo con liste di domini bloccati, dato che deepveindrilling.com elude la classificazione statica.

Per i fornitori di sicurezza, il caso indica che la verifica della conformità patch-based deve essere accompagnata da controllo della persistenza. Una scansione pulita non garantisce assenza di compromissione se l'attore ha già stabilito accesso alternativo.

Chiusura editoriale

La campagna dei 953 negozi non è un caso di vulnerabilità zero-day sfuggita al vendor. È un caso di persistenza che ha reso irrilevante la patch. Il dato che resta è l'ora: sessanta minuti tra scansione pulita e reinfezione, con settimane di avviso ignorati. La tecnica dell'attore è evasiva, ma il punto di fallimento è operativo.

Fonti

• securityweek.com
• radar.offseq.com
• techbytes.app
• coesecurity.com