PrestaShop hackerato o compromesso: segnali, verifica e bonifica

PrestaShop hackerato o compromesso: segnali, verifica e bonifica

PrestaShop hackerato cosa fare: se nota redirect sospetti, blacklist Google o ordini anomali, il sito è compromesso. Agisca subito: modalità manutenzione, cambio password, backup completo prima di toccare file, poi verifica di file modificati, moduli sconosciuti e accessi admin. Non basta ripulire il sintomo, serve trovare la causa.

Il cliente le scrive che il sito lo reindirizza a un dominio russo. Search Console segnala "sito compromesso". Nel back office compaiono ordini con indirizzi email inesistenti o account admin che non ha mai creato lei. Non è paranoia, è il momento di agire con metodo, non con il panico.

Pensi al suo e-commerce come al negozio fisico che gestisce da anni: se una notte qualcuno forza la serratura, non basta rimettere a posto la vetrina rotta e riaprire il giorno dopo. Deve capire come sono entrati, se hanno copiato le chiavi, se hanno lasciato una porta sul retro aperta. Con un sito hackerato è identico: il sintomo visibile è quasi sempre la parte più piccola del problema.

I segnali che il tuo PrestaShop è stato compromesso

Prima di tutto, capiamo se siamo davvero di fronte a una compromissione o a un malfunzionamento normale. Nei negozi che seguo, questi sono i sintomi che ricorrono quasi sempre insieme:

• Redirect strani: il sito, o solo alcune pagine, rimandano a domini esterni (farmacie online, casinò, phishing). Spesso capita solo su mobile o solo arrivando da Google, per restare invisibili a chi naviga da desktop.
• Blacklist Google o browser warning: Chrome mostra "Il sito potrebbe danneggiare il computer" oppure Search Console segnala "Contenuto pirata rilevato" o "Malware rilevato".
• Ordini o clienti anomali: ordini a importo zero, email inesistenti, transazioni ripetute con carte di test, account creati a decine in poche ore.
• File modificati che non ricorda di aver toccato: file .php con data recente in cartelle che dovrebbero essere statiche, tipo /img, /upload, /themes.
• Rallentamenti improvvisi o picchi di CPU: spesso segno di script che inviano spam o fanno mining in background.
• Moduli che non riconosce nell'elenco di Moduli > Gestione moduli, magari con nomi generici tipo ps_facebook2 o smtp_config.

Un segnale isolato non è automaticamente una condanna. Ma se ne trova due o tre insieme, il problema è reale e va verificato subito, non ignorato sperando che passi da solo.

Perché succede: le cause reali

Nella maggior parte dei casi che analizzo, la compromissione di un PrestaShop nasce da una di queste quattro strade:

1. Moduli o temi nulled/piratati: file scaricati gratis da siti terzi che contengono già una backdoor incorporata. È di gran lunga la causa numero uno.
2. Versione di PrestaShop o di un modulo obsoleta, con una vulnerabilità nota pubblicamente (CVE) mai patchata.
3. Credenziali deboli o riutilizzate: password admin uguale a quella di altri servizi, nessuna 2FA, accesso FTP salvato in chiaro su un client compromesso.
4. Hosting condiviso compromesso: un altro sito sullo stesso server è stato violato e l'attaccante si è mosso lateralmente.

Capire quale di queste cause si applica al suo caso specifico è ciò che fa la differenza tra "ripulire" e "risolvere davvero". Se non elimina la causa, il problema torna entro pochi giorni: è come cambiare la serratura ma lasciare la finestra del retro aperta.

Come verificare seriamente (non la pulizia superficiale)

Qui serve metodo. Non basta guardare l'homepage e dire "sembra a posto". Ecco i passi concreti di diagnosi, con i comandi reali.

1. File modificati di recente

Se ha accesso SSH al server, il primo comando da lanciare confronta la data di modifica dei file con l'ultima release ufficiale installata:

find /var/www/html -type f -name "*.php" -mtime -7 -print

Questo elenca tutti i file .php modificati negli ultimi 7 giorni. Se compaiono file dentro /img, /upload, /download o dentro cartelle di temi che non ha toccato di recente, è un campanello d'allarme serio: quelle cartelle non dovrebbero mai contenere PHP eseguibile.

2. Cerca pattern tipici di malware

Un secondo controllo utile è cercare funzioni PHP che i malware usano quasi sempre per offuscare il codice:

grep -r "eval(base64_decode" /var/www/html --include=*.php
grep -r "system(" /var/www/html --include=*.php
grep -r "gzinflate" /var/www/html --include=*.php

Non tutti i risultati sono malevoli — alcuni moduli legittimi usano eval per motivi propri — ma se trova questi pattern in file dentro /themes, /modules con nomi strani o in file isolati fuori contesto, molto probabilmente ha trovato la backdoor.

3. Controlla i log di errore

PrestaShop scrive errori applicativi in var/logs/ (versioni 1.7 e 8). Vale la pena controllare:

tail -n 200 var/logs/prod.log
tail -n 200 var/logs/error.log

Cerchi righe con chiamate a file inesistenti, tentativi di accesso a controller admin non standard, o errori ripetuti da bot che tentano SQL injection o brute force sul login.

4. Moduli e admin: cosa non deve esserci

Vada in Moduli > Gestione moduli e scorra l'elenco completo, non solo quelli installati e attivi. Ogni modulo che non riconosce va isolato: rinomini la cartella in modules/ aggiungendo _disabled per disattivarlo senza cancellarlo, utile per l'analisi successiva.

Controlli anche gli account amministratore in Parametri Negozio > Amministrazione > Team: cerchi profili creati in date che non corrispondono a nessuna assunzione o collaborazione reale. Un attaccante che ottiene accesso spesso crea un secondo account admin come "riserva" per rientrare anche dopo che lei ha cambiato la password del primo.

5. Un controllo lato database

Se ha accesso a phpMyAdmin o al database via terminale, una query utile per individuare admin sospetti:

SELECT id_employee, firstname, lastname, email, date_add
FROM ps_employee
ORDER BY date_add DESC LIMIT 10;

Confronti le date con la sua memoria: se c'è un employee creato la notte in cui sono iniziati i redirect, ha trovato un pezzo importante del puzzle.

Cosa fare SUBITO, nella prima ora

Prima ancora di completare la diagnosi, ci sono azioni da fare immediatamente per limitare il danno:

1. Metta il sito in modalità manutenzione da Parametri Negozio > Manutenzione, per evitare che nuovi clienti vedano redirect o warning mentre indaga.
2. Cambi tutte le password: admin PrestaShop, FTP/SFTP, database, pannello hosting, email collegate. Se una password era condivisa altrove, la cambi ovunque.
3. Faccia un backup completo — file e database — prima di toccare o cancellare qualsiasi cosa. Anche se contiene il malware, le serve come prova e come base di lavoro: non si cancella mai la scena senza prima fotografarla.
4. Revochi le sessioni admin attive e rigeneri eventuali token API o chiavi di integrazione esposte.
5. Avvisi l'hosting: se è condiviso, chieda un controllo lato server, perché il problema potrebbe non essere solo suo.

Bonifica seria vs pulizia superficiale

Qui arriva il punto più importante di tutto l'articolo, quello che quasi sempre viene sbagliato: cancellare il file malevolo che ha trovato non significa aver risolto il problema.

È come scoprire un topo in dispensa, prenderlo ed eliminarlo, ma non chiudere il buco nel muro da cui è entrato. Torna, e la volta dopo porta amici. Un attaccante che è riuscito a entrare una volta lascia quasi sempre più di una backdoor: un file nascosto in una cartella di cache, un account admin dormiente, una modifica nel file .htaccess, un cron job malevolo lato server.

La pulizia superficiale — rimuovere il redirect visibile, disinstallare il primo modulo sospetto trovato — risolve il sintomo per qualche giorno. La bonifica seria richiede:

• Diff completo di tutti i file rispetto a un'installazione pulita della stessa versione di PrestaShop.
• Controllo di cron job e task pianificati lato server, non solo lato applicazione.
• Verifica di .htaccess, robots.txt e file di configurazione per redirect o direttive nascoste.
• Rigenerazione di tutte le chiavi di sicurezza in app/config/parameters.php.
• Verifica che il malware non si sia propagato ad altri account sullo stesso hosting.

La differenza tra "sintomo rimosso per pochi giorni" e "causa eliminata" è esattamente questa lista. Se salta anche un solo punto, la sensazione di sicurezza è illusoria.

Quando serve un esperto

Le dico onestamente una cosa che in pochi le diranno: senza esperienza di analisi forense su un sito compromesso, il rischio concreto è di peggiorare la situazione. Cancellare file legittimi per errore, mandare offline funzionalità critiche, convincersi di aver risolto quando in realtà è rimasta una backdoor che si riattiva due settimane dopo — magari proprio durante un picco vendite.

Se ha competenze tecniche solide e tempo per fare con calma tutti i controlli sopra, può provarci. Ma se il suo e-commerce genera fatturato ogni giorno che resta offline o in blacklist, il costo di un'analisi fatta male quasi sempre supera di gran lunga il costo di farla fare bene una volta sola. Nei casi più gravi — sito completamente down o inaccessibile in urgenza — un intervento rapido e mirato fa la differenza tra riaprire in giornata o restare fermi per settimane.

Prevenzione: come evitare che ricapiti

Una volta bonificato il sito, la parte di prevenzione è quella che davvero fa risparmiare tempo e stress futuri:

• Aggiornamenti regolari di PrestaShop, moduli e tema, con cadenza fissa mensile, non solo "quando c'è tempo".
• Autenticazione a due fattori (2FA) su tutti gli account admin, senza eccezioni.
• Solo moduli da fonti ufficiali: mai temi o moduli "nulled" scaricati gratis, la causa numero uno delle compromissioni che vedo.
• Backup automatici e testati, non solo salvati: un backup mai ripristinato per prova non è un backup, è una speranza.
• Monitoraggio dei file critici con un tool di file integrity monitoring, per essere avvisati appena qualcosa cambia senza il suo intervento.
• Limitare gli accessi admin per IP quando possibile, e rimuovere subito gli account di collaboratori che non lavorano più con lei.

Una parte di questi controlli si può integrare in un piano di manutenzione continuativo, insieme a monitoraggio SEO e assistenza tecnica costante: è il modo più solido per non ritrovarsi da capo tra sei mesi. Se vuole approfondire anche il lato commerciale del suo negozio, può leggere anche la nostra guida su come recuperare i carrelli abbandonati o quella su come impostare correttamente un audit CRO del proprio e-commerce, utile anche dopo una bonifica per capire se l'attacco ha lasciato effetti collaterali su conversioni e UX.

Se vuole andare sul sicuro

Se dopo aver letto questo articolo si rende conto che la diagnosi richiede più tempo o competenze di quelle che ha a disposizione ora, esiste una strada più diretta: l'Audit Tecnico Approfondito PrestaShop (497 €) è pensato esattamente per questi casi. In 24-48 ore individuo la causa reale della compromissione — non il sintomo — con un report tecnico dettagliato su cosa è successo, cosa va bonificato e come evitare che si ripeta.

Non è la strada obbligata: se preferisce seguire i passi di questo articolo da solo, ha già tutto il necessario per iniziare. Ma se il tempo che sta perdendo a indagare vale più di 497 €, è un calcolo che vale la pena fare.

Domande frequenti

Come faccio a sapere se il mio PrestaShop è davvero hackerato o è solo un errore normale?

Un singolo errore isolato non basta a dire che è compromesso. Se però trova insieme redirect strani, ordini anomali e file .php modificati in cartelle statiche, la probabilità che sia un attacco reale è alta e va verificata subito con i comandi indicati sopra.

Posso ripristinare un backup precedente per risolvere subito?

Solo se sa con certezza che quel backup è precedente alla compromissione e non contiene già la backdoor. In caso contrario rischia di reintrodurre lo stesso problema dopo pochi giorni, senza aver capito come sono entrati.

Quanto tempo serve per bonificare seriamente un sito compromesso?

Dipende dalla profondità della compromissione: una pulizia superficiale richiede poche ore, ma una bonifica seria — con diff completo dei file, controllo cron e rigenerazione chiavi — richiede in genere 24-48 ore di lavoro mirato.

Devo denunciare l'attacco o avvisare qualcuno?

Se sono stati sottratti dati di clienti (email, indirizzi, dati di pagamento), la normativa privacy prevede obblighi di notifica. Consulti un legale o il suo DPO se ne ha uno, indipendentemente dalla bonifica tecnica.

Cambiare solo la password admin basta a bloccare l'attaccante?

No. Se l'attaccante ha creato un secondo account admin o installato una backdoor via file, cambiare una sola password non serve a nulla: deve verificare l'intero elenco Team e tutti i file modificati di recente.

Conclusione

Un PrestaShop compromesso non si risolve con la fortuna o con un plugin di sicurezza installato all'ultimo minuto: si risolve con metodo, verifica reale e, quando serve, con l'aiuto di chi questi casi li ha già visti. Se ha bisogno di una diagnosi completa e affidabile in tempi rapidi, visiti francescoingrosso.com e valuti l'Audit Tecnico Approfondito PrestaShop: 497 €, causa individuata in 24-48 ore, nessun altro impegno richiesto.