Chi cerca un servizio di rimozione malware di solito lo fa nel momento peggiore: il sito rimanda a pagine di truffe, Google mostra un avviso rosso, il fornitore di hosting ha sospeso l’account. In quelle condizioni la tentazione è affidarsi al primo che promette «sito pulito in un’ora» e a un prezzo basso. Qualche volta va bene. Spesso, dopo una settimana, l’infezione torna uguale, perché è stato rimosso il sintomo e non la causa.
Una bonifica ben fatta non si riconosce dal sito che torna a funzionare, ma da tre cose che il cliente riceve alla fine: la spiegazione di come l’attaccante è entrato, l’elenco di tutto ciò che è stato trovato e rimosso, e una garanzia con condizioni chiare.
Questa è una guida per chi deve scegliere, scritta da chi fa questo lavoro ma pensata per essere utile qualunque fornitore si scelga. Contiene le domande da fare prima di affidare il sito, le risposte che dovrebbero rassicurare, i segnali d’allarme e ciò che conviene preparare per non perdere tempo. Alla fine diciamo in poche righe come rispondiamo noi, perché è giusto che anche noi passiamo lo stesso esame.
Cosa deve ottenere una bonifica
Prima di confrontare i fornitori conviene avere chiaro il risultato che si compra. Una bonifica completa ha quattro obiettivi: rimuovere il codice malevolo visibile, cioè redirect, spam, script iniettati; rimuovere la persistenza, cioè tutto ciò che permette all’attaccante di tornare, dalle backdoor agli utenti aggiunti ai cron; individuare e chiudere il punto d’ingresso; documentare quanto è stato fatto, anche per eventuali obblighi verso clienti e autorità. Un servizio che copre solo il primo punto consegna un sito che sembra pulito e che non lo è.
Il secondo e il terzo punto sono quelli che separano davvero i fornitori, perché richiedono tempo, esperienza e accessi che vanno oltre il pannello di WordPress. Sono anche quelli che il cliente non può verificare da solo guardando il sito, ed è per questo che le domande vanno fatte prima.
Lavorano anche a livello di sistema?
La domanda più importante è dove arriva il controllo. Molte infezioni vivono solo nei file di WordPress, e per quelle uno strumento che lavora dal pannello può bastare. Le infezioni che tornano, però, di solito hanno un pezzo fuori da WordPress: un cron dell’utente di sistema che riscarica la backdoor ogni ora, un processo PHP rimasto in memoria dopo che il suo file è stato cancellato, un trigger nel database che ricrea un amministratore, un altro sito sullo stesso account di hosting che reinfetta tutti gli altri, come raccontiamo nell’articolo sulla contaminazione incrociata. Nessuno di questi elementi è visibile a un plugin installato nel sito.
Le domande concrete sono: controllate il crontab dell’utente e quelli di sistema? Controllate i processi in esecuzione? Esaminate trigger, procedure ed eventi del database, e non solo le tabelle di WordPress? Guardate gli altri siti sullo stesso account? Come trattate i file offuscati o cifrati con ionCube e simili? Una risposta seria cita strumenti e accessi precisi; una risposta vaga, o «il nostro scanner trova tutto», indica un controllo che si ferma all’applicazione. Il perché è spiegato nell’articolo sui limiti degli scanner: uno scanner è un ottimo primo passo, ma vede solo ciò che somiglia a qualcosa di già noto.
Trovano il punto d’ingresso?
Un sito ripulito con la porta ancora aperta verrà reinfettato, spesso dagli stessi bot automatici, nel giro di giorni. Individuare il vettore richiede di leggere i log di accesso del web server, incrociarli con le date di modifica dei file, confrontare le versioni dei plugin con le vulnerabilità note e a volte risalire a credenziali rubate dal computer di chi gestisce il sito. Non sempre si arriva a una certezza, soprattutto se i log sono stati cancellati o conservati per pochi giorni.
Per questo la domanda giusta non è «garantite di trovare il vettore?», a cui nessuno onesto può rispondere di sì in assoluto, ma «come lo cercate e cosa mi scrivete se non lo trovate?». Una buona risposta descrive il metodo e prevede, in caso di incertezza, un elenco delle ipotesi plausibili con le misure prese per chiuderle tutte: aggiornamento o rimozione dei componenti vulnerabili, cambio di tutte le credenziali, blocchi a livello di server.
Quali accessi chiedono e come li proteggono
Un lavoro a livello di sistema richiede accessi veri: SSH o SFTP, il database, il pannello di hosting, l’amministrazione di WordPress. È normale che vengano chiesti, e diffidare di chi non li chiede è più ragionevole che diffidare di chi li chiede. Contano però il modo e le cautele. Un fornitore attento chiede il minimo necessario e spiega perché ogni accesso serve, suggerisce di creare utenti dedicati invece di condividere quelli personali, indica un canale sicuro per ricevere le password, non l’email in chiaro o una chat qualsiasi, e alla fine chiede esplicitamente di revocare o cambiare tutto.
Le domande da fare: chi lavorerà concretamente sul sito, dipendenti o collaboratori esterni? Dove vengono conservate le credenziali e per quanto? Viene fatta una copia del sito e dei dati sui vostri sistemi, e quando viene cancellata? Le risposte a queste domande sono anche la base per l’aspetto contrattuale che vediamo più avanti.
Vale la pena chiedere anche come funziona la comunicazione durante l’intervento. Chi è il referente, come si viene aggiornati, cosa succede se il lavoro richiede di mettere offline il sito o di disattivare un plugin da cui dipendono gli ordini? Un intervento sul sito di un’azienda tocca persone diverse, dal titolare all’agenzia che lo gestisce al fornitore di hosting, e un fornitore abituato a queste situazioni sa chiedere le autorizzazioni prima di fare modifiche che hanno effetti sul business, non dopo. Se il sito vende online o raccoglie contatti, stabilire in anticipo le finestre in cui si può intervenire evita discussioni a lavoro iniziato.
Prove e rapporto finale
Il riflesso di chi ripulisce un sito in fretta è cancellare subito tutto ciò che è sospetto. Ma i file malevoli, le loro date e le righe dei log sono le prove che servono a capire cosa è successo, a valutare se ci sono stati accessi a dati personali e, se si decide di sporgere denuncia, a documentarlo. Un fornitore serio conserva una copia del sito e del database nello stato in cui li ha trovati, prima di intervenire, secondo lo stesso principio descritto nell’articolo sulle prime due ore dopo un attacco.
Alla fine, il rapporto. Chiedete di vederne un esempio, anche anonimizzato, prima di firmare. Un rapporto utile contiene almeno: la cronologia ricostruita dell’incidente, il punto d’ingresso individuato o le ipotesi, l’elenco dei file e dei record rimossi o modificati con il loro percorso, gli elementi di persistenza trovati fuori da WordPress, le credenziali da cambiare, le indicazioni su eventuali dati personali coinvolti e le raccomandazioni per evitare che si ripeta. Se il sito ha dati di clienti, quel documento diventa la base per decidere se notificare la violazione, come spieghiamo nell’articolo su GDPR e sito hackerato. Un «fatto, il sito è pulito» in un’email non è un rapporto.
Garanzie, tempi e prezzo: leggere le condizioni
Tempi e garanzie sono il terreno dove le promesse commerciali si allontanano di più dalla realtà. Le domande da fare sono precise. Da quando conta il tempo promesso: dal pagamento, dal primo contatto o dal momento in cui il fornitore ha ricevuto tutti gli accessi necessari? La terza risposta è la più onesta, perché senza accessi nessuno può lavorare, ma deve essere scritta insieme all’elenco degli accessi richiesti. Cosa succede se l’infezione torna: c’è un nuovo intervento incluso, entro quale periodo e a quali condizioni? È ragionevole che la garanzia decada se il cliente non applica le misure indicate, come aggiornare un plugin vulnerabile o cambiare una password, ma queste condizioni devono essere scritte prima.
Sul prezzo, la domanda chiave è su cosa è calcolato. Per sito, per installazione WordPress, per account di hosting, a ore? Un multisite con venti siti è un’installazione o venti? Sono inclusi la richiesta di revisione a Google per la rimozione dalle blacklist, il ripristino da backup, l’aggiornamento dei componenti, l’hardening finale? Un prezzo basso che esclude metà di queste voci può costare di più di uno chiaro che le comprende. Diffidate anche del contrario: le promesse di «protezione a vita» senza condizioni non corrispondono a nulla che un fornitore possa garantire davvero.
Intelligenza artificiale, dati personali e riservatezza
Un sito WordPress contiene quasi sempre dati personali: utenti registrati, ordini, messaggi dei moduli di contatto. Chi esegue la bonifica li tratta per conto del proprietario, e il Regolamento generale sulla protezione dei dati prevede, all’articolo 28, che il rapporto con un responsabile del trattamento sia regolato da un contratto o altro atto giuridico con contenuti precisi: trattamento solo su istruzione documentata, riservatezza, misure di sicurezza, regole per eventuali sub-responsabili, cancellazione o restituzione dei dati al termine. Un fornitore abituato a lavorare con aziende propone la nomina senza che gliela si chieda, e firma un accordo di riservatezza se serve.
Oggi molti servizi usano modelli di intelligenza artificiale per analizzare codice e log, e non c’è niente di male: sono strumenti utili per esaminare rapidamente file offuscati o milioni di righe di log. La domanda da fare è dove girano. Se file, database o log del sito vengono inviati alle API di un fornitore esterno, i dati del sito, compresi quelli personali che i log e i dump contengono, escono dal perimetro concordato e quel fornitore diventa di fatto un sub-responsabile. Se i modelli girano su infrastruttura propria, come nell’approccio descritto nell’articolo sull’analisi dei log con AI locale, i dati restano dove sono. In entrambi i casi la risposta deve essere chiara e scritta.
I segnali d’allarme e cosa preparare
Alcune risposte dovrebbero far riflettere prima di firmare. «Installiamo un plugin di sicurezza e facciamo una scansione», senza nient’altro, è un controllo che il proprietario può fare da solo. «Reinstalliamo tutto da zero» sembra radicale, ma se non comprende l’analisi del database, dei cron e del vettore riporta online lo stesso problema con file nuovi; e se il ripristino avviene da un backup non verificato, può riportare anche la backdoor, come spieghiamo nell’articolo sui backup che riportano il malware. Nessun rapporto scritto, garanzie senza condizioni, nessuna domanda sugli accessi, pagamento anticipato integrale senza un preventivo che descriva il lavoro: sono tutti segnali di un intervento superficiale.
Dall’altra parte, il proprietario può far risparmiare ore preziose preparando alcune cose prima del primo contatto. Gli accessi, in primo luogo: pannello di hosting, SSH o SFTP, database, un amministratore di WordPress, e se ci sono anche CDN, DNS e Search Console. Poi le informazioni: quando ci si è accorti del problema e come, cosa è stato già fatto e da chi, quali backup esistono e dove sono conservati, chi altro ha accesso al sito, agenzie e sviluppatori compresi. E un’avvertenza: non cancellate file e non ripristinate backup prima che qualcuno abbia potuto guardare lo stato attuale.
Per completezza, ecco come rispondiamo noi a queste domande. Lavoriamo a livello applicativo e di sistema: file, database con trigger ed eventi, cron, processi, altri siti dello stesso account. Cerchiamo il punto d’ingresso nei log e lo documentiamo, e conserviamo lo stato iniziale prima di intervenire. Usiamo modelli di intelligenza artificiale open-weight che girano sulla nostra infrastruttura, senza inviare i dati a terzi. Garantiamo la pulizia in 6 ore a 399 €, in 12 ore a 299 € o in 24 ore a 199 €, più IVA, per ogni installazione WordPress, con il tempo che conta dal ricevimento degli accessi necessari, e consegniamo un rapporto tecnico. Se vuoi farci queste domande direttamente, scrivici.
