Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania pozostają jednym z najpoważniejszych zagrożeń dla organizacji rozwijających i wdrażających aplikacje. Najnowszy incydent związany z repozytorium PyPI pokazuje, że nawet pakiety wyglądające na użyteczne biblioteki mogą skrywać złośliwy kod uruchamiany już na etapie instalacji lub importu modułu.
W opisywanej kampanii wykryto pakiety Python, które poza deklarowaną funkcjonalnością dostarczały malware nazwane ZiChatBot. Zagrożenie wyróżniało się nie tylko wieloplatformowym charakterem, ale również wykorzystaniem API platformy Zulip jako kanału komunikacji z infrastrukturą sterującą.
W skrócie
- W repozytorium PyPI wykryto trzy pakiety powiązane z kampanią:
uuid32-utils,colorinaloraztermncolor. - Dwa z nich zawierały złośliwy kod, a trzeci pełnił rolę pakietu pośredniego wskazującego zależność.
- Po instalacji na Windows i Linux uruchamiany był dropper zapisujący komponent ZiChatBot oraz konfigurujący mechanizmy trwałości.
- Malware wykorzystywał API Zulip zamiast klasycznego serwera C2, co utrudniało detekcję opartą na prostych wskaźnikach sieciowych.
- Pakiety zostały opublikowane w lipcu 2025 roku i później usunięte z repozytorium.
Kontekst / historia
Ekosystem open source od lat stanowi atrakcyjny cel dla cyberprzestępców i grup APT. Wynika to z powszechnego zaufania do menedżerów pakietów, automatyzacji pipeline’ów CI/CD oraz częstej praktyki bezpośredniego pobierania zależności z publicznych rejestrów bez dodatkowej kontroli bezpieczeństwa.
W tym przypadku atakujący wykorzystali model znany z bardziej zaawansowanych kampanii supply chain: pakiety nie były całkowicie fikcyjne, lecz łączyły pozornie legalną funkcjonalność z ukrytym ładunkiem malware. Taki zabieg zmniejsza prawdopodobieństwo szybkiego wykrycia i zwiększa szanse na instalację przez programistów lub systemy budujące.
Wszystkie trzy pakiety zostały opublikowane w krótkim odstępie czasu między 16 a 22 lipca 2025 roku. Taka synchronizacja sugeruje zaplanowaną operację, której celem było zwiększenie zasięgu infekcji w ekosystemie Pythona.
W analizach pojawiły się także ostrożne odniesienia do częściowego podobieństwa droppera do narzędzi wiązanych wcześniej z grupą OceanLotus, znaną również jako APT32. Nie ma jednak publicznie potwierdzonej atrybucji, dlatego ten element należy traktować jako przesłankę analityczną, a nie rozstrzygający dowód.
Analiza techniczna
Złośliwy mechanizm został osadzony w pakietach, które realizowały również funkcje opisane w metadanych projektu. Dzięki temu biblioteki nie wzbudzały natychmiastowych podejrzeń, a złośliwy kod działał niejako w tle.
Na systemach Windows instalacja prowadziła do wyodrębnienia biblioteki terminate.dll. Po zaimportowaniu komponent był ładowany jako dropper odpowiedzialny za dostarczenie właściwego malware ZiChatBot. Następnie tworzony był mechanizm autostartu w rejestrze systemowym, co zapewniało persystencję po restarcie urządzenia. Część artefaktów pomocniczych była dodatkowo usuwana, aby ograniczyć widoczność infekcji.
Na systemach Linux analogiczną rolę pełnił plik terminate.so. Po uruchomieniu malware instalował się w ścieżce /tmp/obsHub/obs-check-update i dodawał wpis do crontaba w celu utrzymania trwałości. Wybór katalogu tymczasowego oraz nazwy sugerującej proces aktualizacji mógł ułatwiać kamuflaż i utrudniać analizę incydentu.
Najbardziej charakterystycznym elementem kampanii była komunikacja z użyciem REST API platformy Zulip. Zamiast korzystać z dedykowanego serwera dowodzenia i kontroli, malware opierał się na publicznej usłudze komunikacyjnej. To podejście utrudnia blokowanie ruchu na podstawie reputacji domen, zmniejsza koszty utrzymania infrastruktury po stronie atakujących i zwiększa szansę, że połączenia zostaną uznane za legalny ruch aplikacyjny.
Z analiz wynika również, że ZiChatBot był przygotowany do wykonywania shellcode odbieranego z kanału sterującego. Po wykonaniu zadania odsyłał prosty sygnał potwierdzający. Oznacza to, że mógł pełnić funkcję lekkiego loadera lub agenta wykonawczego, używanego do dostarczania kolejnych etapów ataku.
Konsekwencje / ryzyko
Największe ryzyko dotyczy organizacji, które pobierają zależności z publicznych repozytoriów bez rygorystycznej walidacji pochodzenia, pinowania wersji i skanowania artefaktów. W takim modelu pojedyncza instalacja pakietu może doprowadzić do uruchomienia złośliwego droppera na stacji roboczej programisty, w środowisku CI lub na serwerze aplikacyjnym.
Skala zagrożenia jest istotna z kilku powodów. Po pierwsze, kampania obejmowała zarówno Windows, jak i Linux, czyli systemy powszechnie używane przez deweloperów oraz infrastrukturę buildową. Po drugie, wykorzystanie legalnego API utrudnia wykrywanie przez klasyczne reguły sieciowe. Po trzecie, malware zdolny do wykonywania shellcode może zostać użyty do wdrożenia kolejnych ładunków, kradzieży danych, przejęcia poświadczeń lub ruchu bocznego.
W środowiskach enterprise skutki takiego incydentu mogą obejmować kompromitację sekretów CI/CD, tokenów dostępowych do repozytoriów, kluczy chmurowych, artefaktów buildów oraz kodu źródłowego. Szczególnie niebezpieczna jest możliwość wtórnego skażenia łańcucha dostaw, jeśli zainfekowana infrastruktura posłuży do dystrybucji kolejnych nieautoryzowanych zmian.
Rekomendacje
Organizacje korzystające z Pythona powinny wdrożyć restrykcyjną politykę zarządzania zależnościami i ograniczyć zaufanie do publicznych rejestrów. Kluczowe znaczenie ma pinowanie wersji, używanie zaufanych mirrorów lub wewnętrznych repozytoriów oraz blokowanie bezpośrednich instalacji z internetu w środowiskach produkcyjnych i CI/CD.
- Regularnie skanuj zależności pod kątem anomalii behawioralnych, a nie wyłącznie znanych sygnatur.
- Weryfikuj pakiety tworzące lub wyodrębniające pliki DLL i SO podczas instalacji.
- Monitoruj modyfikacje rejestru Windows, crontaba i innych mechanizmów persystencji.
- Analizuj połączenia do usług komunikacyjnych i współpracy, które nie wynikają z deklarowanej funkcji biblioteki.
- Zwracaj uwagę na kod uruchamiany przy imporcie modułu zamiast dopiero przy wywołaniu funkcji biznesowej.
Zespoły bezpieczeństwa powinny przeprowadzić threat hunting pod kątem nazw pakietów uuid32-utils, colorinal i termncolor, a także przeanalizować historię buildów, cache menedżerów pakietów oraz logi instalacji pip. W systemach Windows warto sprawdzić wpisy autostartu i obecność nietypowych bibliotek ładowanych przez projekty Python. W systemach Linux należy skontrolować wpisy crontab, zawartość katalogów tymczasowych oraz procesy inicjujące podejrzany ruch do usług SaaS.
Dobrym kierunkiem jest również wdrożenie praktyk Software Supply Chain Security, takich jak wewnętrzne zatwierdzanie nowych zależności, generowanie i archiwizacja SBOM, podpisywanie artefaktów, uruchamianie buildów w środowiskach izolowanych oraz ograniczanie dostępu środowisk developerskich do sekretów produkcyjnych.
Podsumowanie
Kampania z wykorzystaniem złośliwych pakietów PyPI pokazuje, że współczesne ataki supply chain stają się coraz bardziej dyskretne i technicznie dopracowane. ZiChatBot łączy legalnie wyglądające biblioteki, wieloplatformowy dropper, mechanizmy trwałości i komunikację ukrytą w publicznych API, co wyraźnie podnosi poziom trudności wykrywania.
Najważniejszy wniosek dla organizacji jest prosty: zaufanie do publicznych zależności nie może być bezwarunkowe. Każdy pakiet powinien być traktowany jak potencjalny wektor ataku, a skuteczna obrona wymaga zarówno kontroli łańcucha dostaw, jak i monitorowania zachowania komponentów po ich instalacji.
Źródła
- The Hacker News — https://thehackernews.com/2026/05/pypi-packages-deliver-zichatbot-malware.html
- Securelist — Kaspersky analysis referenced in reporting — https://securelist.com/
- Python Package Index (PyPI) — Security and project ecosystem context — https://pypi.org/