Anatomia di un attacco in stile Magecart a un negozio PrestaShop 1.7.x

Aggiornamento — maggio 2026. Poco dopo la prima pubblicazione di questa analisi, lo stesso negozio è stato colpito di nuovo. La reinfezione non è passata da una backdoor che ci era sfuggita: è entrata dalla porta principale, cioè da una falla non corretta a livello applicativo (una SQL injection nel modulo Lista dei desideri blockwishlist, concatenata alla RCE della cache MySQL di Smarty, CVE-2022-36408) che la nostra bonifica sul posto aveva contenuto, ma mai chiuso. Rimuovere il malware non equivale a chiudere il vettore di ingresso. La correzione più profonda, a livello applicativo — patch virtuale delle vulnerabilità specifiche e blocco dell'origine dietro Cloudflare — è un argomento a sé, trattato in Rafforzamento avanzato di PrestaShop per negozi che non puoi ancora aggiornare. La conclusione non cambia: il contenimento compra tempo; migrare da 1.7.x è la cura.

Questo è un incidente reale avvenuto su un negozio PrestaShop 1.7.x che abbiamo recuperato. Gli identificativi sono stati anonimizzati, ma il flusso di controllo, i percorsi dei file, la struttura dei payload e la logica di rilevamento sono conservati esattamente. Lo scopo di raccontarlo non è spaventare nessuno: è dare ad altri proprietari di negozi e sviluppatori un riferimento concreto su come appare davvero, dall'interno, un attacco moderno in stile Magecart contro PrestaShop, così che quando vedono le stesse forme nei propri file possano riconoscerle in minuti anziché in giorni.

Il proprietario ci ha contattati perché la pagina di pagamento mostrava un modulo di pagamento che non riconosceva. Sembrava un modulo carta di Stripe Elements. Il negozio usa effettivamente Stripe, quindi la somiglianza visiva era sufficiente perché nessuno lo mettesse in dubbio per quasi due giorni. Quando siamo intervenuti, lo skimmer stava già copiando in silenzio i dati delle carte di ogni cliente arrivato alla fase di pagamento. Questo articolo ripercorre l'indagine nell'ordine in cui si è svolta davvero: primo indizio, payload sul server, trucco di esfiltrazione, JavaScript, compromissione root e infine punto di ingresso, perché l'ordine è parte della lezione.

Il primo indizio: un modulo di pagamento che non dovrebbe esistere

Stripe Elements rende i campi della carta dentro iframe cross-origin. La pagina padre non può leggere ciò che il cliente digita al loro interno: quell'isolamento è il motivo stesso per cui Elements esiste, ed è ciò che impedisce a una vetrina compromessa di sottrarre i dati da un'integrazione Stripe corretta. Quindi, davanti a un possibile skimmer, la prima domanda è semplice: i campi della carta sono in un iframe, oppure sono input grezzi nella pagina?

Il modulo che stavamo osservando usava input HTML grezzi, di prima parte:

Tre segnali immediati: niente iframe, un handler a ogni battitura su ogni input e una leggera incoerenza linguistica tra il modulo iniettato e il resto del negozio. Il modulo Stripe legittimo era ancora installato e configurato: il modulo falso era stato semplicemente disegnato sopra. Il vantaggio di conoscere questa singola regola (i gateway reali usano iframe; gli input carta grezzi su una pagina di pagamento PrestaShop sono quasi sempre malevoli) è che qualsiasi commerciante può fare il controllo da solo, oggi stesso, con l'ispettore del browser e senza strumenti speciali: vedi l'elenco degli indicatori alla fine di questo post.

Trovare il payload lato server

Un keylogger nel browser è utile solo se può inviare da qualche parte ciò che cattura. Abbiamo eseguito grep sull'intera directory config/ alla ricerca di schemi sospetti e abbiamo trovato lo stesso blocco anteposto all'inizio di ogni file PHP al suo interno: un frammento che controllava la presenza di un campo $_POST['order_llx'] e, quando lo trovava, ne inoltrava il contenuto tramite curl a due URL codificati in base64 con CURLOPT_SSL_VERIFYPEER disabilitato, poi rimuoveva il campo perché nulla a valle se ne accorgesse.

Tredici file in config/ contenevano questo blocco, e tutti condividevano lo stesso timestamp di modifica dell'inode, fino allo stesso secondo. L'attaccante aveva automatizzato la distribuzione. Le due stringhe base64 decodificate puntavano a indirizzi IP di due server su un grande provider cloud asiatico: l'endpoint di esfiltrazione. Un file, settings.inc.php, era stato sostituito in blocco: era rimasto solo il codice malevolo. E il negozio continuava comunque a funzionare, perché in PrestaShop 1.7 la vera configurazione del database si trova in app/config/parameters.php, non nel deprecato settings.inc.php. L'attaccante lo sapeva, oppure ha avuto fortuna.

Il trucco dell'esfiltrazione in due fasi

La parte davvero astuta di questo attacco è il modo in cui i dati escono. La maggior parte delle Content Security Policy, dei blocchi pubblicità e delle estensioni anti-skimmer è costruita per intercettare il browser che parla direttamente con il server di un attaccante. Questo skimmer non lo fa mai. Il negozio compromesso agisce da intermediario:

• Fase 1 (browser → negozio). L'handler processF() del modulo falso invia via POST i dati carta catturati a / sul dominio stesso del cliente, in un campo chiamato order_llx. Dal punto di vista del browser è normale traffico di prima parte: stessa origine, niente CORS, nulla che una CSP limitata ai terzi possa segnalare.
• Fase 2 (negozio → C2). Il PHP iniettato in config/ intercetta quel campo lato server e lo inoltra tramite curl agli IP dell'attaccante. È una richiesta da server a server che il browser non vede mai: non compare in DevTools, nella scheda rete, né a un amministratore di rete che osserva la connessione del cliente.

Questa è tutta l'evasione. Un amministratore di rete vede una connessione verso il negozio legittimo e smette di indagare; una CSP che blocca solo script di terze parti non intercetta nulla. Questo inoltro a stessa origine è una delle forme Magecart più difficili da individuare dal lato client. Vale la pena essere chiari: non è l'unica forma. Sansec e altri osservatori continuano a vedere, in parallelo, esfiltrazione diretta dal browser, archiviazione nascosta lato server e varianti a recupero differito, senza un singolo schema dominante. Ma l'inoltro è quello che aggira la maggior parte delle difese lato client pronte all'uso.

Lo skimmer JavaScript e la differenza di dimensione che l'ha smascherato

Il modulo falso viveva nel tema. Abbiamo cercato con grep i token univoci che avevamo già visto — cc_owner, processF, smenu — e abbiamo trovato l'iniezione aggiunta in fondo al file ps_shoppingcart.js del tema. La sola differenza di dimensione era la prova evidente: un ps_shoppingcart.js pulito pesa circa 2,7 KB, mentre la copia infetta era di circa 340 KB. Un unico blocco da 337 KB era stato copiato e incollato alla fine di 74 file JavaScript diversi tra tema padre e tema child: ogni theme.js, ogni custom.js, ogni script front-end dei moduli nelle cartelle dei moduli inclusi nel tema.

Il payload era offuscato, ma non in modo sofisticato: un array di stringhe codificate in esadecimale (chiamato _0x5aa5, 225 voci) referenziato per indice ovunque, così che document[_0x5aa5[39]](_0x5aa5[158]) si risolveva semplicemente in document.getElementById("cardNumber"). Decodificando l'array si ottiene l'intero intento: voci per cardNumber, exp-date, cc_owner, cc_cid, i campi di fatturazione, il nome del campo di esfiltrazione order_llx e il tag campagna Zhang. Lo skimmer compone una stringa delimitata da pipe con ogni campo catturato, la codifica in esadecimale, la avvolge in base64 e la invia via POST come FormData a /. Diversi campi esca (products_hash, amount_hash, billing_hash) viaggiano insieme come rumore casuale, così nei log il POST sembra un normale segnale di analytics.

La trappola degli asset compilati (specifica di PrestaShop)

Abbiamo sostituito il file ps_shoppingcart.js infetto con una copia pulita. Il modulo falso compariva ancora. Questa è la trappola che colpisce proprio chi sta ripulendo un negozio PrestaShop, quindi vale la pena capirla con precisione.

La pipeline CCC di PrestaShop (Combine, Compress, Cache) raggruppa gli script del front office registrati per la pagina corrente — qualunque cosa dichiarata tramite registerJavascript senza async/defer — in file combinati come bottom-<hash>.js sotto themes/<theme>/assets/cache/. Gli script infetti erano registrati esattamente in quel modo, quindi il codice malevolo era stato incorporato nei bundle compilati mentre il sorgente era ancora infetto. Finché non abbiamo svuotato quella directory di cache, il browser ha continuato a ricevere lo skimmer dal bundle compilato, qualunque cosa facessimo al file sorgente. La correzione è stata sostituire l'intero albero themes/ con una fonte sicuramente pulita e svuotare ogni cache degli asset: themes/<theme>/assets/cache/, var/cache/ e var/compile/, oltre a eventuali cache degli oggetti Redis o Memcached. Qualsiasi intervento più limitato lascia i bundle rigenerarsi da sorgenti infetti.

Il problema più grande: compromissione root

Mentre cercavamo altri payload dello skimmer, abbiamo eseguito find / -perm -4000 -type f e abbiamo avuto una brutta sorpresa: due binari ELF nella radice web, camuffati con estensione .js. Bit SUID impostato, proprietario root, 1,7 MB ciascuno, SHA256 identico; e non erano affatto JavaScript, ma eseguibili ELF x86_64 (file riportava setuid ELF 64-bit LSB executable, statically linked, stripped). Altri quattro binari SUID-root erano in /usr/bin con nomi casuali, più uno chiamato pkexem: una variazione di una sola lettera del legittimo pkexec, pensata per passare inosservata a un ls frettoloso.

È stato il momento in cui l'incidente ha cambiato categoria. Creare un binario SUID root richiede root. PHP eseguito come utente del sito non può farlo, per quanto vuoto sia disable_functions o permissivo open_basedir. La sola esistenza di quei file dimostrava che era stato compromesso root, non solo l'utente web: il che significa che ripulire la radice web non può mai essere la fine del lavoro, perché la persistenza può nascondersi ovunque sull'host. Per il proprietario di un negozio, la traduzione pratica è secca: a quel punto l'unico stato finale pienamente difendibile è ricreare il server da un'immagine OS pulita, migrare codice e dati verificati come puliti, ruotare ogni segreto e trattare l'host originale come una superficie di contenimento temporanea da tenere in vita solo il tempo necessario a continuare a servire i clienti.

Il vero punto di ingresso: una shell web in index.php

Avevamo ripulito lo skimmer e rimosso i binari backdoor, ma ancora non sapevamo come l'attaccante fosse entrato la prima volta. I log di accesso mostravano un IP che effettuava richieste POST / per settimane, e le dimensioni delle risposte erano l'impronta digitale:

Quella distribuzione ci ha detto due cose. Primo, POST / era esso stesso un endpoint di esecuzione codice: normali richieste alla pagina iniziale non producono un flusso costante di conferme di scrittura file da 695 byte. Secondo, l'esportazione completa della tabella clienti avrebbe raggiunto almeno centinaia di kilobyte, e nei log non c'era nulla che si avvicinasse: l'attaccante usava la shell per scrivere file, non per estrarre dati in massa. Questa discrepanza è una prova davvero rassicurante da poter mostrare a un proprietario preoccupato, ed è il tipo di informazione che i log di accesso ti danno gratis se sai leggere la dimensione della risposta, non solo il codice di stato.

L'endpoint ci ha portati a index.php. La copia del sito in produzione era stata ripulita a un certo punto (probabilmente da un precedente tentativo di recupero), ma un sito di sviluppo in una directory sorella che condivideva la stessa document root conservava ancora l'originale. Si apriva con un loader offuscato: una singola stringa letterale usata come alfabeto, con i nomi delle funzioni pericolose (create_function, assert, base64_decode) composti un carattere alla volta tramite indicizzazione, così da eludere qualunque grep ingenuo. Il loader decodificava un piccolo payload base64, costruiva a runtime una closure PHP eseguibile e la invocava. Il payload decodificato era la shell web stessa: qualsiasi richiesta in cui il parametro product_id corrispondeva a un hash MD5 hardcoded poteva eseguire tramite eval() PHP arbitrario passato nel parametro image_id. I nomi dei parametri sono scelti apposta per sembrare normale traffico e-commerce nei log.

Un dettaglio merita una frase a sé, perché è un vantaggio accidentale dell'aggiornamento: il loader dipende da create_function e dalla valutazione stringa di assert(), entrambi rimossi da PHP 8.0. Su un host moderno con PHP 8, questa backdoor andrebbe in fatal error da sola. Spostare questa base di codice a PHP 8 romperebbe involontariamente la shell: un motivo in più per cui la vera correzione è andare avanti, non di lato.

La cronologia e cosa implica

Non abbiamo potuto datare l'impianto originale della shell web: era precedente alla retention disponibile dei log. Ma il resto si ricostruisce in modo pulito da timestamp dei file e log di accesso:

Il divario di 25 giorni tra compromissione root e distribuzione dello skimmer è la riga più significativa della tabella. È coerente con accesso iniziale e monetizzazione come fasi separate: prima è arrivato l'accesso, poi, settimane dopo, il payload per sottrarre i dati delle carte. Da queste prove da sole non possiamo dimostrare se l'accesso sia stato venduto a un secondo gruppo o semplicemente messo in coda dallo stesso operatore che lavorava su una lista di bersagli; in ogni caso, per chi difende la lezione è la stessa: le settimane silenziose non sono sicurezza, sono un conto alla rovescia. Un negozio che intercetta l'intrusione durante quelle settimane non perde nulla; un negozio che aspetta il sintomo perde ogni carta elaborata nel frattempo.

Correzione, nell'ordine che conta

Due vincoli hanno guidato questo recupero, e sono gli stessi che affronta la maggior parte dei negozi reali. Il sito era in produzione e stava elaborando ordini, quindi non poteva restare offline per ore. E un aggiornamento 1.7.x → 8.x/9.x è un progetto di più settimane: compatibilità dei moduli, refactoring del tema, riconfigurazione dei pagamenti, non un lavoro da un giorno. Quindi il piano è stato contenimento e rafforzamento subito, con una ricostruzione pulita preparata in parallelo. La procedura operativa completa passo passo (conservazione delle prove, rotazione delle credenziali, ricerca di backdoor, blocco firewall degli IP C2, rimozione di strumenti admin esposti, messa a punto del WAF) è un documento a sé: la manteniamo come Checklist di rafforzamento della sicurezza PrestaShop perché resti aggiornata. Ciò che è specifico di questo incidente, e vale la pena portarsi a casa, è l'ordine e alcune mosse consapevoli di PrestaShop:

• Conserva le prove prima di toccare qualsiasi cosa. Fai uno snapshot del disco (o almeno un tar della radice web, di /etc e di /var/log), archivia i log di accesso e di errore e calcola sha256sum per ogni file sospetto. Ti serviranno per l'analisi post incidente, per eventuali richieste del processore di pagamento e per l'inevitabile secondo passaggio quando trovi una backdoor che ti era sfuggita.
• Ferma prima l'emorragia visibile ai clienti. Rimuovi l'iniezione PHP dai 13 file di configurazione, ripristina config/settings.inc.php da una copia pulita della stessa identica release PrestaShop (e concentra la rotazione di DB/cookie su app/config/parameters.php, dove PS 1.7+ conserva davvero quella configurazione), sostituisci l'intero albero themes/ da sorgente pulito e svuota ogni directory di cache e OPcache: altrimenti i bundle compilati continuano a servire lo skimmer, come sopra.
• Poi cerca persistenza su tutto l'host, non solo nella radice web. Poiché root è stato compromesso, gli artefatti pericolosi possono vivere in /etc/cron*, timer e unità systemd, ~/.ssh/authorized_keys di ogni utente, /etc/sudoers.d/, profili shell, file vhost e nella tabella MySQL mysql.user, oltre a eventuali nuovi eventi o trigger. Qualsiasi cosa modificata nella finestra di compromissione è sospetta.
• Rendi immutabili i file del punto di ingresso. Usa chattr +i su index.php e su tutti i file config/*.php. Una futura shell web non può riscrivere un file immutabile senza prima eseguire chattr -i, cosa che richiede root. (Avvertenza: funziona solo su filesystem che rispettano gli attributi estesi: ext4/xfs/btrfs vanno bene; alcuni setup container overlay e ZFS no.)

Una volta toccato root, la pulizia sul posto è contenimento, non cura; e se il vettore di reinfezione è una vulnerabilità applicativa non corretta invece di un file mancato, la procedura sopra non ti salverà. Quel problema a livello applicativo (patch virtuale di CVE specifiche, blocco dell'origine dietro Cloudflare, corretta limitazione del runtime PHP) è esattamente ciò che Rafforzamento avanzato di PrestaShop per negozi che non puoi ancora aggiornare tratta. E se i dati delle carte hanno raggiunto il C2 — presumilo finché non dimostri il contrario — gli obblighi di segnalazione al processore di pagamento iniziano immediatamente; la sequenza completa è nella nostra guida alla risposta a una violazione dei dati.

Indicatori di compromissione — cosa cercare con grep

Esegui la ricerca dalla root del negozio e tratta ogni risultato come prova da ispezionare, non come dimostrazione automatica in sé:

rg -n "order_llx|processF|smenu|cc_owner|cc_cid|CURLOPT_SSL_VERIFYPEER|base64_decode" \
  config themes modules

find config themes modules -type f \( -name '*.php' -o -name '*.js' \) -mtime -14 -ls

Se gestisci un negozio PrestaShop e vuoi controllare questa famiglia specifica, ecco il set ad alto segnale. Esegui grep ricorsivi ampi su uno snapshot o in modalità sola lettura quando puoi: una scansione pesante su una radice web trafficata può far salire l'I/O e attivare i suoi stessi avvisi.

E nel browser, sulla pagina di pagamento renderizzata: campi <input> grezzi con ID cc_owner, cardNumber, cardExpiry o cc_cid (i veri moduli Stripe/Adyen/Braintree usano iframe: gli input carta grezzi sono il segnale di allarme), cookie chiamati __Pres_idk o __Pres_ldk che vengono impostati, e un index.php che si apre con una variabile offuscata in stile <?php $e4d6=, singola lettera più esadecimale, subito dopo il tag di apertura. Il tag campagna Zhang (base64 Wmhhbmc=) compare nel payload di esfiltrazione, ma è troppo generico per essere affidabile da solo: dagli peso solo quando ricorre insieme a un altro indicatore sopra. Per scansioni più profonde, punta php-malware-finder, le regole YARA pubbliche di Sucuri/ESET o un monitor di integrità dei file (AIDE, Wazuh, OSSEC) alla radice web; ma salta gli scanner specifici per Magento, le loro firme non corrisponderanno a un attacco modellato su PrestaShop.

Di cosa parla davvero questo incidente

La shell web era la ferita. Lo skimmer era il sintomo visibile. Ripulire lo skimmer senza trovare la shell avrebbe lasciato la porta spalancata per ridistribuire lo stesso payload, o uno più intelligente, entro pochi giorni: ed è esattamente così che è avvenuta la reinfezione citata all'inizio di questo post. L'abitudine più importante che questo incidente insegna è continuare a tirare il filo: un modulo carta falso porta a file di configurazione iniettati, che portano a una trappola nei bundle compilati, che porta a binari SUID-root, che portano a una shell web in index.php. Fermati a qualunque livello prima dell'ultimo e hai ripulito un sintomo, non chiuso un attacco.

E se oggi stai usando PrestaShop 1.7.x, il quadro onesto è questo: sei un bersaglio, e gli exploit usati per piantare la shell originale sono vecchi di anni, noti e inclusi in scanner automatizzati. Migrare a un ramo PrestaShop supportato e completamente aggiornato — con tutti i moduli e i temi aggiornati e l'host ricostruito e rafforzato — è la strada durevole. Nel frattempo, realisticamente settimane o mesi per un negozio non banale, il rafforzamento nella checklist di rafforzamento e le misure a livello applicativo in rafforzamento avanzato per negozi che non puoi ancora aggiornare non ti rendono invincibile, ma insieme alzano il costo dell'attacco e, altrettanto importante, rendono un'intrusione abbastanza rumorosa da darti una reale possibilità di intercettarla durante le settimane silenziose, invece che dopo che le carte sono sparite.

Riferimenti ufficiali PrestaShop

Per le indicazioni ufficiali, consulta l'avviso di sicurezza di PrestaShop sugli skimmer digitali, il post del progetto su una grave vulnerabilità di sicurezza di PrestaShop, la nota del 2025 sugli attacchi SQL injection e JavaScript iniettato, e le best practice di sicurezza per il negozio di PrestaShop. Nessuno di questi documenti riporta questo specifico incidente, ma sono un contesto ufficiale utile per i controlli sugli skimmer, la rotazione delle credenziali e gli obblighi di escalation.

Domande frequenti

Come posso capire se la mia pagina di pagamento ha uno skimmer come questo?

Apri la pagina di pagamento in produzione in un browser, fai clic destro sui campi carta e ispezionali. Un modulo Stripe, Adyen o Braintree integrato correttamente mette gli input della carta dentro iframe cross-origin: la pagina padre non può leggerli. Se invece vedi campi <input> grezzi di prima parte, con ID come cardNumber, cc_owner o cc_cid, direttamente nella pagina, quello è il segnale di allarme. Poi esegui i grep nella sezione degli indicatori sopra su uno snapshot dei tuoi file. Un singolo risultato è qualcosa da ispezionare, non una prova automatica.

Ho rimosso il malware. Perché il modulo falso è tornato?

Due trappole specifiche di PrestaShop. Primo, la pipeline CCC incorpora gli script infetti nei bundle compilati sotto themes/<theme>/assets/cache/: finché non svuoti quella cache (più var/cache/, var/compile/ ed eventuali Redis/Memcached), il browser continua a ricevere lo skimmer dal bundle qualunque cosa tu faccia al sorgente. Secondo, e peggio: se il vettore di ingresso — una shell web, un modulo non aggiornato — è ancora aperto, l'attaccante ridistribuisce semplicemente il payload. Ripulire file è contenimento, non cura.

Abbiamo trovato binari SUID-root. Quanto è grave?

Creare un binario SUID-root richiede root: PHP eseguito come utente del sito non può farlo, per quanto siano bloccati disable_functions o open_basedir. La loro esistenza dimostra che è stato compromesso root, non solo l'utente web, quindi la persistenza può nascondersi ovunque sull'host. A quel punto l'unico stato finale pienamente difendibile è ricreare il server da un'immagine OS pulita, migrare codice e dati verificati come puliti e ruotare ogni segreto, trattando l'host originale come contenimento temporaneo.

I dati delle carte dei clienti sono stati davvero rubati?

In questo incidente, lo schema delle dimensioni delle risposte nei log di accesso suggeriva che la shell fosse usata per scrivere file, non per esportare in massa il database: un dump completo della tabella clienti avrebbe raggiunto centinaia di kilobyte e nulla si avvicinava. Ma lo skimmer nel browser è rimasto attivo per quasi due giorni, quindi ogni carta inserita nella pagina di pagamento in quella finestra va considerata catturata. Presumi l'esposizione finché non dimostri il contrario e avvia subito la segnalazione al processore di pagamento: la sequenza è nella nostra guida alla risposta a una violazione dei dati.

Sono ancora su 1.7.x e non posso aggiornare per mesi. E adesso?

Sei un bersaglio, e gli exploit usati qui sono vecchi di anni e inclusi in scanner automatizzati; ma nel frattempo non sei senza difese. Applica patch virtuali alle falle specifiche indicate dai tuoi log, blocca l'origine dietro un WAF, limita il runtime PHP e aggiungi monitoraggio dell'integrità dei file perché un secondo tentativo sia rumoroso. Il piano completo per la fase transitoria è rafforzamento avanzato per negozi che non puoi ancora aggiornare, con la base nella checklist di rafforzamento.

Continua a leggere

• Rafforzamento avanzato di PrestaShop per negozi che non puoi ancora aggiornare — chiudere il vettore a livello applicativo che questa bonifica ha contenuto ma mai chiuso.
• Rafforzamento della sicurezza PrestaShop: la checklist completa — la procedura operativa di base completa, mantenuta aggiornata.
• Risposta a una violazione dei dati: cosa fare se il tuo negozio viene hackerato — la sequenza delle prime ore, obblighi GDPR inclusi.