~418 млн $ потеряно: эксплойты Bitget и NEAR Intents

За последние две недели (21.09.2026 - 04.10.2026) произошло 8 инцидентов в сфере безопасности блокчейна, которые привели к совокупным оценочным убыткам около $418,4 млн.

Дата	Инцидент	Тип	Оценочный убыток
2026/09/23	Meter Passport	Ошибка валидации блоков	~$2,3M
2026/09/24	Payy Network	Предполагаемая уязвимость надежности системы доказательств	~$1,9M
2026/09/24	Limit Break	Некорректная проверка calldata	~$7,7M
2026/09/24	Duelbits	Основная причина не раскрыта	~$7M
2026/09/24	Bitget	Уязвимость в стороннем продукте безопасности	~$387,5M
2026/09/27	DYORSwap	Недостаточная проверка конфигурации сети	~$2,1M
2026/09/30	NEAR Intents	Некорректная валидация возврата и отсутствие отката	~$3,9M
2026/10/04	Неназванный Base Vault	Некорректный контроль доступа	~$6M

Причины выбора

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

Bitget

24 сентября около $387,5 млн были выведены из частей горячей и теплой инфраструктуры кошельков Bitget в сетях Ethereum и других EVM-сетях, XRP Ledger, Zcash и TRON. Транзакции на блокчейне содержали действительные подписи кошельков. Bitget сообщила, что злоумышленник использовал уязвимость в стороннем продукте безопасности, получил учетные данные для доступа к внутренней сети и подделал команды на вывод средств, при этом приватные ключи и холодные кошельки оставались в безопасности[1][2].

Обзор инцидента

Отчеты независимых расследований дополняют детали пути атаки, не называя два затронутых продукта безопасности. SlowMist отследила самую раннюю вредоносную активность в отношении Продукта A до 31 августа и выявила уязвимость нулевого дня, затрагивающую сервис на одном узле. Mandiant обнаружила привилегированный доступ к двум устройствам безопасности, веб-шелл и соединение с командным центром (C&C) в Продукте B, а также перемещение по сети к производственному серверу обработки заданий кошелька.

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

Данные на блокчейне показывают, что первые перемещения составили 93 TRX, а 11 секунд позже — 0,84 ETH в 18:31 UTC. Текущая хронология Bitget фиксирует обнаружение несоответствия в 19:05 UTC и активацию экстренного реагирования высшего уровня в 19:14 UTC[1]. Отдельный перевод в размере 20,59 млн TRX поступил на адрес TRON, контролируемый злоумышленником, в 19:16 UTC; Чен описал 17 более крупных переводов в восьми других сетях на общую сумму примерно $361M[3]. Сдерживание инцидента началось в 19:40 UTC, а сервисы вывода и подписания кошельков были остановлены в 21:44 UTC[1].

Состояние средств и реакция сообщества

В 16:35:28 UTC 29 сентября официальный трекер активов Bitget сообщил о $322,67 млн текущих активов злоумышленника, около $632 700 заморожено, $312 500 в стейблкоинах, которые могут быть заморожены эмитентом, и $55,87 млн в пути или еще находящихся на анализе. Отдельное представление по адресам показало, что балансы сосредоточены в BTC ($288,51M), ZEC ($28,91M) и ETH ($7,17M); это представление использует иной охват классификации, отличный от общего обзора.

Binance поделилась разведывательными данными и поддержала трассировку средств, в то время как Bybit обновила LazarusBounty и предложила помощь[4][5]. Поставщики инфраструктуры сделали разные решения. Bitget попросила THORChain отказать в обслуживании перечисленным адресам злоумышленника, аргументируя это тем, что децентрализация не должна защищать циркуляцию известных похищенных средств[6]. THORChain отказалась от выборочного блокирования, заявив, что их средства контроля могут остановить более широкую активность или маршрут цепочки, но не отдельный адрес или транзакцию[7].

NEAR Intents сообщила, что SHIELD выявила и блокировала более $50M попыток потоков, связанных со злоумышленником, после фильтрации дублирующихся записей. Приблизительно $503 000 было заморожено во время выполнения, и около $166 000 прошло через систему; цифра $50M представляет собой попытку потока, а не замороженную или возвращенную сумму[8]. Трекер позже классифицировал $293 507 как замороженные на NEAR Intents, и публичные источники не объясняют эту разницу.

Извлеченные уроки

Злоумышленник проник через сторонние продукты безопасности, достиг сервера обработки заданий кошелька и превратил подделанные запросы на вывод в корректно подписанные транзакции. Любой сторонний продукт с таким уровнем доступа относится к реальной границе безопасности активов: организациям следует изолировать такие продукты, ограничивать идентификаторы и привилегии, отслеживать их поведение и независимо проверять намерение на вывод средств перед подписанием.
Полномочия на восстановление были распределены между биржами, эмитентами стейблкоинов, сервисами маршрутизации и базовыми протоколами, поэтому ни один участник не мог управлять реагированием самостоятельно. Затронутой организации необходимо быстро делиться проверенными адресами и данными транзакций, в то время как поставщики инфраструктуры и команды безопасности координируют трассировку, заморозку, проверку транзакций и восстановление в рамках своих технических и управленческих ограничений.
Превентивные меры контроля, вытекающие из этого инцидента, описаны в материале Внесетевой взлом Bitget на $387,5 млн: за пределами ключей и контрактов, в котором разработана многоуровневая защитная концепция для привилегированного доступа, намерения на вывод, мониторинга потока активов и экстренного реагирования.

NEAR Intents

Между 30 сентября и 1 октября NEAR Intents потеряла около $3,87 млн после того, как ошибка валидации возврата и отсутствие отката состояния в intents.near создали внутренний баланс без соответствующего обеспечения активами. Злоумышленник использовал этот баланс для получения действительных подписей на вывод от HOT MPC и вывода реального USDT из хранилища протокола в сети BNB Chain[9][10].

Контекст

NEAR Intents — это система выполнения намерений (intents) на базе NEAR. Её основной контракт, intents.near, хранит omni-активы, записывает внутренние балансы пользователей и обрабатывает обмены активами и выводы на основе подписанных намерений.

При межсетевом депозите хранилище в исходной сети блокирует реальный актив. Omni создает соответствующий omni-актив на NEAR и передает его в intents.near, который начисляет его на внутренний баланс пользователя.

При выводе средств intents.near запрашивает у Omni сжигание соответствующего omni-актива и создание записи о выводе. HOT MPC проверяет эту запись и выпускает подпись. Хранилище целевой сети проверяет подпись перед выпуском реального актива. Этот процесс требует, чтобы внутренние балансы, записанные intents.near, оставались обеспеченными omni-активами, которыми контракт фактически владеет.

Анализ уязвимости

Путь депозита начислял внутренний баланс получателя до того, как межконтрактный перевод был полностью разрешен. Во время разрешения resolve_deposit_internal() ограничивала контролируемое получателем значение requested_refund общим балансом получателя по данному токену, но не величиной deposited — суммой, фактически переданной в рамках разрешаемого депозита. Общий баланс отражал лишь то, что счет может оплатить; deposited определял, что данный конкретный перевод мог вернуть. Без этого второго ограничения получатель с большим предварительно существующим балансом мог запросить возврат, значительно превышающий текущий депозит[10].

Для пакетного депозита с большим количеством длинных идентификаторов токенов некорректные значения возврата увеличивали сериализованный MtBurnEvent. Путь check_refund().unwrap_or_panic_display().emit() затем вызывал панику при превышении событием общего лимита длины лога NEAR, что приводило к сбою получения (receipt) mt_resolve_deposit.

Внутренний баланс был начислен в более раннем receipt. Паника откатывала попытки вычитания баланса и предложения в receipt обратного вызова, но не отменяла это более раннее начисление. Omni затем возвращала переданные активы отправителю, оставляя у злоумышленника выводимый внутренний баланс, который больше не соответствовал omni-активам, удерживаемым intents.near. Уязвимость объединяла ошибку валидации возврата с отсутствием отката состояния в асинхронной последовательности receipt.

Анализ атаки

Нижеследующая реконструкция основана на общедоступной информации[11].

Этап 1: Создание необеспеченного внутреннего баланса на NEAR

Шаг 1: Злоумышленник внес депозит в размере 10 USDT через хранилище Omni/HOT в сети BNB Chain, в результате чего вредоносный аккаунт-получатель получил ненулевой баланс omni-актива на NEAR.
Шаг 2: Злоумышленник вызвал mt_batch_transfer_call() на v2_1.omni.hot.tg. В mt_on_transfer() intents.near сначала начислил баланс получателю через deposit(), затем уведомил вредоносного получателя и передал его ответ в mt_resolve_deposit().
Шаг 3: Вредоносный получатель вернул значение requested_refund, значительно превышающее текущий депозит. Поскольку валидация использовала общий баланс токена получателя как верхнюю границу, аномальное значение прошло в обработку возврата.
Шаг 4: В пакетных записях завышенные значения возврата увеличили сериализованный MtBurnEvent до превышения общего лимита длины лога NEAR. Обратный вызов mt_resolve_deposit вызвал панику, что откатило его попытки вычитания возврата, но не отменило внутреннее начисление, зафиксированное более ранним receipt. Omni вернул переданные активы, в то время как начисленный баланс оставался доступным в intents.near. Повторение этой последовательности создало необеспеченный баланс, который злоумышленник мог вывести.

Этап 2: Вывод реальных активов из хранилища BNB Chain

Шаг 5: В 18:57 и 20:05 UTC 30 сентября злоумышленник использовал действительные авторизации HOT MPC для проверки хранилища BNB Chain с выводами 10 USDT и 11 USDT. Первая тестовая транзакция подтвердила, что хранилище приняло вышестоящую авторизацию.

Шаг 6: С 23:54 UTC 30 сентября до 06:08 UTC 1 октября злоумышленник выполнил пять более крупных выводов: 800 000 USDT, 1,2 млн USDT, 1,5 млн USDT, 330 000 USDT и 35 000 USDT. Эти транзакции вывели из хранилища в общей сложности 3,865 млн USDT.

Заключение

NEAR Intents была атакована через некорректную валидацию возврата и отсутствие отката после сбоя разрешения депозита. Злоумышленник использовал завышенные запросы на возврат для сохранения внутреннего кредита после того, как исходные активы были возвращены, а затем использовал этот необеспеченный баланс для запроса выводов. Omni создавала соответствующие записи о выводе, HOT MPC подписывала их, а хранилище BNB Chain выпускало реальный USDT.

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

Источники

[1] https://www.bitget.com/academy/bitget-security-incident-what-happened-timeline-impact-response

[2] https://x.com/GracyBitget/status/2104515761691939026

[3] https://www.theblock.co/news/regulation/2026-09-28-bitget-attacker-tested-risk-controls-small-transfers-388-million-theft-ceo-says-417045

[4] https://www.binance.com/en/square/post/09-25-2026-binance-news-richard-teng-puts-binance-s-security-muscle-behind-an-industry-wide-response-370442242243629

[5] https://x.com/benbybit/status/2103328213141508335

[6] https://x.com/GracyBitget/status/2103812967066439817

[7] https://www.coindesk.com/tech/2026/09/28/thorchain-rejects-bitget-request-to-block-hacker-as-usd6-million-moves-to-bitcoin

[8] https://x.com/GracyBitget/status/2104602301503816040

[9] https://x.com/near_intents/status/2105642219357241796

[10] https://github.com/near/intents/pull/362

[11] https://x.com/Phalcon_xyz/status/2105680009687957909

О компании BlockSec

BlockSec — это универсальный поставщик услуг в области безопасности блокчейна и криптовалютного соответствия нормативным требованиям. Мы создаем продукты и услуги, которые помогают клиентам проводить аудит кода (включая смарт-контракты, блокчейн и кошельки), перехватывать атаки в реальном времени, анализировать инциденты, отслеживать незаконные средства и выполнять обязательства по AML/CFT на протяжении всего жизненного цикла протоколов и платформ.

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