Расходы отдельных компаний на украденный доступ к облачным ИИ-моделям достигали $1 млн, прежде чем доступ удавалось отозвать. Схема получила название LLMjacking: преступники похищают ключи и токены, а затем перепродают вычислительные ресурсы клиентов через теневые сервисы. Для российских команд, которые активно подключают модели через API и облачные аккаунты, это ещё один повод считать IAM и расходы на ИИ частью одной задачи, а не двумя строками в разных отчётах.
О формировании такого криминального рынка сообщает Dark Reading со ссылкой на исследование Google Threat Intelligence Group и Mandiant. По наблюдениям исследователей, в отдельных инцидентах мошенническое потребление ресурсов превышало $100 тыс. за сутки. В отличие от криптоджекинга, который часто медленно съедает мощности месяцами, злоупотребление LLM API способно разогнать счёт за несколько часов: достаточно направить через чужой аккаунт поток запросов к дорогой модели.
Цель атакующих не обязательно данные компании и не обязательно остановка сервиса. Им нужен оплаченный кем-то доступ к коммерческим моделям. Получив его, они могут использовать API сами или продать доступ тем, кому не хочется заводить собственный аккаунт, проходить проверки или платить обычную цену. В этой экономике жертва остаётся с облачным счётом, а посредник — с выручкой от подписок.
Как похищают доступ к моделям
Главным входом остаются не уязвимости самих языковых моделей, а скомпрометированные облачные учётные данные. Google перечисляет открытые или украденные IAM-реквизиты, ключи сервисных аккаунтов, персональные токены GitHub и активные токены сессий. Это привычная для облачной безопасности картина, только теперь у похищенного ключа появился особенно понятный способ монетизации.
Атакующие действуют осторожно. В исследовании описаны минимальные проверочные запросы к API — иногда с ответом всего в один токен. Так можно убедиться, что ключ рабочий, почти не оставив заметного следа в расходах. Затем доступ сохраняют, расширяют права или готовят к перепродаже. Ник Таусек, ведущий архитектор автоматизации безопасности в Swimlane, отмечает: пока внутри компании выясняют причину резкого роста счёта за облако, у злоумышленника уже могут быть платящие клиенты.
Один из кластеров, отслеживаемый как UNC6993, в середине года скомпрометировал облачный инстанс через неверно настроенный ключ сервисного аккаунта и использовал его для получения дополнительного доступа к LLM API. В другом эпизоде злоумышленники разместили страницу для перехвата сессии, имитирующую портал приложения. Пользователя убеждали открыть настоящий сайт ИИ-сервиса и вставить туда исходный JSON с активным токеном; данные уходили на сервер атакующих и позволяли обойти пароль и многофакторную аутентификацию.
Исследователи также видели комбинацию украденного токена доступа к приватным репозиториям и предполагаемой уязвимости веб-приложения внутри контейнерной облачной среды. В ещё одном случае скомпрометированные токены федерации позволили программно создать новые ключи доступа и обойти защиту MFA. Общая мораль неприятно знакома: многофакторная аутентификация защищает вход пользователя, но не спасает, если атакующий уже получил действующий токен или возможность выпускать новые ключи.
Почему LLMjacking стал отдельным бизнесом
Ключевой элемент схемы — так называемые LLM Mixer, подпольные сервисы-посредники. Они собирают украденные реквизиты, проксируют запросы клиентов через инфраструктуру жертв и продают доступ к премиальным моделям дешевле легального тарифа. Покупателю такого сервиса не нужен собственный облачный аккаунт и API-ключ, а оператору не приходится объяснять происхождение вычислений. Google зафиксировала расследование, в котором два разных операционных кластера координировали взлом и монетизацию корпоративной ИИ-инфраструктуры. Рынок начинает делиться на специализации: одни добывают доступ, другие превращают его в витрину с тарифами.
Для разработчиков это означает, что секреты для LLM API нельзя воспринимать как менее ценные, чем ключи к базе данных или платёжному провайдеру. Их не стоит хранить в репозиториях, логах, фронтенд-конфигурациях и переменных окружения, которые видит слишком широкий круг сервисов. Нужны короткоживущие учётные данные там, где это возможно, минимальные права сервисных аккаунтов, ротация ключей и отдельные проекты либо аккаунты для разных сред. Командам платформенной инженерии полезно заранее определить, кто и как может выпускать ключи, менять роли и подключать новые модели.
Бизнесу одной настройки лимитов расходов тоже недостаточно, хотя она способна ограничить ущерб. Полезнее сопоставлять три сигнала: неожиданные вызовы AI API, изменения прав и аномалии в облачной идентификации. Отдельного внимания заслуживают небольшие тестовые запросы с новых IP-адресов, сервисных аккаунтов или регионов: при LLMjacking они могут быть не безобидной диагностикой, а проверкой украденного доступа перед масштабной продажей.
Рост LLMjacking показывает, что корпоративные модели окончательно стали товаром с понятной теневой ценой. Чем больше организаций встраивают генеративный ИИ в продукты и внутренние процессы, тем важнее будет не только выбрать модель и контролировать качество ответов, но и доказать, кто именно имеет право тратить её токены. Вопрос уже не в том, появятся ли такие атаки в каждом облаке, а в том, заметит ли их компания до того, как очередной API-ключ начнёт оплачивать чужой бизнес.
