Un sito compromesso non si presenta sempre con un “black screen” o un defacement evidente. Spesso la compromissione sfrutta il tuo progetto come infrastruttura: inserisce pagine spam, inietta link nascosti, crea redirect condizionali, aggiunge utenti amministrativi, oppure lascia una backdoor pronta a riattivarsi dopo il primo intervento.
Il risultato è una combinazione di danni tecnici e reputazionali: utenti esposti a contenuti pericolosi, cali di traffico organico, messaggi di sicurezza in Search Console, peggioramento dei segnali di qualità e, nei casi peggiori, blocchi di browser e motori di ricerca.
In una situazione del genere, “ripristinare” non è sinonimo di “risolvere”. Un ripristino veloce da backup può rimettere online il sito, ma se il backup è già contaminato o se il punto d’ingresso resta aperto (plugin vulnerabile, credenziali rubate, computer amministrativo infetto), la compromissione torna in poche ore.
Inoltre, quando entra in gioco la SEO spam, la bonifica deve coprire due livelli: server/CMS (file e database) e visibilità su Google (indice e avvisi). Senza il secondo livello, il sito può rimanere associato a contenuti indesiderati anche dopo la pulizia.
Serve quindi un percorso disciplinato: prima contenimento e tutela degli utenti, poi diagnosi affidabile, quindi ripristino pulito con controlli post-restore, infine hardening e monitoraggio.
Le indicazioni che seguono privilegiano azioni verificabili e strumenti ufficiali, con esempi pratici utili sia su WordPress sia su CMS equivalenti. Dove è necessario, trovi riferimenti a risorse operative utili per organizzare un intervento che regga anche a distanza di settimane.
Cosa fare subito: priorità operative nei primi 30–60 minuti
Quando sospetti una compromissione, il rischio più grande è continuare a operare “come se nulla fosse”. Ogni minuto in cui il sito resta esposto può amplificare lo spam indicizzato, aumentare la probabilità di phishing verso i visitatori e permettere all’attaccante di consolidare l’accesso (nuove backdoor, nuovi utenti, nuove chiavi).
Le prime azioni hanno tre obiettivi: contenere, mettere in sicurezza gli accessi, preservare informazioni utili. La pulizia vera e propria viene dopo: intervenire subito su file e database senza una minima raccolta di evidenze può rendere più difficile individuare la causa e può portare a recidive.
Isolamento rapido: ridurre l’esposizione senza distruggere il sistema
Scegli una modalità proporzionata al rischio:
- Modalità manutenzione (pagina statica) se il sito non gestisce dati sensibili e vuoi limitare danni SEO e UX.
- Accesso limitato a IP specifici o con autenticazione aggiuntiva se devi continuare a fare verifiche in ambiente live.
- Messa offline temporanea quando ci sono pagamenti, account utenti, aree riservate o segnali di phishing/malware.
L’obiettivo non è restare offline a lungo, ma impedire che utenti e crawler finiscano su contenuti pericolosi mentre la bonifica è in corso.
Se il dominio mostra avvisi di sicurezza nei browser, ridurre subito l’esposizione può contenere ulteriori segnalazioni.
Mappa degli accessi e blocco dei canali più a rischio
Prima di cambiare password a raffica, crea un elenco degli accessi che, se compromessi, consentono di rientrare:
- account amministratori del CMS
- pannello hosting
- FTP/SFTP/SSH
- database
- email utilizzate per reset password
Un dettaglio spesso trascurato: verifica che i dispositivi usati per amministrare il sito siano puliti (scansione completa, aggiornamenti di sicurezza) prima della rotazione credenziali. In caso contrario, le nuove password possono essere sottratte e l’intervento perde efficacia.
Snapshot completo: copia di file e database
Prima di rimuovere o sostituire file:
- esporta una copia del database
- crea un archivio dei file dell’applicazione
- salva log disponibili (web server, accessi, errori, audit)
Questa copia serve per confronti (diff), per individuare file introdotti o modificati, e per ricostruire il vettore d’attacco. Anche senza un’analisi forense completa, avere una baseline dell’incidente evita decisioni “a tentativi”.
Comunicazione minima, ma corretta
Se gestisci account, ordini o dati personali, allinea subito le figure coinvolte (privacy/legale/customer care).
Non serve lanciare comunicazioni pubbliche senza evidenze, ma serve evitare risposte incoerenti nel caso in cui utenti segnalino anomalie.
Come capire se il sito è stato compromesso: controlli tecnici e controlli Google
Un sito può essere compromesso anche quando “sembra funzionare”. È frequente che l’attaccante mostri contenuti puliti agli amministratori e contenuti spam ai crawler, oppure attivi redirect solo da mobile, solo da traffico organico, o solo con user-agent specifici.
Per questo la verifica non può basarsi su un solo test o su un solo tool. Una diagnosi affidabile unisce: segnali lato CMS/server, controlli in Search Console e verifiche esterne come Safe Browsing.
Segnali tipici che indicano compromissione (anche parziale)
Osserva se compaiono uno o più di questi elementi:
- redirect verso domini estranei (soprattutto da smartphone o da SERP)
- pagine con keyword non pertinenti (farmaceutico, betting, “guadagna denaro”)
- file nuovi in directory “scrivibili” (upload, cache, tmp)
- nuovi utenti amministratori o ruoli elevati
- modifiche recenti a
functions.php, template, file di plugin - email di reset password non richieste o notifiche di login insolite
Dal punto di vista operativo, redirect e SEO spam sono spesso più insidiosi del defacement: non interrompono il servizio e vengono scoperti tardi.
Verifica con Search Console: perché è un punto di partenza forte
Il Report “Problemi di sicurezza” in Search Console fornisce categorie di rischio e URL di esempio.
Se compaiono “iniezione di contenuti” o “iniezione di URL”, l’impatto riguarda anche la visibilità organica e serve una bonifica completa, non limitata a pochi file.
Per una prima ricognizione delle pagine indicizzate, abbina una ricerca site:tuodominio.tld per individuare URL non creati da te.
Safe Browsing: utile, ma non sufficiente
La verifica in Safe Browsing/Transparency Report aiuta a capire se il dominio è segnalato come non sicuro e se i browser potrebbero mostrare avvisi. Tuttavia, un esito “pulito” non esclude compromissioni basate su spam: serve sempre un controllo mirato in Search Console e lato server.
Controlli su server e CMS che sbloccano la diagnosi
Se hai log e accessi:
- cerca picchi di richieste a endpoint di login e API
- verifica errori 500/404 anomali su URL non noti
- controlla file modificati nelle ultime 24–72 ore (poi estendi la finestra)
- confronta file core del CMS con versioni ufficiali
Su WordPress, un indicatore comune è la presenza di file PHP in wp-content/uploads o in cartelle che dovrebbero contenere solo media.
Altrettanto frequenti sono “file gemelli”: nomi simili a file legittimi, con una lettera cambiata.
Ripristino da backup: procedura pulita, controlli post-restore e riapertura controllata
Il ripristino da backup è spesso la strada più rapida per tornare operativi, ma “rapido” non significa “sicuro”.
Un backup può essere già compromesso, oppure può ripristinare il sito senza eliminare il punto d’ingresso.
Il ripristino corretto richiede tre cose: selezione rigorosa del punto di ripristino, procedura coerente (file + database), validazione post-restore prima di riaprire tutto al traffico.
Selezione del backup: criterio temporale e criterio tecnico
Il criterio temporale è semplice: scegli un backup precedente ai primi segnali (email di allarme, avvisi Search Console, redirect segnalati, picchi di pagine indicizzate).
Se non conosci la data, lavora a ritroso: ripristina su staging un backup recente e controlla; se trovi spam o file sospetti, torna a un backup più vecchio.
Il criterio tecnico è altrettanto importante: un backup pulito deve essere seguito da aggiornamenti e da controlli di integrità.
Se il primo tentativo non risolve, è normale dover arretrare ulteriormente con la data.
Procedura consigliata (WordPress e CMS analoghi)
- Ambiente di test (staging) quando possibile: riduce il rischio di reinfezione e permette controlli senza pressione.
- Ripristino coerente di file e database della stessa data: evitare mix riduce comportamenti imprevedibili.
- Sostituzione dei file core con copia ufficiale del CMS (se applicabile): rimuove modifiche non autorizzate nel core.
- Aggiornamento immediato di core, plugin e temi.
- Scansione e controllo di directory scrivibili: upload, cache, temp, logs.
- Verifica utenti e ruoli: rimuovere amministratori non riconosciuti, controllare email e data creazione.
Validazione post-restore: cosa controllare prima di riaprire
Prima di rimettere tutto online:
- esegui una ricerca
site:e controlla URL sospetti (anche quelli fuori sitemap) - verifica redirect lato server e lato applicazione
- controlla header HTTP e script inclusi (soprattutto in header/footer)
- usa il controllo URL in Search Console su un campione di pagine strategiche
Se riapri senza validazione, rischi di reintrodurre cloaking o spam non visibile dal tuo browser.
Rotazione credenziali: momento giusto e ordine giusto
La rotazione password è indispensabile, ma va fatta al momento giusto:
- prima assicurati che i dispositivi amministrativi siano puliti (scansione completa, aggiornamenti)
- poi ruota credenziali: CMS, pannello, FTP/SFTP/SSH, database, email
SEO spam: identificazione completa, rimozione e ripristino reputazionale
La SEO spam è una compromissione orientata al profitto: l’attaccante inserisce contenuti e link per posizionarsi con keyword estranee sfruttando l’autorevolezza del tuo dominio.
Il sito può restare apparentemente “ok”, mentre l’indice di Google si riempie di pagine farmaceutiche, betting o truffe.
Questo comporta cali di traffico, peggioramento della fiducia e, in alcuni casi, avvisi in SERP.
Come riconoscere la SEO spam senza affidarsi a un solo segnale
Un primo controllo efficace è la ricerca site:tuodominio.tld insieme a keyword sospette.
Il Report Problemi di sicurezza in Search Console può indicare categorie come “iniezione di contenuti” o “iniezione di URL”, che corrispondono a due modalità tipiche: modifica di pagine esistenti o creazione di nuove pagine.
Cloaking e contenuti invisibili agli amministratori
In presenza di cloaking potresti vedere una pagina pulita mentre Google vede parole e link spam. In questi casi:
- prova user-agent diversi
- verifica pagine da una macchina non autenticata
- usa controllo URL e osserva come Google recupera la pagina
Rimozione corretta: server, database e segnali Google
Una rimozione completa richiede quattro livelli:
- Eliminare il vettore: backdoor, plugin vulnerabile, credenziali compromesse.
- Ripulire contenuti e template: header/footer, file del tema, widget, include di script.
- Ripulire database: spesso lo spam è in tabelle post/opzioni o campi serializzati.
- Richiedere revisione nel report di sicurezza dopo aver verificato che la bonifica è totale.
Quando serve guadagnare tempo, lo Strumento per le rimozioni può nascondere temporaneamente URL dai risultati, ma non sostituisce la bonifica: gli URL vanno rimossi o ripristinati in modo definitivo.
Dopo la bonifica: stabilizzare SEO e prevenire ricomparsa
- rigenera sitemap e includi solo URL legittimi.
- controlla
robots.txt, meta robots e canonical. - monitora crescita pagine indicizzate e query anomale.
Messa in sicurezza dopo il ripristino: hardening verificabile e monitoraggio continuo
Dopo la pulizia, la domanda giusta non è “posso rilassarmi?”, ma “cosa impedisce la stessa compromissione domani?”.
Gli attaccanti tendono a rientrare sfruttando la stessa vulnerabilità: plugin non aggiornato, credenziali riutilizzate, permessi troppo aperti, assenza di monitoraggio.
Qui servono misure concrete e misurabili, con una routine che mantenga stabile il livello di sicurezza nel tempo.
Aggiornamenti e gestione del rischio plugin
- aggiorna core, temi e plugin con una routine calendarizzata
- rimuovi componenti inutilizzati (anche se disattivati)
- sostituisci plugin abbandonati con alternative mantenute
Per organizzare il lavoro in modo sistematico: checklist completa per proteggere un sito WordPress.
Credenziali e 2FA: ridurre il valore di una password rubata
- password uniche, lunghe e non riutilizzate
- 2FA su account amministrativi
- policy di condivisione e archiviazione tramite password manager
Approfondimenti utili: come gestire le credenziali in modo sicuro e VPN e password manager per privacy e sicurezza.
Permessi, integrità dei file e monitoraggio
- permessi file e ownership coerenti (minimo necessario)
- disabilita l’editor file del CMS quando non serve
- imposta monitoraggio file e alert su modifiche sospette
Protezioni applicative
- limitazione tentativi di login
- WAF e regole anti-bot
- hardening di endpoint esposti
Per una panoramica pratica: plugin di sicurezza per WordPress.
Errori tipici che fanno fallire la bonifica (e come evitarli)
Gli incidenti si trascinano per giorni quasi sempre per gli stessi motivi: sequenza sbagliata, bonifica incompleta, fiducia eccessiva in un singolo tool, o mancanza di validazione prima della riapertura.
Evitare questi errori riduce il tempo totale di ripristino e abbassa la probabilità che il problema si ripresenti.
Errori frequenti
- ripristinare un backup senza verificare che sia precedente ai primi segnali
- ripristinare senza aggiornare subito core/plugin/temi
- cambiare password prima di controllare i PC usati per amministrare
- rimuovere solo alcuni URL segnalati, ignorando pattern ripetuti
- lasciare plugin/temi non necessari installati
- ignorare i log e non cercare il punto d’ingresso
Soglie pratiche per coinvolgere un professionista
- infezione che ritorna dopo ripristino e aggiornamento
- cloaking complesso o SEO spam con migliaia di URL
- presenza di pagine ingannevoli, phishing o malware distribuito
- coinvolgimento di dati personali o pagamenti
Riepilogo operativo (checklist rapida)
- Isola il sito (manutenzione/accesso limitato).
- Esegui snapshot di file + database + log.
- Verifica con Search Console (Problemi di sicurezza) e ricerche
site:. - Seleziona un backup precedente ai primi segnali e testalo in staging.
- Ripristina file + database coerenti; sostituisci core con copia ufficiale quando serve.
- Aggiorna core/plugin/temi; rimuovi componenti inutili.
- Controlla utenti/ruoli, directory scrivibili e file sospetti.
- Rimuovi SEO spam e richiedi revisione in Search Console.
- Hardening: 2FA, permessi, monitoraggio file, WAF, routine aggiornamenti.
FAQ
1) Conviene mettere offline il sito appena sospetto un attacco?
Se il sito può esporre utenti a malware/phishing o gestisce dati sensibili, limitare o sospendere l’accesso è una scelta prudente. In altri casi può bastare una modalità manutenzione con accesso ristretto per fare verifiche in sicurezza.
2) Qual è il controllo più affidabile per capire se Google ha rilevato una compromissione?
Il Report Problemi di sicurezza in Search Console è la fonte principale: mostra le categorie rilevate e URL di esempio. In presenza di cloaking, affianca ricerche site: e controllo URL per osservare ciò che Google vede.
3) Ripristinare un backup elimina sempre malware e spam?
No. Se il backup è già compromesso o se resta aperto il punto d’ingresso (plugin vulnerabile o credenziali rubate), la compromissione può tornare. Serve scegliere un backup precedente ai primi segnali, aggiornare tutto e validare prima della riapertura.
4) Che differenza c’è tra malware e SEO spam?
Il malware tende a distribuire codice pericoloso o a compromettere la macchina dell’utente. La SEO spam mira a sfruttare il dominio per posizionare pagine e link su keyword estranee. Entrambi richiedono bonifica, ma la SEO spam richiede anche pulizia dell’indice e dei segnali SEO.
5) Dopo la pulizia, quanto tempo serve per far sparire gli avvisi?
Dopo aver risolto il problema, Search Console consente di richiedere una revisione nel report di sicurezza. I tempi variano in base al tipo di segnalazione e alla verifica effettuata.
Lascia un commento