PyPI Packages Deliver ZiChatBot Malware via Zulip APIs on Windows and Linux

Cybersecurity researchers have uncovered a coordinated supply chain attack targeting users of the Python Package Index (PyPI) repository, where three malicious packages delivered a previously unknown malware family called ZiChatBot to Windows and Linux systems. The campaign, disclosed by researchers at Kaspersky, stands out for its use of public REST APIs from the team chat platform Zulip as command-and-control (C2) infrastructure, bypassing the need for dedicated malicious servers that are often blocked by network defenses. "Unlike traditional malware, ZiChatBot does not communicate with a dedicated command-and-control (C2) server, but instead uses a series of REST APIs from the public team chat app Zulip as its C2 infrastructure," the researchers noted.

Kaspersky researchers identified three packages uploaded to PyPI between July 16 and July 22, 2025, all of which have since been removed from the repository. The packages, which amassed a combined 2,480 downloads before takedown, included uuid32-utils (1,479 downloads), colorinal (614 downloads), and termncolor (387 downloads). Each package included the functionality advertised on its PyPI page to avoid raising early suspicion, but hid malicious payloads in their underlying code.

"While these wheel packages do implement the features described on their PyPI web pages, their true purpose is to covertly deliver malicious files," Kaspersky researchers wrote in their disclosure.

A key tactic in this campaign was the use of dependency chains to expand reach. The termncolor package was designed to look like a legitimate color manipulation tool, but listed colorinal as a dependency. This meant any user who installed termncolor would automatically pull the malicious colorinal package, even if they had not directly searched for it. The uuid32-utils and colorinal packages used near-identical malicious payloads, while termncolor served as a distribution vector for the latter.

How ZiChatBot Works

Once installed, the malicious packages deploy a dropper file specific to the target operating system. On Windows systems, the packages extract a DLL file named terminate.dll to disk. When a user imports the malicious library into a Python project, the DLL loads automatically, acting as a dropper for the ZiChatBot malware. After delivering the payload, the dropper creates an auto-run entry in the Windows Registry to maintain persistence, then deletes itself from the host to avoid detection.

Linux systems follow a similar pattern, with a shared object dropper named terminate.so replacing the Windows DLL. The dropper writes the ZiChatBot malware to the /tmp/obsHub/obs-check-update path and adds a crontab entry to ensure the malware runs on system reboot. This persistence mechanism is common in Linux malware, as crontab entries are often overlooked in routine system checks.

Regardless of the operating system, ZiChatBot communicates with its operators via Zulip's public REST APIs, a departure from traditional malware that relies on dedicated C2 servers. After receiving shellcode from the Zulip-based C2, the malware executes the command and sends a heart emoji as a response to signal successful completion. This unusual signaling method is a distinctive indicator of ZiChatBot activity, though the use of legitimate Zulip traffic makes the malware harder to detect than variants using custom C2 infrastructure.

Links to OceanLotus

Kaspersky researchers noted that the dropper code used in this campaign shares a 64% similarity with tools previously attributed to OceanLotus, a Vietnam-aligned threat group also known as APT32. The group has been active since at least 2014, targeting governments, activists, and private sector organizations in Southeast Asia and beyond. OceanLotus (APT32) is listed in the MITRE ATT&CK framework for its use of sophisticated supply chain attacks and abuse of legitimate tools for malicious purposes.

This is not the first time OceanLotus has used legitimate SaaS platforms for C2. In late 2024, the group targeted members of the Chinese cybersecurity community with poisoned Visual Studio Code projects masquerading as Cobalt Strike plugins. That campaign delivered a trojan that used the Notion note-taking service as its C2 infrastructure, a tactic documented by security firm ThreatBook. Kaspersky noted that if OceanLotus is indeed behind the PyPI campaign, it represents a strategic shift for the group, moving from phishing emails as a primary initial infection vector to broader supply chain attacks targeting open source repositories.

Why This Campaign Matters

Supply chain attacks on open source package repositories have grown increasingly common in recent years, with PyPI, npm, and other repositories repeatedly hosting malicious packages designed to steal credentials, deliver malware, or exfiltrate data. What makes the ZiChatBot campaign notable is its use of a legitimate, widely used team chat platform for C2. Most network defenses focus on blocking traffic to known malicious IP addresses or domains, but Zulip's APIs are used by thousands of legitimate organizations, making blanket blocking impractical. This tactic of abusing SaaS tools for C2 is part of a broader trend among threat actors, who are moving away from custom infrastructure to reduce their operational footprint and evade detection.

The campaign also highlights the risks of dependency chains in open source ecosystems. Many developers install packages without checking their dependencies, especially for tools with low download counts or obscure functionality. The use of termncolor as a seemingly benign package that pulls a malicious dependency takes advantage of this trust, expanding the reach of the campaign beyond users who directly searched for the malicious colorinal package.

Practical Takeaways for Developers and Organizations

Defending against supply chain attacks like the ZiChatBot campaign requires a combination of technical controls and process changes. Developers can take several immediate steps to reduce their risk:

First, verify all packages before installation. Check the package maintainer's history, download counts, and recent updates. Packages with low download counts, newly created maintainer accounts, or unusual dependency chains should be treated with caution. Tools like pip-audit can scan installed packages for known vulnerabilities or malicious entries, while static analysis tools like Bandit can check for suspicious code in package source files.

Second, use isolated environments for all Python projects. Virtual environments (via venv or conda) ensure that malicious packages installed for one project do not affect others or the system as a whole. For organizations, private PyPI mirrors that only host pre-approved, scanned packages can eliminate the risk of installing malicious public packages entirely.

Third, monitor for indicators of compromise (IoCs) associated with ZiChatBot. On Windows systems, check for terminate.dll files in temporary directories and unusual auto-run registry entries. On Linux, look for the /tmp/obsHub/obs-check-update path and crontab entries referencing that directory. While detecting Zulip API traffic alone is not a reliable indicator, security teams can monitor for unusual API call patterns, such as repeated requests to Zulip endpoints from systems that do not normally use the platform, paired with the distinctive heart emoji response.

Finally, stay informed about emerging threats targeting open source ecosystems. Subscribe to security advisories from PyPI, follow researchers like Kaspersky who track supply chain attacks, and regularly update dependency scanning tools to catch new malicious packages as soon as they are identified.

The ZiChatBot campaign is a reminder that open source supply chains remain a high-value target for threat actors, who are constantly adapting their tactics to evade existing defenses. By combining legitimate SaaS tools for C2 with clever dependency chains, this campaign demonstrates the need for layered, proactive defenses that go beyond traditional network blocking. For developers and organizations alike, treating every package installation as a potential risk, rather than assuming open source tools are safe by default, is the best way to avoid falling victim to these increasingly sophisticated attacks.