Badacze wykryli skoordynowany atak na łańcuch dostaw oprogramowania Ruby. Złośliwe wersje trzech pakietów pobierają dodatkowy kod, instalują backdoor i próbują uzyskać uprawnienia administratora. Malware celowo ukrywa się przed popularnymi systemami CI/CD, ponieważ jego głównym celem są komputery programistów zawierające klucze SSH, tokeny i dane dostępowe do chmury.

Czym jest kampania SleeperGem?

Między 18 a 19 lipca 2026 roku w publicznym repozytorium RubyGems.org pojawiły się złośliwe wersje trzech pakietów. Kampanię nazwano SleeperGem, ponieważ napastnicy wykorzystali między innymi konta powiązane z projektami, które przez wiele lat nie publikowały nowych wydań.

Zagrożenie jako pierwszy opisał zespół Aikido Security. Dalsza analiza przeprowadzona przez StepSecurity potwierdziła działanie loadera, pobieranie dodatkowych plików, instalowanie trwałego dostępu i próbę podniesienia uprawnień.

Złośliwe wersje to:

• git_credential_manager — 2.8.0, 2.8.1, 2.8.2 i 2.8.3,
• Dendreo — 1.1.3 i 1.1.4,
• fastlane-plugin-run_tests_firebase_testlab — 0.3.2.

Szczegółowy wykaz wersji oraz wskaźników kompromitacji został opublikowany w analizie technicznej StepSecurity z 19 lipca 2026 r..

RubyGems i pakiety gem — co to właściwie jest?

RubyGems jest systemem dystrybucji bibliotek dla języka programowania Ruby. Programista może dodać gotowy komponent do swojego projektu, zamiast tworzyć każdą funkcję od początku.

Takie biblioteki określa się jako „gems”. Mogą odpowiadać między innymi za:

• komunikację z bazą danych,
• testowanie aplikacji,
• obsługę uwierzytelniania,
• integrację z usługami chmurowymi,
• automatyzację budowania aplikacji,
• komunikację z zewnętrznymi API.

Mechanizm przyspiesza pracę, ale tworzy również zależność od kodu publikowanego przez innych autorów. Złośliwa aktualizacja biblioteki może zostać automatycznie pobrana przez wiele projektów.

Jakie pakiety zostały wykorzystane?

Fałszywy Git Credential Manager

Pakiet git_credential_manager podszywał się nazwą pod oficjalny Microsoft Git Credential Manager. Nie oznacza to, że oficjalne narzędzie Microsoftu zostało zainfekowane.

Zbieżna nazwa mogła jednak przekonać programistę, że ma do czynienia z legalnym komponentem przeznaczonym do obsługi danych uwierzytelniających Git.

Aikido zauważyło, że w ciągu około dziewięciu godzin opublikowano cztery kolejne wersje pakietu. Napastnik stopniowo modyfikował kod, wyciszał jego działanie, dodawał automatyczne uruchamianie oraz aktywował pełny łańcuch infekcji. Analiza Aikido Security opisuje zmiany pomiędzy wersjami SleeperGem.

Uśpiony Dendreo

Pakiet Dendreo nie otr

Dzisiejszy materiał dotyczy świeżo wykrytej kampanii SleeperGem. Napastnicy opublikowali złośliwe aktualizacje pakietów RubyGems, które celowo omijają środowiska CI/CD i uruchamiają się przede wszystkim na komputerach programistów.

SleeperGem atakuje programistów przez RubyGems. Złośliwe pakiety instalują trwały backdoor

Lead: Badacze wykryli skoordynowany atak na łańcuch dostaw oprogramowania w ekosystemie Ruby. Złośliwe wersje trzech pakietów pobierają dodatkowy kod, instalują ukryty proces i próbują uzyskać wyższe uprawnienia. Malware sprawdza przy tym, czy działa w systemie CI/CD — jeżeli tak, kończy pracę, aby uniknąć automatycznych analiz i dotrzeć do komputerów programistów.

Czym jest kampania SleeperGem?

Między 18 a 19 lipca 2026 roku w repozytorium RubyGems.org opublikowano złośliwe wersje trzech pakietów. Badacze Aikido Security nazwali kampanię SleeperGem.

Atak objął:

• git_credential_manager w wersjach 2.8.0–2.8.3,
• Dendreo w wersjach 1.1.3 i 1.1.4,
• fastlane-plugin-run_tests_firebase_testlab w wersji 0.3.2.

Pierwszy pakiet podszywał się nazwą pod Microsoft Git Credential Manager. Nie należy go jednak utożsamiać z oficjalnym narzędziem Microsoftu.

Pozostałe dwa pakiety były wcześniej legalnymi projektami, które przez wiele lat nie otrzymywały aktualizacji. Ich nagłe nowe wydania zawierały zależność prowadzącą do instalacji złośliwego komponentu.

Techniczny przebieg kampanii potwierdzili badacze StepSecurity, uruchamiając pakiety w kontrolowanym środowisku i rejestrując procesy, połączenia oraz modyfikacje plików. Analiza techniczna StepSecurity z 19 lipca 2026 r.

Dlaczego nazwa SleeperGem?

Nazwa kampanii nawiązuje do uśpionych kont opiekunów pakietów. Według badaczy co najmniej dwa konta związane z publikacją pakietów mogły zostać przejęte.

Jeden z projektów nie był aktualizowany od 2020 roku, a inny od 2019 roku. Po kilku latach bezczynności nagle pojawiły się ich nowe wersje — bez odpowiadających im zmian i tagów w repozytoriach kodu źródłowego.

To ważny sygnał ostrzegawczy. Aktualizacja dostępna w rejestrze pakietów nie musi pochodzić z oficjalnego repozytorium projektu. Jeżeli konto opiekuna zostanie przejęte, napastnik może opublikować zmodyfikowany plik bez umieszczania złośliwego kodu w publicznym repozytorium GitHub.

Badacze Aikido Security opisali przejęcie nieaktywnych kont jako szczególnie groźny element kampanii. Konto, które przez lata nie publikowało aktualizacji, może nie być już dokładnie monitorowane, ale nadal posiada uprawnienia do wydawania nowych wersji pakietu.

Jak działa złośliwy pakiet?

Pakiet jest jedynie programem ładującym

Główna część szkodliwego kodu nie znajduje się bezpośrednio w pakiecie. Gem pełni rolę loadera, który pobiera kolejne elementy z kontrolowanego przez napastników repozytorium Forgejo.

Wykorzystywany adres znajdował się w domenie git.disroot.org, w przestrzeni nazw utworzonej tak, aby wyglądała jak oficjalny projekt związany z ekosystemem Git.

Po uruchomieniu pakiet pobierał:

• skrypt deploy.sh,
• natywny plik wykonywalny,
• konfigurację potrzebną do uruchomienia procesu w tle.

W ruchu sieciowym ustawiano nagłówek User-Agent na wartość Git, co mogło upodobnić połączenie do zwykłej aktywności narzędzi programistycznych.

Wystarczyło załadowanie biblioteki

W przypadku wersji git_credential_manager 2.8.2 i 2.8.3 złośliwy mechanizm był uruchamiany podczas zwykłego załadowania biblioteki przez instrukcję require.

Programista nie musiał ręcznie uruchamiać dodatkowego instalatora. Aplikacja korzystająca z pakietu mogła rozpocząć łańcuch infekcji podczas normalnego startu.

Wersja 2.8.2 pobierała komponenty, ale nie uruchamiała pełnego łańcucha. Kilkanaście minut później opublikowano wersję 2.8.3, w której aktywowano wykonanie pobranego skryptu.

Tak szybkie kolejne wydania sugerują, że operatorzy testowali i poprawiali mechanizm infekcji w czasie rzeczywistym.

Malware celowo omija systemy CI/CD

Jedną z najciekawszych cech SleeperGem jest sprawdzanie około 30 zmiennych środowiskowych związanych z platformami automatyzacji, między innymi:

• GitHub Actions,
• GitLab CI,
• CircleCI,
• Jenkins,
• Travis CI,
• Vercel.

Jeżeli malware wykryje, że działa w takim środowisku, kończy pracę bez instalowania właściwego backdoora.

Dlaczego napastnicy omijają CI?

Środowiska CI/CD są często krótkotrwałe i po zakończeniu zadania zostają usunięte. Mogą również posiadać szczegółowe monitorowanie procesów, ruchu sieciowego i plików.

Komputer programisty jest dla napastnika znacznie cenniejszy, ponieważ może zawierać:

• klucze SSH,
• tokeny dostępu do GitHub lub GitLab,
• dane logowania do chmury,
• pliki .env,
• konfiguracje produkcyjne,
• hasła zapisane w przeglądarce,
• dostęp do VPN,
• lokalne kopie kodu źródłowego,
• uprawnienia do publikowania nowych wersji oprogramowania.

Celowe omijanie CI utrudnia również wykrycie podczas typowych testów. Pakiet może zachowywać się poprawnie w procesie budowania, a uruchomić złośliwy kod dopiero na laptopie programisty.

Jak SleeperGem utrzymuje się w systemie?

Na systemie Linux złośliwy skrypt umieszcza natywny plik wykonywalny w ukrytym katalogu:

~/.local/share/gcm/

Następnie uruchamia go jako proces działający w tle i tworzy dwa mechanizmy trwałości:

• usługę użytkownika systemd,
• wpis w harmonogramie cron.

Oba mechanizmy korzystają z niewinnie wyglądającej nazwy git-credential-manager. Nawet po usunięciu jednego z nich drugi może ponownie uruchomić backdoor.

Próba uzyskania uprawnień administratora

Malware sprawdza, czy użytkownik należy do grup sudo lub wheel. Jeżeli może użyć sudo bez podawania hasła, skrypt uruchamia się ponownie z uprawnieniami administratora.

W takim wariancie może umieścić kopię powłoki systemowej z ustawionym bitem SUID w lokalizacji:

/usr/local/sbin/ping6

Plik ma przypominać zwykłe narzędzie sieciowe. W rzeczywistości może umożliwiać wykonywanie poleceń z uprawnieniami roota.

Kto powinien natychmiast sprawdzić środowisko?

Analizę powinny przeprowadzić firmy oraz programiści korzystający z Ruby i narzędzia Bundler, szczególnie jeśli w dniach 18–20 lipca wykonywali aktualizację zależności.

Należy sprawdzić nie tylko bezpośrednią instalację pakietu git_credential_manager. Mógł on zostać pobrany także jako zależność innego gema.

Szczególną uwagę powinny zachować zespoły korzystające z:

• aplikacji Ruby on Rails,
• skryptów automatyzujących wdrożenia,
• wtyczek Fastlane,
• prywatnych repozytoriów kodu,
• kluczy dostępowych zapisanych na komputerach programistów,
• lokalnych danych logowania do usług chmurowych.

Jak sprawdzić pliki Gemfile.lock?

Badacze StepSecurity zaproponowali wyszukanie podatnych wersji w plikach blokady zależności:

grep -RniE 'git_credential_manager \((2\.8\.[0-3])\)|Dendreo \(1\.1\.[34]\)|run_tests_firebase_testlab \(0\.3\.2\)' --include=Gemfile.lock .

Polecenie należy uruchamiać wyłącznie w kontrolowanym środowisku i traktować jako jeden z elementów analizy. Brak wyniku nie wyklucza instalacji pakietu w globalnym środowisku Ruby lub usunięcia pliku po infekcji.

Warto dodatkowo sprawdzić:

gem list | grep -E 'git_credential_manager|Dendreo|fastlane-plugin-run_tests_firebase_testlab'

Wskaźniki możliwej kompromitacji

Administratorzy powinni poszukiwać następujących elementów:

• katalogu ~/.local/share/gcm/,
• pliku ~/.local/share/gcm/git-credential-manager,
• pliku ~/.local/share/gcm/.env,
• usługi użytkownika systemd o nazwie git-credential-manager,
• wpisu cron uruchamiającego plik z katalogu gcm,
• pliku /usr/local/sbin/ping6 z nietypowymi uprawnieniami,
• połączeń z git.disroot.org,
• procesów Ruby uruchamiających skrypt instalacyjny podczas ładowania biblioteki,
• procesu git-credential-manager uruchomionego z katalogu domowego użytkownika.

Sama komunikacja z domeną git.disroot.org nie stanowi automatycznie dowodu infekcji, ponieważ jest to publiczna i legalnie działająca instancja Forgejo. Istotne są dokładna ścieżka, czas połączenia oraz powiązane procesy.

Co zrobić po wykryciu złośliwego pakietu?

1. Odizoluj komputer

Urządzenie należy odłączyć od sieci firmowej, VPN i zasobów chmurowych. Nie powinno być dalej używane do pracy nad kodem ani do logowania do usług.

2. Zabezpiecz materiał do analizy

Przed czyszczeniem warto zachować:

• listę procesów,
• logi systemowe,
• historię połączeń,
• zawartość katalogu gema,
• pliki persistence,
• wpisy cron,
• konfigurację systemd,
• kopię podejrzanego pliku wykonywalnego.

Pozwala to ustalić, czy doszło wyłącznie do pobrania loadera, czy także do uruchomienia właściwego backdoora.

3. Usuń złośliwe wersje

Należy usunąć podatne pakiety z:

• lokalnego środowiska Ruby,
• pliku Gemfile,
• Gemfile.lock,
• wewnętrznych cache’y,
• firmowych proxy pakietów,
• obrazów kontenerów,
• przygotowanych artefaktów.

Samo usunięcie gema nie usuwa jednak procesu działającego w tle ani utworzonej trwałości.

4. Usuń mechanizmy trwałości

Trzeba sprawdzić i usunąć:

• usługę systemd git-credential-manager,
• powiązany wpis cron,
• katalog ~/.local/share/gcm/,
• podejrzany plik /usr/local/sbin/ping6.

W poważnym środowisku firmowym bezpieczniejsze może być pełne odtworzenie stacji roboczej z zaufanego obrazu niż ręczne usuwanie poszczególnych elementów.

5. Wymień wszystkie dostępne sekrety

Jeżeli złośliwa wersja została uruchomiona, należy założyć możliwość ujawnienia wszystkich danych dostępnych z komputera.

Rotacja powinna objąć:

• klucze SSH,
• tokeny GitHub i GitLab,
• klucze API,
• dane dostępowe do AWS, Azure i Google Cloud,
• hasła zapisane w przeglądarce,
• tokeny menedżerów pakietów,
• dane z plików .env,
• certyfikaty,
• konta VPN,
• tokeny publikowania pakietów.

Zmianę danych należy przeprowadzić z czystego, zaufanego urządzenia.

Jak chronić firmę przed podobnymi atakami?

Blokuj automatyczne aktualizacje zależności

Aktualizacja nie powinna być automatycznie wdrażana do środowiska produkcyjnego tylko dlatego, że ma wyższy numer wersji.

Nowe wydanie należy porównać z:

• oficjalnym repozytorium,
• tagiem wydania,
• listą zmian,
• podpisem autora,
• dotychczasową historią projektu.

Nagła aktualizacja pakietu nieaktywnego przez kilka lat powinna wymagać dodatkowej weryfikacji.

Używaj wersji przypiętych w lockfile

Pliki Gemfile.lock powinny być przechowywane w repozytorium i zatwierdzane podczas code review. Zmiana zależności musi być widoczna jako część pull requestu.

Ogranicz uprawnienia komputerów programistów

Programista nie powinien pracować na koncie z nieograniczonym sudo bez hasła. Dostęp do środowiska produkcyjnego, chmury i publikowania pakietów powinien być rozdzielony.

Kontroluj ruch wychodzący

Proces instalowania zależności nie powinien mieć nieograniczonego dostępu do dowolnych domen. Lista dozwolonych miejsc docelowych może uniemożliwić loaderowi pobranie drugiego etapu ataku.

Chroń konta opiekunów pakietów

Wydawcy bibliotek powinni stosować:

• MFA odporne na phishing,
• sprzętowe klucze bezpieczeństwa,
• oddzielne tokeny publikowania,
• ograniczenie tokenów do konkretnych pakietów,
• alerty o nowej publikacji,
• regularny przegląd aktywnych kont i kluczy,
• odbieranie uprawnień nieaktywnym opiekunom.

Fakty potwierdzone i informacje nieustalone

Potwierdzone:

• w RubyGems opublikowano złośliwe wersje trzech pakietów;
• pakiety korzystały ze wspólnej infrastruktury pobierania dodatkowego kodu;
• malware sprawdzał zmienne środowiskowe i omijał systemy CI/CD;
• na stacjach programistów instalował proces działający w tle;
• tworzył trwałość przez systemd i cron;
• zawierał mechanizm próby uzyskania uprawnień roota;
• złośliwe wydania nie miały odpowiadających im tagów w repozytoriach źródłowych.

Nieustalone publicznie:

• liczba zainfekowanych komputerów,
• liczba organizacji, które pobrały złośliwe wersje,
• tożsamość operatorów kampanii,
• sposób przejęcia kont opiekunów,
• pełna funkcjonalność natywnego backdoora,
• dokładny zakres skradzionych danych i sekretów.

Ocena: celowe omijanie CI sugeruje, że głównym celem były stacje programistów, na których napastnik mógł uzyskać długotrwały dostęp do kodu i firmowych danych uwierzytelniających. Nie ma jednak podstaw, aby bez dodatkowych dowodów przypisywać kampanię konkretnej grupie.

Podsumowanie

SleeperGem pokazuje, że bezpieczeństwo aplikacji nie kończy się na analizie własnego kodu. Legalna biblioteka może stać się nośnikiem złośliwego oprogramowania po przejęciu konta jej opiekuna.

Firmy powinny natychmiast sprawdzić wskazane wersje pakietów, stacje programistów i logi sieciowe. Jeżeli złośliwy gem został uruchomiony, samo jego odinstalowanie nie wystarczy — urządzenie i wszystkie dostępne z niego dane uwierzytelniające należy potraktować jako potencjalnie przejęte.