Исследователи Sysdig описали атаку, в которой злоумышленники охотились за забытыми ключами доступа к AWS, OpenAI, Anthropic и другим сервисам. Для этого они использовали вредоносную платформу KeyHunter, рассчитанную на поиск токенов в публичных онлайн-песочницах и тестовых проектах разработчиков.

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

Как работала схема

Атаку связали с уязвимостью CVE-2026-33017 в платформе Langflow. По данным источника, ошибка позволяла выполнить код на сервере без авторизации. После эксплуатации злоумышленник загрузил Python-компонент и Go-бинарник, а затем пытался выйти из контейнера с помощью эксплойтов DirtyPipe и DirtyCreds.

Отдельно выделяется способ управления заражёнными системами. Вместо привычных HTTP-серверов или мессенджеров операторы использовали NATS — платформу обмена сообщениями, которую обычно применяют в облачных и распределённых системах.

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

Что искал KeyHunter

Главная задача KeyHunter — находить и проверять рабочие ключи доступа. Вредоносный модуль сканировал публичные песочницы вроде CodePen, JSFiddle, StackBlitz и CodeSandbox, где разработчики иногда оставляют токены в тестовых проектах.

После обнаружения ключей программа не просто сохраняла их, а сразу проверяла работоспособность. Для AWS использовался запрос sts:GetCallerIdentity, чтобы понять, кому принадлежит ключ и какие возможности он даёт. Для AI-сервисов проверка шла через прямое обращение к API поставщиков моделей.

Зачем нужны украденные ключи

В случае AWS злоумышленники интересовались разными сервисами: Bedrock, S3, EC2, Lambda, ECS и SageMaker. Особое внимание уделялось Amazon Bedrock — через него можно запускать большие языковые модели.

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

Почему NATS-as-C2 важен

Сервер NATS в этой операции использовался как центр координации. При этом инфраструктура была настроена с аутентификацией и списками контроля доступа: заражённый узел мог отправлять результаты и сигналы активности, но не получал полного доступа к управлению другими узлами.

Для защитников это неприятный момент. Такой подход усложняет анализ ботнета и снижает шанс быстро разобрать всю сеть через один скомпрометированный сервер.

Что советуют сделать

Sysdig рекомендует обновить Langflow до версии с исправлением CVE-2026-33017, заблокировать указанные в отчёте адреса и заменить ключи, которые могли храниться в уязвимых экземплярах. Особенно это касается токенов Amazon Web Services, OpenAI, Anthropic и HuggingFace.

На практике важен ещё один вывод: ключи не должны попадать в публичные демо, песочницы и временные проекты. Разработчику кажется, что это «просто тест на пять минут», а автоматизированная платформа вроде KeyHunter как раз такие места и просматривает.

Финал здесь довольно простой: секреты нужно хранить как секреты. Не в коде, не в публичном примере и не в забытом проекте, который никто больше не открывает.

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

Итог

Тревожное — не сложность атаки, а её бытовая сторона. Многие утечки начинаются не с хитрого взлома, а с ключа, который случайно оставили в демо-проекте. KeyHunter просто делает такую охоту массовой и автоматической. Для команд это хороший повод ещё раз проверить, где лежат токены, как быстро они отзываются и есть ли лимиты на использование AI- и облачных API.

Источник: SecurityLab