Malware News KASPERSKY GREAT RESEARCH: OceanLotus suspected of using PyPI to deliver ZiChatBot malware

[Khushal]

Content source

https://securelist.com/oceanlotus-suspected-pypi-zichatbot-campaign/119603/

Introduction

Through our daily threat hunting, we noticed that, beginning in July 2025, a series of malicious wheel packages were uploaded to PyPI (the Python Package Index). We shared this information with the public security community, and the malware was removed from the repository. We submitted the samples to Kaspersky Threat Attribution Engine (KTAE) for analysis. Based on the results, we believe the packages may be linked to malware discussed in a Threat Intelligence report on OceanLotus.

While these wheel packages do implement the features described on their PyPI web pages, their true purpose is to covertly deliver malicious files. These files can be either .DLL or .SO (Linux shared library), indicating the packages’ ability to target both Windows and Linux platforms. They function as droppers, delivering the final payload – a previously unknown malware family that we have named ZiChatBot. 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.

OceanLotus suspected of distributing ZiChatBot malware via wheel packages in PyPI

Kaspersky researchers uncovered malicious wheel packages in PyPI that targeted both Windows and Linux and contained a dropper delivering malware dubbed ZiChatBot. We attribute this activity to OceanLotus APT.

securelist.com

To conceal the malicious package containing ZiChatBot, the attacker created another benign-looking package that included the malicious package as a dependency. Based on these facts, we confirm that this campaign is a carefully planned and executed PyPI supply chain attack.

 

[Bot]

A careful PyPI supply chain attack. The most important point is that the malicious behavior was not obvious from the package description alone, because the attacker hid the real payload behind dependency chains and platform-specific droppers.

What stands out here

• The packages reportedly worked as advertised, which helps them avoid suspicion during basic testing.
• The real malicious activity was in delivering hidden payloads, including both Windows .DLL and Linux .SO files.
• Using a second, benign-looking package as a dependency lure is a classic trust-abuse technique in software supply chain attacks.
• Abusing Zulip REST APIs instead of a dedicated C2 server is notable because traffic to legitimate cloud services can blend in with normal activity.

Why this matters

This is a good example of why “it installs and seems functional” does not mean “it is safe.”

In package ecosystem attacks, malicious code may be:

• Buried in install scripts
• Triggered only on certain platforms
• Downloaded later as a second-stage payload
• Hidden in dependencies that developers did not examine closely

That makes detection harder for both users and automated scanners, especially if the package does not immediately show overtly malicious behavior.

On the OceanLotus link</B]

The reported attribution should be treated carefully unless backed by strong evidence from the researchers. Threat actor attribution is one of the easiest areas to overstate. “May be linked” is a reasonable level of caution; it is not the same as confirmed attribution.

Practical takeaways for developers and defenders

• Pin and review dependencies, including transitive dependencies, rather than trusting package names or descriptions.
• Monitor package install behavior, especially wheel contents, post-install activity, and unexpected native libraries.
• Restrict build environments so they cannot freely reach external services unless necessary.
• Inspect unusual outbound API traffic to legitimate platforms if it does not match expected application behavior.
• Use internal package mirrors or allowlists for production dependency management where possible.
• Treat newly published or low-reputation packages with extra caution, even if they appear useful and functional.

For anyone worried about exposure

A safe response would be:

• Identify whether any affected package names were installed in development, CI/CD, or production systems.
• Check Python environment logs, package lock files, and build histories.
• Scan impacted hosts with reputable security tools.
• Review outbound connections for suspicious access to services that the environment does not normally use.
• Rotate credentials that may have been exposed on any host where the package executed.

The key takeaway is that this appears to be a well-planned supply chain campaign, and the Zulip-based C2 design shows how attackers keep adapting to blend into legitimate infrastructure.