ZiChatBot malware hides in PyPI packages, abusing Zulip C2

Photo of author

CyberSecureFox Editorial Team

Three packages have been discovered on Python Package Index (PyPI) that, in addition to their advertised functionality, silently deliver the previously unknown ZiChatBot malware for Windows and Linux, using the public Zulip chat service as command-and-control infrastructure; this makes developers and any systems where these packages may have been installed between July 16 and 22, 2025 vulnerable and requires an immediate dependency audit and checks for signs of compromise.

Technical details of the attack

Researchers identified three packages on PyPI, published as regular wheel files with working functionality:

  • uuid32-utils — contains a malicious loader;
  • colorinal — uses a malicious module similar to uuid32-utils;
  • termncolor — looks like a harmless package but declares a dependency on colorinal and thus transitively brings in malicious code.

All three packages were uploaded to the PyPI repository in a short window between July 16 and 22, 2025, which is characteristic of a targeted supply chain operation and fits well with the Supply Chain Compromise in MITRE ATT&CK technique.

Infection mechanism on Windows

On Windows, when either of the first two packages is installed, hidden logic is executed:

  • the DLL loader terminate.dll is extracted from the package and written to disk;
  • when the library is imported into a project, the DLL is automatically loaded;
  • terminate.dll acts as a ZiChatBot dropper, deploying the main malware module;
  • a Windows autorun entry (a Run-like registry key) is created;
  • the dropper code self-destructs, wiping its own traces from the host.

As a result, only ZiChatBot remains on the system with a persistent launch point and a minimum of obvious artifacts, complicating retrospective analysis.

Infection mechanism on Linux

On Linux, a parallel logic is used via a shared object:

  • terminate.so is extracted and executed;
  • ZiChatBot is placed at the path /tmp/obsHub/obs-check-update;
  • to maintain persistence, a crontab entry is created that periodically launches the malicious binary.

The use of the /tmp directory and the innocuous-looking name obs-check-update lowers the chance of detection during a quick inspection of the system.

Control via Zulip as a replacement for classical C2

The key feature of ZiChatBot is the absence of a dedicated command-and-control server. Instead, the malware uses the public REST APIs of the corporate chat application Zulip, interacting with it just like a legitimate client through the officially documented Zulip API interfaces.

ZiChatBot’s behavior can be summarized as follows:

  • connecting to specific Zulip channels/streams via the REST API;
  • receiving commands in the form of payloads (shellcode);
  • executing the received shellcode on the compromised system;
  • sending a heart emoji back to the Zulip channel as a signal of successful command execution.

This method of control gives attackers several advantages:

  • traffic to a cloud-based chat service looks legitimate and is often not filtered;
  • there is no static domain or IP address characteristic of traditional C2;
  • switching workspaces or accounts in Zulip completely changes the “infrastructure” with no hosting costs.

From a MITRE ATT&CK perspective, this corresponds to the technique of using legitimate web services for command and control (Web Service C2), which has previously been observed in advanced threat groups.

Context and possible link to OceanLotus

According to researchers, the dropper used in the current campaign shows 64% similarity to another loader previously attributed to the Vietnamese group OceanLotus (APT32). MITRE describes this group under identifier G0050 as deliberately targeting various organizations in Asia.

At the end of 2024, OceanLotus had already been observed attacking the Chinese cybersecurity community: they used fake Visual Studio Code projects masquerading as Cobalt Strike plugins, which automatically launched a trojan upon compilation. In that campaign, the attackers used the Notion note-taking service as a command-and-control channel, leveraging a public cloud service in a manner similar to how Zulip is now being used, as confirmed by public analyses and the official Notion documentation.

The current activity on PyPI cannot be definitively attributed to OceanLotus, but the presence of a similar dropper and the recurring pattern of using popular SaaS platforms (Notion, then Zulip) as C2 points to the evolution of the same operational model:

  • a shift from phishing to supply chain attacks (IDEs, package repositories);
  • maximum camouflage of C2 infrastructure as normal corporate traffic;
  • a focus on developers and security professionals as initial victims.

Impact assessment for organizations

Potentially at risk are all environments where the uuid32-utils, colorinal, or termncolor packages may have been installed during the specified period. The highest risk lies with:

  • development teams that use PyPI directly from the internet on workstations and in CI/CD;
  • build and test infrastructure, where arbitrary code execution opens a path to artifact compromise and “infection” of final products;
  • organizations where developer workstations have elevated privileges or access to sensitive data.

Since ZiChatBot executes arbitrary shellcode, a successful infection is effectively equivalent to obtaining remote control with the privileges of the process user (and, if run with elevated privileges, administrator/superuser rights). Potential consequences include:

  • theft of source code, secrets from configurations, and cloud access keys;
  • tampering with build artifacts and inserting malicious code into the organization’s products;
  • lateral movement within the network via developer workstations as a “bridge” to more protected segments;
  • reputational damage if compromised packages spread to end customers.

The lack of traditional C2 and the use of Zulip complicate network detection and incident rollback: blocking one or two domains or IPs does not solve the problem, and telemetry for traffic to popular SaaS services is usually less granular.

Practical defense recommendations

1. Immediate environment checks

  • On all developer systems and build servers, check installed packages:
    • pip list | findstr uuid32-utils / pip list | findstr colorinal / pip list | findstr termncolor (Windows);
    • pip list | grep -E "uuid32-utils|colorinal|termncolor" (Linux).
  • If found — record the versions and usage context, then remove the packages:
    • pip uninstall uuid32-utils colorinal termncolor.

2. Searching for ZiChatBot artifacts

  • Windows:
    • search for terminate.dll files and suspicious binaries that appeared between July 16 and 22, 2025;
    • check autorun keys (from an elevated command prompt):
      • reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run
      • reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run

      and analyze entries pointing to non-standard executables in the user profile or temporary directories.

  • Linux:
    • check for the path /tmp/obsHub/obs-check-update and any executables inside;
    • inspect scheduled tasks:
      • crontab -l for each user who may have used Python;
      • review system crontab files (/etc/crontab, /etc/cron.*) for references to obs-check-update or anomalous jobs in /tmp.

3. Network detection

  • In network telemetry and proxy logs, check for connections from developer workstations and CI/CD to Zulip-related domains at unusual times or with atypical traffic volumes.
  • Configure detection for anomalous API activity to external chat services (creating/reading messages from servers where such clients are not supposed to run).

4. Strengthening the Python dependency supply chain

  • Switch to using an internal PyPI mirror with a whitelist of vetted packages; restrict direct access to external PyPI from developer workstations.
  • Implement package integrity controls (hash verification, artifact repositories with cryptographic signing).
  • Use static and dynamic analysis for new dependencies, especially if they are unknown or rarely used.
  • Isolate build environments: minimal privileges, restricted network access (allow only necessary repositories and updates, block arbitrary access to external SaaS services).

5. Organizational measures

  • Update internal dependency selection policies: ban “quick” imports of random packages without review and approval.
  • Provide brief training for development teams on the risks of attacks via package repositories and on procedures for vetting new modules.
  • Coordinate security and DevOps teams to integrate dependency checks into the pipeline (software composition analysis).

The key takeaway from the ZiChatBot incident on PyPI is that development and build environments must be treated as priority assets: as quickly as possible, check for the presence of the uuid32-utils, colorinal, and termncolor packages, remove them along with any identified artifacts (including /tmp/obsHub/obs-check-update and suspicious autorun entries), and then lock in the result with technical measures — moving to a controlled PyPI mirror, strictly limiting network access for build systems, and embedding automated checks of third-party dependencies into the pipeline.


CyberSecureFox Editorial Team

The CyberSecureFox Editorial Team covers cybersecurity news, vulnerabilities, malware campaigns, ransomware activity, AI security, cloud security, and vendor security advisories. Articles are prepared using official advisories, CVE/NVD data, CISA alerts, vendor publications, and public research reports. Content is reviewed before publication and updated when new information becomes available.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.