Цепочка технических и человеческих сбоев в системе безопасности, которых можно было избежать, привела к крупнейшей в истории краже криптовалюты — хищению примерно 6,34 миллиарда долларов у Binance. Неправильный мониторинг и ограничение доступа к внутреннему инструменту на базе ИИ сыграли ключевую роль в помощи хакерам и должны послужить предупреждением для руководителей служб информационной безопасности предприятий о необходимости серьезно относиться к управлению ИИ.
В первоначальном отчете Binance, опубликованном 3 ноября, описывается многомесячная многоэтапная кампания против инженеров, отвечающих за инфраструктуру кошельков. В результате вредоносное ПО было установлено на машины разработчиков в двух отдельных инцидентах, причем обнаружен был только один. Затем злоумышленники смогли получить доступ к дополнительным системам разработчиков через внутренний инструмент ИИ, получить токен доступа и развернуть контейнер в инфраструктуре Binance, прежде чем осуществить несанкционированные выводы средств.
Хотя Binance описывает эту атаку как высокотехнологичную, в ней присутствовало множество сбоев в системе безопасности, которых можно было избежать: от слабых или отсутствующих средств контроля доступа до чрезмерно широких привилегий, плохой гигиены учетных данных и недостаточной осведомленности сотрудников о безопасности или нарушений политики.
«Рабочие станции разработчиков тихо стали одними из самых привилегированных активов в корпоративной среде, неся в себе токены развертывания, подписывая доступ и теперь инструменты ИИ, которые могут действовать в рамках внутренних систем от имени сотрудника», — предупреждает Джо Бринкли, директор отдела исследований безопасности и сообщества в компании Cobalt. «Как только злоумышленник получает контроль над этой машиной, инструмент ИИ с широким внутренним охватом становится еще одним доверенным путем, который он может использовать».
Он добавляет: «Команды безопасности должны рассматривать инженеров с доступом к производству или подписи как поверхность атаки высокой ценности, тестировать путь от рабочей станции до производства так, как это сделал бы противник, и максимально строго ограничивать разрешения для инструментов ИИ, как и для любой служебной учетной записи».
Два компромисса, разделенные месяцами
ФБР возложило ответственность за взлом Binance на Северную Корею, идентифицировав хакерскую группу как TraderTraitor, которая, по мнению других исследователей, является частью более крупной операции Lazarus, похитившей миллиарды долларов у криптовалютных платформ за последнее десятилетие. В собственном отчете Binance излагается вывод ФБР и отмечается, что в течение 2026 года команда безопасности компании обнаружила и предотвратила 57 случаев киберугроз, предположительно связанных с Северной Кореей.
Это говорит о том, что Binance учитывает Lazarus APT в своей модели угроз, как и должно быть, и хорошо осведомлена об инструментах, методах и процедурах (TTP) группы, которые включают компрометацию цепочки поставок программного обеспечения, использование вредоносного ПО, маскирующегося под популярные легитимные инструменты, обман разработчиков с помощью фальшивых собеседований и долгосрочные операции социальной инженерии. Тем не менее, два инженера Binance стали жертвами именно этих уловок, что вызывает вопросы относительно обучения сотрудников безопасности компании, а также ее технических средств контроля.
В июне инженер, отвечающий за инфраструктуру кошельков, искал в интернете популярный инструмент для написания кода на базе ИИ и скачал подмененный установщик Homebrew вместо того, чтобы получить программное обеспечение из доверенного источника. Homebrew — это менеджер пакетов и канал распространения для приложений с открытым исходным кодом на macOS. Команда безопасности Binance обнаружила аномалию, заменила устройство и сменила все связанные учетные данные, но злоумышленники уже узнали, кто этот инженер, и кто еще работает в команде инфраструктуры кошельков.
Хорошо, что Binance смогла быстро обнаружить взлом, но инцидент поднимает вопрос, почему инженер вообще устанавливал программное обеспечение из результатов поиска. Есть ли у Binance политика, согласно которой сотрудники устанавливают программное обеспечение только из одобренных источников, и обеспечивается ли это техническими средствами контроля, такими как белый список приложений?
Три месяца спустя злоумышленники связались со вторым инженером через платформу для поиска работы, представившись руководителем проекта, набирающим сотрудников для несуществующей компании. Последовало два постановочных собеседования: одно с предполагаемым представителем отдела кадров, который поделился аккаунтом в социальной сети, заполненным личными фотографиями и видео для установления доверия, и одно с человеком, выдававшим себя за генерального директора компании.
В конце второго собеседования инженеру было предложено скачать задание по программированию на свой рабочий компьютер из репозитория. Задание содержало вредоносный код, и на этот раз инструменты защиты конечных точек Binance не обнаружили его. Компания описала это как вредоносное ПО нулевого дня, но если инструменты защиты конечных точек способны обнаруживать только известные вредоносные программы, то это проблема всей отрасли.
В любом случае, действия разработчика вызывают ряд вопросов относительно политики безопасности, процедур и осведомленности в Binance, прежде всего: почему инженер проводил собеседования и выполнял тестовые задания на своем рабочем компьютере? Почему он клонировал репозиторий непосредственно в свою систему, а не использовал виртуальную машину? Если он регулярно это делает, то это указывает на пробелы в обучении безопасности или преднамеренные нарушения политики. И компании не могут полагаться исключительно на то, что сотрудники всегда следуют политике. Им нужны механизмы обнаружения и принуждения.
«Инженер сделал несколько ошибок», — говорит Тим Чейз, вице-президент по кибербезопасности в компании Fable Security, занимающейся управлением рисками для персонала. «Современная программа управления рисками должна была убедиться, что он понимает современную [атакующую] поверхность социальной инженерии, которую используют злоумышленники сегодня».
Binance не ответила на вопросы CSO о том, существуют ли у компании политики, явно запрещающие действия разработчика на рабочих компьютерах, и охватывает ли обучение сотрудников тактику социальной инженерии с использованием фальшивых вакансий, часто используемую северокорейскими хакерами.
Чрезмерно привилегированный инструмент ИИ обеспечивает боковое перемещение
После того как злоумышленники запустили вредоносное ПО на компьютере инженера, они смогли использовать находящийся на нем внутренний инструмент ИИ для перехода на другие машины, принадлежащие двум другим инженерам из команды инфраструктуры кошельков.
Binance не уточнила назначение этого инструмента в своем отчете или для CSO, но тот факт, что он мог быть использован одним скомпрометированным пользователем для доступа к различным компьютерам, предполагает, что его привилегии были слишком широкими или что ему не хватало надлежащих средств контроля доступа. На это намекает компания в списке мер по устранению последствий, который включал: «Перестроили затронутый внутренний инструмент ИИ и средства контроля доступа».
На одном из дополнительных инженерных компьютеров злоумышленники нашли токен с разрешениями на развертывание новых контейнеров в инфраструктуре компании. Через девять дней они использовали этот токен на другом скомпрометированном инженерном компьютере для развертывания контейнера с вредоносным скриптом, который взаимодействовал со службой подписи кошельков и инициировал вывод средств.
Эта серия событий вызывает дополнительные вопросы о гигиене учетных данных и контроле доступа, поскольку отчет Binance не описывает никаких дополнительных проверок. Почему токен был долгоживущим, а не эфемерным для одной операции? Включало ли развертывание контейнеров в производственную среду дополнительные этапы проверки или утверждения? Существует ли какая-либо аутентификация между развернутым контейнером и службой подписи, или было достаточно находиться в одной доверенной сети? Binance не ответила на вопросы CSO по любому из этих пунктов.
«Внутренний инструмент ИИ, который может получить доступ к системам инженеров, обладает таким же доступом, как и привилегированный сотрудник, и большинство организаций не управляют им таким образом», — говорит Джастин Билс, генеральный директор Strike Graph. «Ожидайте, что больше групп будут копировать этот сценарий против тех, кто владеет ключами подписи, токенами развертывания или доступом к производству. Руководители служб безопасности должны рассматривать инженеров с доступом к производству и инструменты ИИ, которые используют эти инженеры, как привилегированные идентификационные данные. Это означает ограничение того, что устанавливается на рабочих машинах, быстрое истечение срока действия токенов развертывания, а также ведение журналов и анализ того, что на самом деле делают внутренние инструменты ИИ».
Шломи Салем, соучредитель Neo, стартапа, специализирующегося на безопасности ИИ-агентов, предсказал вектор атаки с использованием ИИ за несколько дней до того, как Binance опубликовала свои выводы. «Я не удивлюсь, если следователи найдут отравленный пакет, злоупотребление агентом или и то, и другое в начале этой цепочки», — сказал он 30 октября после объявления о взломе.
Вывод для организаций заключается в том, что внутренние инструменты ИИ теперь являются частью поверхности атаки и нуждаются в соответствующем тестировании, сообщает Брай Фрост, директор по управлению продуктами в Cloud Range, изданию CSO.
«Когда инструмент ИИ может получать доступ к другим системам от имени сотрудника, злоумышленник, контролирующий машину этого сотрудника, может унаследовать все, что может делать этот инструмент», — говорит она. «Это меняет вопрос, на который должны ответить команды безопасности. Важно не только то, дает ли модель хорошие ответы, но и то, что она будет делать и для кого, когда запрос поступает из скомпрометированной сессии».
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Lucian Constantin
