Троян mrmustard в PyPI похищал SSH-, AWS- и Kubernetes-учётные данные

23 июля 2026 года Python Package Index (PyPI) стал площадкой для очередной целевой атаки на цепочку поставок. Вредоносная версия библиотеки mrmustard, применяемой в фотонных квантовых вычислениях, была загружена под видом легитимного обновления. Инцидент обнажил сразу несколько болевых точек экосистемы открытого ПО: от компрометации учётных записей мейнтейнеров до изощрённых техник закрепления, нацеленных на высокопроизводительные вычислительные среды.

Механизм атаки: скрытый payload в безобидном обновлении

Версия 0.7.4 пакета mrmustard, опубликованная через учётную запись ключевого участника проекта ziofil, практически полностью повторяла предыдущий легитимный релиз 0.7.3. Единственное изменение было внесено в файл mrmustard/__init__.py: в функцию _check_tf_compatibility() длиной 258 строк оказался вшит троянский payload. При импорте библиотеки этот код немедленно начинал сбор конфиденциальных данных и их отправку на управляемый злоумышленником сервер (C2).

Анализ показал, что злоумышленник получил доступ к учётным данным мейнтейнера, что позволило выпустить вредоносный релиз напрямую, минуя все стандартные процедуры проверки.

Что попадало под удар

Payload осуществлял прицельную разведку хост-системы, фокусируясь на типичных для разработчиков и исследователей артефактах. В перечень похищаемой информации входили:

• SSH-ключи (приватные ключи и конфигурация);
• учетные данные AWS (файлы credentials и config);
• конфигурационные файлы Kubernetes;
• информация об окружении высокопроизводительных вычислений (HPC): очереди задач SLURM, инвентаризация GPU.

Собранные данные упаковывались в формат JSON, шифровались и отправлялись POST-запросами на закодированную C2-конечную точку. Такой подход затруднял детектирование трафика стандартными сетевыми средствами.

Уклонение и нацеливание на «живые» машины разработчиков

Вредоносная программа демонстрировала высокую осведомлённость об инфраструктуре жертв. Она намеренно избегала выполнения в средах непрерывной интеграции (CI), где долгоживущие секреты встречаются редко, и активировалась только на машинах разработчиков, хранящих актуальные учётные данные на постоянной основе. Это поведение указывает на то, что атакующих интересовал не единовременный доступ к песочнице сборки, а долговременное присутствие в рабочем окружении исследователей и инженеров.

Закрепление: троян остаётся даже после удаления библиотеки

Особую опасность представляли механизмы персистентности, встроенные в payload. Они были спроектированы так, чтобы сохранить своё присутствие даже после того, как скомпрометированная версия mrmustard будет деинсталлирована. Код использовал сразу несколько методов закрепления:

• модификация скриптов инициализации оболочки (файлы rc);
• создание задач cron для периодического выполнения вредоносных действий;
• размещение файла mmcompat.pth, который, согласно устройству Python, автоматически исполняется при каждом запуске интерпретатора.

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

Рекомендации по устранению последствий

Всем пользователям, которые устанавливали или обновляли пакет mrmustard в указанный период, необходимо немедленно принять следующие меры:

• Ротировать все потенциально скомпрометированные учётные данные: SSH-ключи, ключи доступа AWS, токены Kubernetes и иные секреты, к которым имела доступ поражённая машина.
• Провести ревизию Python-окружений на наличие файла mmcompat.pth и удалить его.
• Проверить и очистить записи пользовательского crontab (crontab -l), удалив подозрительные задания.
• Проинспектировать файлы инициализации оболочки (.bashrc, .zshrc и аналогичные) на предмет вставок, активирующих вредоносный код.
• Удалить кэшированные файлы пакета и переустановить проверенную версию 0.7.3 из доверенного источника.

Эти шаги позволят разорвать цепочку закрепления и предотвратить дальнейшую утечку данных.

Уроки для индустрии

Инцидент с mrmustard — очередное жёсткое напоминание о необходимости сквозной верификации происхождения кода. Расхождение между версией, опубликованной в PyPI, и соответствующим коммитом в репозитории исходного кода должно рассматриваться как красный флаг. Компрометация учётной записи мейнтейнера, обладающей правами на публикацию, свела на нет все нижележащие защитные механизмы.

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

Отчет получен из сервиса CTT Report Hub. Права на отчет принадлежат его владельцу.

Ознакомиться подробнее с отчетом можно по ссылке.