Жертва открыла продакшен-сервер и быстро потеряла контроль над инфраструктурой. По оценке Sysdig, за атакой JadePuffer стоял не человек-оператор, а ИИ-агент, который сам прошел путь от разведки до шифрования данных.

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

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

Источник атаки исследователи связали с уязвимостью CVE-2025-3248 в Langflow — опенсорсном фреймворке для приложений на базе больших языковых моделей. Разработчики закрыли дыру 1 апреля 2025 года, но уже в начале мая CISA предупредило, что ее используют в реальных атаках.

Как это сделано

Сценарий выглядел как цепочка привычных для киберпреступников шагов, только без заметного участия человека на каждом этапе. После получения возможности выполнять Python-код агент выгрузил базу PostgreSQL, собрал сведения о хосте и начал искать секреты.

Его интересовали API-ключи LLM-провайдеров, учетные данные облачных платформ, пароли от баз данных и криптовалютные кошельки. Исследователи отдельно отметили, что агент проверял не только AWS, Azure и Google Cloud, но и Alibaba, Aliyun, Tencent и Huawei.

Затем JadePuffer изучил объектное хранилище MinIO и адаптировал свои скрипты под ответы сервера. Если один запрос возвращал XML вместо ожидаемого JSON, следующий код уже учитывал этот формат. Для закрепления на сервере Langflow агент создал cron-задачу, которая связывалась с инфраструктурой атакующего каждые 30 минут.

Дальше вредонос переключился на отдельный продакшен-сервер с MySQL и Alibaba Nacos. Он подключился к открытому порту MySQL с правами root, хотя исследователи так и не поняли, откуда взялись эти учетные данные.

После этого агент атаковал Nacos сразу несколькими способами: эксплуатировал уязвимость обхода аутентификации CVE-2021-29441, подделывал JWT с помощью стандартного ключа подписи и добавил бэкдор-аккаунт администратора в базу. Параллельно он искал способ выйти из контейнера и готовил вымогательский код.

Подобные цепочки в целом не новы, но в этой истории важна связка. Одна модель сама объединила разведку, подбор целей, закрепление и запуск шифровальщика. Похожий риск эксперты ранее обсуждали и в материале о критическом баге в Adobe ColdFusion, где старая уязвимость быстро пошла в дело у атакующих.

Кого затронуло и чем это опасно

В итоге JadePuffer зашифровал все 1342 элемента конфигурации Nacos с помощью MySQL-функции AES_ENCRYPT(). Затем он удалил исходные таблицы config_info и history и создал таблицу README_RANSOM с требованием выкупа, биткоин-адресом и контактом в Proton Mail.

В записке утверждалось, что данные зашифрованы алгоритмом AES-256, но специалисты считают, что на деле использовался более слабый AES-128-ECB. Ключ генерировался случайно, нигде не сохранялся и не отправлялся операторам малвари. Иными словами, даже после выплаты выкупа восстановить данные, похоже, было бы невозможно.

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

На участие ИИ в атаке указывали подробные комментарии в сгенерированном коде. Модель объясняла логику действий и выбор целей, а не просто бездумно повторяла команды. В одном из эпизодов между неудачной попыткой входа и рабочим решением прошло 31 секунда.

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

Что делать сейчас

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

Если у вас есть приложения на базе LLM, контейнеры, Nacos, MinIO, базы PostgreSQL или MySQL, проверьте, нет ли открытых сервисов, старых учетных данных и забытых секретов в конфигурациях. Особое внимание — журналам, cron-задачам, правам root и любым учеткам с избыточными полномочиями.

Для обычного пользователя вывод тоже практический: не держите пароли в заметках, не храните ключи в открытом виде и включайте 2FA там, где это возможно. Если вы часто подключаетесь через чужие или общие точки доступа, [дополнительный слой защиты соединения]https://freedome.space поможет снизить риск перехвата трафика в дороге или в кафе — но он не заменяет обновления, сложные пароли и двухфакторную аутентификацию.

Чек-лист

  • Проверьте, закрыты ли на сервере старые уязвимости, включая компоненты для работы с LLM.
  • Уберите из конфигов пароли, API-ключи и токены, если они хранятся в открытом виде.
  • Ограничьте доступ к MySQL, PostgreSQL, Nacos и MinIO только нужными адресами.
  • Проверьте cron-задачи, автозапуск и другие точки закрепления на сервере.
  • Включите 2FA для админок, облаков и критичных сервисов.
  • Настройте ротацию секретов и следите за подозрительными входами.
  • Для работы вне офиса используйте дополнительные меры приватности в чужих сетях.
  • Если видите признаки шифровальщика, сразу изолируйте хост и снимите копии логов.
Поделиться: