ZiChatBot в Python-пакетах PyPI: скрытая supply chain атака через Zulip

На Python Package Index (PyPI) обнаружены три пакета, которые помимо заявленной функциональности незаметно доставляют ранее неизвестное вредоносное ПО ZiChatBot для Windows и Linux, используя публичный чат-сервис Zulip как инфраструктуру команд и управления; это делает уязвимыми разработчиков и любые системы, где эти пакеты могли быть установлены в период с 16 по 22 июля 2025 года, и требует немедленного аудита зависимостей и проверки признаков заражения.

Технические детали атаки

Исследователи выявили три пакета на PyPI, оформленных как обычные wheel-файлы с рабочей функциональностью:

• uuid32-utils — содержит вредоносный загрузчик;
• colorinal — использует похожий вредоносный модуль, как и uuid32-utils;
• termncolor — выглядит как безобидный пакет, но декларирует зависимость от colorinal и тем самым транзитивно приносит вредоносный код.

Все три пакета были загружены в репозиторий PyPI в коротком окне между 16 и 22 июля 2025 года, что характерно для целенаправленной supply chain операции и хорошо укладывается в технику Supply Chain Compromise в MITRE ATT&CK.

Механизм заражения на Windows

На Windows при установке любого из двух первых пакетов выполняется скрытая логика:

• из пакета извлекается DLL-загрузчик terminate.dll и записывается на диск;
• при импорте библиотеки в проект DLL автоматически загружается;
• terminate.dll выступает дроппером ZiChatBot, разворачивая основной модуль вредоносного ПО;
• создается запись автозапуска в реестре Windows (Run-подобный ключ);
• код дроппера выполняет самоуничтожение, стирая собственные следы с хоста.

В результате на системе остается только ZiChatBot с постоянной точкой запуска и минимумом очевидных артефактов, что затрудняет ретроспективный анализ.

Механизм заражения на Linux

На Linux применяется параллельная логика с использованием разделяемого объекта:

• извлекается и запускается terminate.so;
• ZiChatBot размещается по пути /tmp/obsHub/obs-check-update;
• для сохранения постоянства создается запись в crontab, которая периодически запускает вредоносный бинарный файл.

Использование каталога /tmp и нейтрально выглядящего имени obs-check-update снижает вероятность обнаружения при беглом осмотре системы.

Управление через Zulip как замену классического C2

Ключевая особенность ZiChatBot — отсутствие выделенного сервера команд и управления. Вместо этого вредоносное ПО использует публичные REST API корпоративного чат-приложения Zulip, взаимодействуя с ним так же, как легитимный клиент, через официально документированные интерфейсы Zulip API.

Поведение ZiChatBot можно свести к следующему:

• подключение к определенным каналам/потокам Zulip через REST API;
• получение команд в виде полезной нагрузки (shellcode);
• исполнение полученного shellcode на скомпрометированной системе;
• отправка в ответ эмодзи-сердца в канал Zulip как сигнал успешного выполнения команды.

Такой способ управления сочетает несколько преимуществ для атакующих:

• трафик к облачному сервису чатов выглядит легитимно и часто не фильтруется;
• нет статического домена или IP, характерного для традиционного C2;
• смена рабочей области или учетных записей в Zulip полностью меняет «инфраструктуру» без затрат на хостинг.

С точки зрения MITRE ATT&CK это соответствует технике использования легитимных веб-сервисов для команд и управления (Web Service C2), ранее уже наблюдавшейся у продвинутых группировок.

Контекст и возможная связь с OceanLotus

По данным исследователей, дроппер в рамках текущей кампании демонстрирует 64% сходство с другим загрузчиком, ранее приписанным вьетнамской группировке OceanLotus (APT32). MITRE описывает эту группу под идентификатором G0050 как целенаправленно атакующую различные организации в Азии.

В конце 2024 года OceanLotus уже была замечена в атаке на китайское сообщество кибербезопасности: использовались поддельные проекты Visual Studio Code, выдаваемые за плагины Cobalt Strike, которые при компиляции автоматически запускали троян. В той кампании злоумышленники применяли сервис заметок Notion как канал команд и управления, используя публичный облачный сервис аналогично тому, как сейчас используется Zulip, что подтверждается публичными анализами и официальной документацией Notion.

Текущая активность в PyPI не может быть окончательно приписана OceanLotus, однако наличие схожего дроппера и повторяющийся паттерн использования популярных SaaS-платформ (Notion, затем Zulip) как C2 указывает на эволюцию одной и той же операционной модели:

• смещение от фишинга к атакам через цепочку поставок (IDE, репозитории пакетов);
• максимальное маскирование инфраструктуры C2 под обычный корпоративный трафик;
• ориентация на разработчиков и специалистов по безопасности как первоначальных жертв.

Оценка воздействия на организации

Потенциально под удар попадают все среды, где могли быть установлены пакеты uuid32-utils, colorinal или termncolor в указанный период. Наибольший риск несут:

• команды разработки, использующие PyPI напрямую из интернета в рабочих станциях и CI/CD;
• инфраструктура сборки и тестирования, где выполнение произвольного кода открывает путь к компрометации артефактов и «заражению» конечных продуктов;
• организации, где разработческие станции имеют расширенные привилегии или доступ к чувствительным данным.

Поскольку ZiChatBot исполняет произвольный shellcode, успешное заражение фактически равносильно получению удаленного управления с правами пользователя процесса (а при запуске с повышенными правами — права администратора/суперпользователя). Потенциальные последствия:

• кража исходного кода, секретов из конфигураций, ключей доступа к облаку;
• подмена артефактов сборки и внедрение вредоносного кода в продукты организации;
• боковое смещение внутри сети через разработческие станции как «мост» к более защищенным сегментам;
• репутационный ущерб в случае распространения скомпрометированных пакетов конечным клиентам.

Отсутствие традиционного C2 и использование Zulip усложняют сетевое обнаружение и откат инцидента: блокировка одного-двух доменов или IP не решает проблему, а телеметрия по трафику к популярным SaaS-сервисам обычно менее детализирована.

Практические рекомендации по защите

1. Немедленная проверка среды

• На всех системах разработчиков и серверах сборки выполните проверку установленных пакетов:
  • pip list | findstr uuid32-utils / pip list | findstr colorinal / pip list | findstr termncolor (Windows);
  • pip list | grep -E "uuid32-utils|colorinal|termncolor" (Linux).
• При обнаружении — зафиксируйте версии и контекст использования, затем удалите пакеты:
  • pip uninstall uuid32-utils colorinal termncolor.

2. Поиск артефактов ZiChatBot

• Windows:
  • поиск файлов terminate.dll и подозрительных бинарных файлов, появившихся в период с 16 по 22 июля 2025 года;
  • проверка ключей автозапуска (от имени администратора):
    • reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run
    • reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run

    и анализ записей, указывающих на нестандартные исполняемые файлы в профиле пользователя или во временных каталогах.

• Linux:
  • проверка наличия пути /tmp/obsHub/obs-check-update и любых исполняемых файлов внутри;
  • проверка планировщика задач:
    • crontab -l от имени каждого пользователя, потенциально использовавшего Python;
    • просмотр системных crontab-файлов (/etc/crontab, /etc/cron.*) на наличие ссылок на obs-check-update или аномальные задания в /tmp.

3. Сетевое обнаружение

• В сетевой телеметрии и прокси-логах проверьте обращения с рабочих станций разработчиков и CI/CD к доменам, связанным с Zulip, в необычное время или с нетипичным объемом трафика.
• Настройте детектирование по аномальной активности API к внешним чат-сервисам (создание/чтение сообщений с серверов, на которых такие клиенты не должны работать).

4. Укрепление цепочки поставок Python-зависимостей

• Перейдите на использование внутреннего зеркала PyPI с белым списком проверенных пакетов; прямой выход на внешний PyPI с рабочих станций разработчиков ограничьте.
• Внедрите контроль целостности пакетов (проверка хэшей, артефакт-репозитории с криптографической подписью).
• Используйте статический и динамический анализ для новых зависимостей, особенно если они неизвестны или малоиспользуемы.
• Изолируйте среды сборки: минимальные права, ограниченный сетевой доступ (разрешать только необходимые хранилища и обновления, блокировать произвольный доступ к внешним SaaS-сервисам).

5. Организационные меры

• Обновите внутренние политики выбора зависимостей: запрет на «быстрый» импорт случайных пакетов без ревью и одобрения.
• Проведите краткое обучение команд разработки по рискам атак через репозитории пакетов и по процедурам проверки новых модулей.
• Скоординируйте действия команд безопасности и DevOps для интеграции проверок зависимостей в pipeline (software composition analysis).

Ключевой вывод из инцидента с ZiChatBot в PyPI — разработческие и сборочные среды должны рассматриваться как приоритетные активы: в кратчайшие сроки необходимо проверить наличие пакетов uuid32-utils, colorinal и termncolor, удалить их вместе с выявленными артефактами (включая /tmp/obsHub/obs-check-update и подозрительные записи автозапуска), а затем закрепить результат техническими мерами — переходом на контролируемое зеркало PyPI, жестким ограничением сетевого доступа сборочных систем и встроенными в pipeline автоматическими проверками сторонних зависимостей.