Как могли взломать Binance через поддельное собеседование
По предварительному отчёту Binance от 3 ноября 2026 года, атакующие могли получить доступ к инфраструктуре биржи через фальшивый наём: кандидату прислали тестовое задание с вредоносным Git-архивом, скрытый хук post-checkout запустил код, а компрометация постепенно дошла до токена развёртывания DevOps-инженера и затронула направление Wallet DevOps, как пишет Хабр.
Краткий ответ
Предварительный отчёт Binance описывает многоэтапную операцию: кандидат получил вредоносное тестовое задание, Git-хук post-checkout скачал и запустил код, а доступ постепенно дошёл до токена развёртывания DevOps-инженера и затронул направление Wallet DevOps. ФБР связывает атаку с Северной Кореей. Похожий по сценарию архив независимо разобрали на Хабре, но прямая связь с атакой на биржу не подтверждена.
Фальшивый наём как вход в инфраструктуру
Рекрутер пишет в LinkedIn или мессенджере, предлагает позицию получше текущей, назначает два раунда собеседований — процесс выглядит как обычный найм. Перелом наступает на этапе тестового задания: кандидату присылают архив с «проектом компании» и просят изучить код перед финальным интервью.
В случае Binance получателем такого задания стал сотрудник, обозначенный в отчёте как Software Engineer B. Он выполнил инструкции из задания и дал атакующим первую точку опоры в инфраструктуре биржи. Binance описывает произошедшее как многоэтапную операцию, а не единичный эпизод с мгновенным доступом ко всем кошелькам: вредоносный код сначала закрепился на одной машине, и только позже доступ дошёл до DevOps-инженера A и его токена развёртывания, что затронуло направление Wallet DevOps.
Отчёт не раскрывает, какими именно системами управляет этот токен развёртывания и получили ли атакующие доступ к самим кошелькам биржи — предварительный документ фиксирует факт компрометации доступа, а не итоговый масштаб ущерба.
Этот вектор работает потому, что ломает обычную настороженность разработчика: открывать незнакомый код по приглашению HR-команды — рутинная задача, а не повод для подозрений. Binance ссылается на атрибуцию ФБР; Chainalysis отдельно описывает использование поддельного найма в атаках, связанных с КНДР.
Что нашли при разборе похожего образца
Технические детали конкретного архива, использованного против Binance, биржа публично не раскрыла. Но похожую по сценарию схему разобрал на Хабре автор под ником izoTopworm: его знакомому прислали архив с «игровым проектом» в рамках такого же по форме предложения о работе, и тот передал файл на анализ.
Автор разбора сразу оговаривает границу: связь именно этого образца с атакующими Binance или конкретной северокорейской группой не установлена. Сходство сценария — повод проверить файл, а не доказательство атрибуции. Тем не менее разбор показывает механику, которая объясняет, как подобная доставка вредоноса технически устроена.
README архива просил переключиться на ветку с названием video ещё до установки зависимостей — якобы чтобы посмотреть демо-материалы. Внутри ZIP лежал рабочий каталог .git, а в нём действующий хук post-checkout весом 826 байт, который срабатывает автоматически при переключении ветки и скачивает внешний код с домена nexorolabs[.]store.
Статический анализ этой цепочки — автор использовал Codex с моделью Astra в режиме Extra High — привёл к обфусцированному JavaScript-файлу размером 4,5 МБ. Внутри нашлись три отдельные программы: сборщик данных браузера и криптокошельков, сборщик произвольных пользовательских файлов и RAT с интерактивной удалённой оболочкой. Ещё одна точка загрузки кода обнаружилась в истории коммитов — в файле с намеренно неприметным именем server/config/.svn/env.module.
Почему git-хук так опасен
Хук post-checkout — штатная часть Git: он вызывается после checkout или switch и получает прежний HEAD, новый HEAD и флаг переключения ветки. Такое поведение описано в документации Git и само по себе не уязвимость.
Проблема в другом: обычный git clone не переносит чужую папку .git/hooks как часть исходников, а готовый ZIP-архив рабочего каталога — переносит. Получатель архива с вредоносным репозиторием получает не только код, но и локальный механизм исполнения, который сработает от любой команды checkout или switch независимо от названия ветки.
В разобранном образце хук не проверял ни имя ветки, ни переданные аргументы — срабатывал при любом переключении. В зависимости от операционной системы он вызывал curl, wget или PowerShell и передавал ответ сервера прямо интерпретатору. Дальше запускался отдельный процесс Node.js, который работал как detached-процесс и отвязывался от родительского терминала: закрытие окна уже не останавливало цепочку.
В образце нашлись и другие детали: отключённая функция расшифровки сохранённых паролей и файловый фильтр, который из-за одного слова в пути — user — подхватывал заметно больше файлов, чем можно ожидать от списка «чувствительных» данных.
Матрица решений: что останавливает атаку на каждом этапе
Зная последовательность атаки, легко увидеть, где именно её можно прервать.
| Этап атаки | Что происходит | Что останавливает |
|---|---|---|
| Фальшивый наём | Рекрутер предлагает вакансию, проводит несколько раундов интервью | Проверка компании и рекрутера, политика HR о внешних контактах с инженерами |
| Тестовое задание | Кандидат получает архив с «кодом компании» | Статический анализ и песочница до распаковки, запрет запускать чужой код на рабочей машине |
| Переключение ветки | git checkout или switch запускает скрытый hook | Аудит .git/hooks, контроль core.hooksPath, работа с чужими репозиториями только в одноразовой VM |
| Исполнение загрузчика | Скачивается и запускается обфусцированный JS | EDR на рабочих станциях, мониторинг исходящих соединений к незнакомым хостам |
| Распространение доступа | Компрометация переходит на инженера с правами на деплой | MFA и ротация токенов развёртывания, сегментация доступа между командами |
Каждый уровень защиты дешевле предыдущего взлома: статический анализ архива до запуска занимает минуты, а расследование постинцидента после компрометации доступа — недели.
Где это ломается у обычных команд
Главная слабость такой схемы в том, что она эксплуатирует не баг в коде, а норму поведения инженера. Код-ревью, песочницы для сторонних зависимостей, сканеры уязвимостей — всё это обычно настроено проверять пакеты из npm или PyPI, но редко распространяется на архив, присланный рекрутером по почте или в мессенджере.
Собеседование добавляет социальное давление: кандидат хочет понравиться, не откладывает просмотр задания и часто открывает код на личном или рабочем устройстве, не задумываясь об изоляции. Если на этом же устройстве сохранены токены доступа к корпоративным системам или настроены SSH-ключи, разовое выполнение чужого кода превращается в точку входа.
Отдельная проблема — доверие к Git как к нейтральному инструменту. Разработчики привыкли проверять зависимости и содержимое README, но редко читают .git/hooks перед тем, как переключить ветку: это действие воспринимается как безопасное чтение истории, а не как исполнение кода.
Что проверить у себя
Из этого случая следует практический набор мер для DevOps и security-команд:
- Проверяйте тестовые задания и чужие репозитории в одноразовой изолированной среде — disposable VM без рабочих учётных данных, без сетевого доступа к корпоративным ресурсам и без реальных браузерных профилей.
- Аудируйте
.git/hooksперед работой с чужим репозиторием, проверяйте значениеcore.hooksPathи ограничивайте автоматическое исполнение hooks из непроверенных источников. - Не выполняйте инструкции из README вслепую, включая безобидные на вид команды вроде переключения ветки — само переключение уже исполняет код хуков.
- Включите MFA для токенов развёртывания и систем, которые управляют production-доступом, и настройте короткий срок жизни токенов с автоматической ротацией.
- Сегментируйте доступ между командами: компрометация рабочей станции одного инженера не должна напрямую открывать путь к токенам другого.
- Мониторьте исходящие соединения с рабочих станций к незнакомым доменам и нестандартным портам.
- Введите для HR регламент проверки компании-работодателя и каналов связи с кандидатами до того, как инженер получит тестовое задание.
Почему это важно
Binance — одна из крупнейших криптобирж, и этот случай показывает, что для компрометации доступа такого масштаба необязательно искать уязвимость в коде продукта: достаточно пробить процесс найма, устроенный почти одинаково в любой инженерной компании.
На наш взгляд, это говорит о том, что граница между HR-процессом и периметром безопасности стирается быстрее, чем успевают обновляться корпоративные политики: тестовое задание кандидата становится такой же точкой риска, как сторонняя зависимость в production-коде, и требует сопоставимого контроля.
Binance ссылается на атрибуцию ФБР, связывающую атаку с Северной Кореей. Chainalysis отдельно описывает использование поддельного найма как технику в атаках, которые связывают с КНДР — то есть схема не выглядит разовым экспериментом, а укладывается в уже известный почерк.
Что дальше
Binance назвала отчёт от 3 ноября 2026 года предварительным — значит, возможны уточнения по масштабу компрометации, затронутым системам и итоговому ущербу. Пока неизвестно, какие именно данные или системы были доступны через токен развёртывания DevOps-инженера A, кроме того, что компрометация затронула направление Wallet DevOps; отчёт не детализирует, получили ли атакующие доступ к самим кошелькам биржи.
Для команд вне Binance практический вывод один: цепочка «фальшивый наём → тестовое задание → вредоносный Git-репозиторий» уже задокументирована как рабочая техника и должна войти в модель угроз наравне с атаками на зависимости и CI/CD-пайплайны. Проверка тестовых заданий кандидатов через статический анализ и изолированные среды — естественное продолжение той же логики, что уже применяется к сторонним библиотекам.
Если Binance опубликует финальный отчёт с большей детализацией, он может уточнить атрибуцию, список затронутых систем и реальный объём последствий — пока эти цифры остаются за рамками доступной фактуры.
FAQ
Что такое Git-хук post-checkout и почему он опасен?
post-checkout — штатный механизм Git, который срабатывает после переключения ветки или извлечения файлов. Опасность не в самом хуке, а в том, что ZIP-архив готового рабочего каталога может нести чужую папку .git/hooks с уже активным обработчиком, который исполнит код при обычной команде checkout.
Правда ли, что атаку на Binance связывают с Северной Кореей?
Binance ссылается на атрибуцию ФБР, которая связывает атаку с Северной Кореей. Chainalysis отдельно описывает использование поддельного найма как технику в атаках, которые относят к КНДР.
Была ли скомпрометирована сама крипто-инфраструктура Binance?
Предварительный отчёт этого не уточняет. Известно, что компрометация затронула направление Wallet DevOps и токен развёртывания DevOps-инженера A, но отчёт не говорит прямо, получили ли атакующие доступ к самим кошелькам биржи.
Связан ли разобранный на Хабре архив именно с атакой на Binance?
Нет. Автор разбора прямо указывает, что связь образца с атакующими Binance или конкретной северокорейской группой не установлена. Сходство сценария — повод для проверки, а не доказательство атрибуции.
Как проверить тестовое задание от работодателя, не рискуя рабочим компьютером?
Открывайте архив в одноразовой изолированной среде без рабочих учётных данных и сетевого доступа к корпоративным системам, проверяйте содержимое .git/hooks перед любыми командами и не выполняйте инструкции README вслепую, включая переключение веток.