LLM-jacking: защита API-ключей ИИ-моделей от даркнета

Что произошло

27 сентября 2026 года Google Threat Intelligence Group опубликовала данные о выявлении на даркнет-площадках каналов для продажи несанкционированного доступа к коммерческим ИИ-моделям. Исследователи зафиксировали предложения по доступу к API Anthropic, OpenAI и Google со скидками, достигающими 97% от официальной стоимости. Это явление напрямую связано с ростом атак типа LLM-jacking, при которых злоумышленники компрометируют облачные аккаунты или API-ключи и используют вычислительные ресурсы жертвы для собственных нужд. По данным Cloud Security Alliance, ссылающимся на исследование Sysdig, количество инцидентов, связанных с кражей учётных данных для ИИ-сервисов, выросло на 376% в IV квартале 2025 года по сравнению с I кварталом 2026 года.

Механика атаки заключается в том, что stolen credentials позволяют злоумышленнику потреблять дорогой инференс моделей за счёт владельца ключа. Google подчёркивает, что основной вектор компрометации — это утечка ключей из публичных репозиториев, файлов конфигурации, логов CI/CD и неправильно настроенных облачных хранилищ. После получения ключа атакующие проверяют его на работоспособность, определяют доступные модели и лимиты, а затем либо используют его самостоятельно, либо перепродают доступ, часто маскируя его через reverse-proxy-сети. Экономическая мотивация атаки остаётся высокой: стоимость вычислений и токенов ложится на жертву, а злоумышленник получает доступ к передовым моделям без затрат.

Реакция Google включает рекомендации по усилению управления идентификацией: инвентаризация всех ключей, удаление неиспользуемых, применение принципа наименьших привилегий и использование специализированных сервисов для управления секретами, таких как Secret Manager. Компания отмечает, что хранение API-ключей в исходном коде, клиентских приложениях или открытых конфигурационных файлах недопустимо. Ситуация усугубляется тем, что, по данным CSA, в открытом доступе находится около 175 000 экземпляров платформы Ollama, многие из которых могут раскрывать не только API-ключи, но и данные диалогов из-за неправильной конфигурации.

Как это устроено

Механика компрометации API-ключей

Первичный этап атаки — поиск секретов. Автоматизированные сканеры continuously индексируют публичные Git-репозитории (например, на GitHub), Docker Hub, Pastebin и неправильно настроенные S3-бакеты в поисках строк, похожих на API-ключи. По нашему опыту проектов, ключи часто оказываются в файлах .env, config.json, скриптах развертывания или в истории коммитов. После обнаружения ключ немедленно проверяется на валидность путём отправки тестового запроса к API провайдера. Успешная проверка позволяет злоумышленнику определить тип ключа, доступные модели, установленные квоты и привязанный платёжный аккаунт.

Экономика и монетизация LLM-jacking

Компрометированный ключ становится товаром на теневых рынках. Монетизация происходит двумя основными способами: прямая продажа ключа или предоставление доступа через reverse-proxy. В первом случае покупатель получает сам ключ и использует его напрямую, что рискованно из-за возможного быстрого отзыва. Во втором, более распространённом сценарии, покупатель отправляет запросы на прокси-сервер злоумышленника, который, в свою очередь, перенаправляет их на API провайдера, используя украденный ключ. Это скрывает как конечного пользователя, так и сам скомпрометированный ключ от владельца и провайдера, затрудняя обнаружение.

Технология уклонения от обнаружения

Для обхода систем обнаружения аномалий злоумышленники применяют тактику «медленного и низкого» (low and slow). Они распределяют запросы по большому пулу IP-адресов через прокси-сети, чтобы не превысить пороговые значения по количеству запросов с одного адреса. Запросы генерируются в разное время суток, имитируя активность легитимных пользователей из разных географических регионов. В типовом сценарии атакующий избегает запросов к самым дорогим моделям с длинным контекстом, предпочитая менее заметные, но всё ещё затратные операции, чтобы не привлекать внимание резким скачком расхода.

Роль уязвимостей в само-hosted решениях

Риск не ограничивается облачными провайдерами. Компании, развертывающие модели вроде Ollama на собственных серверах, также уязвимы. Неправильная конфигурация, например, открытие API-порта без аутентификации, позволяет злоумышленнику найти такой инстанс через поисковики вроде Shodan и использовать его для своих задач. CSA упоминает уязвимость CVE-2026-7482 («Bleeding Llama»), которая может привести к утечке данных. В этом случае компания несёт не только финансовые потери на нагрузку GPU, но и рисует утечку внутренних промптов и данных, которые модель обрабатывала.

Ограничения традиционных защит

Многие стандартные практики оказываются недостаточными. Простая ротация ключей не решает проблему, если новый ключ снова попадёт в утечку по той же причине. Ограничение скорости (rate limiting) снижает финансовый ущерб, но не предотвращает exfiltration данных через промпты. Политики безопасности, основанные на инструкциях для модели (prompts), игнорируются, так как атакующий взаимодействует с API напрямую, минуя любые внутренние ограничения модели. Защита должна быть многослойной и строиться вокруг управления доступом, а не вокруг поведения самой модели.

Как это выглядит на практике

Сценарий 1: Утечка ключа из CI/CD пайплайна

Разработчик в спешке добавляет API-ключ от OpenAI в переменные окружения CI/CD-системы для автоматизированного тестирования. Система сохраняет логи выполнения задач, включая переменные, в artefact store, который по ошибке оказался доступен для чтения из интернета. Бот сканирует такие хранилища, находит лог, извлекает ключ и проверяет его. Ключ имеет высокий месячный лимит. Злоумышленник продаёт доступ к нему через reverse-proxy. В течение недели компания видит аномальный рост расхода токенов, при этом запросы приходят с десятков IP-адресов из Юго-Восточной Азии и генерируют контент на языках, которые компания не использует.

Сценарий 2: Компрометация сервисного аккаунта в облаке

Сотрудник финансового отдела становится жертой фишинга и передаёт учётные данные от своего аккаунта в Google Cloud. У аккаунта нет прав на создание виртуальных машин, но ему назначена роль AI Platform User для использования Vertex AI в аналитических задачах. Злоумышленник, получив доступ, не крадёт API-ключ, а использует скомпрометированный аккаунт напрямую для отправки запросов к моделям Gemini. Все расходы списываются с платёжного аккаунта компании. Обнаружить инцидент сложно, так как активность исходит от легитимного сервисного аккаунта, а не от внешнего IP-адреса.

Сценарий 3: Незащищённый инстанс Ollama для внутреннего пилота

Команда R&D разворачивает сервер с Ollama и популярной open-source моделью для внутреннего пилотного проекта. Для удобства разработчики открывают порт 11434 (стандартный порт API Ollama) для доступа из офисной сети, но по ошибке настраивают правило брандмауэра так, что порт оказывается доступен из любого IP-адреса в интернете. Атакующий находит сервер через Shodan, использует его API для генерации кода и анализа данных, нагружая GPU компании. Дополнительно, если в конфигурации Ollama было включено сохранение истории, злоумышленник получает доступ к промптам и ответам, содержащим коммерческую тайну.

Что это значит для российской компании

Для российского бизнеса риски LLM-jacking имеют двойственную природу. Первая связана с использованием зарубежных облачных API, вторая — с отечественными или самостоятельно развёрнутыми решениями. Доступность сервисов OpenAI, Anthropic, Google Cloud и Azure для российских компаний ограничена санкционным режимом, политикой провайдеров и сложностями с платёжными операциями. Как отметил 24 сентября Герман Греф, российские компании в несколько раз увеличили использование зарубежных моделей, в первую очередь китайских DeepSeek и Qwen, что создаёт новую зависимость и связанные с ней риски компрометации учётных данных.

Правовые аспекты не менее важны. Использование иностранных API может противоречить требованиям 152-ФЗ о защите персональных данных, если данные обрабатываются за пределами РФ, а также нормам о коммерческой тайне и критической информационной инфраструктуре. Трансграничная передача промптов, содержащих чувствительную информацию, через скомпрометированный ключ становится не просто техническим инцидентом, а юридическим нарушением. Импортозамещение в виде российских моделей не отменяет необходимости защищать ключи доступа — экономический ущерб от неконтролируемой нагрузки на GPU-кластер или шлюз российского провайдера будет сопоставим.

Влияние на бюджеты и процессы прямое. Неконтролируемое использование API может привести к многомиллионным счетам, которые компания будет обязана оплатить. Процессы разработки должны включать обязательные этапы проверки кода на наличие секретов (secret scanning), а процессы управления рисками — рассматривать API-ключи как высокоценный актив, требующий специальной защиты и мониторинга. Отсутствие резервного контура на случай блокировки внешнего API или компрометации ключа парализует бизнес-процессы, зависящие от ИИ.

Что делать: пошагово

1. Провести полную инвентаризацию всех действующих API-ключей, сервисных аккаунтов и учётных данных, используемых для доступа к ИИ-сервисам как внешним, так и внутренним.
2. Выполнить сканирование всех репозиториев кода, CI/CD-пайплайнов, контейнерных образов, конфигурационных файлов и облачных хранилищ на предмет наличия секретов с помощью специализированных инструментов (например, GitGuardian, TruffleHog).
3. Немедленно отозвать все ключи, происхождение которых неизвестно, которые не используются или которые были обнаружены в открытых источниках.
4. Перенести все секреты в централизованный менеджер секретов (HashiCorp Vault, AWS Secrets Manager, Google Secret Manager или их аналоги), обеспечивающий разграниченный доступ и аудит.
5. Применить принцип наименьших привилегий к каждому ключу: ограничить доступные API, модели, установить IP-белые списки и ограничить количество запросов в минуту.
6. Настроить жёсткие бюджетные оповещения и квоты на уровне проекта, сервиса и учётной записи в облаке, чтобы автоматически блокировать превышение лимитов.
7. Маршрутизировать весь внешний трафик к ИИ-API через внутренний шлюз (AI Gateway), который будет аутентифицировать, авторизовывать и логировать каждый запрос.
8. Разработать и утвердить регламент регулярной ротации ключей (например, раз в 90 дней) и план реагирования на инцидент компрометации, включая процедуру экстренного отзыва.

Типичные ошибки

• Хранение API-ключей в исходном коде приложений или в файлах конфигурации внутри репозитория. Это самая распространённая ошибка, которая автоматически делает ключ публичным достоянием.
• Использование одного «супер-ключа» для всех сред — разработки, тестирования и эксплуатации. Компрометация такого ключа парализует все процессы и максимизирует ущерб.
• Отсутствие мониторинга потребления API и биллинга. Многие компании обнаруживают инцидент только после получения счёта в конце месяца, когда ущерб уже нанесён.
• Пренебрежение защитой внутренних и self-hosted инстансов. Распространённое заблуждение, что «своё» означает «безопасное», приводит к открытым портам и отсутствию аутентификации.
• Игнорирование аномалий малого масштаба. Небольшой всплеск активности в нерабочее время или из необычной страны часто списывается на погрешность, хотя это может быть признаком начинающейся атаки.
• Полная reliance на политика использования провайдера. Надежда на то, что провайдер сам заблокирует подозрительную активность, неверна, так как злоумышленники стараются маскировать свою активность под легитимную.

Как понять, что вы на верном пути

• Существует актуальный и полный реестр всех API-ключей и сервисных аккаунтов с указанием владельца, назначения и области применения.
• Ни один секрет не хранится в Git, кодовой базе или конфигурациях; все они находятся в менеджере секретов с ротацией доступа.
• Настроены и протестированы оповещения о резком изменении расхода токенов, появлении новых географических регионов или использовании нехарактерных моделей.
• Разработчики имеют чёткую инструкцию и инструментальные средства для безопасного запроса и использования ключей, исключающие их попадание в код.
• Проводятся регулярные (например, ежеквартальные) аудиты безопасности, включающие сканирование секретов и проверку прав доступа.
• Существует и отрепетирован план действий при компрометации ключа, и команда ИБ знает, как отозвать ключ и переключить трафик за час.

Вопросы, которые нам задают

Достаточно ли регулярно ротировать API-ключи для защиты?

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

Наши разработчики перешли на DeepSeek и Qwen, снизились ли риски?

Финансовый риск LLM-jacking остаётся точно таким же, так как атакуется не сам провайдер, а учётные данные для доступа к его API. Экономическая мотивация для злоумышленников сохраняется. Меняются только юридические и геополитические риски, связанные с юрисдикцией провайдера и трансграничной передачей данных. Технически вектор атаки и методы защиты идентичны.

Мы размещаем модель на своих серверах, полностью ли мы защищены от LLM-jacking?

Нет. Размещение на своих серверах смещает фокус с биллинга на расход собственных вычислительных ресурсов (GPU) и утечку данных. Если ваш inference-endpoint доступен из интернета без надлежащей аутентификации и авторизации, злоумышленник может использовать его для своих задач, нагрузив вашу инфраструктуру и, возможно, украв данные из промптов. Защита эндпоинта и управление доступом здесь критически важны.

Как быстро можно обнаружить, что ключ скомпрометирован?

Самый эффективный способ — комбинация реального времени мониторинга использования API и настроенных алертов. Ключевые индикаторы компрометации: резкий рост потребления токенов, запросы из новых географических локаций, обращение к моделям, которые ваша компания не использует, или изменение паттерна запросов (например, массовая генерация кода вместо аналитики текста). Чем быстрее настроена система обнаружения аномалий, тем меньше будет финансовый ущерб.

Источники

• Google Threat Intelligence Group — From Prompting to Autonomy: The Evolution of Adversarial AI
• Google Cloud Documentation — Best practices for managing API keys