Hacker hanno dirottato circa una dozzina di siti web di protocolli DeFi e svuotato circa 138.000 dollari dagli utenti che hanno interagito con le front-end compromesse. Ogni sito interessato condivideva un dettaglio comune: il dominio era registrato tramite Name.com. L'incidente ricorda direttamente che la superficie di fiducia di un protocollo DeFi si estende ben oltre i suoi smart contract, fino all'infrastruttura web che serve la sua interfaccia utente.

Cosa si sa sui dirottamenti dei siti DeFi

Secondo quanto riportato da The Block il 31 ottobre 2026, gli aggressori hanno ottenuto il controllo di circa dodici siti DeFi e hanno reindirizzato gli utenti verso flussi dannosi che hanno comportato circa 138.000 dollari di fondi rubati.

I fatti confermati restano ristretti: circa dodici siti web DeFi sono stati colpiti, tutti registrati tramite Name.com, e circa 138.000 dollari di fondi utente sono stati rubati. I protocolli specifici presi di mira, il vettore d'attacco preciso e il numero delle singole vittime non sono stati confermati dalle fonti disponibili. La registrazione condivisa da sola non stabilisce un rapporto causale, e Name.com non è stato confermato come punto di guasto diretto.

Cosa resta non confermato

Secondo rapporti non confermati, la registrazione condivisa su Name.com potrebbe indicare una compromissione delle credenziali o un account takeover a livello di registrar, che avrebbe permesso agli aggressori di modificare i record DNS e reindirizzare il traffico dei domini senza toccare gli smart contract sottostanti. L'incidente potrebbe altresì aver coinvolto account di registrar compromessi, ingegneria sociale o un vettore completamente diverso.

Questa distinzione è importante sia per gli utenti interessati sia per i team dei protocolli: se i record DNS sono stati manomessi, gli smart contract on-chain potrebbero essere rimasti illesi, il che significa che le treasuries dei protocolli e i pool di liquidità potrebbero essere rimasti intatti, mentre gli utenti che hanno interagito con le front-end contraffatte hanno subito le perdite.

I dirottamenti di front-end instradati attraverso l'infrastruttura dei domini hanno precedenti nel settore: nel 2022, gli aggressori hanno reindirizzato il DNS di Curve Finance verso un clone dannoso della sua interfaccia dopo aver compromesso un account del fornitore di domini, un episodio ampiamente citato che ha inserito i controlli su registrar e DNS nelle checklist di sicurezza dei team DeFi. Il precedente, tuttavia, non è una prova: se la registrazione condivisa su Name.com in questo caso fosse stata centrale o marginale potrà essere stabilito solo dalle conclusioni dell'inchiesta dei team interessati.

Come un sito DeFi dirottato mette a rischio gli utenti

Una compromissione della front-end web è strutturalmente diversa da un exploit di smart contract. Quando gli aggressori controllano un dominio, possono servire una copia visivamente identica dell'interfaccia legittima sostituendo silenziosamente gli endpoint di connessione del wallet, gli indirizzi dei contratti o i calldata delle transazioni. Un utente che firma ciò che sembra un'approvazione di routine potrebbe in realtà autorizzare un contratto drainer a spazzare via l'intero saldo dei suoi token.

Cosa dovrebbero verificare gli utenti prima di firmare qualsiasi transazione

Prima di collegare un wallet o firmare qualsiasi transazione su un'interfaccia DeFi, gli utenti dovrebbero verificare in modo indipendente l'indirizzo del contratto con cui interagiscono confrontandolo con la documentazione ufficiale del protocollo, non solo con l'URL nel browser. Il framework Secure Transaction Verification and Authorization (STVA) illustra i passaggi specifici per ispezionare i calldata prima dell'approvazione. Un dominio che risolve correttamente e mostra un certificato SSL valido non garantisce che la front-end non sia stata manomessa a livello DNS o di hosting.

Gli hardware wallet resistenti al phishing possono visualizzare i dettagli delle transazioni sullo schermo del dispositivo, indipendentemente dal browser, offrendo agli utenti un secondo livello di verifica. Anche così, un aggressore determinato che controlla la front-end può creare descrizioni di transazioni fuorvianti. L'unica protezione affidabile è verificare l'indirizzo del contratto di destinazione rispetto al deployment on-chain canonico del protocollo, ricavato dal repository GitHub ufficiale o dalla documentazione di governance anziché dall'interfaccia dApp collegata.

Le approvazioni dei token concesse a un contratto compromesso persistono on-chain fino alla revoca esplicita. Qualsiasi utente che abbia collegato un wallet e firmato una transazione durante la finestra in cui questi siti erano sotto il controllo degli aggressori dovrebbe considerare potenzialmente dannose le approvazioni in sospeso. Gli strumenti di gestione delle approvazioni consentono agli utenti di verificare e revocare i permessi sui token ERC-20, ma solo dopo aver confermato in modo indipendente i corretti indirizzi dei contratti da revocare e la rete corretta su cui operare.

Cosa dovrebbero fare ora gli utenti e i team DeFi

Azioni degli utenti

Gli utenti che hanno interagito con uno qualsiasi dei siti DeFi interessati dovrebbero innanzitutto evitare di collegare wallet o firmare nuove transazioni finché il protocollo interessato non confermi pubblicamente che la front-end è stata ripristinata e verificata. Le comunicazioni ufficiali dovrebbero provenire dagli account social verificati del protocollo e dai forum di governance, non da link incorporati in messaggi diretti o chat di community, che rappresentano un comune vettore d'attacco secondario dopo la compromissione di una front-end. Poiché le fonti disponibili non hanno nominato i protocolli interessati, gli utenti di qualsiasi front-end DeFi dovrebbero fare attenzione agli annunci diretti dei protocolli che utilizzano anziché dare per scontato di non essere stati coinvolti.

Per gli utenti che hanno firmato transazioni durante la finestra dell'incidente, la revoca delle approvazioni è consigliabile solo dopo aver confermato il corretto indirizzo del contratto dannoso da una fonte verificata e indipendente. Revocare il contratto sbagliato spreca gas e offre una falsa sicurezza. Protocolli come Aave V4 pubblicano registri di contratti canonici che possono servire come punto di riferimento per distinguere i contratti legittimi del protocollo dai drainer distribuiti dagli aggressori.

Risposta dei team dei protocolli

I team interessati dovrebbero trattare questo come un incidente attivo finché l'intera catena d'attacco non sarà confermata. Le priorità immediate includono l'audit dei log di accesso degli account del registrar dei domini, la rotazione di tutte le credenziali associate agli account Name.com, la verifica dei record DNS attuali rispetto a snapshot noti come validi e il controllo dei log di trasparenza dei certificati HTTPS per individuare eventuali certificati non autorizzati emessi durante la finestra dell'attacco.

I team dovrebbero inoltre preservare tutte le prove dell'incidente prima di apportare modifiche, poiché i dati forensi relativi alla finestra dell'attacco — inclusi i log delle modifiche DNS e ogni comunicazione con il registrar — saranno necessari per stabilire esattamente cosa è stato compromesso e quando. Pubblicare un rapporto sull'incidente chiaro e con indicazione temporale una volta confermato il vettore d'attacco, anziché emettere comunicazioni speculative durante l'indagine, è lo standard che le community interessate si aspettano.

La sicurezza degli account presso il registrar dei domini, inclusa l'applicazione dell'autenticazione a due fattori e i lock dei domini a livello di registrar, è una fase di rafforzamento di base che previene modifiche DNS non autorizzate anche quando le credenziali degli aggressori sono valide. Il domain locking impedisce trasferimenti e modifiche DNS senza conferma esplicita del registrar, rendendolo un controllo significativo per qualsiasi protocollo il cui sito web rappresenta una superficie di fiducia rivolta agli utenti per transazioni che coinvolgono fondi reali.

La lezione più ampia

La perdita di 138.000 dollari riportata su circa una dozzina di protocolli è contenuta rispetto al TVL totale DeFi su Ethereum. Ma la vulnerabilità strutturale che espone — ovvero che un account registrar web2 può diventare l'anello più debole nella catena di sicurezza di un protocollo — si applica a qualsiasi progetto DeFi che si affidi a un dominio registrato centralmente per servire la propria interfaccia utente. La sicurezza delle front-end, inclusi il monitoraggio DNS, il rafforzamento degli account registrar e la guida agli utenti sulla verifica indipendente dei contratti, merita lo stesso rigore operativo applicato all'auditing degli smart contract.