'ZiChatBot' Malware Delivered via PyPI Abuses Zulip Chat APIs for Command and Control, OceanLotus APT Suspected

Executive Summary

Security researchers have identified a software supply chain attack involving three malicious packages hosted on the Python Package Index (PyPI). The packages, named uuid32-utils, colorinal, and termncolor, were designed to deliver a previously unknown malware family dubbed ZiChatBot to developer systems running Windows and Linux. The malware employs a novel and stealthy technique for command-and-control (C2), abusing the REST APIs of the legitimate team chat application Zulip to receive commands and exfiltrate data. This method allows the C2 traffic to masquerade as legitimate API calls, making it difficult to detect. The campaign, which was active in July 2025, is suspected to be the work of the OceanLotus APT group, indicating a potential expansion of their TTPs to include supply chain compromises.

Threat Overview

The attack relies on typosquatting and dependency confusion within the PyPI ecosystem. The threat actor published three packages:

• uuid32-utils: A malicious package directly containing the payload.
• colorinal: Another malicious package containing the payload.
• termncolor: A seemingly benign package that lists the malicious colorinal package as a dependency, effectively hiding the malicious code one level deep.

When a developer installs one of these packages, a setup script executes that drops and runs the ZiChatBot malware. The malware's most distinctive feature is its C2 mechanism. Instead of connecting to a traditional C2 server, it communicates with a specific organization on the public Zulip chat service. It uses Zulip's legitimate REST APIs to post messages (exfiltrate data) and read messages (receive commands), blending its malicious communications with normal SaaS traffic.

On Windows systems, the infection chain is more complex, involving a DLL dropper (terminate.dll) that installs ZiChatBot, establishes persistence via a Windows Registry entry, and then deletes the original dropper to cover its tracks.

Technical Analysis

Based on analysis with the Kaspersky Threat Attribution Engine (KTAE), the campaign is attributed with medium-to-high confidence to the OceanLotus APT group (also known as APT32 or SeaLotus). If this attribution is correct, it marks a significant tactical shift for the group, which has historically relied on spear-phishing for initial access.

The attack chain maps to the following MITRE ATT&CK techniques:

• Initial Access: T1189 - Drive-by Compromise: While not a traditional drive-by, compromising a software repository fits this category. A more specific sub-technique could be considered supply chain compromise.
• Execution: T1059.006 - Python: The malware is executed via the setup.py script during package installation with pip.
• Persistence: T1547.001 - Registry Run Keys / Startup Folder: On Windows, the malware adds a registry entry to ensure it runs on system startup.
• Defense Evasion: T1027 - Obfuscated Files or Information: The use of a benign package with a malicious dependency is a form of obfuscation.
• Command and Control: T1102.002 - Bidirectional Communication: The malware uses a legitimate web service (Zulip) for C2, a technique known as Command and Control Through Web Service.

Impact Assessment

Although no active infections were observed in the wild due to the swift takedown of the packages, the potential impact of this campaign is significant. By compromising the software supply chain, the attackers could have gained initial access to developer workstations within numerous organizations. This type of access is highly valuable, as developers often have privileged access to source code repositories, build systems, and production environments. A successful breach could lead to intellectual property theft, injection of malicious code into legitimate software (a secondary supply chain attack), or lateral movement into sensitive corporate networks. The use of a legitimate chat application for C2 makes detection extremely challenging for organizations that do not perform deep packet inspection or closely monitor API traffic to third-party services.

IOCs — Directly from Articles

No traditional IOCs like IP addresses or domains were provided, as the C2 mechanism relied on a legitimate service.

Cyber Observables — Hunting Hints

Security teams can hunt for signs of this or similar attacks using the following methods:

Detection & Response

1. Dependency Scanning: Integrate automated security scanning into the CI/CD pipeline to check for malicious or vulnerable dependencies before they are incorporated into a project. Tools like pip-audit can help identify known malicious packages. This relates to D3FEND's D3-SCA - Software Component Analysis.
2. Egress Traffic Analysis: For C2 detection, focus on D3-NTA - Network Traffic Analysis of traffic to legitimate cloud services like Zulip. Baseline normal API usage and alert on anomalies, such as a server that has never used Zulip before suddenly sending a high volume of API requests.
3. Endpoint Monitoring: Use an EDR to monitor for suspicious behavior during package installation, such as pip or setup.py writing new executables to disk or creating persistence mechanisms in the registry.
4. Response: If a malicious package is detected, immediately isolate the affected host. Revoke all credentials and secrets stored on the machine. Investigate developer activity to determine the extent of the compromise and check source code repositories for any unauthorized modifications.

Mitigation

Preventing supply chain attacks requires a defense-in-depth strategy.

1. Curated Repositories: Whenever possible, use a private, internal package repository (like JFrog Artifactory or Sonatype Nexus) that mirrors and vets packages from public sources like PyPI. This implements a form of M1037 - Filter Network Traffic at the application layer.
2. Developer Training: Educate developers on the risks of supply chain attacks, including typosquatting and dependency confusion. Encourage careful vetting of new dependencies. This is a specific application of M1017 - User Training.
3. Principle of Least Privilege: Ensure that developer accounts and CI/CD systems do not have excessive permissions. Build processes should run in isolated, ephemeral environments with limited network access. This aligns with M1026 - Privileged Account Management.
4. Code Signing: Enforce policies that require dependencies to be signed, although this is not a foolproof solution as attackers can sometimes sign their malicious packages. This is part of M1045 - Code Signing.