ZiChatBot у PyPI: шкідливі пакети та C2 через 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 автоматичними перевірками сторонніх залежностей.