Im Python Package Index (PyPI) wurden drei Pakete entdeckt, die neben der deklarierten Funktionalität unbemerkt die bislang unbekannte Malware ZiChatBot für Windows und Linux einschleusen. Dabei wird der öffentliche Chat-Service Zulip als Command-and-Control-Infrastruktur genutzt; dadurch sind Entwickler sowie alle Systeme verwundbar, auf denen diese Pakete im Zeitraum vom 16. bis 22. Juli 2025 installiert wurden, und es ist ein umgehendes Audit der Abhängigkeiten sowie eine Prüfung auf Anzeichen einer Kompromittierung erforderlich.

Technische Details des Angriffs

Forscher haben drei Pakete auf PyPI identifiziert, die als gewöhnliche Wheel-Dateien mit funktionierender Legit-Funktionalität erscheinen:

• uuid32-utils — enthält einen bösartigen Loader;
• colorinal — verwendet ein ähnliches bösartiges Modul wie uuid32-utils;
• termncolor — wirkt wie ein harmloses Paket, deklariert jedoch eine Abhängigkeit von colorinal und bringt damit transitiv den bösartigen Code mit.

Alle drei Pakete wurden in einem kurzen Zeitfenster zwischen dem 16. und 22. Juli 2025 in das PyPI-Repository hochgeladen, was typisch für eine gezielte Supply-Chain-Operation ist und gut zur Technik Supply Chain Compromise in MITRE ATT&CK passt.

Infektionsmechanismus unter Windows

Unter Windows wird bei der Installation eines der beiden ersten Pakete versteckte Logik ausgeführt:

• aus dem Paket wird der DLL-Loader terminate.dll extrahiert und auf die Festplatte geschrieben;
• beim Import der Bibliothek in ein Projekt wird die DLL automatisch geladen;
• terminate.dll fungiert als Dropper für ZiChatBot und entpackt das Hauptmodul der Malware;
• es wird ein Autostart-Eintrag in der Windows-Registrierung (Run-ähnlicher Schlüssel) erstellt;
• der Code des Droppers führt eine Selbstzerstörung durch und löscht seine eigenen Spuren vom Host.

In der Folge verbleibt auf dem System nur ZiChatBot mit einem persistierenden Einstiegspunkt und einem Minimum an offensichtlichen Artefakten, was die nachträgliche Analyse erheblich erschwert.

Infektionsmechanismus unter Linux

Unter Linux wird eine parallele Logik mit einem Shared Object angewendet:

• terminate.so wird extrahiert und gestartet;
• ZiChatBot wird unter dem Pfad /tmp/obsHub/obs-check-update abgelegt;
• zur Persistenz wird ein Eintrag in der crontab angelegt, der die bösartige Binärdatei regelmäßig ausführt.

Die Nutzung des Verzeichnisses /tmp und des unauffällig wirkenden Namens obs-check-update senkt die Wahrscheinlichkeit einer Entdeckung bei einer oberflächlichen Systemprüfung.

Steuerung über Zulip als Ersatz für klassisches C2

Ein zentrales Merkmal von ZiChatBot ist das Fehlen eines dedizierten Command-and-Control-Servers. Stattdessen verwendet die Malware die öffentlichen REST-APIs der Enterprise-Chat-Anwendung Zulip und interagiert damit wie ein legitimer Client über die offiziell dokumentierten Schnittstellen des Zulip API.

Das Verhalten von ZiChatBot lässt sich wie folgt zusammenfassen:

• Verbindung zu bestimmten Kanälen/Streams in Zulip über das REST API;
• Empfang von Befehlen in Form von Payload (Shellcode);
• Ausführung des empfangenen Shellcodes auf dem kompromittierten System;
• Rückmeldung eines Herz-Emojis in den Zulip-Kanal als Signal für die erfolgreiche Befehlsausführung.

Diese Art der Steuerung bietet Angreifern mehrere Vorteile:

• Traffic zu einem Cloud-basierten Chat-Service wirkt legitim und wird häufig nicht gefiltert;
• es gibt keine statische Domain oder IP, wie sie für klassisches C2 typisch ist;
• ein Wechsel des Workspaces oder der Accounts in Zulip verändert die gesamte „Infrastruktur“ ohne Hosting-Kosten.

Aus Sicht von MITRE ATT&CK entspricht dies der Technik der Nutzung legitimer Web-Services für Command and Control (Web Service C2), die bereits zuvor bei fortgeschrittenen Gruppen beobachtet wurde.

Kontext und mögliche Verbindung zu OceanLotus

Laut den Forschern weist der Dropper in der aktuellen Kampagne eine 64%ige Ähnlichkeit zu einem anderen Loader auf, der zuvor der vietnamesischen Gruppe OceanLotus (APT32) zugeschrieben wurde. MITRE beschreibt diese Gruppe unter der Kennung G0050 als Akteur, der gezielt unterschiedliche Organisationen in Asien angreift.

Ende 2024 wurde OceanLotus bereits bei einem Angriff auf die chinesische Cybersicherheits-Community beobachtet: Es kamen manipulierte Visual-Studio-Code-Projekte zum Einsatz, die sich als Cobalt-Strike-Plugins ausgaben und beim Kompilieren automatisch einen Trojaner starteten. In jener Kampagne nutzten die Angreifer den Notizdienst Notion als Command-and-Control-Kanal und setzten damit einen öffentlichen Cloud-Service in ähnlicher Weise ein, wie jetzt Zulip verwendet wird, was durch öffentliche Analysen und die offizielle Dokumentation von Notion belegt ist.

Die aktuelle Aktivität auf PyPI kann nicht endgültig OceanLotus zugeschrieben werden, doch die Existenz eines ähnlichen Droppers und das wiederkehrende Muster der Nutzung populärer SaaS-Plattformen (zunächst Notion, nun Zulip) als C2 deutet auf die Weiterentwicklung desselben operativen Modells hin:

• Verlagerung von Phishing hin zu Angriffen über die Lieferkette (IDE, Paket-Repositories);
• maximale Tarnung der C2-Infrastruktur als gewöhnlicher Unternehmens-Traffic;
• Fokussierung auf Entwickler und Sicherheitsspezialisten als anfängliche Opfer.

Auswirkungen auf Organisationen

Potentiell betroffen sind alle Umgebungen, in denen die Pakete uuid32-utils, colorinal oder termncolor im genannten Zeitraum installiert worden sein könnten. Das größte Risiko besteht für:

• Entwicklungsteams, die PyPI direkt aus dem Internet auf Workstations und in CI/CD nutzen;
• Build- und Test-Infrastrukturen, in denen die Ausführung beliebigen Codes den Weg zur Kompromittierung von Artefakten und zur „Infektion“ von Endprodukten eröffnet;
• Organisationen, in denen Entwickler-Workstations erweiterte Privilegien oder Zugriff auf sensible Daten besitzen.

Da ZiChatBot beliebigen Shellcode ausführt, entspricht eine erfolgreiche Infektion faktisch dem Erhalt einer Remote-Steuerung mit den Rechten des betroffenen Prozesses (und bei Ausführung mit erhöhten Rechten den Rechten eines Administrators/Superusers). Mögliche Folgen sind:

• Diebstahl von Quellcode, Secrets aus Konfigurationen und Zugangsschlüsseln zu Cloud-Umgebungen;
• Manipulation von Build-Artefakten und Einschleusen bösartigen Codes in Produkte der Organisation;
• laterale Bewegung im Netzwerk über Entwickler-Workstations als „Brücke“ zu stärker geschützten Segmenten;
• Reputationsschäden, falls kompromittierte Pakete an Endkunden ausgeliefert werden.

Das Fehlen klassischer C2-Infrastruktur und der Einsatz von Zulip erschweren sowohl die netzwerkbasierte Erkennung als auch die Incident-Response: Das Blockieren eines oder zweier Domains oder IPs löst das Problem nicht, und Telemetrie zum Traffic hin zu populären SaaS-Services ist in der Regel weniger detailliert.

Praktische Schutzempfehlungen

1. Sofortige Überprüfung der Umgebung

• Führen Sie auf allen Entwickler-Systemen und Build-Servern eine Prüfung der installierten Pakete durch:
  • pip list | findstr uuid32-utils / pip list | findstr colorinal / pip list | findstr termncolor (Windows);
  • pip list | grep -E "uuid32-utils|colorinal|termncolor" (Linux).
• Bei Fund — Versionen und Nutzungskontext dokumentieren und anschließend die Pakete entfernen:
  • pip uninstall uuid32-utils colorinal termncolor.

2. Suche nach ZiChatBot-Artefakten

• Windows:
  • Suche nach Dateien namens terminate.dll sowie nach verdächtigen Binärdateien, die im Zeitraum vom 16. bis 22. Juli 2025 erstellt wurden;
  • Überprüfung der Autostart-Schlüssel (mit Administratorrechten):
    • reg query HKCU\Software\Microsoft\Windows\CurrentVersion\Run
    • reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Run

    und Analyse von Einträgen, die auf ungewöhnliche ausführbare Dateien im Benutzerprofil oder in temporären Verzeichnissen verweisen.

• Linux:
  • Prüfung, ob der Pfad /tmp/obsHub/obs-check-update und darin ausführbare Dateien vorhanden sind;
  • Überprüfung des Task-Schedulers:
    • crontab -l für jeden Benutzer, der potentiell Python genutzt haben könnte;
    • Durchsicht der systemweiten Crontab-Dateien (/etc/crontab, /etc/cron.*) auf Verweise auf obs-check-update oder ungewöhnliche Jobs in /tmp.

3. Netzwerkbasierte Erkennung

• Prüfen Sie in Netzwerktelemetrie und Proxy-Logs Zugriffe von Entwickler-Workstations und CI/CD-Systemen auf Zulip-bezogene Domains zu ungewöhnlichen Zeiten oder mit atypischem Traffic-Volumen.
• Richten Sie Erkennungsmechanismen für anomale API-Aktivität gegenüber externen Chat-Services ein (Erstellen/Lesen von Nachrichten von Servern, auf denen solche Clients nicht betrieben werden sollten).

4. Härtung der Supply Chain von Python-Abhängigkeiten

• Stellen Sie auf ein internes PyPI-Mirror mit Whitelist verifizierter Pakete um; begrenzen Sie den direkten Zugriff von Entwickler-Workstations auf das externe PyPI.
• Implementieren Sie Integritätskontrollen für Pakete (Hash-Prüfung, Artefakt-Repositories mit kryptographischer Signatur).
• Setzen Sie statische und dynamische Analysen für neue Abhängigkeiten ein, insbesondere wenn diese unbekannt oder wenig verbreitet sind.
• Isolieren Sie Build-Umgebungen: minimale Rechte, eingeschränkter Netzwerkzugang (nur notwendige Repositories und Updates erlauben, beliebigen Zugriff auf externe SaaS-Services blockieren).

5. Organisatorische Maßnahmen

• Aktualisieren Sie interne Richtlinien zur Auswahl von Abhängigkeiten: Verbot des „schnellen“ Imports beliebiger Pakete ohne Review und Freigabe.
• Führen Sie ein kurzes Training für Entwicklungsteams zu Risiken von Angriffen über Paket-Repositories und zu Verfahren zur Prüfung neuer Module durch.
• Koordinieren Sie Security- und DevOps-Teams, um Dependency-Prüfungen in die Pipeline zu integrieren (Software Composition Analysis).

Die wichtigste Lehre aus dem ZiChatBot-Vorfall auf PyPI lautet: Entwicklungs- und Build-Umgebungen müssen als vorrangige Schutzgüter betrachtet werden. Es ist kurzfristig zu prüfen, ob die Pakete uuid32-utils, colorinal und termncolor vorhanden sind, diese zusammen mit identifizierten Artefakten zu entfernen (einschließlich /tmp/obsHub/obs-check-update und verdächtiger Autostart-Einträge) und das Ergebnis anschließend durch technische Maßnahmen zu verstetigen — den Umstieg auf ein kontrolliertes PyPI-Mirror, strikte Einschränkung des Netzwerkzugriffs von Build-Systemen sowie in die Pipeline integrierte automatische Prüfungen externer Abhängigkeiten.