Как взломали Binance: подготовка атаки на $6,3 млрд
Небольшие переводы для подготовки. Миллиарды на выходе. AML Crypto разбирает взлом Binance 29 октября 2026 года: от финансирования операционных адресов до вывода активов и блокировок стейблкоинов.
→ От финансирования кошельков до вывода средств в нескольких сетях
→ Подготовка инфраструктуры
→ Подготовка смарт-контракта Ethereum
→ Компрометация инфраструктуры Binance
→ Активация EIP-7702 и вывод средств из Binance 14
→ Как атака развивалась сразу в нескольких сетях
→ Дальнейшее движение активов и блокировки Tether и Circle
→ Подготовка инфраструктуры
→ Подготовка смарт-контракта Ethereum
→ Компрометация инфраструктуры Binance
→ Активация EIP-7702 и вывод средств из Binance 14
→ Как атака развивалась сразу в нескольких сетях
→ Дальнейшее движение активов и блокировки Tether и Circle
Получить консультацию экспертов AML Crypto
От финансирования кошельков до вывода средств в нескольких сетях
29 октября 2026 года с горячих кошельков Binance, по предварительным оценкам, вывели криптоактивы примерно на $6,3 млрд. Операции затронули сразу несколько блокчейнов, причём основная часть переводов прошла в течение двадцати минут.
В Ethereum использовался необычный механизм: злоумышленники задействовали EIP-7702, позволяющий обычному кошельку исполнять код другого смарт-контракта.
Но Ethereum был лишь частью истории. Примерно в то же время крупные суммы перемещались в Bitcoin, Tron, Solana и XRP Ledger. У этих сетей разные механизмы авторизации, поэтому объяснить всю атаку одной уязвимостью смарт-контракта не получится.
Мы начали разбирать инцидент с подготовительных транзакций в Ethereum. Они позволяют проследить, откуда поступали средства для операционных кошельков и как один из этих адресов оказался связан с контрактом, использованным при выводе активов.
В Ethereum использовался необычный механизм: злоумышленники задействовали EIP-7702, позволяющий обычному кошельку исполнять код другого смарт-контракта.
Но Ethereum был лишь частью истории. Примерно в то же время крупные суммы перемещались в Bitcoin, Tron, Solana и XRP Ledger. У этих сетей разные механизмы авторизации, поэтому объяснить всю атаку одной уязвимостью смарт-контракта не получится.
Мы начали разбирать инцидент с подготовительных транзакций в Ethereum. Они позволяют проследить, откуда поступали средства для операционных кошельков и как один из этих адресов оказался связан с контрактом, использованным при выводе активов.
Подготовка инфраструктуры
28–29 октября через два пула Tornado Cash - 0.1 ETH и 1 ETH - на группу связанных адресов поступило около 1,48 ETH. Всего на исследуемом графе мы видим шесть выводов.
Основной интерес представляет кошелёк:
0x7c8601d4645b93cea45f71e118a729332e6b5ca0
На него поступило около 1,3763 ETH. Часть переводов шла напрямую из Tornado Cash, остальные - через промежуточный адрес.
Граф AML Крипто: подготовка и финансирование:
Основной интерес представляет кошелёк:
0x7c8601d4645b93cea45f71e118a729332e6b5ca0
На него поступило около 1,3763 ETH. Часть переводов шла напрямую из Tornado Cash, остальные - через промежуточный адрес.
Граф AML Крипто: подготовка и финансирование:
На схеме есть и другая ветка. Один из кошельков получает ETH из Tornado Cash, взаимодействует с контрактами MetaMask, затем отправляет небольшие суммы ETH, USDT и USDC на несколько адресов. Часть токенов после этого собирается на одном кошельке.
По характеру переводов это похоже на проверку работы адресов и маршрутов движения токенов. Суммы небольшие, а последовательность операций довольно характерная: пополнение, распределение, обратная консолидация.
Но назвать эти транзакции доказанным тестом будущего эксплойта мы пока не можем. Сам граф показывает движение средств, а не намерения владельцев кошельков.
Гораздо интереснее оказалось то, что мы обнаружили при изучении кода смарт-контракта.
По характеру переводов это похоже на проверку работы адресов и маршрутов движения токенов. Суммы небольшие, а последовательность операций довольно характерная: пополнение, распределение, обратная консолидация.
Но назвать эти транзакции доказанным тестом будущего эксплойта мы пока не можем. Сам граф показывает движение средств, а не намерения владельцев кошельков.
Гораздо интереснее оказалось то, что мы обнаружили при изучении кода смарт-контракта.
Подготовка смарт-контракта Ethereum
29 октября в 15:59 UTC, согласно исследуемой хронологии, был развёрнут контракт:
0x63e842B054Bd624a465454D533C33F573e9c6fAe
Контракт в Etherscan
В реконструированном Solidity-коде есть переменная authorizedCaller, которой присвоен адрес:
0x7C8601d4645b93cea45F71e118A729332e6B5CA0
Это именно тот кошелёк, который мы проследили на графе финансирования.
0x63e842B054Bd624a465454D533C33F573e9c6fAe
Контракт в Etherscan
В реконструированном Solidity-коде есть переменная authorizedCaller, которой присвоен адрес:
0x7C8601d4645b93cea45F71e118A729332e6B5CA0
Это именно тот кошелёк, который мы проследили на графе финансирования.
Скриншот 1. Адрес оператора в коде контракта
В контракте предусмотрен модификатор onlyAuthorized. Он проверяет, кто вызывает функцию. Если msg.sender отличается от указанного адреса, выполнение прерывается ошибкой NotAuthorized().
Получается прямая связка: адрес, который заранее пополняли через Tornado Cash, позднее оказался единственным разрешённым оператором функций вывода средств в этом контракте.
Вторая интересная часть кода - функция sweep().
Получается прямая связка: адрес, который заранее пополняли через Tornado Cash, позднее оказался единственным разрешённым оператором функций вывода средств в этом контракте.
Вторая интересная часть кода - функция sweep().
Скриншот 2. Функция sweep()
У функции два параметра: адрес получателя to и массив токенов tokens.
Если в массиве указан address(0), код обрабатывает ETH. Он проверяет баланс и отправляет получателю всё, что превышает 1 ETH.
Для ERC-20 механизм другой: контракт вызывает balanceOf(), получает баланс токена и пытается перевести всю сумму через transfer().
Ошибки отдельных переводов записываются в событие SweepItemFailed. Это позволяет продолжить обработку других активов, даже если одна из операций не удалась.
Сама по себе такая функция не является уязвимостью Ethereum. Проблема возникает тогда, когда возможность исполнять её получает кошелёк, на котором хранятся чужие активы.
Если в массиве указан address(0), код обрабатывает ETH. Он проверяет баланс и отправляет получателю всё, что превышает 1 ETH.
Для ERC-20 механизм другой: контракт вызывает balanceOf(), получает баланс токена и пытается перевести всю сумму через transfer().
Ошибки отдельных переводов записываются в событие SweepItemFailed. Это позволяет продолжить обработку других активов, даже если одна из операций не удалась.
Сама по себе такая функция не является уязвимостью Ethereum. Проблема возникает тогда, когда возможность исполнять её получает кошелёк, на котором хранятся чужие активы.
Как здесь работает EIP-7702
EIP-7702 позволяет обычному Ethereum-адресу (EOA) делегировать исполнение кода другому контракту.
При этом адрес кошелька не меняется, а средства остаются на его балансе. Меняется логика, которую он может исполнять.
В нашем случае речь идёт о горячем кошельке Binance 14:
0x28C6c06298d514Db089934071355E5743bf21d60
Если этот адрес делегирует исполнение контракту 0x63e842…6fae, функция sweep() работает в контексте самого Binance 14.
Именно поэтому выражение address(this) в коде обращается к балансу кошелька Binance, а не к балансу контракта, на который указывает делегирование.
Однако есть обязательное условие: для такого делегирования нужна действительная подпись владельца кошелька.
Просто развернуть контракт и указать в нём адрес Binance недостаточно.
EIP-7702 позволяет обычному Ethereum-адресу (EOA) делегировать исполнение кода другому контракту.
При этом адрес кошелька не меняется, а средства остаются на его балансе. Меняется логика, которую он может исполнять.
В нашем случае речь идёт о горячем кошельке Binance 14:
0x28C6c06298d514Db089934071355E5743bf21d60
Если этот адрес делегирует исполнение контракту 0x63e842…6fae, функция sweep() работает в контексте самого Binance 14.
Именно поэтому выражение address(this) в коде обращается к балансу кошелька Binance, а не к балансу контракта, на который указывает делегирование.
Однако есть обязательное условие: для такого делегирования нужна действительная подпись владельца кошелька.
Просто развернуть контракт и указать в нём адрес Binance недостаточно.
Компрометация инфраструктуры Binance
Здесь мы подходим к наиболее сложной части расследования.
Согласно предварительной версии, атакующие могли получить доступ к устройству DevOps-инженера и связанным с ним внутренним сервисам Binance.
Если эта версия подтвердится, она может объяснить, каким образом злоумышленники получили возможность инициировать операции от имени горячих кошельков.
Но пока нельзя уверенно сказать, что именно было скомпрометировано: приватные ключи, процесс подписания транзакций или другой компонент инфраструктуры.
И это существенное различие.
Блокчейн позволяет проверить действительность подписи и увидеть результат операции. Но он не показывает, кто физически инициировал подписание, при каких обстоятельствах и был ли этот процесс санкционирован владельцем системы.
Согласно предварительной версии, атакующие могли получить доступ к устройству DevOps-инженера и связанным с ним внутренним сервисам Binance.
Если эта версия подтвердится, она может объяснить, каким образом злоумышленники получили возможность инициировать операции от имени горячих кошельков.
Но пока нельзя уверенно сказать, что именно было скомпрометировано: приватные ключи, процесс подписания транзакций или другой компонент инфраструктуры.
И это существенное различие.
Блокчейн позволяет проверить действительность подписи и увидеть результат операции. Но он не показывает, кто физически инициировал подписание, при каких обстоятельствах и был ли этот процесс санкционирован владельцем системы.
Активация EIP-7702 и вывод средств из Binance 14
29 октября в 20:20:59 UTC, согласно исследуемой транзакции, в Ethereum появилась операция типа 4:
0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b
Открыть транзакцию в Etherscan
В ней содержалось 50 авторизаций EIP-7702. Согласно предоставленной реконструкции подписей, все они относились к одному адресу - Binance 14.
Их nonce шли последовательно: от 18 914 775 до 18 914 824.
Зачем понадобились nonce
Nonce в Ethereum - это публичный счётчик аккаунта. Он используется, в частности, для определения последовательности транзакций и защиты от повторного применения уже использованных подписанных операций.
В EIP-7702 nonce включается в авторизацию вместе с адресом делегируемого контракта и идентификатором сети.
Когда Ethereum проверяет авторизацию, значение nonce должно совпадать с текущим счётчиком соответствующего аккаунта. После успешного принятия авторизации счётчик увеличивается.
Поэтому 50 последовательных nonce - это не 50 разных кошельков и не 50 разрешений на вывод отдельных токенов.
Это последовательность подписанных авторизаций для одного аккаунта.
По данным реконструкции, принятая авторизация соответствовала nonce 18 914 809.
Здесь легко сделать неправильный вывод: будто злоумышленники подобрали nonce и тем самым получили доступ к кошельку.
Nonce не секретный. Его можно узнать из блокчейна. Для создания действительной авторизации всё равно требуется криптографическая подпись соответствующего адреса.
После применения делегирования оператор получил возможность вызывать предусмотренные контрактом функции в контексте Binance 14.
Адресом получателя средств в исследуемой схеме выступал:
0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c
К 20:24:23 UTC, по предварительной реконструкции, начался массовый вывод активов из Binance 14. Среди них - около 167,5 тыс. ETH, 1,615 млрд USDT и десятки других токенов.
Отдельно происходили операции с Binance 16. В отличие от Binance 14, для этого кошелька рассматривается вывод через обычные подписанные транзакции, без использования делегирования EIP-7702.
0xad99264d5532ae0dd04b2004eebda05f25657e70dacb764f7ac8d4ccd051298b
Открыть транзакцию в Etherscan
В ней содержалось 50 авторизаций EIP-7702. Согласно предоставленной реконструкции подписей, все они относились к одному адресу - Binance 14.
Их nonce шли последовательно: от 18 914 775 до 18 914 824.
Зачем понадобились nonce
Nonce в Ethereum - это публичный счётчик аккаунта. Он используется, в частности, для определения последовательности транзакций и защиты от повторного применения уже использованных подписанных операций.
В EIP-7702 nonce включается в авторизацию вместе с адресом делегируемого контракта и идентификатором сети.
Когда Ethereum проверяет авторизацию, значение nonce должно совпадать с текущим счётчиком соответствующего аккаунта. После успешного принятия авторизации счётчик увеличивается.
Поэтому 50 последовательных nonce - это не 50 разных кошельков и не 50 разрешений на вывод отдельных токенов.
Это последовательность подписанных авторизаций для одного аккаунта.
По данным реконструкции, принятая авторизация соответствовала nonce 18 914 809.
Здесь легко сделать неправильный вывод: будто злоумышленники подобрали nonce и тем самым получили доступ к кошельку.
Nonce не секретный. Его можно узнать из блокчейна. Для создания действительной авторизации всё равно требуется криптографическая подпись соответствующего адреса.
После применения делегирования оператор получил возможность вызывать предусмотренные контрактом функции в контексте Binance 14.
Адресом получателя средств в исследуемой схеме выступал:
0x5227f603C1eE34CE3C06eFe6477003BDfCCB2f8c
К 20:24:23 UTC, по предварительной реконструкции, начался массовый вывод активов из Binance 14. Среди них - около 167,5 тыс. ETH, 1,615 млрд USDT и десятки других токенов.
Отдельно происходили операции с Binance 16. В отличие от Binance 14, для этого кошелька рассматривается вывод через обычные подписанные транзакции, без использования делегирования EIP-7702.
Как атака развивалась сразу в нескольких сетях
Пока в Ethereum готовилось применение EIP-7702, вывод активов уже происходил в других блокчейнах.
По предварительной хронологии, основные события 29 октября выглядели так:
По предварительной хронологии, основные события 29 октября выглядели так:
Между первыми крупными переводами в XRP Ledger и выводом средств из Binance 14 прошло меньше двадцати минут.
Самое интересное здесь - различие технических механизмов.
В Ethereum использовалось делегирование кода через EIP-7702. Но этот механизм не существует в Bitcoin, Tron, Solana или XRP Ledger в таком же виде.
Для операций в каждой из этих сетей нужны собственные полномочия подписания.
Поэтому мы рассматриваем происходившее как возможную компрометацию более широкого контура управления горячими кошельками, а не как результат одной ошибки в Ethereum.
Близость транзакций по времени говорит в пользу заранее согласованной последовательности действий. Но пока она не раскрывает, каким способом атакующие получили доступ к каждой сети.
Самое интересное здесь - различие технических механизмов.
В Ethereum использовалось делегирование кода через EIP-7702. Но этот механизм не существует в Bitcoin, Tron, Solana или XRP Ledger в таком же виде.
Для операций в каждой из этих сетей нужны собственные полномочия подписания.
Поэтому мы рассматриваем происходившее как возможную компрометацию более широкого контура управления горячими кошельками, а не как результат одной ошибки в Ethereum.
Близость транзакций по времени говорит в пользу заранее согласованной последовательности действий. Но пока она не раскрывает, каким способом атакующие получили доступ к каждой сети.
Дальнейшее движение активов и блокировки Tether и Circle
После вывода средства начали распределяться между новыми адресами. Часть активов проходила через обмены, часть консолидировалась на отдельных кошельках.
Особенно заметной стала ситуация со стейблкоинами. В отличие от BTC или ETH, централизованные токены вроде USDT и USDC могут быть заблокированы эмитентами на уровне смарт-контрактов.
По предварительным оценкам, объём заблокированных стейблкоинов достиг примерно $2,7 млрд. Часть USDT, предположительно, успели обменять до введения ограничений.
Интересно, что под блокировку Tether и Circle попали даже два адреса самой Binance.
Похоже, заморозить средства на этих адресах оказалось быстрее, чем Binance смогла самостоятельно перевести их на безопасные кошельки.
Вероятно, после обнаружения взлома были запущены внутренние процедуры безопасности, ограничивающие подписание транзакций до выяснения всех обстоятельств: как именно произошла атака, какие устройства и ключи были скомпрометированы.
В такой ситуации заморозка со стороны Tether и Circle могла оказаться самым быстрым способом сохранить средства.
Особенно заметной стала ситуация со стейблкоинами. В отличие от BTC или ETH, централизованные токены вроде USDT и USDC могут быть заблокированы эмитентами на уровне смарт-контрактов.
По предварительным оценкам, объём заблокированных стейблкоинов достиг примерно $2,7 млрд. Часть USDT, предположительно, успели обменять до введения ограничений.
Интересно, что под блокировку Tether и Circle попали даже два адреса самой Binance.
Похоже, заморозить средства на этих адресах оказалось быстрее, чем Binance смогла самостоятельно перевести их на безопасные кошельки.
Вероятно, после обнаружения взлома были запущены внутренние процедуры безопасности, ограничивающие подписание транзакций до выяснения всех обстоятельств: как именно произошла атака, какие устройства и ключи были скомпрометированы.
В такой ситуации заморозка со стороны Tether и Circle могла оказаться самым быстрым способом сохранить средства.
Граф AML Крипто: заблокированные адреса
На графе синим цветом выделены адреса, заблокированные Tether и Circle, включая два адреса Binance.
Сообщения о транзакциях блокировки:
Сам граф показывает связи между кошельками и выделенные адреса. Предположение о внутренних ограничениях Binance остаётся версией: подтвердить его можно только дополнительными сведениями о действиях биржи после обнаружения инцидента.
После вывода средства начали распределяться между новыми адресами. Часть активов проходила через обмены, часть консолидировалась на отдельных кошельках.
Сообщения о транзакциях блокировки:
Сам граф показывает связи между кошельками и выделенные адреса. Предположение о внутренних ограничениях Binance остаётся версией: подтвердить его можно только дополнительными сведениями о действиях биржи после обнаружения инцидента.
После вывода средства начали распределяться между новыми адресами. Часть активов проходила через обмены, часть консолидировалась на отдельных кошельках.
Расследование продолжается. Данный материал дополняется.
Хотите узнать больше и получить консультацию экспертов? Оставьте email и мы с вами оперативно свяжемся!
Проверьте блокчейн-адрес с помощью Btrace
За секунды определите уровень риска адреса контрагента, узнайте источник его средств и примите взвешенное решение о взаимодействии с ним.
ПРЕДОТВРАТИте БЛОКИРОВКУ СРЕДСТВ
ОГРАДИте себя от мошенников
избегите проблем с законом
Смотрите также
