PrestaShop violato: come scoprire e rimuovere uno skimmer di carte

L'attacco peggiore è quello che non rompe nulla

Quando un negozio PrestaShop violato va in errore 500, chi lo gestisce se ne accorge nel giro di un'ora. Quando invece ospita uno skimmer, continua a funzionare alla perfezione: gli ordini arrivano, i clienti pagano e uno script iniettato nella pagina di pagamento copia in silenzio i numeri di carta verso un server esterno.

L'ondata osservata su PrestaShop all'inizio del 2026 segue questo schema. Il punto di ingresso non è quasi mai il core: è un modulo di terze parti non aggiornato, a volte installato anni prima e poi dimenticato.

Due conseguenze immediate: la perdita di conformità PCI DSS nei confronti del proprio gestore dei pagamenti e l'obbligo di notificare la violazione all'autorità di controllo — in Italia il Garante per la protezione dei dati personali — entro 72 ore, ai sensi dell'articolo 33 del GDPR.

I segnali che devono mettere in allarme

Nessuno di questi segnali è una prova di per sé, ma ognuno merita una verifica:

• alcuni clienti segnalano addebiti fraudolenti poco dopo un ordine sul suo sito;
• il suo gestore dei pagamenti la contatta per un tasso di frode anomalo;
• un file JavaScript del tema ha una data di modifica recente anche se non ha pubblicato nulla;
• nel codice sorgente della pagina d'ordine compare un tag <script> che punta a un dominio sconosciuto;
• Google Search Console segnala contenuti ingannevoli o pagine di spam indicizzate.

I domini usati per l'esfiltrazione imitano di proposito servizi legittimi: nomi che contengono cdn, analytics, jquery, tag-manager, su estensioni poco comuni. Un dominio che somiglia a Google senza essere google.com è il segnale più affidabile.

La diagnosi via SSH, in cinque comandi

File modificati negli ultimi sette giorni:

find . -type f -name "*.php" -mtime -7 -not -path "./var/cache/*"
find . -type f -name "*.js" -mtime -7 -not -path "./var/cache/*"

Codice offuscato nei temi e nei moduli:

grep -rl "eval(atob\|eval(String.fromCharCode\|_0x" themes/ modules/

Backdoor classiche:

grep -rl "eval(\$_POST\|assert(\$_REQUEST\|base64_decode(\$_" . --include="*.php"

Lato database, un'iniezione storica ben documentata consiste nell'infilare del JavaScript nel nome del negozio, che viene poi ristampato su tutte le pagine:

SELECT name, value FROM ps_configuration WHERE value LIKE '%<script%';
SELECT id_employee, email, active FROM ps_employee;

Un account dipendente che non riconosce, o un valore di configurazione che contiene HTML, valgono come conferma.

La procedura di bonifica

Ripulire un sito violato senza un ordine preciso garantisce la reinfezione. La sequenza conta.

1. Congelare la scena. Faccia una copia completa dei file e del database prima di toccare qualsiasi cosa. È l'unica prova a disposizione e l'unico modo per risalire al vettore di ingresso.

2. Fermare l'emorragia. Metta il negozio in manutenzione. Finché la pagina di pagamento è online, i numeri continuano a uscire.

3. Ripristinare il codice da una fonte sana. Riscarichi il core PrestaShop nella versione esatta installata e sovrascriva i file, conservando img/, upload/, download/, i moduli sviluppati su misura e config/settings.inc.php. Reinstalli ogni modulo di terze parti dal sito del suo editore, mai da un archivio trovato sul server.

4. Ripulire il database. Corregga i valori alterati in ps_configuration, elimini gli account dipendente sconosciuti e controlli le pagine CMS e le descrizioni prodotto che contengono <script>.

5. Rinnovare tutto. Password dei dipendenti, password del database, accessi FTP/SSH, chiavi API dei moduli di pagamento e chiavi crittografiche di config/settings.inc.php (_COOKIE_KEY_, _RIJNDAEL_KEY_). Rigenerare queste chiavi disconnette tutte le sessioni, compresa quella di chi ha attaccato.

6. Chiudere la porta d'ingresso. Senza questo passaggio la reinfezione arriva nel giro di pochi giorni. Aggiorni tutti i moduli, controlli per ciascuno i bollettini pubblicati da Friends-of-Presta e applichi le patch di sicurezza del core.

Irrobustire il negozio per il futuro

• Rinominare la cartella di amministrazione e proteggerla con un'autenticazione HTTP aggiuntiva.
• Vietare l'esecuzione di PHP in img/, upload/ e download/ dalla configurazione del server.
• Attivare l'autenticazione a due fattori su tutti gli account dipendente.
• Mettere in campo un web application firewall e un controllo dell'integrità dei file: un file PHP creato in modules/ deve far scattare un avviso.
• Fare un backup quotidiano, con una conservazione di almeno 30 giorni. Un backup di 7 giorni non serve a nulla di fronte a un'intrusione scoperta dopo tre settimane.

Se il suo negozio è stato compromesso attraverso un modulo di ricerca a faccette non aggiornato, legga anche la nostra analisi della vulnerabilità ps_facetedsearch.

Intervento d'urgenza

Ogni giorno in cui uno skimmer resta attivo costa di più. Analizziamo, bonifichiamo e mettiamo in sicurezza, con un rapporto scritto sul vettore di ingresso. Diagnosi gratuita, risposta entro 1 ora — ci contatti.