ZiChatBot в PyPI: что известно об атаке, связанной с OceanLotus, и роли Zulip API

Эти пакеты не были пустыми «пустышками». По словам Kaspersky, wheel‑пакеты действительно реализовывали функции, заявленные на своих страницах PyPI, но их реальной задачей была скрытая доставка вредоносных файлов. The Hacker News, ссылаясь на тот же разбор Kaspersky, также пишет, что пакеты выглядели рабочими, но предназначались для незаметной доставки ZiChatBot на Windows и Linux.

В публичных сводках названы три поддельные библиотеки PyPI, участвовавшие в кампании:

• uuid32-utils
• colorinal
• termncolor

С атрибуцией стоит быть аккуратными. В публикации Securelist Kaspersky формулирует осторожно: образцы были отправлены в Kaspersky Threat Attribution Engine, а результаты указывают, что пакеты могут быть связаны с вредоносным ПО, обсуждавшимся в отчете по киберразведке об OceanLotus. В индексе threat research Kaspersky формулировка прямее: компания относит активность ZiChatBot в PyPI к OceanLotus APT. Одна публичная сводка описывает уверенность в атрибуции как умеренную.

Как выглядела цепочка заражения

Технически это была кросс‑платформенная цепочка с дроппером. Индекс исследований Kaspersky сообщает, что вредоносные wheel‑пакеты PyPI были нацелены на Windows и Linux и содержали дроппер, доставлявший вредоносное ПО под названием ZiChatBot.

Одна из публичных сводок описывает дальнейшие шаги так: из wheel‑пакета извлекался DLL или .SO дроппер, затем закрепление выполнялось через реестр Windows или Linux crontab, после чего развертывался ZiChatBot.

Практический вывод для команд разработки простой: проверять нужно не только серверы приложений. Если такие пакеты попадали на рабочие станции разработчиков, в виртуальные окружения, CI‑раннеры, сборочные агенты или контейнерные образы, риск мог возникнуть именно там, где обычно выполняется

pip install

И еще один важный урок: «пакет работает» не равно «пакет безопасен». В этой кампании вредоносные wheel‑пакеты, по данным Kaspersky, выполняли заявленные функции и одновременно доставляли скрытые вредоносные файлы.

Как ZiChatBot использовал Zulip для C2

Zulip — легитимная платформа для командного общения. Именно это и делало схему заметной: по сообщениям о выводах Kaspersky, ZiChatBot не использовал отдельный command-and-control сервер, а применял набор REST API Zulip как C2‑инфраструктуру.

Документация Zulip описывает операции, которые хорошо укладываются в модель «C2 поверх чата»: отправку и получение сообщений, загрузку файлов, редактирование и удаление сообщений, построение message narrows — то есть фильтрованных выборок сообщений — а также работу с темами в каналах. Документация по ботам Zulip также показывает, что боты могут перехватывать, просматривать и обрабатывать сообщения пользователей, а затем отправлять ответы.

На высоком уровне это позволяет представить команды оператора как сообщения в чате или сообщения в конкретной теме, а вредоносное ПО — как клиента, который получает нужные сообщения и публикует результаты обратно через тот же сервис. В доступных публичных материалах не раскрываются конкретный workspace Zulip, учетные данные бота, последовательность endpoint’ов или набор команд ZiChatBot; поэтому корректнее всего говорить, что ZiChatBot злоупотреблял штатной функциональностью REST API Zulip для C2, а не опирался на инфраструктуру C2, напрямую принадлежащую атакующим.

Чего эта деталь не означает

Упоминание Zulip не означает, что сам сервис Zulip был взломан. В цитируемых материалах речь идет о злоупотреблении обычными REST API и бот‑механиками обмена сообщениями, а не о компрометации платформы.

То же относится и к PyPI. Публикация Kaspersky описывает вредоносные wheel‑пакеты, загруженные в репозиторий, и сообщает, что вредоносное ПО позже удалили из PyPI; это не равно взлому инфраструктуры PyPI.

Для защитников главное последствие другое: трафик к легитимному сервису совместной работы может быть подозрительным, если он исходит от хоста, процесса, CI‑задания или сервисной учетной записи, которым незачем обращаться к этому сервису. Одних списков блокировки по «плохим доменам» здесь может быть недостаточно: важны контекст процесса и ожидаемое бизнес‑использование, а не только репутация адресата.

Что проверить командам безопасности

Начать стоит с инвентаризации зависимостей. Ищите uuid32-utils, colorinal и termncolor на машинах разработчиков, сборочных узлах, в виртуальных окружениях, lock‑файлах зависимостей и контейнерных образах.

Проверьте журналы установок и артефакты начиная с июля 2025 года — именно этот период Kaspersky указывает как начало загрузки вредоносных wheel‑пакетов. Если один из названных пакетов найден, лучше сначала сохранить окружение и логи для расследования, а не просто удалить пакет и считать инцидент закрытым.

На Windows имеет смысл искать неожиданное закрепление в Registry; на Linux — подозрительные записи crontab. Это соответствует публично описанной цепочке заражения для кампании.

Отдельно проверьте сетевую и процессную телеметрию: обращения к API Zulip от Python‑интерпретаторов, процессов установки пакетов, CI‑воркеров, серверов или сервисных учетных записей должны объясняться реальным рабочим сценарием. Вопрос не в том, является ли Zulip легитимным сервисом вообще, а в том, должен ли именно этот процесс на этом хосте вызывать Zulip API.

Итог

Кампания, связанная с OceanLotus, включала вредоносные wheel‑пакеты PyPI, загружавшиеся начиная с июля 2025 года; среди публично названных пакетов — uuid32-utils, colorinal и termncolor. Они доставляли ZiChatBot на Windows и Linux, а ключевая операционная особенность ZiChatBot заключалась в использовании REST API Zulip для command-and-control вместо выделенного C2‑сервера злоумышленников.