23 июля 2026 года из стейкинг-контракта B² Network вывели токены B2 примерно на $3,9 млн. Случай примечателен тем, что хакер не ломал код в привычном смысле. Злоумышленник завладел служебным ключом, которым проект обновляет свои контракты, тихо подменил их «начинку» и заставил контракт сам отдать средства. А дальше похищенное растворилось в четырех сетях.
Аналитики BitOK выяснили, как именно мошенник использовал «золотой ключик» и где осели украденные деньги.
Содержание:
Как из стейкинга B² Network вывели около $3,9 млн
Вот какие шаги предпринял хакер
Как двигались похищенные средства
Куда в итоге ушли средства
Ключевые адреса
Общая картина
Какой урок стоит извлечь
Как из стейкинга B² Network вывели около $3,9 млн
Первое, что важно понять: слабым местом был не код контракта, а условия права доступа, которые позволяют его менять. Перед тем как продолжить, коротко напомним значение трех терминов, которые нам понадобятся:
Стейкинг — размещение токенов в специальном контракте ради вознаграждения. В таком контракте B² Network хранились токены B2.
Обновляемый контракт (proxy). Многие смарт-контракты устроены так, что их логику можно обновлять: внешний адрес остается прежним, а «начинка» — правила, по которым он работает, — заменяется на новую версию. Право на такое обновление есть только у владельца доверенного служебного ключа (upgrade-ключа).
Компрометация ключа — ситуация, когда доверенный ключ попадает в чужие руки. Злоумышленнику не нужно ломать контракт. Он может беспрепятственно установить свою версию правил работы системы. Именно это здесь и произошло.
Заметка инвестигейтора: инцидент возник не из-за ошибки расчета в контракте и не из-за уязвимости, которую мог бы повторить любой пользователь. Злоумышленник получил доступ к полномочиям обновления, подменил рабочую логику контракта и заставил его переводить B2 на свой кошелек. Как именно был получен контроль над ключом — кража, компрометация инфраструктуры или действие инсайдера — не установлено.
Простая аналогия, которая поможет понять суть эксплойта. Представьте офис, где все платежи проводит робот-кассир — строго по инструкции, которая лежит в сейфе. Сам кассир неподкупен и не ошибается: он лишь исполняет написанное. Но у технического администратора есть право переписывать эту инструкцию. Злоумышленник получил доступ администратора и дописал в регламент строчку: «по такому-то сигналу перевести все средства на этот счет». Кассир, ничего не нарушая, выполнил новую инструкцию. Ломать его не пришлось — подменили не исполнителя, а правила, которым он подчиняется.
Вот главное об инциденте:
Ущерб — около $3,9 млн в токенах B2.
Тип атаки — компрометация административного доступа.
Что стало со средствами — B2 продали за BNB, консолидировали и распределили по нескольким сетям и сервисам. Публичный след уходит в приватный сервисный слой.
Вот какие шаги предпринял хакер
Получение привилегированного доступа. Злоумышленник получил контроль над адресом, который проект уже использовал для обновлений стейкинг-контракта.
Подготовка вредоносной версии. Он развернул новую реализацию контракта — с функцией, способной переводить B2 на любой заданный адрес.
Подмена логики. Через штатный механизм обновления контракт переключили на эту вредоносную версию. Адрес стейкинг-контракта остался прежним, но его поведение изменилось.
Вывод B2. Новая функция заставила контракт отправить хранившиеся в нем токены на основной кошелек злоумышленника (в отчете он обозначен как Exploiter 1).
Продажа и распределение. Токены продали за BNB, выручку перевели на второй кошелек (Exploiter 2) и разделили между маршрутами в разных сетях.
Важно! Не было ни повторного вывода средств из-за ошибки в коде, ни манипуляции ценовым оракулом, ни сбоя в начислении наград. Определяющим событием стала именно несанкционированная подмена логики контракта.
Как двигались похищенные средства
Получив B2, злоумышленник не стал держать активы в исходном токене. Их продали через торговую инфраструктуру LiquidMesh. Полученные BNB/WBNB собрали на втором кошельке, WBNB конвертировали обратно в обычный BNB. Так поток разделился на несколько ветвей.
Заметка инвестигейтора. WBNB — это «обернутая» версия BNB, технический формат монеты для торговли. Перевод обратно в BNB упростил хакеру дальнейшие переводы.
Возвращаемся к маршруту переводов:
Маршрут A — напрямую в NEAR. Часть BNB и USDT ушла с BNB Chain на одноразовые депозитные адреса сервиса NEAR Intents. Оттуда средства собрал служебный узел HOT Bridge Treasury — то есть деньги вошли в официальный сервисный контур NEAR.
Маршрут B — через Ethereum и снова в NEAR. Крупная часть потока прошла через сервисы Relay и Bridgers и появилась в сети Ethereum в виде ETH. Ethereum был лишь промежуточной площадкой. После ETH распределили по одноразовым адресам, тоже связанным с конфиденциальными депозитами NEAR Intents.
Маршрут C — Solana. Отдельную часть BNB конвертировали через мосты в SOL, разделили между двумя адресами, а затем снова собрали на общем кошельке-коллекторе. Это последний уверенно прослеживаемый публичный узел ветки.
Две внешне разные ветки — прямая с BNB Chain и обходная через Ethereum — в итоге сходятся в одном месте: сервисном слое NEAR Intents. А это важно для понимания, почему след теряется.
Как мошенник переводил деньги. Граф построен при помощи инструмента Graph от BitOK.
Заметка инвестигейтора: поступление на депозит NEAR Intents не раскрывает конечного получателя автоматически. Сервис исполняет намерение пользователя через внутренние расчеты и служебные адреса, поэтому отслеживание показывает вход в систему, но не всегда позволяет связать его с последующим выходом.
Отдельно стоит упомянуть предполагаемый, но не доказанный выход в Zcash. Внутри инфраструктуры NEAR/HOT замечены операции с ZEC. Это может указывать на конвертацию части средств в Zcash, но публичный адрес вывода, который удалось бы доказательно связать с похищенным, не установлен. Поэтому Zcash — гипотеза направления, а не подтвержденная конечная точка.
Куда в итоге ушли средства
Публично средства удается проследить до нескольких границ. Важно различать последний видимый узел и фактического конечного владельца: сервисный депозит или мост могут быть лишь промежуточной точкой, а не карманом злоумышленника.
Ветка;Движение;Последняя видимая точка;Статус
NEAR (напрямую);BNB/USDT → депозиты → HOT Treasury;Сервисный слой NEAR Confidential Intents;Подтверждено
Ethereum;Relay/Bridgers → ETH → одноразовые депозиты;NEAR Intents после промежуточного Ethereum;Подтверждено
Solana;BNB → SOL → разделение → консолидация;Коллектор 6tckH…LoDQ;Подтверждено
Zcash;Внутренние операции NEAR/HOT с ZEC;Адрес вывода не установлен;Гипотеза
Итог: основная часть отслеживаемого потока ушла в NEAR Confidential Intents — частично напрямую, частично через Ethereum. Еще одна подтвержденная ветка завершилась на Solana-коллекторе. После входа в NEAR однозначная публичная связь с конечными кошельками теряется, а доказательств полного вывода в Zcash нет.
Важно! NEAR Intents смешивает депозиты множества пользователей и работает с ними через внутренние служебные кошельки. Один вход не обязательно соответствует одному выходу, а совпадение сумм или близость операций по времени сами по себе ничего не доказывают. Для окончательной деанонимизации нужны внутренние данные сервиса — записи о заявках, депозитах и выводах.
Ключевые адреса
Роль;Адрес;Пояснение
Стейкинг-контракт B2 (жертва);0xf0C1…3B94;Контракт, из которого вывели B2
Upgrade operator;0x35fe…287d;Скомпрометированный привилегированный адрес
Вредоносная реализация;0x0b87…9dca;Подмененная логика контракта
Exploiter 1;0xEc44…F433;Получение и продажа B2
Exploiter 2;0xf977…Bf6D;Распределение выручки по сетям
HOT Bridge Treasury;0x233c…B4Cd;Служебный узел NEAR, не адрес атакующего
Solana-коллектор;6tckH…LoDQ;Последний видимый узел Solana-ветки
Ключевым активом злоумышленника был не капитал и не хитрая рыночная схема, а доступ к доверенному ключу обновления. Завладев им, он подменил логику стейкинг-контракта, заставил его отдать B2, продал их за BNB и увел выручку сразу по нескольким сетям, сведя большую часть в приватный сервисный слой NEAR.
Разнесение по маршрутам и уход в конфиденциальные депозиты говорят о том, что запутывание следов планировалось заранее.
Какой урок стоит извлечь
Главный вывод этой истории в том, что смарт-контракт безопасен ровно настолько, насколько защищено право менять его логику.
Ключ обновления — это ключ от всех денег. Здесь не было дыры в коде: контракт честно исполнил новую логику, которую поставил обладатель доверенного ключа. Значит, безопасность проекта определяется тем, насколько надежно хранится и насколько ограничен этот ключ. Одинокий upgrade-ключ на обычном рабочем компьютере — это единственная точка отказа, компрометация которой разрушила все.
Право обновления нужно рассредоточить. Разумная защита — передать его под мультиподпись с несколькими независимыми участниками и обязательной задержкой (таймлоком), при которой у команды и пользователей есть время заметить подозрительное обновление и вмешаться. Плюс автоматические тревоги на смену логики контракта и нетипичные переводы из хранилища.
В нашем случае деньги ушли не в один миксер, а в конфиденциальный сервисный слой через четыре сети. Отследить вход удалось, а вот конечного получателя — уже нет. Это лишний раз доказывает, что вернуть средства после такого вывода крайне сложно. Стоимость защиты ключей несопоставимо ниже цены, которую придется заплатить за эксплойт.