Hai chiuso un vecchio sito, smesso di utilizzare un progetto o cambiato nome alla tua azienda. Il dominio non serve pi\u00f9 e decidi di non rinnovarlo. Sembra la fine della storia.<\/p>\n
In realt\u00e0 potrebbe essere soltanto l’inizio.<\/p>\n
Se quel dominio scaduto<\/strong> viene registrato da un’altra persona, il nuovo proprietario pu\u00f2 creare nuovamente indirizzi come Questo tipo di rischio viene chiamato Domain Resurrection Attack<\/strong>: il dominio “torna in vita”, ma nelle mani di qualcun altro, mentre molti servizi online continuano a fidarsi delle vecchie identit\u00e0 email associate a quel dominio.<\/p>\n Non \u00e8 soltanto una possibilit\u00e0 teorica. Nel 2025 il Python Package Index (PyPI) ha introdotto controlli specifici sui domini in scadenza proprio per contrastare questo vettore di attacco. Nei primi mesi di funzionamento il sistema aveva gi\u00e0 rimosso lo stato di verifica a oltre 1.800 indirizzi email associati a domini entrati nelle fasi di scadenza.<\/p>\n Vediamo come funziona, perch\u00e9 riguarda aziende, professionisti, webmaster e semplici proprietari di domini e cosa fare prima di abbandonare definitivamente un dominio<\/strong>.<\/p>\n Un Domain Resurrection Attack<\/strong> sfrutta la fiducia residua che Internet continua ad attribuire a un dominio anche dopo che il suo proprietario originale ha smesso di controllarlo.<\/p>\n Il problema nasce da un fatto molto semplice: migliaia di servizi utilizzano ancora l’indirizzo email come prova dell’identit\u00e0 dell’utente.<\/p>\n Quando dimentichiamo una password, spesso il procedimento \u00e8:<\/p>\n Finch\u00e9 l’indirizzo email rimane sotto il nostro controllo, il sistema funziona.<\/p>\n Ma cosa succede se la casella era Il nuovo proprietario del dominio pu\u00f2 potenzialmente ricreare quella stessa casella email. Dal punto di vista del vecchio servizio online, l’indirizzo non \u00e8 cambiato: continua a essere \u00c8 cambiata invece la persona che riceve i messaggi.<\/p>\n Immaginiamo una piccola azienda che nel 2021 utilizza il dominio:<\/p>\n La casella:<\/p>\n viene utilizzata per registrarsi a diversi servizi:<\/p>\n Nel 2024 l’azienda cambia nome e passa a:<\/p>\n Il vecchio dominio viene mantenuto per qualche tempo e poi lasciato scadere.<\/p>\n Nel 2026 una terza persona registra Da quel momento pu\u00f2 configurare i record MX e creare nuovamente:<\/p>\n Se uno dei vecchi servizi permette ancora il recupero dell’account tramite quell’indirizzo, il nuovo proprietario del dominio potrebbe ricevere il messaggio di reset.<\/p>\n Il servizio vede la stessa email di sempre. Ma dietro quell’email non c’\u00e8 pi\u00f9 la stessa persona.<\/p>\n Siamo abituati a considerare un dominio come l’indirizzo di un sito web. In realt\u00e0 un dominio \u00e8 molto di pi\u00f9.<\/p>\n Pu\u00f2 essere collegato a:<\/p>\n Quando il dominio cambia proprietario, non viene automaticamente cancellata la fiducia che decine o centinaia di servizi esterni gli avevano attribuito negli anni.<\/p>\n Questa situazione viene spesso descritta in sicurezza come residual trust<\/strong>, cio\u00e8 fiducia residua: un sistema continua a fidarsi di un’identit\u00e0, di un indirizzo o di una risorsa che nel frattempo ha cambiato proprietario.<\/p>\n OWASP include espressamente i domini scaduti e i vecchi indirizzi email tra gli asset che possono essere sfruttati per intercettare messaggi, recuperare account e ottenere accessi non autorizzati.<\/p>\n Puoi approfondire nella pagina OWASP dedicata a Allowing Domains or Accounts to Expire<\/a>.<\/p>\n Il punto pi\u00f9 delicato \u00e8 il classico pulsante “Password dimenticata?”<\/strong>.<\/p>\n Molti servizi verificano l’identit\u00e0 inviando una mail all’indirizzo registrato anni prima.<\/p>\n Il problema \u00e8 che il servizio pu\u00f2 sapere che l’indirizzo:<\/p>\n era valido quando l’account \u00e8 stato creato, ma non necessariamente sa che vecchiodominio.it ha cambiato proprietario<\/strong>.<\/p>\n Per il database del servizio l’email \u00e8 sempre la stessa.<\/p>\n Se il dominio viene registrato nuovamente e quella casella viene ricreata, la procedura di recupero potrebbe consegnare il link alla persona sbagliata.<\/p>\n Naturalmente questo non significa che ogni account possa essere automaticamente sottratto. Molti servizi utilizzano autenticazione a due fattori, controlli aggiuntivi, passkey, dispositivi fidati o procedure di recupero pi\u00f9 robuste.<\/p>\n Ma la presenza di una vecchia email su un dominio che non controlliamo pi\u00f9 costituisce comunque un rischio che dovrebbe essere eliminato.<\/p>\n Un caso particolarmente interessante arriva da PyPI, il Python Package Index<\/strong>, uno dei repository software pi\u00f9 importanti dell’ecosistema Python.<\/p>\n Nell’agosto 2025 PyPI ha pubblicato un’analisi intitolata Preventing Domain Resurrection Attacks<\/em>, spiegando di aver introdotto un sistema per controllare periodicamente lo stato dei domini associati agli indirizzi email degli utenti.<\/p>\n Quando un dominio entra in una fase avanzata del processo di scadenza, PyPI pu\u00f2 rimuovere lo stato di verifica dell’indirizzo associato. In questo modo quell’email non pu\u00f2 continuare a essere considerata automaticamente attendibile per operazioni come il recupero della password.<\/p>\n Secondo PyPI, dall’introduzione iniziale del sistema nel giugno 2025 erano gi\u00e0 stati rimossi dalla verifica pi\u00f9 di 1.800 indirizzi email<\/strong> associati a domini entrati nelle fasi di scadenza.<\/p>\n PyPI sottolinea inoltre che non si tratta di un rischio puramente teorico: un attacco di questo tipo aveva gi\u00e0 interessato almeno un progetto PyPI nel 2022 e problemi analoghi sono stati osservati in altri ecosistemi software.<\/p>\n La spiegazione completa \u00e8 disponibile sul blog ufficiale di PyPI<\/a>.<\/p>\n Nel caso di un normale account personale, un takeover pu\u00f2 compromettere i dati del singolo utente.<\/p>\n Nel mondo dello sviluppo software le conseguenze possono essere pi\u00f9 estese.<\/p>\n Se un vecchio indirizzo email \u00e8 collegato all’account di un manutentore di un pacchetto, un eventuale accesso non autorizzato potrebbe teoricamente coinvolgere anche:<\/p>\n \u00c8 uno dei motivi per cui i repository software stanno aumentando i controlli su autenticazione, 2FA, token e domini associati agli account.<\/p>\n Il dominio non \u00e8 quindi soltanto “il nome del sito”: pu\u00f2 diventare una componente della catena di fiducia dell’intera infrastruttura.<\/p>\n No.<\/strong> Registrare un dominio scaduto non permette automaticamente di recuperare la vecchia casella postale o leggere i messaggi archiviati sul precedente server.<\/p>\n Il nuovo proprietario non ottiene magicamente lo storico delle email.<\/p>\n Il rischio riguarda invece i nuovi messaggi inviati dopo il cambio di propriet\u00e0<\/strong>.<\/p>\n Configurando un nuovo servizio di posta e gli opportuni record MX, il nuovo proprietario pu\u00f2 creare indirizzi identici a quelli utilizzati in passato e ricevere eventuali messaggi che terze parti continuano a spedire a quelle caselle.<\/p>\n Per esempio:<\/p>\n \u00c8 proprio questa continuit\u00e0 apparente dell’indirizzo email a rendere il problema poco intuitivo.<\/p>\n Se controlla il dominio e il relativo servizio di posta, pu\u00f2 generalmente creare nuove caselle o alias sotto quel dominio, nei limiti del servizio utilizzato.<\/p>\n Pu\u00f2 quindi ricreare indirizzi comuni come:<\/p>\n oppure indirizzi nominativi, se li conosce.<\/p>\n Esiste inoltre il concetto di catch-all<\/strong>: una configurazione che consente di ricevere messaggi inviati anche a indirizzi non creati esplicitamente.<\/p>\n Per questo non \u00e8 sufficiente pensare: “nessuno conosceva il nome della mia vecchia casella”.<\/p>\n Non \u00e8 necessario che siano segreti particolarmente difficili da trovare.<\/p>\n Vecchi indirizzi email possono rimanere visibili in:<\/p>\n Un dominio utilizzato per anni lascia spesso molte tracce online.<\/p>\n Questo \u00e8 uno dei motivi per cui, quando un’azienda cambia dominio, \u00e8 importante considerare il vecchio nome come un asset da gestire e non semplicemente come una spesa da eliminare.<\/p>\n No.<\/strong> Sono problemi diversi.<\/p>\n Nel domain hijacking<\/strong> un attaccante riesce a prendere il controllo di un dominio che appartiene ancora alla vittima, per esempio compromettendo l’account del registrar o manipolando procedure di trasferimento.<\/p>\n Nel Domain Resurrection Attack<\/strong>, invece, il dominio \u00e8 stato realmente abbandonato, scade e successivamente viene registrato legalmente da un nuovo soggetto.<\/p>\n Il problema nasce perch\u00e9 servizi esterni continuano a fidarsi delle vecchie email e delle vecchie associazioni.<\/p>\n Abbiamo approfondito i rischi relativi alla protezione del dominio nella nostra guida sulla sicurezza dei domini e il domain hijacking<\/a>.<\/p>\n No, ma i due problemi possono incontrarsi.<\/p>\n Con una password compromessa<\/strong> il rischio nasce perch\u00e9 una credenziale non \u00e8 pi\u00f9 segreta.<\/p>\n Nel Domain Resurrection Attack la password originale potrebbe essere perfettamente sicura e sconosciuta all’attaccante. Il problema \u00e8 che il nuovo proprietario del dominio potrebbe tentare di reimpostarla attraverso l’email di recupero<\/strong>.<\/p>\n Nel nostro approfondimento su come Apple, Google e altri servizi rilevano una password compromessa<\/a> abbiamo visto come i data breach possano rendere pericolosa una credenziale anche molti anni dopo.<\/p>\n Qui il principio \u00e8 simile: una decisione presa anni fa pu\u00f2 continuare ad avere conseguenze perch\u00e9 Internet conserva relazioni e fiducia molto pi\u00f9 a lungo di quanto immaginiamo.<\/p>\n Pu\u00f2 ridurre notevolmente il rischio, ma dipende dalla procedura di recupero del servizio.<\/strong><\/p>\n Se un account richiede un secondo fattore indipendente dalla posta elettronica, il semplice controllo dell’indirizzo email potrebbe non essere sufficiente per accedere.<\/p>\n Tuttavia alcuni servizi consentono procedure di account recovery che possono modificare o aggirare i normali fattori di autenticazione dopo ulteriori verifiche.<\/p>\n \u00c8 quindi sbagliato considerare la 2FA come un motivo per lasciare vecchie email associate agli account.<\/p>\n La soluzione migliore rimane aggiornare l’indirizzo email prima di perdere il controllo del dominio<\/strong>.<\/p>\n Per gli utenti Xlogic abbiamo una guida dedicata a come attivare l’autenticazione a due fattori su cPanel e Webmail<\/a>.<\/p>\nadmin@vecchiodominio.it<\/code>, info@vecchiodominio.it<\/code> o nome.cognome@vecchiodominio.it<\/code>. Se uno di quegli indirizzi \u00e8 ancora associato a vecchi account online, potrebbe ricevere email di recupero password, notifiche o altre comunicazioni che il servizio continua a considerare destinate al proprietario originale.<\/p>\nCos’\u00e8 un Domain Resurrection Attack?<\/h2>\n
\n
admin@azienda.it<\/code> e, anni dopo, azienda.it scade e viene registrato da un’altra persona<\/strong>?<\/p>\nadmin@azienda.it<\/code>.<\/p>\nUn esempio semplice: il vecchio dominio dell’azienda<\/h2>\n
azienda-verde.it<\/code><\/p>\namministrazione@azienda-verde.it<\/code><\/p>\n\n
azienda-blu.it<\/code><\/p>\nazienda-verde.it<\/code>.<\/p>\namministrazione@azienda-verde.it<\/code><\/p>\nPerch\u00e9 un dominio scaduto pu\u00f2 diventare un problema di identit\u00e0 digitale?<\/h2>\n
\n
Dominio scaduto e recupero password: dove nasce il rischio?<\/h2>\n
mario@vecchiodominio.it<\/code><\/p>\nPyPI ha modificato il proprio sistema proprio per questo problema<\/h2>\n
Perch\u00e9 questo rischio \u00e8 particolarmente serio per gli sviluppatori?<\/h2>\n
\n
Un dominio scaduto permette di leggere le vecchie email?<\/h2>\n
\n
Il nuovo proprietario pu\u00f2 ricreare qualsiasi indirizzo email?<\/h2>\n
\n
info@dominio.it<\/code><\/li>\nadmin@dominio.it<\/code><\/li>\namministrazione@dominio.it<\/code><\/li>\nsupporto@dominio.it<\/code><\/li>\nwebmaster@dominio.it<\/code><\/li>\n<\/ul>\nCome potrebbe un estraneo scoprire i vecchi indirizzi?<\/h2>\n
\n
Il Domain Resurrection Attack \u00e8 uguale al domain hijacking?<\/h2>\n
\u00c8 la stessa cosa di una password compromessa?<\/h2>\n
La 2FA protegge da un dominio scaduto?<\/h2>\n
E le passkey?<\/h2>\n