OceanLotus PyPI attack: how ZiChatBot used Zulip as command-and-control

Kaspersky’s Securelist write-up says researchers noticed the malicious wheels beginning in July 2025, shared the information with the public security community, and the malware was removed from the repository.^[3] The packages reportedly implemented the features described on their PyPI pages, but their true purpose was to covertly deliver malicious files.^[3][4]

On attribution, the public wording is worth reading carefully. Kaspersky’s Securelist text says the samples were submitted to Kaspersky Threat Attribution Engine and that the packages may be linked to malware discussed in an OceanLotus threat-intelligence report.^[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 describes the attribution as moderate confidence.^[2]

What the infection chain looked like

The supported public reporting points to a cross-platform dropper chain. The malicious packages targeted both Windows and Linux systems and delivered ZiChatBot through embedded droppers.^[1][2][6]

One public summary describes the chain 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 cross-platform design is part of what makes the campaign relevant to developer workstations, CI systems, and servers that install Python packages from PyPI.

How ZiChatBot used Zulip for command-and-control

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

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

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

Why the Zulip detail matters

The Zulip angle does not imply that Zulip was breached. The evidence points to abuse of normal bot and messaging APIs, not compromise of the chat service itself.^[4][19][21]

For defenders, the important lesson is that C2 traffic may appear as communication with a legitimate collaboration service. Blocklists focused only on suspicious attacker domains can miss this kind of pattern; detection should also consider whether a given host, process, build job, or service account has any legitimate reason to call Zulip APIs.^[4][21]

What to check now

Security teams investigating possible exposure should prioritize a few concrete checks:

1. Package inventory: Search developer machines, build runners, virtual environments, lockfiles, and container images for uuid32-utils, colorinal, and termncolor.^[1][2]
2. Timeline review: Review PyPI installation activity from July 2025 onward, the period Kaspersky identified for the malicious wheel uploads.^[3]
3. Persistence artifacts: On suspected Windows and Linux hosts, look for unexpected persistence through the Windows Registry or crontab, matching the public infection-chain summary.^[2]
4. Unexpected Zulip API use: Inspect network and process telemetry for Zulip API traffic from Python interpreters, package-install processes, CI workers, or servers that do not normally use Zulip.^[4][21]
5. Package behavior review: Treat packages that appear functional as still potentially dangerous; Kaspersky said the malicious wheels implemented their advertised features while also delivering malicious files.^[3][4]

Bottom line

The attack Kaspersky linked to OceanLotus was a malicious PyPI wheel-package campaign involving uuid32-utils, colorinal, and termncolor. Those packages acted as droppers for ZiChatBot on Windows and Linux, and ZiChatBot’s standout technique was using Zulip REST APIs as command-and-control infrastructure instead of a dedicated C2 server.^[1][2][4][6]