Sito WordPress compromesso: primi controlli e sicurezza

I sintomi possono includere redirect indesiderati, pagine spam, nuovi amministratori, file PHP sconosciuti, email inviate dal sito, avvisi del browser, modifiche a tema o plugin e consumo anomalo di risorse. Un sito WordPress compromesso richiede una procedura ordinata per evitare di perdere dati o distruggere elementi utili alla diagnosi.

Segnali che possono indicare una compromissione

• redirect verso siti esterni o pubblicità;
• pagine e risultati spam indicizzati;
• utenti amministratori non riconosciuti;
• plugin o temi installati senza autorizzazione;
• file PHP recenti in cartelle insolite;
• modifiche ripetute a .htaccess, wp-config.php o file del tema;
• email indesiderate inviate dall’account;
• avvisi Imunify360 o del browser;
• picchi CPU, processi e richieste anomale;
• impossibilità di accedere all’amministrazione.

Un singolo errore non prova necessariamente un attacco. Registra il sintomo, l’URL, data e ora prima di modificare il sito.

Metti temporaneamente il sito in sicurezza

Se il sito distribuisce contenuti dannosi, reindirizza i visitatori o espone dati, valuta una pagina di manutenzione o una limitazione temporanea degli accessi. Non utilizzare però una pagina WordPress se WordPress stesso è compromesso: la protezione dovrebbe avvenire a livello server o tramite una copia statica sicura.

Non disattivare indiscriminatamente firewall, Imunify360 o protezioni. Se il problema è attivo, apri subito un ticket Xlogic indicando il dominio e il comportamento osservato.

Conserva prove e backup dello stato compromesso

Prima della pulizia crea una copia di file e database con data e ora. Il backup compromesso non deve sostituire una copia pulita, ma può aiutare a:

• confrontare file e timestamp;
• identificare il vettore di accesso;
• recuperare contenuti recenti;
• fornire elementi all’assistenza;
• verificare se l’infezione ricompare.

Non distribuire pubblicamente l’archivio: può contenere password, chiavi, dati personali e codice malevolo.

Cambia le credenziali da un dispositivo affidabile

Dopo aver verificato che il computer amministrativo non sia compromesso, cambia:

• password degli amministratori WordPress;
• password cPanel e account FTP/SFTP;
• password database quando necessario;
• password delle caselle usate dal sito;
• chiavi API e token esposti nella configurazione;
• credenziali dei servizi esterni collegati.

Non riutilizzare la vecchia password e non limitarti ad aggiungere un carattere. Attiva l’autenticazione a due fattori dove disponibile.

Controlla gli utenti WordPress

Apri Utenti e verifica tutti gli amministratori. Controlla email, data di registrazione e ruoli. Rimuovi o declassa soltanto gli account che hai identificato come non autorizzati.

Con WP-CLI puoi elencare gli utenti:

wp user list --fields=ID,user_login,user_email,roles,user_registered

Non eliminare un utente senza decidere a chi attribuire i suoi contenuti.

Verifica l’integrità del core WordPress

WP-CLI può confrontare i file del core con i checksum ufficiali:

wp core verify-checksums

File core modificati o aggiuntivi richiedono verifica. La sostituzione del core con una copia ufficiale della stessa versione può rimuovere alterazioni, ma non pulisce plugin, temi, upload o database.

Non sovrascrivere wp-content o wp-config.php come se fossero file core standard.

Controlla plugin e temi

Elenca componenti, versioni e stato:

wp plugin list
wp theme list

Rimuovi plugin e temi non utilizzati, ma conserva prima le informazioni necessarie. Reinstalla componenti legittimi da sorgenti ufficiali o dal fornitore originale. Non scaricare copie “nulled” o archivi provenienti da siti non verificati.

Un componente aggiornato dopo la compromissione può eliminare la vulnerabilità ma non necessariamente i file già inseriti dall’attaccante.

Esamina file recenti e percorsi anomali

Controlla le date senza assumere che ogni file recente sia malevolo:

find /percorso/del/sito -type f -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' | sort

Presta attenzione a file PHP in uploads, nomi simili a file di sistema, directory nascoste, file con estensioni doppie e modifiche a file di avvio. I timestamp possono essere alterati, quindi il controllo non è sufficiente da solo.

Leggi gli avvisi Imunify360 senza cancellare alla cieca

Se l’interfaccia mostra file segnalati, annota percorso, stato e data. Un avviso deve essere verificato nel contesto del sito. Non eliminare automaticamente un file di tema, plugin o applicazione senza sapere se è legittimo e senza una copia.

Non è necessario avviare scansioni manuali: utilizza le informazioni disponibili e contatta l’assistenza quando il pannello non consente l’azione necessaria o sospetti un falso positivo. Consulta Imunify360: file segnalati e falsi positivi.

Controlla wp-config.php e chiavi di sicurezza

Verifica che wp-config.php non contenga inclusioni sconosciute, codice offuscato o URL esterni. Dopo il contenimento rigenera le salt di WordPress per invalidare le sessioni esistenti. Controlla anche eventuali costanti che abilitano debug pubblico o modificano URL e percorsi.

Non pubblicare il contenuto completo di wp-config.php in un ticket o forum: contiene credenziali database e chiavi.

Controlla database, cron e attività pianificate

Una compromissione può persistere nel database o tramite eventi pianificati. Controlla:

• opzioni con script o URL esterni;
• widget e contenuti modificati;
• utenti e ruoli;
• eventi WP-Cron sconosciuti;
• cron job cPanel aggiunti;
• Action Scheduler e code anomale;
• plugin must-use nella directory mu-plugins.

Non cancellare tabelle o opzioni in blocco. Crea prima un backup e identifica il componente proprietario.

Ripristinare un backup pulito

Un backup precedente può essere la soluzione più sicura soltanto se è realmente antecedente alla compromissione. Dopo il ripristino devi comunque:

• aggiornare WordPress, plugin e temi;
• cambiare le credenziali;
• rimuovere componenti vulnerabili o inutilizzati;
• controllare utenti e attività pianificate;
• verificare che il problema non ricompaia.

Consulta le guide JetBackup 5 presenti nella KB per file, database e account.

Hardening dopo la pulizia

• mantieni aggiornati core, plugin e temi;
• usa password uniche e autenticazione a due fattori;
• elimina componenti inutilizzati;
• limita gli amministratori;
• utilizza HTTPS e fonti ufficiali;
• mantieni backup separati e verificati;
• monitora modifiche, errori e risorse;
• non condividere credenziali nei ticket.

La sicurezza non si conclude con la rimozione del file visibile: bisogna eliminare il vettore di ingresso e ogni meccanismo di persistenza.

Quando aprire un ticket Xlogic

Apri subito un ticket se il sito distribuisce malware, invia spam, mostra redirect, non consente l’accesso o presenta segnalazioni che non sai interpretare. Indica dominio, URL interessati, data e ora, screenshot, percorsi dei file segnalati e modifiche recenti.

Non inviare password, codici 2FA, chiavi private, contenuto completo di wp-config.php o archivi del sito tramite canali non concordati.

Fonti tecniche ufficiali

• WordPress: My site was hacked
• WordPress: Hardening
• WordPress: security checks with WP-CLI

Domande frequenti su WordPress compromesso