Hakerzy przejęli około tuzina stron protokołów DeFi i wykradli około 138 000 dolarów użytkownikom, którzy korzystali ze skompromitowanych interfejsów. Wszystkie dotknięte strony łączył jeden wspólny szczegół: ich domeny były zarejestrowane przez Name.com. Incydent jest bezpośrednim przypomnieniem, że powierzchnia zaufania protokołu DeFi wykracza daleko poza kontrakty inteligentne, obejmując infrastrukturę webową serwującą interfejs użytkownika.

Co wiadomo o przejęciach stron DeFi

Zgodnie z doniesieniami The Block z 31 października 2026 r. atakujący przejęli kontrolę nad mniej więcej dwunastoma stronami DeFi i przekierowali użytkowników do złośliwych ścieżek, w wyniku których ukradziono około 138 000 dolarów.

Potwierdzone fakty pozostają wąskie: dotkniętych było około dwanaście stron DeFi, wszystkie zarejestrowane przez Name.com, a ukradziono około 138 000 dolarów środków użytkowników. Konkretne protokoły, dokładny wektor ataku i liczba poszkodowanych nie zostały potwierdzone w dostępnych doniesieniach. Sam wspólny rejestrator nie dowodzi związku przyczynowego, a Name.com nie zostało potwierdzone jako bezpośredni punkt awarii.

Co pozostaje niepotwierdzone

Według niepotwierdzonych doniesień wspólna rejestracja w Name.com może wskazywać na kompromitację poświadczeń lub przejęcie konta na poziomie rejestratora, co umożliwiłoby atakującym modyfikację rekordów DNS i przekierowanie ruchu domenowego bez ingerencji w same kontrakty inteligentne. Incydent mógł równie dobrze obejmować skompromitowane konta rejestratora, inżynierię społeczną lub zupełnie inny wektor.

To rozróżnienie ma znaczenie zarówno dla dotkniętych użytkowników, jak i zespołów protokołów: jeśli rekordy DNS zostały zmanipulowane, same kontrakty inteligentne on-chain mogą pozostać nietknięte, co oznacza, że skarbce protokołów i pule płynności mogą pozostać nienaruszone, podczas gdy straty ponieśli użytkownicy, którzy korzystali z podrobionych interfejsów.

Przejęcia front-endu routowane przez infrastrukturę domenową mają w branży precedens: w 2022 r. atakujący przekierowali DNS Curve Finance do złośliwego klonu jej interfejsu po skompromitowaniu konta u dostawcy domeny — to powszechnie przywoływane zdarzenie wprowadziło kontrole rejestratora i DNS na listy bezpieczeństwa zespołów DeFi. Precedens nie jest jednak dowodem — czy wspólna rejestracja w Name.com w tym przypadku była kluczowa, czy przypadkowa, mogą rozstrzygnąć wyłącznie ustalenia zespołów dotkniętych incydentem.

Jak przejęta strona DeFi naraża użytkowników

Kompromitacja front-endu różni się strukturalnie od eksploitacji kontraktu inteligentnego. Gdy atakujący kontrolują domenę, mogą serwować wizualnie identyczną kopię legalnego interfejsu, po cichu podmieniając punkty połączenia portfela, adresy kontraktów lub calldata transakcji. Użytkownik podpisujący pozornie rutynowe zatwierdzenie może w rzeczywistości autoryzować kontrakt drenujący do opróżnienia całego salda tokenów.

Co użytkownicy powinni zweryfikować przed podpisaniem transakcji

Przed połączeniem portfela lub podpisaniem jakiejkolwiek transakcji w interfejsie DeFi użytkownicy powinni niezależnie zweryfikować adres kontraktu, z którym wchodzą w interakcję, w oficjalnej dokumentacji protokołu, a nie tylko URL w przeglądarce. Framework Secure Transaction Verification and Authorization (STVA) opisuje konkretne kroki inspekcji calldata przed zatwierdzeniem. Domena, która poprawnie się rozwiązuje i wyświetla ważny certyfikat SSL, nie gwarantuje, że front-end nie został zmanipulowany na poziomie DNS lub hostingu.

Odporne na phishing portfele sprzętowe mogą wyświetlać szczegóły transakcji na ekranie urządzenia, niezależnie od przeglądarki, dając użytkownikom drugą warstwę weryfikacji. Mimo to zdeterminowany atakujący kontrolujący front-end może sformułować mylące opisy transakcji. Jedyną niezawodną ochroną jest weryfikacja docelowego adresu kontraktu względem kanonicznego wdrożenia on-chain protokołu, pochodzącego z oficjalnego repozytorium GitHub lub dokumentacji governance, a nie z połączonego interfejsu dApp.

Zatwierdzenia tokenów przyznane skompromitowanemu kontraktowi utrzymują się on-chain do momentu ich wyraźnego odwołania. Każdy użytkownik, który połączył portfel i podpisał transakcję w okresie, gdy strony znajdowały się pod kontrolą atakujących, powinien traktować aktywne zatwierdzenia jako potencjalnie złośliwe. Narzędzia do zarządzania zatwierdzeniami pozwalają audytować i odwoływać uprawnienia dla tokenów ERC-20, ale dopiero po niezależnym potwierdzeniu właściwych adresów kontraktów do odwołania i właściwej sieci.

Co powinni teraz zrobić użytkownicy i zespoły DeFi

Działania użytkowników

Użytkownicy, którzy korzystali z którejkolwiek z dotkniętych stron DeFi, powinni najpierw unikać łączenia portfeli lub podpisywania nowych transakcji, dopóki dany protokół publicznie nie potwierdzi, że front-end został przywrócony i zweryfikowany. Oficjalne komunikaty powinny pochodzić ze zweryfikowanych kont społecznościowych protokołu i forów governance, a nie z linków w wiadomościach bezpośrednich lub na czatach społeczności, które stanowią częsty wtórny wektor ataku po kompromitacji front-endu. Ponieważ dostępne doniesienia nie wymieniły dotkniętych protokołów, użytkownicy dowolnego front-endu DeFi powinni obserwować bezpośrednie ogłoszenia protokołów, z których korzystają, zamiast zakładać, że ich to nie dotyczy.

Dla użytkowników, którzy podpisali transakcje w okresie incydentu, odwołanie zatwierdzeń jest zalecane dopiero po potwierdzeniu właściwego złośliwego adresu kontraktu ze zweryfikowanego, niezależnego źródła. Odwołanie niewłaściwego kontraktu marnuje gas i daje fałszywe poczucie bezpieczeństwa. Protokoły takie jak Aave V4 publikują kanoniczne rejestry kontraktów, które mogą służyć jako punkt odniesienia do odróżniania legalnych kontraktów protokołu od drenów wdrożonych przez atakujących.

Reakcja zespołów protokołów

Dotknięte zespoły powinny traktować to jako aktywny incydent do czasu potwierdzenia pełnego łańcucha ataku. Bezpośrednie priorytety obejmują audyt logów dostępu do kont rejestratora domen, rotację wszystkich poświadczeń powiązanych z kontami Name.com, weryfikację bieżących rekordów DNS względem znanych dobrych migawek oraz sprawdzenie logów transparentności certyfikatów HTTPS pod kątem nieautoryzowanych certyfikatów wydanych w oknie ataku.

Zespoły powinny również zabezpieczyć wszystkie dowody incydentu przed wprowadzaniem zmian, ponieważ dane kryminalistyczne o oknie ataku — w tym logi zmian DNS i wszelka komunikacja z rejestratorem — będą potrzebne do ustalenia, co dokładnie zostało skompromitowane i kiedy. Publikacja przejrzystego, opatrzonego znacznikiem czasu raportu z incydentu po potwierdzeniu wektora ataku, zamiast spekulacyjnych komunikatów w trakcie dochodzenia, to standard, jakiego oczekują dotknięte społeczności.

Bezpieczeństwo kont u rejestratora domen, w tym wymuszenie uwierzytelniania dwuskładnikowego i blokady domen na poziomie rejestratora, to podstawowy krok utwardzenia, który zapobiega nieautoryzowanym modyfikacjom DNS nawet przy ważnych poświadczeniach atakującego. Blokada domeny uniemożliwia transfery i zmiany DNS bez wyraźnego potwierdzenia rejestratora, co czyni ją istotną kontrolą dla każdego protokołu, którego strona stanowi powierzchnię zaufania użytkownika dla transakcji z realnymi środkami.

Szersza lekcja

Strata 138 000 dolarów zgłoszona w około tuzinie protokołów jest umiarkowana w porównaniu z całkowitym TVL DeFi na Ethereum. Jednak ujawniona przez nią strukturalna podatność — mianowicie, że konto rejestratora web2 może stać się najsłabszym ogniwem w stosie bezpieczeństwa protokołu — dotyczy każdego projektu DeFi opierającego się centralnie zarejestrowanej domenie do serwowania interfejsu użytkownika. Bezpieczeństwo front-endu, w tym monitoring DNS, utwardzenie kont rejestratora i wskazówki dla użytkowników dotyczące niezależnej weryfikacji kontraktów, zasługuje na tę samą rygorystyczność operacyjną, jaką stosuje się przy audycie kontraktów inteligentnych.