Złośliwe pakiety PyPI przejmują serwery botów Telegrama

Wprowadzenie do problemu / definicja

Ekosystem open source od lat pozostaje jednym z kluczowych obszarów ryzyka w łańcuchu dostaw oprogramowania. Najnowsza kampania wymierzona w programistów Pythona pokazuje, że nawet pozornie wiarygodne forki znanych bibliotek mogą zawierać ukryte mechanizmy zdalnego dostępu. W opisywanym przypadku celem stały się środowiska uruchamiające boty Telegrama, a wektorem ataku były złośliwe pakiety opublikowane w repozytorium PyPI.

W skrócie

Badacze opisali kampanię, w której atakujący publikowali trojanizowane forki biblioteki Pyrogram, używanej do tworzenia klientów i botów Telegrama w Pythonie. Złośliwy kod był ukryty w dodatkowym module i aktywował się podczas importu biblioteki lub uruchomienia bota. Po infekcji napastnik mógł wykonywać kod Python, uruchamiać polecenia powłoki, odczytywać pliki z serwera oraz wykradać sekrety i dane dostępne dla zainfekowanej aplikacji.

• Atak był ukierunkowany na boty Telegrama działające w środowiskach produkcyjnych.
• Złośliwe pakiety podszywały się pod techniczne warianty znanej biblioteki.
• Backdoor umożliwiał zdalne wykonywanie poleceń i eksfiltrację danych.

Kontekst / historia

Kampania była aktywna co najmniej od listopada 2025 roku do czerwca 2026 roku. W tym czasie na PyPI opublikowano wiele pakietów podszywających się pod rozwidlenia popularnego projektu Pyrogram. Choć sam Pyrogram nie jest aktywnie rozwijany od kwietnia 2023 roku, nadal pozostaje szeroko używany w projektach integrujących się z Telegramem, co czyni go atrakcyjną przynętą dla cyberprzestępców.

W analizowanej operacji wykorzystano nazwy pakietów wyglądające jak alternatywne lub zmodyfikowane wersje legalnej biblioteki. Tego rodzaju zabieg jest typowy dla ataków na software supply chain. Zamiast kompromitować oryginalny projekt, napastnik publikuje własny pakiet o przekonującej nazwie, licząc na błąd developera, automatyczne pobranie zależności lub niedostateczną kontrolę w pipeline CI/CD.

Analiza techniczna

Technicznie atak opierał się na dołączeniu backdoora do forka legalnej biblioteki. Pakiety zawierały oryginalny kod projektu, ale dodatkowo wprowadzano ukryty komponent w module pomocniczym. Dzięki temu większość funkcjonalności działała zgodnie z oczekiwaniami, a złośliwa logika uruchamiała się dopiero podczas pracy aplikacji.

Backdoor rejestrował ukryte handlery komend Telegrama. W praktyce operator kampanii mógł komunikować się z przejętym botem poprzez specjalne polecenia i odbierać odpowiedzi bez potrzeby korzystania z osobnej infrastruktury command-and-control. To szczególnie groźne, ponieważ ruch sterujący może wyglądać jak zwykła aktywność samego bota.

Mechanizm zapewniał atakującemu co najmniej dwa kluczowe zestawy możliwości:

• wykonywanie dowolnego kodu Python w kontekście procesu aplikacji,
• wykonywanie poleceń systemowych przez powłokę.

W praktyce oznacza to pełne przejęcie uprawnień procesu uruchamiającego bota. Jeżeli aplikacja miała dostęp do zmiennych środowiskowych, tokenów, kluczy API, plików konfiguracyjnych, baz danych, lokalnych wolumenów lub sekretów chmurowych, atakujący mógł je odczytać i wyeksfiltrować. Wyniki poleceń były zwracane przez wiadomości Telegrama, a większe odpowiedzi mogły być przesyłane jako załączniki.

Istotnym elementem kampanii był również mechanizm selekcji ofiar. Badacze zauważyli, że backdoor aktywował się wyłącznie dla kont botów Telegrama, a nie dla wszystkich klientów. Wskazuje to na precyzyjne ukierunkowanie na środowiska serwerowe i produkcyjne, gdzie boty są często zintegrowane z webhookami, bazami danych, kolejkami zadań i usługami chmurowymi.

Konsekwencje / ryzyko

Ryzyko związane z tą kampanią należy ocenić jako wysokie, ponieważ kompromitacja może objąć nie tylko samą aplikację, ale całe środowisko, w którym działa bot. W najgorszym scenariuszu złośliwy pakiet umożliwia przejęcie sekretów, dostęp do danych operacyjnych i dalszy ruch boczny w infrastrukturze.

• kradzież tokenów botów Telegrama,
• odczyt plików konfiguracyjnych i sekretów z serwera,
• dostęp do sesji, kontaktów i wiadomości,
• pobranie danych z lokalnych lub podłączonych baz,
• ruch boczny w infrastrukturze,
• instalację dodatkowych mechanizmów trwałości.

Szczególnie zagrożone są organizacje wykorzystujące boty do automatyzacji procesów operacyjnych, integracji z helpdeskiem, notyfikacji bezpieczeństwa, obsługi klientów lub orkiestracji zadań administracyjnych. W takich wdrożeniach bot często działa z szerokimi uprawnieniami i ma dostęp do danych, które mogą posłużyć do dalszej eskalacji dostępu.

Rekomendacje

Zespoły deweloperskie i bezpieczeństwa powinny potraktować ten incydent jako kolejny sygnał ostrzegawczy dotyczący ryzyk związanych z zależnościami open source. Reakcja nie powinna ograniczać się do odinstalowania podejrzanego pakietu, lecz obejmować pełne działania incident response.

Najważniejsze działania operacyjne obejmują:

• natychmiastową weryfikację, czy w środowiskach deweloperskich, testowych i produkcyjnych nie zainstalowano podejrzanych pakietów,
• usunięcie złośliwych bibliotek ze wszystkich hostów, obrazów kontenerów i pipeline’ów CI/CD,
• rotację wszystkich sekretów dostępnych dla aplikacji, w tym tokenów botów, kluczy API, haseł i poświadczeń chmurowych,
• analizę logów procesów, audytów systemowych oraz historii wdrożeń pod kątem nietypowych poleceń i odczytów plików,
• odtworzenie zaufanego środowiska uruchomieniowego zamiast polegania wyłącznie na usunięciu biblioteki.

W ramach prewencji warto wdrożyć także długofalowe kontrole bezpieczeństwa:

• ścisłe pinowanie wersji i wewnętrzne mirrorowanie zatwierdzonych pakietów,
• skanowanie zależności pod kątem malware, typosquattingu i podejrzanych forków,
• ograniczanie uprawnień kont serwisowych oraz procesów uruchamiających boty,
• przechowywanie sekretów w dedykowanych menedżerach zamiast w zmiennych środowiskowych,
• segmentację środowisk botów od systemów krytycznych,
• monitorowanie anomalii w zachowaniu procesów Pythona i komunikacji zewnętrznej.

Podsumowanie

Incydent z trojanizowanymi forkami Pyrogram na PyPI to kolejny przykład dojrzałego ataku na łańcuch dostaw oprogramowania, ukierunkowanego na realne środowiska produkcyjne. Zamiast masowej infekcji napastnik postawił na precyzyjne uderzenie w boty Telegrama, które często działają z szerokimi uprawnieniami i mają dostęp do cennych sekretów. Dla zespołów bezpieczeństwa i DevSecOps jest to wyraźny sygnał, że kontrola pochodzenia oraz zachowania zależności open source musi być traktowana jako podstawowy element higieny bezpieczeństwa.

Źródła

1. BleepingComputer – Malicious PyPI packages give hackers control of Telegram bot servers
   https://www.bleepingcomputer.com/news/security/malicious-pypi-packages-give-hackers-control-of-telegram-bot-servers/
2. PyPI – Pyrogram project page
   https://pypi.org/project/Pyrogram/
3. Checkmarx – Malicious Package Protection
   https://checkmarx.com/product/malicious-packages/