Назад

2026/11/02

Крупнейшая криптокража началась не в блокчейне, а на одном ноутбуке: уроки Binance

Кража у Binance началась со взломанного ноутбука DevOps-инженера, а не со взлома криптографии. Что подтверждено, что нет, и пять проверок для ваших систем.

29 октября 2026 года злоумышленники за несколько часов опустошили горячие кошельки Binance как минимум в десяти блокчейнах. Binance оценивает ущерб примерно в 6,3 млрд долларов, что почти наверняка делает этот инцидент крупнейшей кражей в истории криптовалют. Подвела не криптография. Согласно предварительным выводам Binance, атака началась с одного скомпрометированного ноутбука, принадлежавшего DevOps-инженеру.

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

Главное

  • Предварительное расследование Binance указывает на скомпрометированный ноутбук DevOps-инженера как на точку входа, и, по словам Binance, признаков утечки приватных ключей кошельков не обнаружено. Оба вывода предварительные.
  • Злоумышленнику, который контролирует системы, запрашивающие и одобряющие подписи, не нужно красть сами ключи.
  • FBI и ряд компаний, занимающихся блокчейн-аналитикой, приписывают кражу северокорейской группировке TraderTraitor; сама Binance атакующих не назвала.
  • Важнее всего защита, которая охватывает людей, конечные точки и цепочки одобрения вокруг ключей, а не только сами ключи.
  • Та же схема применима к облачным консолям, SSH, конвейерам CI/CD и ИИ-агентам, способным действовать в продакшене.

Что произошло и что пока остаётся предварительным

Компания блокчейн-аналитики TRM Labs сообщает, что средства начали уходить с кошельков Binance около 20:05 UTC 29 октября, причём основная часть суммы была выведена примерно за 20 минут. В предварительном заявлении, о котором сообщил BleepingComputer, Binance указала, что инцидент может быть связан со скомпрометированным ноутбуком DevOps-инженера, через который злоумышленник получил доступ к сервисному контейнеру и отправил несанкционированные транзакции на вывод средств. Binance приостановила вывод, отозвала затронутые полномочия и начала работать с правоохранительными органами.

Позднее Binance заявила, что в ходе расследования «выявлены дополнительные точки проникновения». Со-генеральный директор Richard Teng заявил, что атака не сводилась к полномочиям одного инженера, и, как цитирует Elliptic, что она «не проходила через наши обычные механизмы одобрения». Binance пообещала подробный разбор инцидента (post-mortem), который на момент написания статьи (2 ноября) ещё не был опубликован.

ВопросСтатус на момент написания
Сумма ущербаОколо 6,3 млрд долларов по оценке Binance; аналитические компании называют от 6,36 до 6,43 млрд долларов в зависимости от методики и используемых цен.
Точка входаПредварительно: скомпрометированный ноутбук DevOps-инженера. Позднее Binance сообщила о дополнительных точках проникновения.
Утечка приватных ключейПо словам Binance, признаков утечки приватных ключей кошельков не обнаружено. Расследование продолжается.
Кто стоит за атакой31 октября FBI приписало кражу северокорейской группировке TraderTraitor, что совпадает с выводами TRM Labs, Chainalysis и Elliptic. Binance атакующих не назвала.
Замороженные средстваДанные не окончательные. Binance говорит примерно о 3 млрд долларов, которые удалось обездвижить; Elliptic по состоянию на 1 ноября подтвердила заморозку или изъятие в блокчейне около 2,85 млрд долларов, в основном в стейблкоинах.
Последствия для клиентовBinance заявляет, что возьмёт убытки на себя и что средства пользователей в безопасности. С 1 ноября вывод средств поэтапно возобновляется.

Заморожено не значит возвращено. Эмитенты стейблкоинов, такие как Tether и Circle, могут замораживать выпущенные ими токены, но биткоин, XRP и другие нативные активы так заморозить нельзя, и значительная часть украденного всё ещё отмывается.

Почему скомпрометированная привилегированная конечная точка может быть опаснее украденного ключа

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

Данные из блокчейна вписываются в эту картину. По оценке TRM Labs, характер транзакций во множестве сетей «указывает на компрометацию инфраструктуры подписания горячих кошельков Binance», то есть злоумышленник мог заставить собственные системы Binance подписывать выбранные им транзакции. В Ethereum компания по безопасности Blockaid обнаружила, что один из горячих кошельков подписал пакет авторизаций EIP-7702, которые передали контроль над кошельком контракту злоумышленника. Каким образом были получены эти подписи, пока не подтверждено; этот механизм мы разберём в отдельной статье.

Это не ново. При краже у Bybit в феврале 2025 года, которую FBI также приписало TraderTraitor, злоумышленники скомпрометировали компьютер разработчика у поставщика кошельков и подменили транзакцию, которую одобрили подписанты Bybit. В обоих случаях ключи сделали ровно то, что от них требовали. Вопрос был в том, кто именно этого требовал.

Пять защитных проверок

1. Отделите привилегированные устройства от повседневной работы

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

2. Требуйте участия нескольких человек и добавьте задержку

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

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

3. Укрепите конечные точки и следите за ними

Установите EDR на каждое привилегированное устройство и обеспечьте круглосуточный разбор его оповещений. Своевременно устанавливайте обновления, блокируйте неподписанное или неразрешённое ПО, используйте устойчивую к фишингу MFA, например аппаратные ключи безопасности, и ограничьте срок действия административных сессий и токенов. Рассматривайте инструменты разработчика, включая пакеты, расширения IDE и ИИ-ассистенты для программирования, как часть поверхности атаки.

4. Выявляйте аномалии и будьте готовы быстро всё заморозить

Средства Binance были выведены за считаные минуты. Определите, как выглядит норма для ваших самых критичных операций — объёмы, получатели, время суток, частота подписания, — и настройте оповещения об отклонениях в реальном времени. Подготовьте механизм экстренной остановки, способный за секунды приостановить вывод средств, развёртывания или подписание, заранее определите, кто вправе его запускать, и отработайте его применение.

5. Проверьте, кто и что может инициировать подписание и доступ к продакшену

Составьте список всех людей, сервисных учётных записей, контейнеров, конвейеров и ключей API, которые могут запросить подпись, одобрить платёж или изменить продакшен. Для каждого проверьте, нужен ли ещё этот доступ, ограничен ли он настолько узко, насколько возможно, и записывается ли его использование туда, где злоумышленник не сможет стереть следы. По возможности откажитесь от постоянных привилегий и перейдите на доступ just-in-time.

Уроки для корпоративного облака, SSH, CI/CD и ИИ-операций

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

  • Облако: ноутбук администратора с активной сессией консоли или кэшированными учётными данными CLI ценен так же, как root-учётная запись. Используйте краткосрочные учётные данные, сессии с привязкой к устройству и процессы одобрения для разрушительных или особо значимых действий.
  • SSH: долгоживущие ключи на компьютерах инженеров дают злоумышленнику прямой доступ к серверам. Отдавайте предпочтение краткосрочным SSH-сертификатам, выдаваемым на каждую сессию, и централизованно журналируйте каждую привилегированную сессию.
  • CI/CD: конвейеры часто хранят учётные данные для развёртывания и подписания. Защитите определения конвейеров обязательным ревью, разделите учётные данные для сборки и выпуска и требуйте одобрения для релизов в продакшен.
  • ИИ-операции: ИИ-агенты, способные выполнять команды, открывать pull request или вызывать API продакшена, — это новые привилегированные сущности. Выдайте им собственные учётные данные с узкими правами, сохраните этап одобрения человеком для критичных действий и журналируйте их действия.

Совет: Проведите штабные учения (tabletop exercise) с одним вопросом: «Если бы ноутбук этого инженера был полностью скомпрометирован сегодня ночью, что успел бы сделать злоумышленник, прежде чем кто-то заметит?» Ответ покажет, где ваши цепочки одобрения зависят от одного устройства.

За чем следить дальше

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

Чем может помочь LOGIQ

LOGIQ помогает организациям проверять привилегированный доступ на серверах Linux, в облачных средах и конвейерах CI/CD, а также проектировать механизмы одобрения и мониторинга, соответствующие тому, как на самом деле работают их команды. Если вы хотите взглянуть со стороны на то, кто и что может действовать с полномочиями в вашей среде, свяжитесь с нами.

Источники