OceanLotus-linked PyPI attack: how ZiChatBot used Zulip APIs for C2

The packages were not merely broken or empty decoys. Kaspersky said the wheels implemented the features described on their PyPI pages, while their true purpose was to covertly deliver malicious files.^[3] The Hacker News separately reported the same Kaspersky finding: the packages looked functional but were designed to stealthily deliver ZiChatBot on Windows and Linux systems.^[4]

Public reporting identifies three fake PyPI libraries involved in the campaign:^[1][2]

• uuid32-utils
• colorinal
• termncolor

Kaspersky’s own public wording on attribution should be read carefully. The Securelist post says the samples were submitted to Kaspersky Threat Attribution Engine and that the packages may be linked to malware discussed in a threat-intelligence report on OceanLotus.^[3] Kaspersky’s threat-research index is more direct, stating that the company attributes the PyPI ZiChatBot activity to OceanLotus APT.^[6] A public summary characterizes the attribution as moderate confidence.^[2]

The infection chain: malicious wheel to ZiChatBot

The supported public picture is a cross-platform dropper chain. Kaspersky’s threat-research index says the malicious PyPI wheel packages targeted both Windows and Linux and contained a dropper that delivered malware dubbed ZiChatBot.^[6]

One public summary describes the next steps as extracting either a DLL or .SO dropper from the wheel package, establishing persistence through the Windows Registry or Linux crontab, and then deploying ZiChatBot.^[2] That matters because the campaign is relevant not only to application servers, but also to developer workstations, virtual environments, build runners, and container images that may have installed the affected packages.

The campaign also shows why functional packages cannot be treated as safe by default. Kaspersky said the malicious wheels did implement the features advertised on their PyPI pages, even as they delivered hidden malicious files.^[3][4]

How ZiChatBot used Zulip for command-and-control

ZiChatBot’s notable twist was its use of a legitimate collaboration platform as the C2 layer. Reporting on Kaspersky’s findings says ZiChatBot did not communicate with a dedicated C2 server; instead, it used a series of REST APIs from Zulip, the public team-chat application, as command-and-control infrastructure.^[4]

Zulip’s documented APIs support the kinds of operations that a chat-based C2 design would need, including sending messages, getting messages, uploading files, editing or deleting messages, constructing message narrows, and working with channel topics.^[17][21] Zulip’s bot documentation also describes bots that can intercept, view, and process messages sent by users, then send new messages as replies.^[19]

At a high level, that means operator instructions can be represented as chat messages or topic-scoped messages, while malware can retrieve relevant messages and post results back through the same service. The public sources provided here do not disclose the exact Zulip workspace, bot credentials, endpoint sequence, or command set used by ZiChatBot, so the safest description is that ZiChatBot abused legitimate Zulip REST API functionality for C2 rather than relying on attacker-owned C2 infrastructure.^{[4][17][19][21]}

What the Zulip detail does — and does not — mean

The Zulip angle does not imply that Zulip itself was breached. The cited reporting describes abuse of normal REST API and bot-style messaging functionality, not a compromise of the chat service.^[4][19][21]

It also does not imply that PyPI’s infrastructure was compromised. Kaspersky’s report describes malicious wheel packages uploaded to PyPI, and says the malware was later removed from the repository.^[3]

For defenders, the implication is practical: traffic to a legitimate collaboration service can still be suspicious when it comes from a host, process, CI job, or service account that has no reason to talk to that service. Blocklists focused only on attacker-owned domains may miss this pattern, so investigation should include process context and expected business use, not just destination reputation.^[4][21]

What security teams should check

Start with package inventory. Search developer machines, build runners, virtual environments, dependency lockfiles, and container images for uuid32-utils, colorinal, and termncolor.^[1][2]

Review installation timelines from July 2025 onward, the period Kaspersky identified for the malicious wheel uploads.^[3] If any of the named packages appear in logs or artifacts, preserve the environment for investigation rather than simply deleting the package and moving on.

On Windows systems, look for unexpected persistence in the Registry; on Linux systems, check for suspicious crontab entries. That matches the public infection-chain summary for the campaign.^[2]

Inspect network and process telemetry for Zulip API activity from Python interpreters, package-install processes, CI workers, servers, or service accounts that do not normally use Zulip. The key question is not whether Zulip is legitimate in general, but whether that particular host and process have a legitimate reason to call Zulip APIs.^[4][21]

Finally, treat functional behavior as irrelevant to trust. In this campaign, the packages reportedly delivered their advertised features while also serving as droppers for malicious files.^[3][4]

Bottom line

The OceanLotus-linked PyPI campaign involved malicious wheel packages uploaded beginning in July 2025 and publicly named packages including uuid32-utils, colorinal, and termncolor.^[1][2][3] Those packages delivered ZiChatBot on Windows and Linux systems, and ZiChatBot’s defining operational choice was to use Zulip REST APIs for command-and-control instead of a dedicated attacker-run C2 server.^[4][6]