Взлом Bitget на $387,5 млн вне блокчейна: не только ключи и контракты

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

На основе публичных заявлений и ончейн-доказательств, доступных по состоянию на 29 сентября 2026 года, 16:35 UTC, в первой части приводится краткое изложение раскрытой последовательности атаки, последующих перемещений средств, восстановления сервисов и различных ответных действий участников экосистемы. Во второй части эти наблюдения сочетаются с нашим опытом в области безопасности для представления комплексной (эшелонированной) системы защиты для криптоинституций, а также практических рекомендаций по безопасности.

1. От офчейн-доступа к ончейн-потере и восстановлению

Bitget связала точку входа с уязвимостью в стороннем продукте безопасности, но не раскрыла ни сам продукт, ни затронутый компонент, ни техническую механику эксплуатации [1, 2]. В её публичном описании нисходящий путь атаки представлен как: внутренний доступ, поддельные команды на вывод средств, обход проверки рисков, действительные подписи и ончейн-переводы.

1.1 Хронология атаки и атрибуция

Хронология, представленная генеральным директором Bitget Грейси Чен, вместе с ончейн-данными, показывает, как развивался инцидент [3]:

• 18:31 UTC, 24 сентября: первые перемещения составили 0,84 ETH и 93 TRX. Оба значения были ниже порога риск-контроля биржи.
• 18:58–20:09 UTC: Чен описала семнадцать более крупных переводов через Ethereum, XRP Ledger, Zcash, BNB Chain, Base, Arbitrum, Optimism и Avalanche на общую сумму около 361 млн долларов [3]. Ончейн-данные также показывают перевод 20,59 млн TRX в сети TRON в 19:16 UTC.
• Через семь минут после первого крупного перевода: система сверки Bitget обнаружила расхождение и остановила инициированные пользователями выводы средств. В хронологии Bitget это действие отделяется от последующего отключения сервисов вывода средств и подписи кошельков в 21:44 UTC [1].

Чен заявила, что злоумышленник удалил следы, оставленные мошенническими командами [3]. Что касается предварительной атрибуции, она также сказала, что поведение IP-адресов и ончейн-паттерны в значительной степени соответствуют известным северокорейским хакерским группам [4]. Это остаётся предварительной атрибуцией, а не окончательным выводом; официальная страница инцидента Bitget не называет ответственную группу, и расследование продолжается [1].

1.2 Движение средств и операционное восстановление

Ончейн-данные, отражённые в официальном трекере Bitget, показывают, что украденные стейблкоины были конвертированы в ETH в течение нескольких минут [5]. В отличие от USDT или USDC, нативные активы, такие как ETH, не имеют функции заморозки, контролируемой эмитентом. Такое поведение согласуется с попыткой снизить риск заморозки, контролируемой эмитентом, но не устанавливает личность или уровень опыта злоумышленника.

Официальная затронутая сумма впоследствии выросла примерно до 387,5 млн долларов, поскольку Bitget включила более полный учёт, включающий Zcash и TRON [1]. Bitget опубликовала адреса злоумышленников, портал для сообщений о возврате средств и API адресов [1, 6], а также сайт отслеживания в реальном времени [5]. Раздел активов на сайте показывает текущее распределение, а граф движения средств отображает нисходящие адреса, сервисы, мосты и кросс-чейн маршруты.

По состоянию на 16:35:28 UTC 29 сентября официальный трекер сообщал о 322,67 млн долларов текущих активов злоумышленника, около 632 700 долларов, замороженных по восьми позициям, 312 500 долларах в стейблкоинах, которые могут быть заморожены эмитентом, и 55,87 млн долларов в пути или всё ещё анализируемых [5]. Замороженная сумма включала 293 507 долларов на NEAR Intents (которая сообщила о заморозке приблизительно 503 000 долларов в ходе исполнения [12]), 239 242 доллара, замороженных Tether, и 99 990 долларов, замороженных Circle. Публичные источники не согласуют показатели NEAR Intents между собой.

На ту же временную отметку в обозревателе адресов балансы, отнесённые к атрибутированным адресам, были сосредоточены в BTC (288,51 млн долларов), ZEC (28,91 млн долларов) и ETH (7,17 млн долларов) [5]. Обозреватель использует иной охват классификации, чем обзорная страница, поэтому его показатель на уровне адресов в 327,69 млн долларов напрямую не сопоставим с показателем текущих активов в 322,67 млн долларов из обзора.

Операционное восстановление также продвигалось. Bitget возобновила выводы ETH в 08:00 UTC 29 сентября. К 09:00 UTC она сообщила о приблизительно 9674 ETH входящих поступлений и 9023 ETH исходящих переводов, то есть поступления превысили исходящие переводы примерно на 651 ETH [7].

1.3 После вывода средств: реакция сообщества

Как только активы покидают кошельки пострадавшей организации, их возврат зависит от организаций за пределами первоначального периметра безопасности. Bitget открыла свои данные отслеживания и запустила программу вознаграждений за содействие, приведшее к заморозке или возврату средств [1, 6]. Binance заявила, что её команда безопасности делилась разведданными, отслеживала средства и поддерживала процесс возврата [8]. Генеральный директор Bybit Бен Чжоу предложил помощь и обновил платформу возврата LazarusBounty, отметив, что Bitget помогала Bybit после её собственного инцидента в 2025 году [9]. Реакция Bybit продолжила традицию взаимной помощи между этими двумя биржами.

Инфраструктурные провайдеры имели разные варианты действий из-за особенностей своих технических решений и моделей управления. Bitget попросила THORChain отказать в обслуживании публично раскрытым и активно отслеживаемым адресам злоумышленника. Грейси Чен заявила, что «децентрализация — это принцип проектирования, а не щит для содействия обороту заведомо украденных средств» [10]. THORChain пояснила, что не поддерживает выборочное внесение в чёрный список: её механизмы экстренного контроля могут остановить более широкую активность или маршрут в определённой сети, но не отдельный адрес или транзакцию. Часть украденных активов продолжила перемещаться из ETH в BTC через эту сеть [11].

NEAR Intents сообщила о другой реакции. Её система оценки рисков SHIELD выявила и заблокировала попытки перевода более 50 млн долларов, связанные со злоумышленниками, после фильтрации дублирующихся попыток; примерно 503 000 долларов были заморожены в ходе исполнения, в то время как около 166 000 долларов прошли через систему. NEAR Intents также отказалась от своей доли вознаграждения за возврат средств Bitget [12]. Показатель в 50 млн долларов — это объём попыток перевода, которые система отказалась обрабатывать, а не замороженная или возвращённая сумма.

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

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

2. Разрыв и локализация пути эксплуатации: системная эшелонированная система защиты

Опираясь на путь инцидента и реакцию на него, описанные в разделе 1, а также на наш опыт и экспертизу, мы предлагаем двухуровневую систему, представленную ниже. Подробнее о том, почему аудиты кода и мониторинг не охватывают весь путь работы со средствами, см. в статье Why Crypto Institutions Need Blockchain Penetration Testing [13].

• Раскрытый путь эксплуатации проходит от стороннего продукта безопасности до ончейн-переводов.
• Уровень предотвращения и обнаружения в системе содержит первые три практики безопасности. Разделы 2.1 и 2.2 рассматривают, как контроль привилегированного доступа и независимая проверка намерений могут предотвратить перерастание закрепления в инфраструктуре в подписание транзакций. Раздел 2.3 посвящён мониторингу движения активов, который выявляет и эскалирует исходящие аномалии и может удерживать рискованные входящие депозиты.
• Уровень реагирования и восстановления содержит четвёртую практику. Он может быть запущен сигналом высокой степени уверенности из любой части уровня предотвращения и обнаружения либо операционным сбоем. Раздел 2.4 посвящён независимой возможности приостановить затронутые операции или перевести подверженные риску активы на проверенные безопасные адреса назначения.

Каждый подраздел следует одной и той же структуре: цель безопасности, риск, раскрытый в ходе инцидента, и превентивные, детективные или ответные меры, которые могут внедрить организации. Эти практики должны опираться на отдельные полномочия и доказательства. Вместе они снижают зависимость от какой-либо одной меры защиты и дают организациям подготовленные варианты для ограничения потерь.

2.1 Привилегированный доступ и команды на вывод средств

Цель — не допустить, чтобы компрометация инфраструктуры или привилегированных систем сама по себе была достаточной для создания доверенной команды на вывод средств.

Стороннему продукту не обязательно иметь прямой доступ к подписанию, чтобы влиять на перемещение активов. Доступа к учётным данным или системам, формирующим команды на вывод средств, может быть достаточно, чтобы определить, что подпишет другая система. Такие продукты относятся к поверхности атаки Web3 на уровне организации [14]. Их риск зависит от ценности, на которую они могут повлиять, и систем, к которым у них есть доступ.

Необходимые меры контроля включают принцип наименьших привилегий, сегментацию сети, ограниченные пути обновления и администрирования, краткосрочные учётные данные, защищённые от подмены журналы и протестированную процедуру отзыва доступа. Внутренний доступ не должен автоматически предоставлять возможность создать доверенную команду на вывод средств. Каждая команда должна нести аутентифицированное происхождение, неизменяемый идентификатор запроса и подписанную или иным образом аутентифицированную версию конфигурации. Создание команды, её утверждение, подписание и трансляция должны относиться к отдельным привилегиям, а нисходящие системы должны отклонять команды с неизвестным происхождением, устаревшими конфигурациями или неполными привязками.

2.2 Намерение на вывод средств и подписание

Цель — не допустить, чтобы поддельная или изменённая команда на вывод средств превратилась в валидно подписанную транзакцию.

Действительная подпись подтверждает, что соответствующий приватный ключ подписал данные транзакции; она не устанавливает, что исходный запрос на вывод средств был подлинным или прошёл независимое утверждение.

Граница подписания должна восстанавливать ожидаемую транзакцию на основе независимой доверенной записи и сравнивать все поля, способные повлиять на перемещение стоимости. Как минимум, утверждение должно привязывать сеть, актив, сумму, получателя, исходный кошелёк, nonce транзакции, границы комиссии, срок действия и исходный запрос на вывод средств или казначейский запрос.

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

2.3 Исходящие и входящие потоки активов

Цель — обнаруживать расхождение между фактическим движением активов и независимо восстановленным бизнес-намерением.

Криптоинституция может быть одновременно как источником, так и получателем потоков цифровых активов. Мониторинг исходящих потоков должен сравнивать фактическую активность в сети с независимо восстановленным набором утверждённых выводов средств. Для сохранения независимости монитор не должен полагаться исключительно на ту же команду, которую сформировала система вывода средств.

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

• Небольшие тестовые переводы, за которыми следует быстрая эскалация.
• Повторное использование новых получателей в разных учётных записях, активах или сетях.
• Внезапный рост скорости вывода средств или общей подверженности риску.
• Одновременные исходящие переводы с нескольких уровней операционных кошельков.
• Переход к нативным активам, которые сложнее заморозить.
• Расхождения между утверждённым запросом, подписанными данными транзакции и транслированной транзакцией.

Механизмы контроля должны оценивать совокупную сумму, скорость, новизну адреса назначения, уровень кошелька, лёгкость конвертации актива и кросс-чейн поведение в пределах временного окна. Первоначальные перемещения ETH и TRX у Bitget иллюстрируют ценность оценки транзакций как последовательности, а не только как изолированных событий [3]. Расхождение с высокой степенью уверенности должно запускать путь экстренного реагирования, описанный в разделе 2.4. Аномалии с более низкой степенью уверенности могут требовать второго утверждения, периода «охлаждения» для получателя, сниженного лимита или временной приостановки вывода средств.

Мониторинг входящих потоков должен проверять депозиты до их зачисления и повторно проверять их перед выводом средств. Он должен отслеживать средства через мосты, децентрализованные биржи (DEX), сервисы маршрутизации на основе намерений и промежуточные адреса, поскольку сопоставления только с первым адресом злоумышленника недостаточно. Совпадения с высокой степенью уверенности требуют документированного процесса удержания средств, расследования совпадения, обработки апелляций и завершения любой юридической передачи.

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

2.4 Экстренная приостановка и перевод активов

Цель — ограничить оставшуюся подверженность риску после выявления сигнала высокой степени уверенности о нарушении безопасности или операционного сбоя.

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

• Независимые полномочия на приостановку: возможность приостановки должна оставаться доступной даже в случае компрометации основной системы администрирования. Её охват должен быть достаточно узким, чтобы остановить конкретную сеть, кошелёк, актив или операцию там, где это позволяет архитектура. Активация и отмена требуют аутентифицированных полномочий, защищённых от подмены записей, явных критериев возобновления и тестирования в условиях деградации системы.
• Непрерывность пути перевода: изменение конфигурации не должно делать старый экстренный путь недействительным до того, как его замена будет развёрнута, авторизована, подписана, сохранена и протестирована.
• Готовность к исполнению транзакции: сохранённые экстренные транзакции могут устареть из-за изменений nonce, недостаточного баланса нативного токена для оплаты комиссии, изменений баланса исходного актива, изменений на рынке комиссий, делающих подписанные лимиты комиссии неприменимыми, истечения срока действия или обновлений конфигурации. Проверки готовности должны непрерывно подтверждать эти зависимости. Полностью подписанные данные транзакции должны оставаться зашифрованными и под контролем доступа до тех пор, пока экстренное действие не будет утверждено и готово к немедленной трансляции.
• Охват и резервирование: каждый операционный кошелёк, сеть, нативный актив и поддерживаемый токен нуждаются в основном и резервном путях перевода. Инфраструктура трансляции и проверки также нуждается в резервировании между конечными точками удалённого вызова процедур (RPC), операционными системами и инструментами ручного восстановления.
• Проверки завершения и учения: процедура экстренного реагирования должна определять завершение через подтверждённое исполнение в сети, проверку по каждому активу, проверки остаточного баланса и сверку между состоянием в сети и внутренними записями. Она также должна выявлять реорганизации сети и неудавшиеся транзакции. Регулярные учения должны измерять полное время восстановления от обнаружения до итоговой проверки баланса.

Авторизованное тестирование на проникновение в блокчейн-инфраструктуру может превратить межуровневые предположения в доказательства путём проверки работающей среды в согласованных рамках [15]. Для тестирования на продакшн-среде документированные правила проведения работ (Rules of Engagement, RoE) должны определять авторизацию, допустимые методы, критерии остановки, ограничения по стоимости, порядок связи, обработку доказательств и полномочия на приостановку ещё до начала тестирования [16].

Заключение

Инцидент с Bitget не был ни компрометацией приватных ключей, ни эксплуатацией смарт-контракта. Bitget заявила, что злоумышленники воспользовались уязвимостью в стороннем продукте безопасности для получения учётных данных доступа к внутренней сети, а затем подделали команды на вывод средств, которые система кошельков обработала в валидно подписанные ончейн-переводы [1, 2]. После того как активы покидают пострадавшую организацию, их возврат становится совместной задачей всей экосистемы. Реакции Bitget, Binance, Bybit, THORChain и NEAR Intents показывают, что участники могут реагировать по-разному [8-12]. То, как сообщество сможет быстро и ответственно координировать эти возможности при возникновении крупного инцидента безопасности или угрозы, остаётся более широким вызовом для криптоиндустрии.

Известный нисходящий путь атаки лёг в основу предложенной здесь системной системы, которая соединяет предотвращение и обнаружение с реагированием и восстановлением. Организации могут снизить зависимость от какой-либо одной меры защиты, ограничивая привилегированный доступ и аутентифицируя происхождение команд, независимо восстанавливая утверждённое намерение на вывод средств при подписании, отслеживая исходящие последовательности и входящие поступления, а также поддерживая независимо работоспособные пути приостановки и перевода. Кастодиальное хранение остаётся необходимым, и эти практики дополняют его на всём протяжении цепочки работы со средствами [13, 15].

Список источников

[1] Bitget. Bitget Security Incident: Official Progress Update. https://www.bitget.com/campaigns/bitget-security-incident-2026

[2] Gracy Chen. Security Incident Root-Cause Boundary. https://x.com/GracyBitget/status/2104515761691939026

[3] The Block. Bitget Attacker Tested Risk Controls with Small Transfers Before $388 Million Theft, CEO Says. https://www.theblock.co/news/regulation/2026-09-28-bitget-attacker-tested-risk-controls-small-transfers-388-million-theft-ceo-says-417045

[4] Gracy Chen. Preliminary Attribution Assessment. https://x.com/GracyBitget/status/2103359775723626736

[5] Bitget. Live Tracing Dashboard and Fund-Flow Graph. https://trace.bgblockchain.xyz/v2#track

[6] Bitget. Live Tracing Information and Recovery Portal. https://x.com/bitget/status/2103485491220033607

[7] Gracy Chen. ETH Withdrawal Resumption Update. https://x.com/GracyBitget/status/2104886024979816508

[8] Binance. Richard Teng Puts Binance's Security Muscle Behind an Industry-Wide Response. 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

[9] Ben Zhou. Bybit Support for Bitget. https://x.com/benbybit/status/2103328213141508335

[10] Gracy Chen. Request to THORChain. https://x.com/GracyBitget/status/2103812967066439817

[11] CoinDesk. THORChain Rejects Bitget Request to Block Hacker as $6 Million Moves to Bitcoin. https://www.coindesk.com/tech/2026/09/28/thorchain-rejects-bitget-request-to-block-hacker-as-usd6-million-moves-to-bitcoin

[12] Gracy Chen. NEAR Intents and SHIELD Response. https://x.com/GracyBitget/status/2104602301503816040

[13] BlockSec. From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing. https://blocksec.com/blog/why-crypto-institutions-need-blockchain-penetration-testing

[14] BlockSec. Web3 Attack Surfaces: A Penetration Testing Overview. https://blocksec.com/blog/web3-attack-surfaces-penetration-testing

[15] BlockSec. What Is Blockchain Penetration Testing? Definitions and Boundaries. https://blocksec.com/blog/what-is-blockchain-penetration-testing

[16] BlockSec. Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing. https://blocksec.com/blog/blockchain-penetration-testing-rules-of-engagement