Sicurezza web: controlli rapidi quando sospetti una compromissione

Diagnosi probabile

Quando si sospetta una compromissione, le cause più comuni sono tre: credenziali rubate (pannello hosting, FTP, SSH, CMS), vulnerabilità note in plugin, temi o componenti server, oppure upload malevoli che hanno aggiunto backdoor, web shell o redirect nascosti. In molti casi il primo segnale non è un messaggio d’errore evidente, ma un cambiamento anomalo: file modificati di recente, traffico verso domini sconosciuti, redirect intermittenti, nuovi utenti amministratori o attività croniche non autorizzate.

In ambito hosting e web server, un’infezione può restare silente a lungo. Il sito continua a rispondere, ma serve spam, mostra contenuti alterati, invia richieste esterne o viene usato per distribuire malware. Per questo la priorità non è “ripulire subito a caso”, ma stabilizzare, raccogliere evidenze e capire se l’attacco è ancora attivo.

Se il sito è in produzione, tratta il caso come un incidente: prima contenimento e verifica, poi bonifica, infine ripristino controllato.

Verifiche immediate

1. Controlla se il comportamento anomalo è reale e ripetibile. Apri il sito da una finestra in incognito, da rete diversa e con un test semplice: homepage, login, una pagina interna, eventuale checkout o form. Esito atteso: l’anomalia deve essere osservabile in modo coerente, non solo sul browser locale o con cache attiva.
2. Verifica gli ultimi cambiamenti. Controlla aggiornamenti recenti di CMS, plugin, temi, pannelli e credenziali. Se hai accesso al pannello hosting o al CMS, cerca utenti nuovi, permessi elevati, cron job sconosciuti, redirect o modifiche recenti a file critici. Esito atteso: individuare una finestra temporale plausibile dell’intrusione.
3. Osserva i sintomi tipici di compromissione. Cerca redirect verso domini esterni, popup o script non previsti, file PHP in cartelle di upload, pagine che restituiscono contenuti diversi in base all’user agent, e-mail inviate senza autorizzazione, consumo insolito di CPU o processi web anomali. Esito atteso: almeno un indizio concreto che distingua un problema di cache da una reale alterazione.
4. Controlla i log essenziali. Se hai accesso al server, verifica i log del web server, PHP e autenticazioni. Cerca richieste ripetute a file sospetti, accessi da IP insoliti, errori di permessi e tentativi di login falliti o riusciti in orari anomali. Esito atteso: trovare correlazione tra accesso sospetto e modifica dei file.

Indicatori pratici da non ignorare

• Nuovi file PHP in cartelle come uploads, cache o tmp.
• File con nomi casuali, offuscati o simili a librerie legittime ma con contenuto anomalo.
• Modifiche a .htaccess, wp-config.php, index.php o file di bootstrap del sito.
• Utenti admin non riconosciuti nel CMS o nel pannello hosting.
• Invii SMTP, code mail o bounce insoliti, spesso segno di spam automatizzato.

Soluzione consigliata passo-passo

1. Contieni l’incidente senza distruggere prove. Se il sito è attivamente compromesso, mettilo temporaneamente in manutenzione o limita l’accesso solo al tuo IP, se possibile. Evita di cancellare subito file sospetti: prima copiane una copia per analisi. Se usi un pannello come cPanel, Plesk o FastPanel, la via più sicura è attivare una pagina di manutenzione o una protezione temporanea con password. Esito atteso: riduzione dell’impatto esterno e conservazione delle evidenze.
2. Fai un backup completo prima di intervenire. Salva file e database in una copia separata, preferibilmente fuori dal web root. Include anche configurazioni, cron e log recenti se disponibili. Questo passaggio è fondamentale perché una bonifica fatta senza backup può rendere impossibile ricostruire la catena dell’infezione. Esito atteso: avere un punto di rollback verificabile.
3. Cambia subito le credenziali più sensibili. Aggiorna password di pannello hosting, FTP/SFTP, SSH, database, CMS e caselle email collegate. Se usi chiavi SSH condivise o account multipli, revoca quelli non necessari. Se sospetti furto di sessione, disconnetti tutte le sessioni attive del CMS e del pannello. Esito atteso: bloccare l’accesso persistente dell’attaccante.
4. Individua e rimuovi il vettore iniziale. Verifica aggiornamenti mancanti, plugin o temi abbandonati, credenziali deboli, file caricati tramite form non protetti e permessi troppo permissivi. Se il problema nasce da WordPress o CMS simili, disattiva temporaneamente componenti recenti e confronta i file core con una copia pulita della stessa versione. Esito atteso: trovare il punto di ingresso più probabile, non solo il sintomo.
5. Bonifica i file alterati. Ripristina da backup pulito i file core del CMS e sostituisci i file modificati in modo sospetto con versioni note e verificabili. Controlla in particolare file di bootstrap, configurazione e directory di upload. Se trovi file PHP dove non dovrebbero esserci, trattali come altamente sospetti. Esito atteso: eliminare web shell, backdoor e redirect malevoli.
6. Pulisci database e contenuti dinamici. Cerca inserimenti anomali in tabelle di opzioni, widget, post, snippet, redirect o account amministratore. Molti attacchi web non vivono solo nei file, ma anche nel database. Esito atteso: rimuovere codice o record malevoli che ricreano l’infezione dopo il ripristino dei file.
7. Rivedi permessi e configurazioni. Imposta permessi ragionevoli su file e directory, verifica che il web server non possa scrivere dove non serve e controlla che .htaccess, regole di rewrite e config del vhost non contengano direttive sospette. Esito atteso: ridurre la superficie di reinfezione.
8. Verifica persistenza e automazioni. Controlla cron job, task schedulati, servizi di startup e script in cartelle temporanee. Gli attaccanti usano spesso meccanismi di persistenza per ricreare il malware a ogni intervallo o riavvio. Esito atteso: nessun processo automatico sconosciuto rimasto attivo.
9. Confronta il sito con una copia pulita. Se disponibile, usa un confronto file per individuare differenze non giustificate tra installazione sana e compromessa. Questo è spesso il modo più rapido per scoprire modifiche in file apparentemente innocui. Esito atteso: lista chiara di file da sostituire o analizzare.
10. Applica hardening minimo subito dopo la bonifica. Aggiorna CMS, plugin, tema e componenti server; disabilita ciò che non serve; abilita MFA dove possibile; limita accessi amministrativi; imposta backup automatici e monitoraggio. Esito atteso: riduzione concreta del rischio di reinfezione.

Controlli tecnici utili su server Linux

Se hai shell, puoi fare una prima verifica non distruttiva per individuare file recenti o sospetti. I comandi seguenti non modificano nulla e servono solo per raccogliere evidenze.

find /var/www -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.js' \) -mtime -7 | head -200

Esito atteso: elenco dei file modificati negli ultimi 7 giorni, utile per restringere il perimetro.

grep -RniE 'base64_decode|gzinflate|shell_exec|system\(|passthru|eval\(' /var/www 2>/dev/null | head -200

Esito atteso: eventuali pattern sospetti, da valutare con cautela perché possono comparire anche in codice legittimo offuscato o in librerie note.

find /var/www -type f -name '.htaccess' -o -name 'wp-config.php' -o -name 'config.php' -o -name 'index.php' -print

Esito atteso: elenco dei file critici da controllare manualmente per redirect, inclusioni remote o credenziali esposte.

Controlli finali / rollback

1. Verifica funzionale post-bonifica. Riapri il sito in incognito, controlla homepage, login, form, area admin e contenuti dinamici. Esito atteso: nessun redirect, nessun codice inatteso e nessun errore anomalo.
2. Riesegui un controllo dei log. Dopo la pulizia, osserva per alcune ore se compaiono nuove richieste sospette, nuovi tentativi di login o file che tornano a modificarsi. Esito atteso: assenza di persistenza attiva.
3. Monitora e conferma il ripristino. Attiva alert su modifiche file, accessi admin e invii mail. Se il problema ricompare, ripristina il backup pulito preso prima della bonifica e blocca temporaneamente i servizi interessati per una nuova analisi. Esito atteso: rollback disponibile e verificabile nel caso in cui la rimozione manuale non sia stata completa.
4. Conserva le evidenze. Archivia copia dei file sospetti, log e data/ora dei cambiamenti per eventuale analisi forense o confronto con il provider. Esito atteso: materiale sufficiente per capire il vettore iniziale e prevenire una nuova compromissione.

Assunzione: le verifiche proposte sono pensate per un sito web o un server Linux con accesso al pannello hosting o a una shell amministrativa.