Ricorso del titolare del dominio

Pensate che ci siamo sbagliati?
Facci dimostrarlo.

Invia il tuo dominio per una nuova valutazione. Confrontiamo i nostri dati con le informazioni aggiornate sulle minacce, eseguiamo una verifica automatizzata indipendente e un operatore esamina manualmente tutti i casi non univoci.

Massimo 48 ore — rimozione automatica se non recensito La privacy prima di tutto — tracciamento tramite ID Registro pubblico dei commit
La nostra promessa delle 48 ore

Ogni ricorso viene analizzato in parte dall'intelligenza artificiale, ma la decisione finale richiede comunque la verifica da parte di un operatore. Se nessun operatore riesce a confermare il tuo ricorso entro 48 ore, il sistema approva automaticamente — il tuo dominio verrà rimosso dal nostro sito, dal repository GitHub e dal database. Il conto alla rovescia inizia nel momento in cui invii la richiesta.

01
Invia
Dominio, indirizzo e-mail di contatto, perché abbiamo sbagliato.
02
Verifica
Estraiamo i nostri dati interni, i risultati attuali di VirusTotal, URLScan, DNS e la cronologia dei certificati.
03
Recensione
Il triage automatizzato individua i casi chiari; quelli ambigui vengono sottoposti a un revisore umano.
04
Decidi
Se approvato: rimozione completa da tutti i database, dal repository pubblico e dalle cache. URL del commit da archiviare.

Il dominio completo che abbiamo elencato (senza https://, nessun percorso)

L'impostazione predefinita è configurata in modo tale da non dover condividere alcuna informazione personale. Non conserviamo i dati di contatto, non effettuiamo alcun follow-up — se ci siamo sbagliati, basta rimuovere il dominio. Tieni traccia del tuo ricorso tramite l'ID. Se desideri davvero ricevere una notifica, sostituisci con il tuo indirizzo (va bene anche una casella di posta temporanea).

Non servono prove, attestati di proprietà né un linguaggio formale. Basta dirci cosa c'è. Ci occuperemo noi della verifica.

Non è necessario creare un account né fornire un indirizzo e-mail. Non conserviamo i registri delle richieste. Politica di sicurezza.

Incolla l'ID del tuo ricorso (UUID) oppure apri l'URL di tracciamento che ti abbiamo inviato.

Risposte senza giri di parole

Sulle scuse, sulla “durezza” e su ciò di cui veniamo accusati.

Perché non vi siete scusati prima?

Il dominio l’abbiamo sempre rimosso — su questo non c’è mai stato alcun dubbio. Quello che non facevamo era scrivere per chiedere scusa. Non per arroganza: semplicemente pensavamo che una nostra lettera non avesse valore per nessuno. Una rimozione è qualcosa di concreto; le scuse sono parole. Su questo ci sbagliavamo. Per chi ha perso traffico o ha dovuto vedersela con il proprio Registrar, sentirsi dire chiaramente che l’errore è stato nostro conta. Per noi non è difficile, e abbiamo sempre cercato di farlo quando potevamo.

Il vero ostacolo erano i dati. Siamo fermamente contrari alla conservazione di dati non pubblici: ogni indirizzo archiviato è un onere e un rischio. PhishDestroy non è il nostro lavoro, ed è costruito in modo da poter smettere di essere nostro in qualsiasi momento senza che nulla si rompa. Non deve dipendere da noi. Mailing list, archivi degli utenti e log conservati: tutto questo lo lega a noi personalmente.

Ora possiamo farlo senza conservare nulla. Se il tuo ricorso è stato approvato — oggi o in qualsiasi momento in passato — inserisci qui sotto l’ID del ricorso e un indirizzo e-mail. Ti inviamo un unico messaggio di scuse, con una lettera in PDF che puoi inoltrare al tuo Registrar o ai tuoi clienti, e l’indirizzo viene eliminato. Un falso positivo, una lettera.

Richiedi una lettera di scuse

Solo per ricorsi approvati. Invio unico. L’indirizzo non viene conservato.

“PhishDestroy è troppo duro.”

Ce lo sentiamo dire spesso. Non vogliamo polemizzare — ma onestamente non vediamo dove sia questa durezza, né verso chi sia rivolta. Ecco quindi esattamente cosa facciamo, e puoi verificare ogni singolo punto.

“Segnalate in massa i Registrar.”

“In massa” si riferisce a quanti domini di phishing gestiamo, non a quanto duramente colpiamo ciascuno di essi. Un dominio riceve una sola segnalazione, inviata al suo Registrar. Un sollecito parte solo se il dominio è ancora attivo, e può essere inviato anche all’ICANN o al gestore del TLD. I solleciti sono soggetti a limiti rigorosi: mai prima di 48 ore dalla segnalazione precedente. Secondo i nostri dati, nel 2026 circa il 7% dei domini ha ricevuto qualcosa oltre alla prima segnalazione — e ognuno di essi era stato confermato come malevolo. Il nostro sistema è aperto: il numero di segnalazioni inviate per ciascun dominio è pubblico.

Non gridiamo “bloccateli!” ai Registrar. Non abbiamo alcun potere di costringere nessuno, e i nostri modelli di segnalazione sono pubblici da tempo. Chiedono al team abuse del Registrar di esaminare con urgenza il dominio, il suo titolare e i suoi contenuti. Non sosteniamo che il titolare sia malintenzionato, e nemmeno che i contenuti gli appartengano. Diciamo che il sito potrebbe essere stato compromesso o violato, e chiediamo al Registrar o al provider di hosting di verificare. Rispettiamo esplicitamente le loro procedure interne e lasciamo la decisione alla loro AUP e ai loro Termini di servizio. La segnalazione indica inoltre che il dominio è stato aggiunto al nostro elenco pubblico, con data e ora, per informare la comunità della sicurezza.

Non accusiamo nessuno e non chiediamo blocchi. Sarebbe scorretto, e va oltre le nostre competenze. Le nostre conclusioni derivano da sistemi di scansione qualificati e da indicatori che raccogliamo noi stessi, ma nessuno scanner, certificato o meno, può garantire zero errori — basta il cloaking a impedirlo. Non abbiamo mai sostenuto di non commettere errori. Ovunque diciamo il contrario.

Se attaccassimo i Registrar, ci avrebbero inserito in una blocklist da tempo.

Questo mito ha un autore. Circa un anno fa, alcuni truffatori hanno pubblicato una guida per aggirare le sospensioni di NiceNIC. Il modello di lettera al Registrar contenuto nella guida sosteneva che il loro casinò truffaldino fosse il bersaglio di “attacchi di massa coordinati, commissionati dai concorrenti”.

“PhishDestroy lancia attacchi DDoS contro i siti.”

No. Questa l’ha inventata un’IA, partendo dalle parole “seed-phrase flooding”. Per un’IA, “flood” significa un attacco malevolo. Non è di questo che si tratta.

Il seed flooding consiste nell’inviare frasi di recupero false al modulo di raccolta di un kit di phishing. Questo svaluta i dati rubati e rivela come il kit li elabora, così che il suo backend possa essere segnalato. Servizi come EmailJS hanno per lo più reagito revocando le chiavi che identificavano i siti di phishing. Abbiamo usato questo metodo in molte indagini sulle infrastrutture, e la descrizione completa si trova su /seed-flooding/.

Ogni esecuzione viene registrata — obiettivo, orario e numero di richieste. I volumi possono essere elevati, a volte fino a un milione di invii. Ma il processo non è quasi mai stato completamente automatizzato. Anni fa abbiamo provato ad automatizzarlo contro i moduli di phishing pubblicizzati tramite annunci Google, e non ha funzionato: i phisher cambiavano formato, aggiungevano captcha e payload cifrati, e trovare automaticamente la finestra giusta non era possibile.

  • Un invio è una singola richiesta POST di 12 parole più uno stato di risposta. Aprire un sito web dal tuo IP pesa molto di più.
  • Quasi ogni utilizzo, in tutti questi anni, è avvenuto all’interno di Cloudflare, da Cloudflare a Cloudflare. Date le dimensioni dei pacchetti, l’infrastruttura condivisa e la distribuzione del carico, non può funzionare come attacco. Le due eccezioni sono state gestite con precauzioni di base: il provider di hosting era stato avvisato dei nostri test.
  • Siamo un progetto senza scopo di lucro. Non abbiamo botnet, né proxy, niente che serva a mettere fuori uso un server.
  • Un sito legittimo non ha nulla da temere. Se hai un modulo, qualunque esso sia, una frase di 12/24 parole non gli fa nulla. Gli handler dei kit usano variabili specifiche; su un sito normale sono innocue richieste POST verso il nulla.

Ci serve l’opposto di un disservizio: il sito di phishing deve restare online mentre il Registrar lo verifica. PhishDestroy non ha mai fatto un DDoS a nessuno. Non pensiamo che questo metodo sia piacevole, ma non c’è alcun intento malevolo, e lo manteniamo entro limiti ragionevoli.

“Qualcuno sta usando il vostro sistema contro un concorrente.”

Diccelo direttamente — tramite un issue su GitHub o il bot Telegram. Rispondiamo.

Non abbiamo alcun interesse a inserire nell’elenco siti legittimi o segnalati per errore. Non ci guadagniamo nulla, solo danni alla nostra reputazione e filtri più severi sul nostro stesso sistema. Ma il sistema ha dei contributori. Il diritto di inviare senza verifiche si ottiene solo dopo che un numero consistente di domini ha prima superato la revisione standard. Questo status ha un valore, e se ne è abusato, come nel caso di alcuni servizi di “stress test” e di un’attività di casinò indonesiana dai contorni poco chiari.

Siamo fermamente contrari a chi usa PhishDestroy per un tornaconto personale invece che per combattere il phishing. Anche se il tuo servizio non è del tutto pulito, se ritieni che qualcuno stia pagando per far rimuovere dei siti, inviaci il dominio o i domini. Verificheremo. Se un membro della nostra comunità vende rimozioni, blocchiamo quel membro e ogni dominio che ha inserito a scopo commerciale. Ogni questione si può risolvere. Ma se il tuo sito è davvero illegale, difficilmente lo rimuoveremo.

Indagate sui vostri errori?

Sì. Ogni falso positivo si traduce in un affinamento delle nostre regole. I casi di massa o le anomalie — più siti legittimi nel database contemporaneamente — non passano mai inosservati: individuiamo quale segnale ha fallito, quale fonte lo ha alimentato e cos’altro quella fonte ha toccato.

Ogni correzione è pubblica?

Sì. Ogni dominio rivelatosi un falso positivo viene rimosso pubblicamente da GitHub e aggiunto a allow/allowlist.json con un commit separato. Una correzione che nessuno può verificare non vale nulla.

Domande frequenti

Quanto tempo ci vuole per prendere una decisione?

Entro 48 ore dall'invio. La nostra intelligenza artificiale effettua un controllo preliminare parziale di ogni ricorso, ma la decisione finale richiede comunque la verifica da parte di un operatore. Se nessun operatore riesce a confermare in tempo, il sistema approva automaticamente e rimuove il tuo dominio dal nostro sito, dal repository GitHub e dal database — senza bisogno di alcuna approvazione manuale. Il limite di tempo è imposto dal codice, non da una politica.

Mi mandi un'e-mail?

Solo se lo chiedi: dopo l’approvazione puoi richiedere una lettera di scuse una tantum qui sopra. Per noi la privacy è una priorità: non conserviamo i registri delle richieste e non gestiamo una mailing list. Puoi seguire lo stato del tuo ricorso tramite l'ID utilizzando il link che ti forniamo al momento dell'invio. Ti contatteremo via e-mail solo in rari casi in cui siano necessari chiarimenti.

Ma voi chiudete davvero i siti?

No. Non abbiamo un pulsante “Elimina questo sito”. Effettuiamo scansioni, analizziamo i risultati e li inoltriamo ai registrar di domini, ai provider di hosting e ai feed di intelligence sulle minacce dei nostri partner. La decisione effettiva di rimuovere il sito spetta a loro — e i registrar intervengono solo in caso di phishing effettivo. Se il tuo sito è legittimo, non hai nulla da temere.

Devo fornire una prova della proprietà?

No. Basta inviarci il dominio e una breve descrizione del contesto. Siamo noi stessi a occuparci della verifica, incrociando i dati con le informazioni aggiornate sulle minacce, i record DNS, la cronologia dei certificati e le nostre prove. Chiedere ai proprietari di dimostrare la propria identità ci sembrava invasivo, quindi abbiamo smesso di farlo.

Ma perché il mio dominio è stato inserito nell'elenco, innanzitutto?

La maggior parte delle segnalazioni deriva dal rilevamento automatico di kit di phishing, script di drenaggio, casi di usurpazione di identità di marchi o segnalazioni da parte della comunità. Se desideri vedere esattamente quali prove abbiamo a disposizione, presenta un ricorso e consulta la pagina pubblica di monitoraggio.

Prendi già decisioni in modo automatico grazie all’IA?

Non ancora — ci stiamo lavorando con attenzione. Al momento, i ricorsi vengono sottoposti a un sistema automatizzato di triage che individua eventuali segnali di allarme (VirusTotal, urlscan, DNS, cronologia dei certificati), ma la decisione finale spetta comunque a una persona. Ci rifiutiamo di automatizzare un processo che ha conseguenze concrete per i proprietari dei siti finché non avremo abbastanza fiducia nel sistema.

E se venissi rifiutato?

Se le circostanze dovessero cambiare, potrai inviare nuovamente la richiesta in un secondo momento; se ritieni che il rifiuto sia stato ingiustificato, puoi aprire un issue su GitHub per discuterne pubblicamente. Non prevediamo uno scambio di e-mail a più riprese: l’obiettivo è prendere decisioni eque, non negoziare.