Как фейковое интервью открыло путь к Binance

Как развивалась атака

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

На момент публикации сообщения Binance связывала дальнейшее развитие атаки уже с рабочей средой. Скомпрометированный ноутбук и внутренний ИИ-инструмент использовали, чтобы добраться до ноутбуков ещё двух инженеров. Это важная деталь: атакующий двигался не через экзотический эксплойт, а через доверенные пользовательские и разработческие маршруты.

Дальше в описании фигурируют токен развёртывания контейнеров, вход на другой инженерный компьютер и запуск вредоносного скрипта. Затем был задействован внутренний сервис подписи, а механизм Ethereum EIP-7702 дал контролируемому контракту частичные полномочия над горячим кошельком.

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

Почему одного MDM недостаточно

К ноябрю 2026 года вывод для меня простой: MDM здесь нужен, но в одиночку не спасает. Jamf может навязать конфигурации, ограничить ПО, убрать постоянные права администратора, поставить защитные агенты и обеспечить удалённую реакцию. Но «запретить терминал» недостаточно: ту же операцию можно вызвать другим бинарником или через доверенный инструмент.

Реальное обнаружение строится на поведении. EDR должен видеть дерево процессов, команды, файловые изменения, сеть и доступ к токенам; SIEM должен связать это с журналами идентификации, репозиториев, контейнерной платформы и сервиса подписи. Свежий репозиторий, обфусцированный shell, чтение токена и нетипичное развёртывание вместе уже выглядят как инцидент, а не шум.

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

Ранее мы разбирали, как Unicode-гомоглифы маскируют вредоносные URL и команды, обманывая ИИ-агентов. Те же методы социальной инженерии, что стоят за приманками с фейковыми интервью, показывают, почему командам нужно проверять ссылки, личности и запросы на выполнение команд.