Risposta a una violazione dei dati: cosa fare se il tuo negozio viene hackerato

Il momento peggiore per capire qual è il tuo piano di risposta agli incidenti è alle 2 di notte, davanti a un'email di un cliente che dice "il tuo pagamento mi ha addebitato due volte la carta e ora ricevo SMS di phishing". Se gestisci un negozio PrestaShop abbastanza a lungo, esiste una possibilità concreta di subire una compromissione — i negozi piccoli e medi vengono colpiti di continuo, non perché siano presi di mira uno per uno, ma perché scanner automatici sparano exploit noti di PrestaShop e dei moduli su tutto il web e provano ogni porta rimasta aperta. Questa guida è il runbook per il momento dopo l'allarme: una sequenza calma e ordinata di cosa controllare, cosa conservare e quali punti specifici di PrestaShop l'attaccante ha quasi certamente toccato. Non è volutamente una guida di prevenzione — se sei qui prima che qualcosa sia andato storto, parti invece dalla checklist di hardening della sicurezza PrestaShop.

Leggila una volta adesso, mentre non c'è nessuna emergenza in corso. Il principale fattore che determina un ripristino pulito è conoscere l'ordine delle operazioni prima di averne bisogno.

Revisionato a giugno 2026 rispetto alle attuali strutture di file e database di PrestaShop 1.6, 1.7, 8 e 9, e alla regola GDPR di notifica delle violazioni entro 72 ore in vigore al momento della scrittura.

Prima di toccare qualsiasi cosa: conserva le prove

Una lente d'ingrandimento passa su una griglia di icone luminose di file e cartelle, alcune evidenziate in arancione.

Se hai accesso shell, copia i file, il database e i log prima di eliminare qualsiasi cosa. Adatta il nome del database e i percorsi al tuo hosting.

#!/usr/bin/env bash
set -euo pipefail

stamp=$(date +%F-%H%M%S)
case_dir="/root/prestashop-incident-$stamp"
mkdir -p "$case_dir"

tar --xattrs --acls -czf "$case_dir/files.tgz" /var/www/html
mysqldump --single-transaction --routines --triggers prestashop > "$case_dir/database.sql"
cp -a /var/log/nginx /var/log/apache2 /var/log/php* "$case_dir/" 2>/dev/null || true

sha256sum "$case_dir"/* > "$case_dir/SHA256SUMS"
chmod -R go-rwx ";$case_dir

L'istinto è entrare nel back office e iniziare a eliminare i file sospetti. Resisti. Nel momento in cui inizi a modificare le cose, distruggi la traccia che ti dice come sono entrati — e se non trovi il punto di ingresso, verrai compromesso di nuovo nel giro di pochi giorni. La tua prima azione è copiare, non pulire.

Fai uno snapshot completo prima di qualsiasi bonifica:

• L'intera web root — la directory PrestaShop, inclusi i file nascosti (.htaccess, .user.ini). Gli attaccanti li adorano perché poche persone li controllano.
• Un dump del database — esegui mysqldump dell'intero database. L'iniezione spesso vive nel database, non solo su disco (vedi sotto).
• I log — log di accesso/errore del server web (/var/log/nginx/ o /var/log/apache2/), log PHP-FPM e i log propri di PrestaShop in var/logs/ (PS 1.7+) o log/ (PS 1.6). I log ruotano e spariscono; prendili per primi.

Conserva quello snapshot in un posto che l'attaccante non possa raggiungere — il tuo laptop o un nuovo bucket di storage, non una seconda cartella sullo stesso server compromesso. Questo snapshot è ciò che il team abuse del tuo hosting, un professionista forense o una pratica di assicurazione cyber ti chiederanno, ed è l'unico modo per ricostruire una cronologia in seguito.

Contieni l'emorragia senza distruggere la scena

Contenimento e analisi forense tirano in direzioni opposte: vuoi fermare il danno, ma staccare la spina può cancellare prove volatili (sessioni attive, processi dell'attaccante). L'equilibrio per un negozio tipico: rendi il front office offline per i clienti, ma mantieni il server in esecuzione così puoi investigare.

PrestaShop ha una modalità manutenzione integrata. Nel back office vai su Shop Parameters → General → Maintenance (PS 1.7/8/9) e disattiva il negozio, poi aggiungi il tuo IP al campo Maintenance IP così puoi continuare a lavorare mentre i clienti vedono una pagina di attesa. I flag sottostanti sono PS_SHOP_ENABLE e PS_MAINTENANCE_IP nella tabella ps_configuration — utili se il back office stesso è bloccato o deturpato e devi modificarli direttamente nel database.

Se i dati di pagamento potrebbero essere coinvolti, la modalità manutenzione non basta — e non iniziare prima a frugare tra i file. Due chiamate hanno la priorità su qualsiasi attività tecnica:

• Il tuo provider di pagamento. Stripe, PayPal, Mollie, Adyen, la tua banca acquirer — chiunque gestisca gli incassi. Hanno team antifrode che possono monitorare pattern di test delle carte e segnalare le carte coinvolte. Se nella procedura di pagamento è stato iniettato uno skimmer di carte, è così che le carte esposte vengono monitorate prima che siano abusate.
• Il tuo hosting. Molte compromissioni partono dall'account di hosting, non dall'installazione PrestaShop, e il provider può vedere cose che tu non puoi vedere (altri siti sullo stesso account, spam in uscita, il cron che mina criptovalute).

Dove si nascondono davvero gli attaccanti in PrestaShop

Questa è la parte che gli articoli generici del tipo "sei stato hackerato" saltano, ed è il punto decisivo. Sapere in quali punti specifici vivono le infezioni PrestaShop trasforma un disperato "scansiona tutto" in una ricerca mirata. In ordine approssimativo di frequenza con cui li vediamo:

Una prima scansione pratica sul server: elenca ogni file PHP modificato negli ultimi 30 giorni e leggi ciascuno di quelli che non riconosci. Dalla web root, find . -name "*.php" -mtime -30 -ls fa emergere i file toccati di recente; confrontali con una copia pulita della stessa versione di PrestaShop (scarica la release esatta dal sito ufficiale) così puoi distinguere i file core da quelli manomessi. Presta particolare attenzione a qualsiasi PHP presente sotto img/ o upload/ — quelle directory non dovrebbero mai contenere PHP eseguibile, e una singola riga nel tuo .htaccess che nega l'esecuzione PHP lì è uno dei miglioramenti di hardening più economici una volta che sei pulito.

Inserisci un piccolo .htaccess in ciascuna directory di upload (img/, upload/, download/) così, anche se una shell dovesse arrivare di nuovo lì, il server si rifiuta di eseguirla. Su Apache 2.4:

# img/.htaccess (and upload/, download/) — refuse to execute PHP
<FilesMatch "\.(php|php\d|phtml|phar)$">
    Require all denied
</FilesMatch>
php_flag engine off

Questo è contenimento, non una correzione: impedisce a una web shell piazzata sul server di essere eseguita, ma non risolve in alcun modo il modo in cui il file è stato scritto in primo luogo — ed è a questo che serve la ricerca del punto di ingresso qui sotto.

Per il lato database, esporta la tabella e confronta con grep il tuo elenco ps_employee con le persone che lavorano davvero per te, poi cerca nei contenuti CMS/configurazione <script, base64_decode, eval( e domini esterni che non riconosci. Se la violazione si rivela nello specifico uno skimmer nella procedura di pagamento, vale la pena capire in dettaglio la meccanica di come è entrato e di come sottrae le carte — ne abbiamo analizzato uno reale in anatomia di un attacco in stile Magecart su un negozio PrestaShop.

Chiudi le porte: ruotare ogni credenziale che l'attaccante potrebbe avere

Presumi che l'attaccante abbia una copia di tutto ciò che poteva leggere, e ruota tutto. Su PrestaShop, "tutto" è più lungo di quanto molti si aspettino, e dimenticare un solo elemento significa lasciargli rientrare dalla porta principale:

• Ogni password dei dipendenti del back office — ed elimina ogni account di cui non sai spiegare l'origine. Forza il reset per tutto il team, non solo per te.
• Le credenziali del database in config/settings.inc.php (PS 1.6) o app/config/parameters.php (PS 1.7+). Cambia la password dell'utente MySQL e aggiorna il file nella stessa operazione.
• Le chiavi dei cookie — le costanti _COOKIE_KEY_/_COOKIE_IV_ in settings.inc.php su PS 1.6, oppure i valori cookie_key/cookie_iv (e new_cookie_key dove presente su PS 8/9) in parameters.php su PS 1.7+. Se sono trapelate, i vecchi cookie di sessione admin potrebbero essere ancora validi. Ruotare solo le chiavi non basta: dopo la rotazione, svuota le sessioni attive lato server e la cache, poi obbliga ogni dipendente a disconnettersi e a reimpostare la password — è questo che uccide davvero la sessione dell'attaccante.
• Accessi FTP/SFTP, SSH e al pannello di hosting — una password FTP rubata è il modo più comune in cui un sito "pulito" viene reinfettato nel giro di ore.
• Qualsiasi chiave API / segreto webhook per integrazioni di pagamento e spedizione salvati nella configurazione dei moduli.

Una volta ruotate le credenziali, questo è il momento per chiudere la porta definitivamente con l'autenticazione a due fattori sul back office, così una password trapelata da sola non basta più — il procedimento è in autenticazione a due fattori, policy password e sicurezza admin per PrestaShop. Se l'indagine ha mostrato che l'attacco è arrivato martellando il login o tramite IP abusivi, aggiungere blocchi IP e reCAPTCHA sul modulo di login mitiga i tentativi automatici di accesso. Non trattarlo però come una soluzione completa — reCAPTCHA può essere aggirato e non fa nulla contro il credential stuffing con una password rubata valida, quindi abbinalo a 2FA, rate limiting e limitazione per IP, password dipendenti robuste e uniche, e monitoraggio dei log.

Il conto alla rovescia delle 72 ore: i tuoi obblighi GDPR

Se il tuo negozio ha clienti europei — e se spedisci nell'UE o usi un processore di pagamento europeo, li ha — il GDPR trasforma un incidente tecnico in un fatto legale con una scadenza rigida. La regola che coglie molti di sorpresa: hai 72 ore dal momento in cui vieni a conoscenza della violazione per notificarla alla tua autorità di controllo (l'autorità per la protezione dei dati nel tuo Paese), salvo che sia improbabile che la violazione presenti un rischio per i diritti delle persone. Una violazione che coinvolge password, indirizzi o dati di pagamento dei clienti supera facilmente quella soglia, quindi pianifica la notifica.

Se è probabile che la violazione comporti un rischio elevato per le persone — e di nuovo, dati di pagamento e password rientrano nel caso — devi anche avvisare direttamente i clienti interessati, con un linguaggio chiaro, spiegando cosa è successo, quali dati sono coinvolti, cosa stai facendo e cosa dovrebbero fare loro (cambiare la password, controllare gli estratti conto, aspettarsi phishing che faccia riferimento alla violazione). È esattamente per questo che lo snapshot delle prove del primo passaggio conta: non puoi scrivere una notifica onesta se hai distrutto i dati che ti dicono cosa è stato realmente accessibile. Il conto alla rovescia delle 72 ore parte quando ne diventi consapevole, non quando finisci l'indagine — quindi spesso la notifica parte mentre la bonifica è ancora in corso, con un aggiornamento successivo quando sai di più. È consentito ed è previsto.

Una nota pratica facile da dimenticare: questo conto alla rovescia corre in parallelo con tutto il resto della guida. Contenimento, analisi forense e notifica legale avvengono nello stesso momento, ed è il motivo principale per tenere un registro continuo, con timestamp, di ogni azione che compi dalla prima ora. Quel registro è sia la tua cronologia forense sia la prova della tua diligenza se un'autorità te la chiede.

Informare i clienti senza peggiorare la situazione

I clienti perdonano il negozio che li ha avvisati per primo e disprezzano quello di cui hanno saputo dalla banca o dalle notizie. Il compito della notifica è essere onesta e utile, non minimizzare. Spiega cosa è successo in termini comprensibili, esattamente quali dati loro sono stati coinvolti e quali azioni specifiche dovrebbero compiere — e indirizza le risposte verso un canale che non sommerga il supporto ordinario. Un indirizzo dedicato alla risposta alla violazione tiene le email allarmate del tipo "sono stato coinvolto?" fuori dalla coda delle domande sugli ordini.

Preparati anche agli opportunisti: le notifiche di violazione attirano i phisher che si fingeranno te per "aiutare i clienti a reimpostare la password". Spiega nella notifica esattamente quale canale userai e che non chiederai mai la loro password — costa una frase e previene una seconda ondata di vittime.

Non ripristinare l'infezione: ricostruire da uno stato pulito

L'errore più comune nel ripristino è ricaricare il backup della notte precedente. Se l'attaccante era dentro da due settimane, il backup di ieri notte contiene anche la backdoor — ripristinerai la compromissione e la riscoprirai il mese prossimo. Lavora a ritroso dallo snapshot per identificare quando è comparso il primo file malevolo o la prima riga dipendente sospetta, poi ripristina da un backup precedente oppure, in modo più affidabile, ricostruisci pulito:

• Reinstalla il core PrestaShop da un download fresco della tua versione esatta — sostituisci in blocco i file core invece di provare a pulirli chirurgicamente.
• Reinstalla ogni modulo dalla sua fonte originale (lo sviluppatore, non la tua copia forse manomessa). Tutto ciò che non riesci a reperire in modo pulito va eliminato.
• Riapplica solo i file override/ e le modifiche al tema di cui puoi spiegare con certezza l'origine.
• Migra i dati (ordini, clienti, prodotti) dal database, ma solo dopo averli ripuliti con grep da payload iniettati.

Questo è anche il momento di sistemare la tua strategia di backup così che una ricostruzione pulita sia davvero possibile la prossima volta: backup giornalieri automatici, salvati fuori dal server di produzione, con una retention sufficiente (pensa a 30+ giorni) per risalire oltre una compromissione lenta e silenziosa. Un backup che torna indietro solo di tre giorni è inutile contro un attaccante rimasto quieto per due settimane.

Dopo che la polvere si è posata: chiudi definitivamente il vettore

Hai trovato il punto di ingresso durante l'analisi forense — ora chiudilo in modo permanente, perché la ricompromissione attraverso la stessa falla è il seguito più comune dopo una violazione. La correzione dipende da ciò che ha trovato l'indagine:

• PrestaShop obsoleto o un modulo vulnerabile? Aggiorna. Se davvero non puoi ancora aggiornare il core (una realtà frequente su negozi 1.6/1.7 molto personalizzati), il virtual patching ti permette di bloccare l'exploit noto al livello della richiesta senza toccare il codice — ne parliamo in hardening avanzato per i negozi che non puoi ancora aggiornare.
• Password admin debole o riutilizzata? Policy password più 2FA, come nella guida alla sicurezza admin.
• Sicurezza del trasporto mancante o un .htaccess permissivo? Configura correttamente HTTPS (configurazione SSL/HTTPS) e blocca le regole del server (regole di sicurezza .htaccess), inclusa la negazione dell'esecuzione PHP nelle directory di upload.
• Non sai nemmeno da dove iniziare con l'hardening? La guida in linguaggio semplice per non sviluppatori è mettere in sicurezza il tuo negozio PrestaShop, mentre la versione esaustiva è la checklist di hardening della sicurezza.

Domande frequenti

Come faccio a sapere se il mio negozio PrestaShop è stato davvero hackerato o se è solo spam?

Cerca le cose che uno spammer non può falsificare: una riga ps_employee che non hai creato, file PHP modificati negli ultimi giorni che non hai toccato (find . -name "*.php" -mtime -7), PHP eseguibile sotto img/ o upload/, <script o base64_decode inattesi nelle pagine CMS o nella configurazione, oppure il tuo negozio che reindirizza i visitatori altrove ma non te. Carrelli spazzatura e spam nei moduli fanno rumore ma sono innocui; nuovi account admin, script iniettati e file core manomessi sono una compromissione.

Devo mettere subito offline il negozio?

Rendi il front office offline per i clienti con la modalità manutenzione, ma tieni il server in esecuzione così puoi investigare. Spegnere l'intera macchina cancella prove volatili (sessioni attive, processi dell'attaccante) prima che tu abbia capito come sono entrati — e senza il punto di ingresso, verrai reinfettato nel giro di pochi giorni. L'unica eccezione è uno skimmer di carte attivo nella procedura di pagamento: lì viene prima fermare l'emorragia per i clienti, e chiami in parallelo il tuo provider di pagamento.

Non posso semplicemente ripristinare il backup di ieri notte e andare avanti?

Di solito no. Se l'attaccante era dentro da due settimane, il backup di ieri notte contiene anche la backdoor, quindi ripristineresti la compromissione e la riscopriresti il mese prossimo. Lavora a ritroso dallo snapshot delle prove per trovare quando è apparso il primo file malevolo o la prima riga dipendente sospetta, poi ripristina da un backup precedente — oppure, in modo più affidabile, ricostruisci pulito da un nuovo download del core e dalle fonti originali dei moduli, migrando solo i dati che hai verificato puliti con grep.

Devo segnalare la violazione a qualcuno?

Se il tuo negozio ha clienti nell'UE e la violazione ha toccato dati personali (password, indirizzi, dati di pagamento), il GDPR ti dà 72 ore dal momento in cui ne vieni a conoscenza per avvisare la tua autorità di controllo, e devi informare direttamente i clienti interessati se il rischio per loro è elevato. Il conto alla rovescia parte quando ne diventi consapevole, non quando finisci l'indagine, quindi la prima notifica spesso viene inviata mentre la bonifica è ancora in corso, con un aggiornamento successivo. È normale.

Come impedisco che succeda di nuovo?

Chiudi il vettore esatto che la tua analisi forense ha individuato — aggiorna il core o il modulo obsoleto, elimina la password admin debole, correggi la directory di upload permissiva — perché la ricompromissione attraverso la stessa falla è il seguito più comune dopo una violazione. Poi aggiungi gli strati che rendono più difficile il prossimo tentativo: 2FA sul back office, backup fuori server con 30+ giorni di retention e la più ampia checklist di hardening.

La parte davvero difficile del recupero dopo una violazione non è la pulizia — è sapere quando hai davvero chiuso ogni porta, perché una backdoor mancata significa rifare tutto da capo. Se preferisci non portare da solo quell'incertezza, il nostro team costruisce e verifica negozi PrestaShop ogni giorno e lavora direttamente con i commercianti proprio su incidenti di questo tipo — senza intermediari, senza strati di rivenditori. Quindi che cosa ottieni? Un secondo paio di occhi che sa dove si nascondono le infezioni PrestaShop, così puoi riaprire il front office con la certezza che sia davvero pulito, invece di sperarlo.

Un'ultima cosa, ed è quella che conta di più: scrivi che cosa hai fatto, in ordine, con i timestamp, nel momento in cui l'emergenza immediata è rientrata. Quel registro è la tua prova GDPR, la base per la richiesta assicurativa e — quando lo rileggerai con calma la settimana prossima — l'audit di sicurezza più onesto che avrai mai del tuo negozio. La maggior parte delle violazioni risale a un aggiornamento rimandato o a una password condivisa da tutti. Non è sfortuna: è la lista di cose da fare che ora non hai più scuse per ignorare.