Il sito web NapoliBene.it era online, caricava regolarmente, riceveva traffico. Non c'era nessun avviso di Google, nessun reindirizzamento sospetto, nessun popup. Il sito sembrava funzionare perfettamente.
Era stato compromesso settimane prima.
Lo hanno scoperto solo quando un utente esterno, navigando da un dispositivo mobile, è stato reindirizzato verso un sito di spam. Da desktop, tutto normale. L'attacco era configurato per essere invisibile agli amministratori e visibile solo a certi visitatori — una tecnica chiamata cloaking condizionale, usata dagli hacker per restare inosservati il più a lungo possibile.
Questo articolo non parla dei segnali ovvi di un attacco — reindirizzamenti evidenti, schermata rossa di Google, sito offline. Di quelli si accorge chiunque. Parla dei 5 segnali invisibili che indicano una compromissione silenziosa, quelli che la maggior parte dei proprietari di siti non sa dove cercare.
Come funziona un attacco silenzioso
Gli attacchi che fanno notizia — sito offline, schermata Google "sito pericoloso", ransomware — sono in realtà quelli meno sofisticati. Un attaccante alle prime armi vuole visibilità immediata. Un attaccante competente vuole esattamente il contrario.
L'obiettivo di un attacco silenzioso non è distruggere il sito. È usarlo. Il tuo dominio ha autorità, ha traffico, ha anni di storia. Per un hacker è una risorsa preziosa da sfruttare senza bruciarla.
Le tecniche più comuni di compromissione silenziosa sono tre. La prima è la SEO spam injection: vengono inserite pagine o link nascosti che puntano a siti terzi (gioco d'azzardo, farmaci, truffe) per sfruttare la tua autorità di dominio. Queste pagine sono invisibili agli amministratori ma indicizzate da Google. La seconda è il cloaking condizionale: il codice malevolo si attiva solo per certi utenti — chi arriva da mobile, chi arriva da Google, chi non è loggato come admin. La terza è il credential harvesting: viene installato uno script che intercetta i dati inseriti nei form del tuo sito prima che vengano salvati nel database.
In tutti e tre i casi, il sito continua a funzionare normalmente per chi lo gestisce. I danni emergono settimane o mesi dopo.
Segnale 1: calo di traffico organico senza causa apparente
Un calo improvviso del traffico organico del 20-40% in pochi giorni, senza che tu abbia pubblicato o modificato nulla, è uno dei primi segnali di una penalizzazione Google per compromissione. Google scopre il malware o i link di spam prima che tu lo faccia — i suoi crawler scansionano il sito con frequenza molto maggiore di quanto tu verifichi manualmente.
Come verificarlo: entra in Google Search Console → sezione "Risultati della ricerca" → confronta i click degli ultimi 28 giorni con il periodo precedente. Se c'è un calo netto e non coincide con nessuna modifica al sito, vai in "Problemi di sicurezza" — trovi tutti gli avvisi che Google ha già rilevato.
Nota: un calo può avere cause diverse (aggiornamento algoritmo, stagionalità, concorrenza). Ma se coincide con un avviso in Search Console o con altri segnali di questa lista, la probabilità di compromissione è alta.
Segnale 2: pagine indicizzate che non hai creato
Questa è la firma più chiara di una SEO spam injection. L'hacker inserisce nel tuo sito decine o centinaia di pagine con contenuti di spam — spesso in lingue diverse, spesso con URL strutturati per sembrare legittimi — che Google indicizza normalmente.
Come verificarlo: vai su Google e cerca site:iltuodominio.it. Scorri i risultati. Se vedi pagine che non riconosci — con titoli strani, in lingue che non usi, su argomenti che non c'entrano niente con il tuo sito — il tuo sito è compromesso. Questo è esattamente il tipo di problema che avevano diversi siti Joomla che abbiamo migrato: Google indicizzava contenuti che i proprietari non avevano mai visto.
Puoi affinare la ricerca con site:iltuodominio.it viagra o site:iltuodominio.it casino — questi sono i termini più comuni nei siti spam iniettati. Se escono risultati, il problema è già grave.
Segnale 3: file modificati di recente senza interventi
Ogni webshell o backdoor installata da un hacker lascia una traccia: un file modificato o creato in una data in cui nessuno ha lavorato al sito. Su WordPress questo si vede nei file PHP della cartella wp-content, spesso con nomi innocui come functions-helper.php o cache-loader.php.
Come verificarlo via SSH o FTP: cerca i file modificati negli ultimi 30-60 giorni nelle cartelle principali del sito. Su SSH il comando è find /path/to/site -name "*.php" -mtime -30 -ls. Se trovi file PHP modificati in date in cui non hai fatto nessun aggiornamento, aprili e verificane il contenuto — un file con funzioni come eval(base64_decode(...)) o system($_GET['cmd']) è una webshell attiva.
Per approfondire come riconoscere e bloccare le webshell, abbiamo scritto una guida tecnica specifica: Webshell: cos'è, come funziona e come bloccarla.
Segnale 4: richieste HTTP anomale nei log del server
I log di accesso del server registrano ogni richiesta ricevuta. Un sito compromesso mostra pattern specifici: richieste ripetute a file PHP insoliti, accessi a percorsi che non esistono nel tuo sito (/wp-admin/admin-ajax.php su un sito Joomla, per esempio), richieste con parametri GET sospetti.
Come verificarlo: i log di accesso si trovano tipicamente in /var/log/apache2/access.log o /var/log/nginx/access.log, oppure sono accessibili dal pannello di controllo del tuo hosting. Cerca richieste con codice 200 (successo) verso file PHP che non conosci. Una concentrazione di richieste verso lo stesso file da IP diversi in breve tempo indica che qualcuno sta usando attivamente una backdoor.
Questo tipo di analisi richiede accesso SSH o un pannello hosting che esponga i log. Se non hai accesso, puoi chiedere al tuo provider — è un dato a cui hai diritto.
Segnale 5: comportamento diverso da mobile e da desktop
Il cloaking condizionale è la tecnica più sofisticata e quella che ha colpito NapoliBene. Il codice malevolo viene eseguito solo in certe condizioni: user agent mobile, referrer Google, utente non autenticato. Chi gestisce il sito — sempre loggato, sempre da desktop — non vede mai il problema.
Come verificarlo: usa Google Search Console → sezione "Ispezione URL" → "Visualizza come Google". Questo ti mostra esattamente cosa vede il crawler di Google quando visita le tue pagine. Se quello che vedi lì è diverso da quello che vedi nel browser, c'è cloaking.
Un secondo metodo: usa il tuo smartphone con una connessione dati (non WiFi di casa) e visita il sito da una ricerca Google, non digitando l'URL direttamente. Questa è la condizione più simile a quella di un utente normale che arriva organicamente — ed è spesso quella che attiva il redirect malevolo.
Come verificare in 10 minuti con strumenti gratuiti
Checklist rapida da eseguire subito:
1. Google Search Console → Problemi di sicurezza — se Google ha già rilevato qualcosa, lo trovi qui. Accesso gratuito, dati immediati.
2. Google Safe Browsing Transparency Report — inserisci il tuo dominio su transparencyreport.google.com/safe-browsing/search. Risultato in 10 secondi.
3. Ricerca site: su Google — site:iltuodominio.it — scorri le prime 5 pagine di risultati. Pagine che non riconosci sono un segnale immediato.
4. Sucuri SiteCheck — sitecheck.sucuri.net — scanner gratuito che controlla malware noto e blacklist. Non è esaustivo ma è un primo filtro utile.
5. Visualizzazione da mobile su rete dati — accedi al sito come utente organico, non come amministratore.
Se uno di questi cinque controlli restituisce qualcosa di anomalo, il passo successivo è un'analisi tecnica approfondita — non un "ripristino di emergenza" che rimuove i sintomi senza trovare la causa.
Perché alcuni CMS sono strutturalmente più esposti
La SEO spam injection, il cloaking condizionale e le backdoor PHP hanno una cosa in comune: sfruttano il file system aperto e l'ecosistema di plugin di un CMS open source. Su WordPress, un plugin vulnerabile con 200.000 installazioni attive è un vettore di attacco che colpisce 200.000 siti in parallelo entro ore dalla scoperta della falla.
Non è un problema risolvibile con Wordfence o con un altro plugin di sicurezza — come abbiamo analizzato in dettaglio nell'articolo Sito hackerato? Quanto ti costa davvero. Un WAF applicativo che opera dentro la stessa installazione che sta cercando di proteggere ha un limite strutturale preciso: può essere disabilitato dallo stesso vettore che sfrutta.
La differenza con un CMS proprietario chiuso — senza ecosistema di plugin pubblici, senza codice sorgente analizzabile — è che non esiste una superficie di attacco standardizzata. Un attaccante non può scrivere uno script che cerca "tutti i siti con il plugin X vulnerabile" perché quel plugin non esiste. La protezione di KeideaCMS è integrata nell'architettura, non aggiunta sopra.
Se hai eseguito i controlli di questa guida e hai trovato qualcosa di anomalo — o se semplicemente non riesci a verificare perché non hai accesso ai log — l'audit gratuito che offriamo analizza lo stack attuale, identifica le vulnerabilità concrete e ti mostra cosa sta succedendo realmente sul tuo sito.
