OceanLotus-nahe PyPI-Kampagne: Wie ZiChatBot Zulip-APIs für Command-and-Control missbrauchte

Öffentliche Berichte nennen drei gefälschte PyPI-Bibliotheken aus der Kampagne:

• uuid32-utils
• colorinal
• termncolor

Bei der Zuordnung zu OceanLotus lohnt sich ein genauer Blick auf die Formulierung. Im Securelist-Beitrag heißt es, die Proben seien in Kasperskys Threat Attribution Engine eingereicht worden; auf Basis der Ergebnisse könnten die Pakete mit Malware in Verbindung stehen, die in einem Threat-Intelligence-Bericht zu OceanLotus behandelt wurde. Kasperskys Threat-Research-Index formuliert es direkter und schreibt, das Unternehmen ordne die PyPI-ZiChatBot-Aktivität OceanLotus APT zu. Eine öffentliche Zusammenfassung beschreibt die Attribution als „moderate confidence“ — also mit mittlerem Vertrauen.

Von schädlichem Wheel zu ZiChatBot

Das öffentlich gestützte Bild zeigt eine plattformübergreifende Dropper-Kette. Kasperskys Threat-Research-Index zufolge zielten die schädlichen PyPI-Wheel-Pakete auf Windows und Linux und enthielten einen Dropper, der die als ZiChatBot bezeichnete Malware auslieferte.

Eine öffentliche Zusammenfassung beschreibt die nächsten Schritte so: Aus dem Wheel-Paket werde entweder ein DLL- oder ein .SO-Dropper extrahiert, danach werde Persistenz über die Windows-Registry beziehungsweise über Linux-Crontab eingerichtet, bevor ZiChatBot ausgerollt werde.

Das ist für Security-Teams wichtig, weil nicht nur klassische Server betroffen sein können. Prüfen sollten auch Entwickler-Workstations, virtuelle Python-Umgebungen, Build-Runner und Container-Images, sofern dort eines der genannten Pakete installiert wurde.

Der Fall zeigt außerdem ein altes Problem in neuer Verpackung: Ein Paket kann funktionieren und trotzdem bösartig sein. Kaspersky zufolge lieferten die Wheels die beworbenen Funktionen, während sie gleichzeitig versteckte schädliche Dateien mitbrachten.

Wie ZiChatBot Zulip als C2-Kanal nutzte

ZiChatBots besondere Wendung war die Nutzung einer legitimen Kollaborationsplattform. Laut Berichten über Kasperskys Befunde kommunizierte ZiChatBot nicht mit einem eigenen Command-and-Control-Server, sondern nutzte eine Reihe von REST-APIs der öffentlichen Team-Chat-Anwendung Zulip als C2-Infrastruktur.

Zulips dokumentierte APIs bieten genau jene Arten von Funktionen, die ein chatbasiertes C2-Design grundsätzlich benötigen würde: Nachrichten senden und abrufen, Dateien hochladen, Nachrichten bearbeiten oder löschen, sogenannte „Narrows“ für gezielte Nachrichtenabfragen konstruieren sowie mit Channel-Topics arbeiten. Die Bot-Dokumentation von Zulip beschreibt zudem Bots, die von Nutzern gesendete Nachrichten abfangen, ansehen und verarbeiten und anschließend neue Nachrichten als Antworten senden können.

Auf hoher Ebene bedeutet das: Operator-Anweisungen können als Chatnachrichten oder als Nachrichten innerhalb bestimmter Topics erscheinen, während die Malware passende Nachrichten abruft und Ergebnisse über denselben Dienst zurückschreibt. Die hier vorliegenden öffentlichen Quellen nennen jedoch weder den konkreten Zulip-Workspace noch Bot-Zugangsdaten, die genaue Endpoint-Reihenfolge oder den Befehlssatz von ZiChatBot. Am saubersten ist daher die Beschreibung, dass ZiChatBot legitime Zulip-REST-API-Funktionalität für C2 missbrauchte, statt auf eigene Angreifer-Infrastruktur zu setzen.

Was die Zulip-Spur nicht bedeutet

Die Zulip-Komponente heißt nicht, dass Zulip selbst kompromittiert wurde. Die zitierten Berichte beschreiben den Missbrauch normaler REST-API- und Bot-Messaging-Funktionen, nicht einen Einbruch in den Chatdienst.

Ebenso wenig belegt der Fall eine Kompromittierung der PyPI-Infrastruktur. Kasperskys Bericht spricht von schädlichen Wheel-Paketen, die auf PyPI hochgeladen wurden, und davon, dass die Malware später aus dem Repository entfernt wurde.

Für Verteidiger ist die Konsequenz dennoch unangenehm: Traffic zu einem legitimen Kollaborationsdienst kann verdächtig sein, wenn er von einem Host, Prozess, CI-Job oder Service-Account kommt, der normalerweise keinen Grund hat, mit diesem Dienst zu sprechen. Blocklisten, die nur bekannte Angreifer-Domains erfassen, können ein solches Muster übersehen. Entscheidend sind deshalb Prozesskontext, erwartete Geschäftsnutzung und Abweichungen vom Normalverhalten — nicht nur die Reputation des Ziel-Dienstes.

Was Security-Teams jetzt prüfen sollten

Beginnen sollten Teams mit einer Paket-Inventur. Suchen Sie auf Entwicklerrechnern, Build-Runnern, in virtuellen Python-Umgebungen, Dependency-Lockfiles und Container-Images nach uuid32-utils, colorinal und termncolor.

Prüfen Sie Installationszeitpunkte ab Juli 2025, dem Zeitraum, den Kaspersky für die schädlichen Wheel-Uploads nennt. Taucht eines der genannten Pakete in Logs oder Artefakten auf, sollte die Umgebung für eine Untersuchung gesichert werden, statt das Paket nur zu löschen und zur Tagesordnung überzugehen.

Auf Windows-Systemen sollten unerwartete Persistenzmechanismen in der Registry geprüft werden; auf Linux-Systemen gehören verdächtige Crontab-Einträge auf die Liste. Das entspricht der öffentlich beschriebenen Infektionskette der Kampagne.

Untersuchen Sie außerdem Netzwerk- und Prozess-Telemetrie auf Zulip-API-Aktivität von Python-Interpretern, Paketinstallationsprozessen, CI-Workern, Servern oder Service-Accounts, die Zulip üblicherweise nicht verwenden. Die Frage lautet nicht, ob Zulip an sich legitim ist, sondern ob genau dieser Host und genau dieser Prozess einen legitimen Grund für Zulip-API-Aufrufe haben.

Und schließlich: Funktionalität ist kein Vertrauensbeweis. In dieser Kampagne sollen die Pakete ihre beworbenen Funktionen bereitgestellt haben, während sie zugleich als Dropper für schädliche Dateien dienten.

Fazit

Die mit OceanLotus in Verbindung gebrachte PyPI-Kampagne bestand aus schädlichen Wheel-Paketen, die ab Juli 2025 hochgeladen wurden; öffentlich genannt werden unter anderem uuid32-utils, colorinal und termncolor. Diese Pakete lieferten ZiChatBot auf Windows- und Linux-Systeme aus. Das prägende technische Merkmal war, dass ZiChatBot Zulip-REST-APIs für Command-and-Control nutzte, statt auf einen klassischen, von Angreifern kontrollierten C2-Server zu setzen.