Хакеры взломали примерно дюжину сайтов DeFi-протоколов и вывели около 138 000 долларов у пользователей, взаимодействовавших со скомпрометированными фронтендами. Все затронутые сайты объединяла одна деталь: домены были зарегистрированы через Name.com. Инцидент наглядно напоминает, что поверхность доверия DeFi-протокола простирается далеко за пределы его смарт-контрактов — до веб-инфраструктуры, обслуживающей его интерфейс.

Что известно о взломах DeFi-сайтов

Согласно сообщению The Block от 31 октября 2026 года, злоумышленники получили контроль примерно над двенадцатью DeFi-сайтами и перенаправляли пользователей на вредоносные сценарии, в результате чего было похищено около 138 000 долларов.

Подтвержденные факты ограничены: затронуто около двенадцати DeFi-сайтов, все они зарегистрированы через Name.com, а сумма похищенных средств пользователей составляет примерно 138 000 долларов. Конкретные протоколы, точный вектор атаки и число пострадавших не подтверждены в доступных отчетах. Сам по себе общий регистратор не доказывает причинно-следственную связь, и Name.com не подтвержден как прямая точка отказа.

Что остается неподтвержденным

По неподтвержденным данным, общая регистрация через Name.com может указывать на компрометацию учетных данных или захват учетной записи на уровне регистратора, что позволило бы злоумышленникам изменять DNS-записи и перенаправлять трафик домена, не затрагивая базовые смарт-контракты. Инцидент мог быть вызван скомпрометированными аккаунтами регистратора, социальной инженерией или совершенно иным вектором.

Это различие важно как для затронутых пользователей, так и для команд протоколов: если DNS-записи были изменены, сами ончейн-смарт-контракты могут остаться незатронутыми, а значит, казначейства протоколов и пулы ликвидности могут остаться нетронутыми, тогда как убытки понесли пользователи, взаимодействовавшие с поддельными фронтендами.

Угоны фронтендов через доменную инфраструктуру уже имеют прецеденты в отрасли: в 2022 году злоумышленники перенаправили DNS Curve Finance на вредоносную копию интерфейса, скомпрометировав аккаунт у доменного провайдера — широко цитируемый случай, который добавил контроль за регистратором и DNS в чек-листы безопасности DeFi-команд. Однако прецедент — не доказательство: был ли общий регистратор Name.com в данном случае центральным фактором или случайным совпадением, могут определить только выводы расследования самих затронутых команд.

Как взломанный DeFi-сайт подвергает пользователей риску

Компрометация веб-фронтенда структурно отличается от эксплойта смарт-контракта. Когда злоумышленники контролируют домен, они могут показывать визуально идентичную копию легитимного интерфейса, незаметно подменяя конечные точки подключения кошелька, адреса контрактов или calldata транзакций. Пользователь, подписывающий, казалось бы, рутинное одобрение, на самом деле может авторизовать дрейнер-контракт на вывод всего баланса его токенов.

Что пользователи должны проверить перед подписанием любой транзакции

Прежде чем подключать кошелек или подписывать транзакцию в DeFi-интерфейсе, пользователи должны самостоятельно сверить адрес контракта с официальной документацией протокола, а не только с URL в браузере. Фреймворк безопасной проверки и авторизации транзакций (STVA) описывает конкретные шаги по проверке calldata перед одобрением. Корректно разрешающийся домен с действительным SSL-сертификатом не гарантирует, что фронтенд не был изменен на уровне DNS или хостинга.

Аппаратные кошельки, устойчивые к фишингу, могут отображать детали транзакции на экране устройства независимо от браузера, обеспечивая второй уровень проверки. Тем не менее решительный злоумышленник, контролирующий фронтенд, может составить вводящие в заблуждение описания транзакций. Единственная надежная защита — сверка адреса контракта назначения с каноническим ончейн-развертыванием протокола, взятым из официального репозитория GitHub или документации управления, а не из подключенного интерфейса dApp.

Одобрения токенов, выданные скомпрометированному контракту, сохраняются в блокчейне до явной отмены. Любой пользователь, подключивший кошелек и подписавший транзакцию в период, когда сайты находились под контролем злоумышленников, должен считать действующие одобрения потенциально вредоносными. Инструменты управления одобрениями позволяют аудитировать и отзывать разрешения для токенов ERC-20, но только после самостоятельного подтверждения правильных адресов контрактов для отзыва и правильной сети.

Что должны делать пользователи и DeFi-команды

Действия пользователей

Пользователи, взаимодействовавшие с любым из затронутых DeFi-сайтов, должны сначала воздержаться от подключения кошельков и подписания новых транзакций, пока соответствующий протокол публично не подтвердит, что фронтенд восстановлен и проверен. Официальные сообщения следует черпать из верифицированных социальных аккаунтов протокола и форумов управления, а не из ссылок в личных сообщениях или чатах сообществ, которые являются распространенным вторичным вектором атаки после компрометации фронтенда. Поскольку доступные отчеты не называют затронутые протоколы, пользователям любых DeFi-интерфейсов следует следить за прямыми объявлениями используемых ими протоколов, а не предполагать, что они не пострадали.

Для пользователей, все же подписавших транзакции в период инцидента, отзыв одобрений целесообразен только после подтверждения правильного вредоносного адреса контракта из верифицированного независимого источника. Отзыв не того контракта приводит к напрасной трате газа и создает ложное чувство безопасности. Такие протоколы, как Aave V4, публикуют канонические реестры контрактов, которые могут служить ориентиром для отличия легитимных контрактов протокола от развернутых злоумышленниками дрейнеров.

Реакция команд протоколов

Затронутым командам следует рассматривать это как активный инцидент, пока не подтверждена полная цепочка атаки. Первоочередные задачи включают аудит журналов доступа к аккаунтам регистратора доменов, ротацию всех учетных данных, связанных с аккаунтами Name.com, сверку текущих DNS-записей с заведомо корректными снимками и проверку журналов прозрачности HTTPS-сертификатов на предмет несанкционированных сертификатов, выпущенных в период атаки.

Командам также следует сохранить все доказательства инцидента до внесения изменений, так как для установления того, что именно было скомпрометировано и когда, потребуются криминалистические данные о периоде атаки, включая журналы изменений DNS и любую переписку с регистратором. Публикация четкого отчета об инциденте с временными метками после подтверждения вектора атаки, а не спекулятивных сообщений в ходе расследования — это тот стандарт, которого ожидает затронутое сообщество.

Безопасность аккаунтов регистратора доменов, включая принудительную двухфакторную аутентификацию и блокировку домена на уровне регистратора, — это базовый шаг укрепления защиты, предотвращающий несанкционированное изменение DNS-записей, даже когда учетные данные злоумышленника валидны. Блокировка домена предотвращает передачу и изменения DNS без явного подтверждения регистратора, что делает ее значимой мерой для любого протокола, чей сайт представляет собой ориентированную на пользователей поверхность доверия для транзакций с реальными средствами.

Более широкий урок

Убыток в 138 000 долларов, о котором сообщается по примерно дюжине протоколов, скромен на фоне общего TVL DeFi на Ethereum. Но структурная уязвимость, которую он обнажает, — а именно то, что аккаунт web2-регистратора может стать самым слабым звеном в стеке безопасности протокола, — применима к любому DeFi-проекту, полагающемуся на централизованно зарегистрированный домен для обслуживания своего пользовательского интерфейса. Безопасность фронтенда, включая мониторинг DNS, укрепление аккаунтов регистратора и обучение пользователей самостоятельной проверке контрактов, заслуживает той же операционной строгости, что и аудит смарт-контрактов.