Сообщается, что угрожающий субъект под названием Azazel злоупотребил ИИ-ассистентом для программирования, чтобы проводить атаки с использованием программ-вымогателей, красть данные и компрометировать корпоративные сети в шести странах. Атака с использованием программы-вымогателя через ИИ-ассистента для программирования, как описано в Cybersecurity News, — это напоминание о том, что инструменты, которым разработчики доверяют каждый день, могут стать путём в корпоративную сеть.

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

Что Azazel сделал с ИИ-ассистентом для программирования

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

Из сводки выделяются три вещи:

  • Развёртывание программы-вымогателя: Сообщается, что ассистент был частью того, как проводились атаки, а не просто сторонним наблюдателем.
  • Кража данных: Помимо шифрования систем, злоумышленник, как сообщается, украл данные, что соответствует распространённой схеме двойного вымогательства.
  • Международный охват: Цели в шести странах говорят о том, что это был не единичный инцидент против одной организации.

То, чего в отчёте нет, не менее важно. Мы не знаем, как Azazel получил доступ к ассистенту, какие компании пострадали или сколько данных было похищено. Пока не опубликовано больше деталей, относитесь к любым утверждениям за пределами сводки с осторожностью.

Почему инструменты разработчиков — привлекательный канал для атак

ИИ-ассистенты для программирования находятся в необычно привилегированном положении. Чтобы быть полезными, им часто нужно читать исходный код, выполнять команды, получать доступ к репозиториям и подключаться к внутренним сервисам. Этот доступ предоставляется намеренно — именно это и делает их привлекательными.

Есть несколько причин, по которым злоумышленники обращают внимание на эти инструменты:

  • Доверие по умолчанию: Активность с машины разработчика или от одобренного инструмента с меньшей вероятностью вызовет тревогу, чем трафик с неизвестного устройства.
  • Широкие разрешения: Разработчики часто обладают учётными данными, токенами и сетевым доступом, которых нет у обычных сотрудников.
  • Автоматизация: Ассистент может действовать быстро и в масштабе, что помогает злоумышленнику двигаться быстрее, чем человек, работающий вручную.

Это не первый раз, когда такая схема всплывает. В более раннем материале о том, как хакеры Aurora обманом заставили Cursor AI взломать 7 фирм, описывалось, как группировки программ-вымогателей переключают внимание с обмана сотрудников на атаки на инструменты, на которые эти сотрудники полагаются. Отчёт об Azazel говорит о том, что этот сдвиг продолжается.

Где VPN и доступ с нулевым доверием помогают, а где нет

Естественно спросить, ограничили бы ущерб VPN или уровень доступа с нулевым доверием. Честный ответ: частично.

Где они помогают

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

Где они не помогают

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

Короче говоря, сетевые меры контроля уменьшают радиус поражения, но они не могут заменить жёсткие ограничения на то, что разрешено делать самому инструменту.

Шаги, которые организации могут предпринять для ограничения доступа ИИ-инструментов

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

  1. Проведите инвентаризацию инструментов. Знайте, какие ассистенты используются, включая те, что разработчики установили самостоятельно.
  2. Применяйте принцип наименьших привилегий. Давайте каждому инструменту только те репозитории, команды и учётные данные, которые ему нужны, и избегайте долгоживущих токенов.
  3. Требуйте одобрения для рискованных действий. Где возможно, заставляйте ассистент спрашивать человека перед выполнением shell-команд или изменением системных настроек.
  4. Сегментируйте сеть. Держите машины разработчиков подальше от резервных копий, производственных баз данных и контроллеров домена.
  5. Мониторьте и логируйте. Отслеживайте, что делают ассистенты, и оповещайте о необычном доступе к файлам, массовой передаче данных или неожиданных исходящих подключениях.
  6. Защищайте резервные копии. Держите офлайн- или неизменяемые копии, чтобы программы-вымогатели не могли добраться до них через скомпрометированный инструмент.

Что это значит для вас

Если вы работаете в сфере безопасности или ИТ, вывод таков: относитесь к ИИ-ассистентам для программирования как к привилегированным учётным записям, а не безобидным дополнениям для продуктивности. Проверьте, что они могут читать, выполнять и к чему подключаться.

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

Если вы обычный пользователь, с этим отчётом не связано никаких прямых действий. Тем не менее инцидент — полезное напоминание о том, что корпоративные данные, которыми вы делитесь с работодателем или сервисом, могут быть раскрыты, когда инструменты поставщика подвергаются злоупотреблению, поэтому используйте надёжные уникальные пароли и включайте многофакторную аутентификацию.

Выводы

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

Чтобы увидеть, как это вписывается в более широкую картину, прочитайте наш материал о взломе Cursor AI, связанном с хакерами Aurora. Затем задайте своей команде простой вопрос на этой неделе: какие разрешения и сетевой доступ мы предоставили нашим ИИ-инструментам для программирования, и действительно ли им нужно всё это?