La prima notizia arriva quasi sempre dall’esterno. Una mail dell’hosting che parla di una segnalazione di abuso, un avviso di un CERT, la schermata rossa di Chrome che un cliente fotografa e inoltra. Il sito, aperto dalla home page, sembra identico a sempre. Eppure a un indirizzo che nessuno ha mai visto, qualcosa come /wp-content/uploads/2026/09/xk29a/, c’è la copia perfetta della pagina di accesso di una banca o del tracciamento di un corriere, e da qualche giorno raccoglie credenziali di persone che non hanno mai sentito parlare del sito che le ospita.
Un kit di phishing non danneggia il sito che lo ospita: lo usa. Il danno lo subiscono le vittime, e la reputazione del dominio.
In questo articolo vediamo come un kit di phishing finisce su un sito WordPress, com’è fatto, come trovarlo con pochi comandi, perché conservare le prove prima di cancellare e come chiudere la vicenda con l’hosting, con chi ha inviato la segnalazione e con Google.
Perché proprio un sito WordPress
Chi organizza una campagna di phishing ha bisogno di indirizzi web che non siano già in blacklist, che abbiano un certificato HTTPS valido e che restino online almeno qualche giorno. Registrare domini nuovi costa e li espone ai filtri che controllano l’età del dominio; usare siti legittimi compromessi risolve tutti e tre i problemi. Un dominio aziendale con anni di storia, un certificato valido e una buona reputazione è il posto ideale in cui nascondere una pagina che deve passare i filtri antispam delle caselle di posta.
Per questo il sito ospite viene toccato il meno possibile. Niente defacement, niente redirect dalla home page, niente modifiche visibili: il kit vive in una cartella a parte e il resto del sito deve continuare a funzionare, perché un proprietario che non si accorge di nulla è un proprietario che non cancella nulla. È una differenza importante rispetto ad altre infezioni, come lo spam SEO o i redirect condizionali, che almeno lasciano sintomi osservabili da chi visita il sito.
Come arriva: uno zip estratto in una cartella qualsiasi
Un kit di phishing è di solito un archivio zip con tutto il necessario: pagine HTML e PHP, immagini e fogli di stile copiati dal sito originale, script di invio dei dati. Per installarlo l’attaccante ha bisogno di scrivere file sul server, e le strade sono quelle di qualsiasi compromissione:
- una webshell caricata in precedenza, spesso da un altro gruppo che rivende gli accessi;
- credenziali di amministratore rubate o deboli, usate per installare un plugin di gestione dei file o per caricare un plugin fasullo che contiene il kit;
- una vulnerabilità di upload in un plugin, che permette di caricare file senza autenticazione;
- credenziali FTP o del pannello di hosting, come quelle rubate dal PC dello sviluppatore.
Una volta caricato, lo zip viene estratto con la funzione ZipArchive di PHP o con un comando di sistema, in una cartella con un nome casuale o plausibile: una sottocartella degli upload del mese, una cartella dentro un plugin poco usato, oppure .well-known, che esiste su molti siti per i certificati e che raramente qualcuno apre. Spesso lo zip resta lì accanto, e la sua data è un ottimo punto di partenza per la ricostruzione.
Anatomia di un kit: pagina clone, filtri e invio dei dati
I kit cambiano da campagna a campagna, ma la struttura è ricorrente. C’è una pagina d’ingresso che imita un servizio noto (banca, poste, corriere, webmail, piattaforme di streaming), spesso con più passaggi: prima nome utente e password, poi il codice ricevuto via SMS, poi i dati della carta. Ogni modulo invia i dati a uno script PHP locale, che li inoltra e passa alla pagina successiva, per chiudere con un reindirizzamento al sito vero, così che la vittima pensi a un errore temporaneo.
Poi ci sono i filtri. Un .htaccess nella cartella del kit e uno o più script «antibot» cercano di mostrare la pagina solo alle vittime: bloccano indirizzi IP di aziende di sicurezza e di data center, user agent di crawler, visitatori da paesi diversi da quello preso di mira. Il risultato è che chi analizza la segnalazione da un server può trovare un errore 404 o una pagina vuota, mentre da uno smartphone italiano la pagina di phishing appare perfettamente. È lo stesso principio del cloaking usato dallo spam SEO, applicato in senso opposto.
Infine l’esfiltrazione. I kit più semplici spediscono i dati per email con la funzione mail() di PHP, usando il server del sito come mittente, con effetti sulla reputazione di posta del dominio simili a quelli descritti per i server che inviano spam. Molti kit recenti usano invece l’API dei bot di Telegram: come documentato nell’analisi di Cofense, i dati inseriti dalla vittima vengono inviati con una richiesta sendMessage a api.telegram.org, con il token del bot nel percorso e l’identificativo della chat nel corpo. Alcuni kit salvano anche una copia locale in un file di testo, che contiene quindi i dati personali delle vittime ed è spesso scaricabile da chiunque conosca l’indirizzo.
I segnali che arrivano dall’esterno
Poiché il sito non mostra sintomi, la scoperta dipende da altri. Le segnalazioni più comuni arrivano dal fornitore di hosting, che le riceve a sua volta dall’indirizzo abuse e può sospendere l’account se il contenuto non viene rimosso in tempi brevi; dai CERT nazionali e dai gruppi di risposta delle banche, che monitorano le campagne contro i propri clienti; da Google Safe Browsing, che contrassegna l’indirizzo come ingannevole e fa comparire l’avviso a schermo intero in Chrome, Firefox e Safari; dai clienti stessi, che ricevono l’avviso visitando il sito.
Una segnalazione di abuso contiene quasi sempre l’indirizzo esatto della pagina di phishing: è il dato più prezioso, e va conservato. In Search Console, il rapporto Problemi di sicurezza indica la categoria «ingegneria sociale» e alcuni URL di esempio. Se non si ha un account di Search Console, lo stato del dominio si può controllare nel Transparency Report di Google. Attenzione: un’etichetta di phishing riguarda spesso l’intero dominio, non solo la cartella del kit, e ha effetti anche sulla posta, perché i link al dominio nelle email vengono considerati pericolosi.
Trovare il kit: cartelle recenti, zip e moduli sospetti
Se la segnalazione indica l’indirizzo, la cartella è nota; ma raramente un kit è da solo. La ricerca va estesa a tutto il sito e agli altri siti dello stesso account, partendo dalle cartelle create di recente e dagli archivi:
# Cartelle create o modificate negli ultimi 30 giorni, escluse le cache
find ~/public_html -type d -mtime -30 -not -path '*/cache/*' | sort
# Archivi nel sito: nessuno dovrebbe stare dentro wp-content
find ~/public_html \( -name '*.zip' -o -name '*.tar.gz' -o -name '*.rar' \) -printf '%TY-%Tm-%Td %TH:%TM %p\n'
# Cartelle nascoste o dentro .well-known con file PHP
find ~/public_html -path '*/.well-known/*' -name '*.php'
# Esfiltrazione verso Telegram o per email con dati del modulo
grep -rlE 'api\.telegram\.org|sendMessage|chat_id' --include='*.php' ~/public_html
grep -rlE 'mail\s*\(.*\$_(POST|REQUEST)' --include='*.php' ~/public_htmlUn altro indizio affidabile è il contenuto HTML: un file index.php o index.html fuori dai percorsi di WordPress che contiene un modulo con campi di password, codici OTP o numeri di carta, oppure il nome di una banca nel titolo, non appartiene al sito. Una ricerca per parole chiave come cvv, otp o il nome dei marchi più imitati trova in pochi secondi anche i kit che non usano Telegram. Gli access log, infine, dicono da quanto tempo il kit è attivo e quante persone l’hanno visitato: le richieste POST verso gli script del kit corrispondono, con buona approssimazione, ai dati inviati dalle vittime.
# Prima e ultima richiesta alla cartella del kit (log dal più vecchio al più recente)
grep -h '/uploads/2026/09/xk29a/' /var/log/nginx/access.log.1 /var/log/nginx/access.log \
| awk '{print $4}' | sed -n '1p;$p'
# Moduli inviati (POST) agli script del kit, per indirizzo IP
grep -h 'POST /wp-content/uploads/2026/09/xk29a/' /var/log/nginx/access.log* \
| awk '{print $1}' | sort | uniq -c | sort -rn | head
Conservare le prove prima di cancellare
La tentazione è eliminare subito la cartella e rispondere all’hosting che il problema è risolto. Prima conviene fare una copia, per tre motivi. Il primo è capire il vettore: le date dei file e dello zip, confrontate con gli access log, indicano quale richiesta ha caricato il kit, e senza quell’informazione il kit tornerà. Il secondo sono le vittime: il file di testo con i dati raccolti e i log delle richieste POST servono a valutare la portata dell’accaduto, anche per valutare gli obblighi di notifica previsti dall’articolo 33 del GDPR se sono stati coinvolti anche dati trattati dal sito. Il terzo è l’eventuale denuncia: il token del bot Telegram, gli indirizzi email di destinazione e gli IP di chi ha caricato il kit sono informazioni utili alla Polizia Postale e ai CERT.
# Archivio della cartella con date e permessi originali, fuori dal sito
mkdir -p ~/incidente
tar -czpf ~/incidente/kit-xk29a.tar.gz -C ~/public_html/wp-content/uploads/2026/09 xk29a xk29a.zip
cp -p /var/log/nginx/access.log* ~/incidente/ 2>/dev/null
sha256sum ~/incidente/* > ~/incidente/SHA256SUMS
chmod -R go-rwx ~/incidenteLa copia contiene dati personali di terzi e va trattata di conseguenza: fuori dalla cartella pubblica, con accesso ristretto, e cancellata quando non serve più. Se il sito è coinvolto in un’indagine, la procedura di acquisizione va concordata con chi la conduce; il metodo generale è quello descritto per le prime ore dopo un attacco. Il CERT-AgID, per esempio, mette a disposizione una casella per l’invio di campioni e segnalazioni, indicata nella sua pagina dei contatti.
Se il kit salvava una copia locale dei dati, c’è un controllo in più da fare: cercare negli access log le richieste GET a quel file. Un file di testo scaricato da indirizzi diversi da quelli delle vittime significa che i dati raccolti sono stati prelevati da lì, dall’operatore del kit o da altri che ne conoscevano il percorso, ed è un’informazione che cambia la valutazione dell’incidente.
grep -h 'xk29a/result.txt' /var/log/nginx/access.log* | awk '{print $1, $4, $9}'Rimozione e chiusura del vettore
Rimuovere il kit è la parte facile: si cancella la cartella, lo zip e ogni file trovato con le ricerche precedenti. La parte che conta è chiudere la strada da cui è entrato, altrimenti il prossimo kit arriva entro pochi giorni, magari in un’altra cartella. Questo significa cercare le webshell e le backdoor che hanno permesso il caricamento, controllare gli utenti amministratori, verificare i plugin installati di recente, ruotare le credenziali di WordPress, FTP, database e pannello. Il kit è quasi sempre il sintomo visibile di un accesso che esiste da prima e che va trattato come una compromissione completa.
Per verificare che l’indirizzo non risponda più, meglio controllare da più punti di vista, perché l’antibot può falsare il risultato: una richiesta da riga di comando dal server, una da uno smartphone su rete mobile, una con user agent di un browser comune. Tutte devono restituire un 404 o un 410 generato da WordPress, non una pagina vuota o un redirect. Nei giorni successivi conviene tenere d’occhio gli access log: le email di phishing già inviate continuano a portare visitatori alla vecchia cartella, e un ritorno improvviso di risposte 200 su quei percorsi indica che il kit è stato ricaricato, quindi che il vettore è ancora aperto.
Chiudere la segnalazione e chiedere la revisione
Una volta rimosso il kit e chiuso il vettore, restano tre interlocutori. All’hosting e a chi ha inviato la segnalazione si risponde in modo circostanziato: cosa è stato trovato, quando è stato rimosso, come è entrato l’attaccante e cosa è stato fatto per impedirlo. Una risposta generica del tipo «abbiamo pulito» è spesso quella che porta alla sospensione alla segnalazione successiva.
Con Google, si chiede la revisione dal rapporto Problemi di sicurezza di Search Console, descrivendo le azioni svolte. Secondo la guida di Search Console la revisione può richiedere da alcuni giorni a qualche settimana; una richiesta respinta perché nel sito era rimasto un secondo kit allunga i tempi, ed è il motivo per cui la ricerca va fatta su tutto il sito prima di inviarla. Il procedimento completo è descritto nell’articolo sulla rimozione dalle blacklist.
Un kit di phishing è uno dei casi in cui la velocità conta di più: ogni ora di permanenza online significa nuove vittime e una reputazione del dominio più difficile da recuperare. Nei nostri interventi la ricerca dei kit si estende a tutti i siti dell’account e al sistema, i file offuscati vengono analizzati anche con modelli di intelligenza artificiale eseguiti in locale, e le prove vengono conservate prima della rimozione. Se hai ricevuto una segnalazione di phishing per il tuo sito, la bonifica garantita in 6, 12 o 24 ore per ogni installazione WordPress comprende anche la preparazione della richiesta di revisione: puoi contattarci inoltrando il testo della segnalazione ricevuta.
