Атаки на цепочки поставок программного обеспечения продолжают оставаться одной из наиболее серьёзных и растущих угроз в киберпространстве. Вместо прямого нападения на конечную цель злоумышленники всё чаще выбирают окольный путь, компрометируя доверенные компоненты, которые используются тысячами разработчиков и компаний по всему миру. Последним наглядным примером такой тактики стала успешная кампания, в ходе которой в марте 2026 года были внедрены вредоносные версии популярной Python-библиотеки LiteLLM, выступающей в роли универсального шлюза для множества ИИ-агентов. Этот инцидент демонстрирует, как единичный скомпрометированный пакет может привести к утечке критически важных данных и закреплению в инфраструктуре целых организаций.
Описание
Атака началась с компрометации канала распространения пакетов через официальный реестр PyPI. Злоумышленникам удалось загрузить в него две троянизированные версии библиотеки - litellm==1.82.7 и litellm==1.82.8. Важно отметить, что был скомпрометирован именно дистрибутив пакета: в первой версии вредоносный код был встроен в файл "proxy_server.py", а во второй добавлен отдельный файл "litellm_init.pth", что обеспечивало различный механизм исполнения. В техническом отчёте экспертов подробно описано, что оба варианта содержали один и тот же зловредный код, но в версии 1.82.7 он активировался только при импорте прокси-функционала, тогда как файл ".pth" в версии 1.82.8 обеспечивал выполнение кода при каждом запуске интерпретатора Python, что значительно расширяло поверхность атаки.
После запуска скрытый скрипт разворачивал многоступенчатую вредоносную активность. Первым делом он приступал к рекурсивному сканированию рабочих директорий на системе жертвы, включая "/root", "/app/" и "/var/www". Целью были не просто файлы, а конфиденциальные данные, критичные для инфраструктуры: SSH- и TLS-ключи, учётные записи Git, файлы конфигураций для AWS, Kubernetes, различных баз данных (MySQL, PostgreSQL, MongoDB), а также секреты из файлов ".env". Особенностью этого вредоносного ПО стало то, что оно не ограничивалось поиском статических секретов на диске. Оно активно пыталось извлечь runtime-секреты из облачной инфраструктуры, обращаясь к сервисам метаданных AWS по стандартным внутренним адресам. Это позволяло злоумышленникам получать временные учётные данные IAM-ролей, предоставляющие прямой доступ к ресурсам AWS в момент заражения, что резко повышало опасность компрометации.
Собранные данные шифровались с использованием алгоритма AES-256-CBC, а ключ шифрования, в свою очередь, защищался заранее инициализированным открытым RSA-ключом злоумышленников. Весь этот зашифрованный архив отправлялся на удалённый сервер под контролем атакующих. Однако на этом этапе атака не заканчивалась. Следующей фазой было закрепление в системе, особенно в инфраструктуре Kubernetes. Если вредоносная нагрузка обнаруживала достаточные привилегии, она конфигурировала привилегированный под (pod) с опцией "securityContext.privileged=true" и монтировала корневую файловую систему узла кластера. Это классический метод побега из контейнера, позволяющий выполнять действия на уровне узла. После этого на диск узла сохранялся скрипт, замаскированный под легитимный системный компонент, и регистрировался как служба через systemd. Такой подход обеспечивал атакующим устойчивое присутствие в инфраструктуре даже после остановки или пересоздания исходного заражённого контейнера.
Параллельно исследователи обнаружили схожую угрозу в экосистеме OpenVSX, где были скомпрометированы популярные расширения для платформы Checkmarx, используемой для оценки безопасности приложений. Троянизированные версии расширений "ast-results" и "cx-dev-assist" доставляли NodeJS-версию того же вредоносного ПО. Хотя эта версия имела несколько меньший функционал и не пыталась эскалировать привилегии на уровне узлов Kubernetes, её опасность заключалась в целевом характере: компрометация инструментов для анализа кода даёт злоумышленникам доступ не только к файлам проектов, но и к значительной части среды разработки, включая токены и локальные конфигурации. География инцидента оказалась широкой, с наибольшим количеством попыток заражения, зафиксированных в России, Китае, Бразилии, Нидерландах и ОАЭ.
Данный случай наглядно иллюстрирует эволюцию тактик атак на цепочки поставок. Злоумышленники создают не просто крадущие данные троянцы, а сложные инструменты, предназначенные для комплексного захвата облачных сред. Они одновременно атакуют локальные системы, runtime-секреты облаков, оркестрируемые кластеры и средства криптографической защиты. Такой широкий охват позволяет быстро перейти от компрометации одной библиотеки в среде разработки к захвату служебных учётных записей и контроля над всей инфраструктурой. Для организаций это означает, что защита не может ограничиваться лишь сканированием конечных приложений. Необходим постоянный мониторинг доверенных внешних компонентов, строгий контроль за правами доступа в облачных средах и сегментация кластеров Kubernetes для минимизации ущерба от потенциального побега из контейнера. На момент публикации скомпрометированные версии были удалены из репозиториев, однако последствия атаки могут проявляться ещё долгое время, требуя от потенциальных жертв ротации всех потенциально скомпрометированных учётных данных и тщательной проверки систем на признаки закрепления злоумышленников.
Индикаторы компрометации
Domains
- checkmarx.zone
- models.litellm.cloud
SHA256
- 05bacbe163ef0393c2416cbd05e45e74
- 0fccc8e3a03896f45726203074ae225d
- 2e3a4412a7a487b32c5715167c755d08
- 85ed77a21b88cae721f369fa6b7bbba3
- cde4951bee7e28ac8a29d33d34a41ae5
- f5560871f6002982a6a2cc0b3ee739f7
