Из Binance вывели миллиарды долларов, а биржа предварительно связывает инцидент с ноутбуком своего инженера. В этой истории больше всего настораживает заявление об отсутствии признаков утечки приватных ключей. Если оно подтвердится, злоумышленнику удалось добраться до системы, которая распоряжается деньгами, сохранив сами ключи внутри биржевой инфраструктуры.
Наша рабочая версия — атакующий получил возможность передавать внутренним сервисам команды, которые те приняли за разрешённые. Ниже объясняем, как такое возможно, где эта версия пока держится на предположениях и какие последствия имеют значение для владельца криптовалюты.
Экспертное мнение редакции FinTerminal. Факты проверены по доступным сообщениям на 30 октября 2026 года. Реконструкция механизма атаки — гипотеза, а не результат доступа к внутреннему расследованию Binance. Комментарии — NPB Markets.
Что сообщила Binance и чего мы пока не знаем
В официальном сообщении Security Incident Update Binance оценила масштаб инцидента примерно в $6,3 млрд и заявила о заморозке около $3 млрд затронутых активов. Компания пообещала покрыть потери средствами SAFU и собственными деньгами.
Предварительное расследование биржи указывает на возможную компрометацию ноутбука DevOps-инженера. Через него атакующий, по версии Binance, получил доступ к сервисному контейнеру и отправил неразрешённую операцию вывода. Доказательств компрометации приватных ключей биржа на тот момент не обнаружила. В первоначальном уведомлении также сообщалось о временной приостановке ввода и вывода, отзыве затронутой авторизации и подготовке технического отчёта. Это состояние из конкретного сообщения, поэтому доступность операций следует проверять в текущих уведомлениях Binance. Первоисточник — публикация официального аккаунта Binance.
Для разбора пока недостаёт журналов доступа, правил проверки заявок и описания полномочий скомпрометированного сервиса. Мы не знаем, как именно взломали ноутбук, сколько времени атакующий находился внутри и какие защитные проверки он обошёл. Называть виновного сотрудника или конкретную группировку на такой базе было бы преждевременно.
Как украсть деньги, сохранив ключ в защищённом хранилище
Приватный ключ подтверждает право отправить транзакцию. Но в крупной компании вокруг него работает целая цепочка программ. Одна принимает заявку на вывод, другая проверяет баланс, следующая оценивает риск, отдельный сервис формирует операцию и передаёт её на подпись. Человек обычно видит результат работы всей цепочки.
Представим условную систему, в которой ключ хранится в изолированном модуле. Достать его наружу нельзя. Однако разрешённый внутренний сервис умеет обращаться к модулю с запросом на подпись. Если преступник захватит этот сервис, а модуль недостаточно строго проверяет смысл запроса, подпись окажется математически правильной. Получатель денег при этом будет чужим.
Это пример возможной архитектуры, а не описание установленного устройства Binance. Он объясняет, почему отсутствие утечки ключа совместимо с кражей. Блокчейн проверяет подпись и правила выполнения операции. Он не знает, давал ли клиент биржи распоряжение и соответствует ли запрос внутренним процедурам компании.
Для оценки защиты нам недостаточно ответа о месте хранения ключа. Нужно знать, кто может запросить подпись, какую операцию ему разрешено подписать и какая независимая проверка остановит ошибочную команду.
Комментарий NPB Markets
Отсюда вопрос к будущему отчёту Binance. Какие ограничения должны были удержать сервис вывода в пределах его задач и почему этих ограничений оказалось недостаточно?
Наша версия — захват внутреннего пути согласования
Мы считаем разумным сначала проверять сценарий злоупотребления внутренними полномочиями. Он согласуется с предварительным сообщением о ноутбуке и сервисном контейнере. Для его объяснения не требуется предполагать взлом криптографии или извлечение каждого ключа по отдельности.
В такой реконструкции начальным доступом могли стать украденная рабочая сессия, вредоносное обновление, заражённый инструмент разработки или адресная атака на сотрудника. Выбирать один из этих вариантов пока нельзя. Даже если точкой входа был ноутбук, способ заражения ещё предстоит установить.
Дальше злоумышленнику понадобилось бы превратить доступ к рабочей среде в право обращаться к сервисам, связанным с деньгами. Здесь могла сыграть роль сервисная учётная запись с чрезмерными разрешениями, недостаточное разделение сред или доверие к запросам, пришедшим из внутренней сети. Это альтернативные объяснения одного перехода; мы не утверждаем, что все они присутствовали одновременно.
Последний переход — от доступа к сервису до исполнения операции. При корректном разделении обязанностей одной рабочей сессии недостаточно для произвольного вывода. Если же несколько проверок опираются на один и тот же источник данных или одну учётную запись, их количество создаёт обманчивое ощущение независимости.
Допустим, программа сама формирует получателя, сама сообщает, что получатель проверен, и сама отправляет заявку на подпись. Дополнительная отметка о проверке в этой схеме мало помогает. Система повторно доверяет участнику, которого уже контролирует атакующий.
В этом участке цепочки мы видим предмет для проверки. Но признать версию доказанной можно только после сопоставления внутренних журналов, прав доступа и реальных транзакций.
Зачем в обсуждении вспоминают EIP-7702
Ещё один технический сюжет связан с делегированием полномочий кошелька. В Ethereum стандарт EIP-7702 позволяет обычному аккаунту выполнять код выбранного контракта в своём контексте. Это расширяет возможности кошельков, но делает содержание подписываемой авторизации особенно важным.
В спецификации EIP-7702 прямо разобраны риски делегирования. Небезопасный код способен дать атакующему почти полный контроль над аккаунтом. Сам факт корректной подписи не означает, что выбранному коду следовало доверять.
Из этого не следует, что EIP-7702 сам по себе уязвим или что именно он объясняет весь инцидент Binance. Для такой связи нужны конкретные авторизации, адреса делегированных контрактов и разбор их исполнения. Мы не проводили собственную верификацию полной цепочки операций и не выдаём обсуждаемую техническую версию за установленный факт.
Есть и граница применимости. Механизм Ethereum нельзя автоматически переносить на вывод биткоина или активов из сетей с другими правилами. Если расследование подтвердит согласованные операции в разных системах, придётся искать общий источник команд над отдельными блокчейнами. Делегирование в одной сети тогда способно объяснить часть цепочки, но не обязательно её начало.
Какие данные изменят нашу оценку
Хорошая гипотеза допускает проверку и отказ от неё. Поэтому мы заранее обозначаем, что хотим увидеть в техническом отчёте.
| Что раскроет расследование | Как это повлияет на версию |
|---|---|
| Неразрешённые запросы к штатному сервису подписи из захваченной рабочей среды | Усилят версию злоупотребления внутренними полномочиями. |
| Доказанное извлечение приватных ключей | Потребует пересмотреть предположение о сохранности ключевого материала. |
| Подмена данных между проверкой заявки и её подписью | Сместит внимание на целостность операции и независимость проверок. |
| Опасная авторизация делегирования в конкретной сети | Объяснит контроль над соответствующим аккаунтом; для остальных сетей понадобится отдельная проверка. |
Отдельный вопрос — время обнаружения. Между первой вредоносной командой, первым переводом и остановкой сервиса могут находиться разные интервалы. Смешивать их в одно число нельзя. Для оценки ущерба и качества реакции нужны все эти отметки времени вместе с объяснением, какие сигналы видела защита.
Заморозить активы и вернуть деньги — разные этапы
Заявленная Binance заморозка части активов ограничивает дальнейшее движение средств. Однако замороженный токен ещё не равен деньгам, которые снова доступны бирже. Возврат зависит от технической процедуры, решений участников и обстоятельств расследования.
Поэтому арифметика, в которой из $6,3 млрд вычитают $3 млрд и называют остаток окончательным убытком, преждевременна. Для такого расчёта нужно знать, какие активы возвращены, в какой оценке посчитаны суммы и какие расходы или дополнительные потери возникли при восстановлении.
Заявление о компенсации задаёт обязательство компании, но ещё не показывает, когда клиент сможет свободно распорядиться своим балансом. Для пользователя момент восстановления доступа бывает важнее заголовка о величине страхового фонда.
Покрытый убыток и доступный остаток на счёте отвечают на разные вопросы. Биржа способна обещать возмещение, пока клиент всё ещё не может перевести средства. В этот промежуток его возможности уже ограничены.
Комментарий NPB Markets
Почему новость о взломе мешает даже тем, кто не хранит деньги на Binance
Риск передаётся через торговые связи. Рассмотрим условного участника, который держит актив на одной площадке, а противоположную позицию — на другой. Пока переводы работают, он перебрасывает обеспечение и поддерживает обе позиции. При остановке вывода привычная схема перестаёт работать, хотя сам участник не стал жертвой кражи.
Если ему приходится срочно искать обеспечение или сокращать позицию, появляются дополнительные заявки на покупку и продажу. При одновременных действиях многих участников стаканы способны стать менее глубокими, а разница между ценой покупки и продажи — увеличиться. Это механизм возможного распространения стресса, а не наше утверждение о размере уже случившегося рыночного эффекта.
Универсальный прогноз падения биткоина на определённый процент здесь был бы выдумкой. Направление и сила движения зависят от доступной ликвидности, размера плеча и поведения владельцев средств. Даже быстрый отскок цены сам по себе не подтверждает, что доступ к активам восстановлен.
При выборе между биржевым счётом и торговлей через брокера тоже полезно разобрать, какое требование получает клиент. Покупка криптовалюты и производный контракт на её цену предполагают разные права и риски. Для проверки конкретных условий у нас есть карточка NPB Markets. Упоминание брокера здесь не означает, что его счёт заменяет криптокошелёк или устраняет риск контрагента.
Что сейчас имеет смысл проверить владельцу счёта
Смена личного пароля не исправляет уязвимость внутреннего сервиса биржи. Она полезна при подозрении на компрометацию собственного аккаунта, но не должна создавать ощущение, что инфраструктурный инцидент больше вас не касается.
Начать стоит с проверки того, что находится под вашим контролем:
- Открывать уведомления через приложение или самостоятельно набранный адрес биржи. Ссылки из сообщений о срочной компенсации проверять отдельно.
- Посмотреть историю входов, активные сессии и API-ключи. Неиспользуемым интеграциям незачем сохранять доступ к счёту.
- Сохранить выписки, идентификаторы заявок и историю обращений, если операции ограничены или баланс вызывает вопросы.
- Проверить запас обеспечения по открытым позициям. План, который требует немедленного перевода с другой площадки, зависит от доступности этого перевода.
- После восстановления операций пересмотреть сумму, которую действительно необходимо держать на бирже для текущей торговли.
Самостоятельное хранение добавляет ответственность за резервную копию, подписи и правильность адресов. Перевод всех средств в незнакомый кошелёк в спешке способен создать новую проблему. Такой переход лучше делать после проверки инструмента и небольшой тестовой операции.
Тем, кто сравнивает торговые площадки и брокеров, полезнее изучать договор и порядок вывода, чем полагаться на рекламные заявления о безопасности. В обзоре NPB Markets на FinTerminal можно начать проверку брокера; актуальные условия конкретного счёта нужно сверять с документами обслуживающего юридического лица.
На какой ответ мы будем смотреть после расследования
Версия FinTerminal состоит в том, что злоумышленник мог использовать доверие между внутренними сервисами и добиться исполнения чужих команд штатными средствами биржи. Она объясняет, как кража совместима с предварительным заявлением об отсутствии утечки ключей, но пока не устанавливает точный путь атаки.
Фраза о взломанном ноутбуке оставляет слишком большой пробел между заражённым устройством и многомиллиардным выводом. Этот пробел должен заполнить технический отчёт. Нас будут интересовать полномочия захваченной сессии, независимые ограничения на подпись, контроль сумм и причины, по которым необычные операции не остановили раньше.
Для клиента проверка ещё конкретнее. Восстановлены ли операции, можно ли вывести свои активы и подтверждено ли их покрытие после восстановления? Возобновлённый вывод и подтверждённое покрытие балансов покажут, что изменилось для владельца счёта. Технический отчёт покажет, выдержала ли проверку наша версия.
