ИИ-шлюз для кражи ваших данных

С атаками на цепочку поставок связана значительная доля киберинцидентов, и эта доля постоянно растет. За последний год мы видели множество различных методов таких атак: начиная от создания вредоносных, но с виду легитимных библиотек с открытым исходным кодом или отложенных атак в таких же с виду легитимных библиотеках и заканчивая простым, но самым действенным методом — компрометацией аккаунтов владельцев популярных библиотек с целью в дальнейшем выпускать их вредоносные версии. Такие библиотеки используются разработчиками повсеместно, включаются во многие решения и сервисы. Последствия атаки могут быть совершенно разными, начиная от доставки вредоносного ПО на устройство разработчика и заканчивая компрометацией целой инфраструктуры, если вредоносная библиотека попала в код какого-либо сервиса или продукта.

Так и случилось в марте 2026 года, когда злоумышленники внедрили вредоносный код в популярную Python-библиотеку LiteLLM, которая служит многофункциональным шлюзом для большого набора ИИ-агентов. Атакующие  выпустили две троянизированные версии LiteLLM, которые доставляли в систему жертвы вредоносные скрипты. Обе версии попали в репозиторий PyPI для Python. Технический разбор показал, что основной целью злоумышленников были серверы, на которых хранятся конфиденциальные данные, связанные с AWS, Kubernetes, NPM и т. д., а также различные базы данных (MySQL, PostgreSQL, MongoDB и т. д.). В последнем случае атакующих интересовали в первую очередь конфигурации баз. Помимо этого в логику зловреда входила функциональность по воровству конфиденциальных данных криптокошельков и техники закрепления в кластере Kubernetes.

Компрометация репозитория

Компрометация затронула канал дистрибуции пакетов через PyPI: 24 марта 2026 года в реестр были загружены вредоносные версии litellm==1.82.7 и litellm==1.82.8. Скомпрометировано было именно дистрибутивное содержимое пакета: в 1.82.7 вредоносный код был встроен в proxy_server.py, а в 1.82.8 дополнительно появился файл litellm_init.pth.

Технический анализ

В обеих версиях библиотеки содержался один и тот же вредоносный код, но был по-разному реализован запуск его исполнения. В версии 1.82.7 он исполнялся только при импорте функциональности прокси, а в 1.82.8 появился .pth-файл, который может выполнять код при каждом запуске интерпретатора.

Пример вредоносного кода в proxy_server.py

Вредоносный код в файлах proxy_server.py и litellm_init.pth содержал зашифрованный в base64 код на Python. Зараженный скрипт после запуска сохранял этот код рядом с собой как файл p.py и сразу же исполнял его.

Скрипт p.py запускал основную нагрузку — еще один скрипт, также закодированный в base64, — не сохраняя на диск. При этом он записывал вывод работы этой нагрузки в файл в директории, откуда он был запущен. Перед записью вывод шифровался при помощи алгоритма AES‑256‑CBC со сгенерированным в коде случайным ключом, который сохранялся в файл session.key. Файл с ключом также шифровался — при помощи заранее инициализированного публичного RSA-ключа.

Зашифрованный ключ и результат вывода объединялись в архив tpcp.tar.gz и отправлялись на удаленный сервер злоумышленников.

Что же происходило непосредственно во вредоносной нагрузке, чей вывод отправлялся на C2? После ее запуска начинался рекурсивный обход рабочих директорий в системе жертвы (/root, /app/, /var/www и т. д.). В каждой директории скрипт просматривал содержимое файлов, которое выводил в буфер stdout, откуда оно потом сохранялось в ранее упомянутый файл как результат. Далее скрипт собирал информацию о системе и также сохранял в файл. После этого он переходил к поиску конфиденциальных данных. Его интересовали следующие данные, находящиеся на серверах и в инфраструктурах различных сервисов:

• SSH-ключи
• учетные записи GIT
• .env-файлы
• конфигурации AWS, Kubernetes, почтовых сервисов, баз данных, WireGaurd
• файлы, связанные с Helm, Terraform, CI
• TLS-ключи и сертификаты

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

В коде выше используются адреса 169.254.169.254 и 169.254.170.2. Первый соответствует сервису AWS Instance Metadata Service (IMDS), через который EC2-инстанс (виртуальный сервер в AWS, запускаемая в облаке машина) может получать метаданные и временные учетные данные IAM-роли (учетная запись AWS с набором разрешений, которую может использовать сервис или приложение, чтобы получить временные учетные данные для вызовов к API AWS). Второй применяется в Amazon ECS для выдачи контейнеру временных учетных данных во время выполнения. Таким образом, вредоносный скрипт нацелен не только на кражу статических секретов, но и на те, что выдаются облаком и могут открыть прямой доступ к ресурсам AWS в момент заражения.

Дополнительно скрипт ищет конфигурации криптокошельков, а также вебхуки, связанные с мессенджерами Slack и Discord. Последнее показывает интерес злоумышленников не только к инфраструктурным секретам и учетным записям, но и к каналам общения внутри команды разработчиков.

Следующим этапом зловред переходит от сбора данных к закреплению в инфраструктуре кластера Kubernetes: при наличии доступа он формирует конфигурацию привилегированного пода (минимальная единица запуска в Kubernetes, внутри которой работает один или несколько контейнеров) путем включения опции securityContext.privileged=true и монтирует корневую файловую систему узла через hostPath. Это позволяет ему выйти за пределы контейнера и выполнять действия на уровне узла.

Далее зловред разворачивает еще одну стадию заражения — сохраняет закодированный в base64 скрипт на диск узла Kubernetes по пути /root/.config/sysmon/sysmon.py под видом легитимного системного компонента и регистрирует его через systemd. После запуска скрипт выдерживает начальную задержку в 300 секунд, а затем начинает периодически обращаться к C2-узлу checkmarx[.]zone/raw, получая оттуда ссылку на следующую полезную нагрузку. Если полученное значение отличается от состояния, ранее сохраненного в /tmp/.pg_state, скрипт загружает новый файл в /tmp/pglog, делает его исполняемым и запускает в фоне. На этой стадии злоумышленники получают точку входа в систему, способную регулярно получать обновляемую нагрузку без повторного внедрения. Поскольку вредоносная нагрузка записывается не во временную файловую директорию контейнера, а непосредственно на узел кластера Kubernetes, даже после завершения работы контейнера злоумышленники сохранят доступ к инфраструктуре.

Аналогичный сценарий используется и для локального закрепления: при отсутствии Kubernetes скрипт sysmon.py разворачивается в каталоге пользователя по пути ~/.config/sysmon/sysmon.py и также регистрируется как сервис через systemd.

OpenVSX-версия зловреда

При анализе файлов, коммуницирующих с C2, мы обнаружили вредоносные версии двух распространенных расширений ПО Checkmarx, использующегося для оценки безопасности приложений: ast-results 2.53.0 и cx-dev-assist 1.7.0. В них содержался вредоносный код, доставляющий NodeJS-версию вышеописанного зловреда.

Эта версия загружается с адреса checkmarx[.]zone/static/checkmarx-util-1.0.4.tgz при помощи утилит установки NodeJS-пакета и имеет название checkmarx-util. Ее ключевое отличие от Python-версии заключается в том, что она не пытается выйти на уровень узла Kubernetes и не создает привилегированный под для закрепления. Вместо этого она реализует локальное закрепление в текущем окружении. Это значит, что NodeJS-вариант закрепляется только там, где он уже запущен.

Кроме того, список папок для поиска и кражи секретов в этой версии значительно меньше, чем в Python-варианте.

Расширения Checkmarx используются для сканирования кода и конфигураций инфраструктур, поэтому их компрометация довольно опасна: зловред получает доступ не только к файлам проекта, но и к значительной части среды разработки, токенам и локальным конфигурациям.

Жертвы

В ходе изучения последствий атаки мы обнаружили жертв по всему миру, однако большая часть оказалась в России, Китае, Бразилии, Нидерландах и ОАЭ.

Заключение

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

Профилактика и защита

Для защиты от заражений подобного рода мы рекомендуем использовать специальное решение для мониторинга компонентов с открытым исходным кодом. «Лаборатория Касперского» предоставляет потоки актуальных данных о скомпрометированных пакетах и библиотеках, которые можно использовать для обеспечения безопасности цепочки поставок и защиты разработок от подобных угроз.

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

Для защиты корпоративных устройств мы рекомендуем применять комплексное решение, такое как Kaspersky Symphony, которое позволяет выстроить гибкую и эффективную систему безопасности. Продукты, входящие в состав этой линейки, обеспечивают видимость угроз и защиту в режиме реального времени, а также предоставляют возможности уровня EDR и XDR для исследования и реагирования на угрозы.

На момент написания статьи скомпрометированные версии LiteLLM уже удалены из PyPI и OpenVSX. Если вы успели воспользоваться ими, а также в качестве проактивного реагирования на угрозу мы советуем принять следующие меры в системах и инфраструктурах:

• Провести полное сканирование системы при помощи надежного защитного решения.
• Ротировать все потенциально затронутые учетные данные — API-ключи, переменные окружения, SSH-ключи, токены сервисных аккаунтов Kubernetes и другого рода секреты.
• Проверить хосты и кластеры на следы закрепления — наличие файлов ~/.config/sysmon/sysmon.py, подозрительные поды в Kubernetes.
• Очистить кэш и провести инвентаризацию модулей PyPI: проверить наличие вредоносных и откатить версии до чистых.
• Проверить наличие индикаторов компрометации (файлов в системе или сетевых признаков).

Индикаторы компрометации

URL-адреса
models[.]litellm[.]cloud
checkmarx[.]zone

Версии пакетов:
85ED77A21B88CAE721F369FA6B7BBBA3
2E3A4412A7A487B32C5715167C755D08
0FCCC8E3A03896F45726203074AE225D

Скрипты:
F5560871F6002982A6A2CC0B3EE739F7
CDE4951BEE7E28AC8A29D33D34A41AE5
05BACBE163EF0393C2416CBD05E45E74