Gheist wykorzystuje skradzione tokeny GitHub do kradzieży sekretów chmurowych

securitybeztabu.pl 21 godzin temu

Wprowadzenie do problemu / definicja

Gheist to aktywna kampania wymierzona w łańcuch dostaw oprogramowania, która bazuje na przejętych tokenach GitHub i nadużyciu mechanizmów GitHub Actions. Celem atakujących jest pozyskanie sekretów, poświadczeń oraz danych konfiguracyjnych przechowywanych w repozytoriach i procesach CI/CD.

To zagrożenie jest szczególnie istotne dla organizacji rozwijających oprogramowanie w modelu chmurowym, ponieważ kompromitacja pojedynczego tokenu deweloperskiego może otworzyć drogę nie tylko do kodu źródłowego, ale również do kluczy API, danych dostępowań do chmury i elementów infrastruktury wdrożeniowej.

W skrócie

Kampania objęła ponad 850 skompromitowanych kont.
W repozytoriach pozostawiono ponad 13,5 tys. złośliwych gałęzi.
Napastnicy tworzyli branche o wzorcu ci-sync-* i dodawali workflow sync-check.
Sekrety były eksfiltrowane przez logi GitHub Actions oraz pobierane przez API platformy.
Atak szczególnie groźny okazał się dla prywatnych repozytoriów i środowisk enterprise.

Kontekst / historia

Aktywność Gheist została zaobserwowana 15 września 2026 roku i pozostawała rozwijającą się kampanią także pod koniec października 2026 roku. Według ustaleń badaczy źródłem wykorzystywanych tokenów były przede wszystkim logi z malware typu infostealer oraz poświadczenia ujawnione wcześniej w innych incydentach supply chain.

Szerszy kontekst tej operacji wpisuje się w rosnący trend ataków na tożsamości deweloperskie. W praktyce token GitHub z szerokimi uprawnieniami może dać dostęp do kodu, sekretów aplikacyjnych, integracji CI/CD oraz zasobów chmurowych powiązanych z procesem budowania i wdrażania oprogramowania.

Analiza techniczna

Mechanizm działania kampanii jest relatywnie prosty, ale bardzo skuteczny. Po przejęciu tokenu GitHub napastnik tworzy nową gałąź o nazwie rozpoczynającej się od ci-sync-, a następnie dodaje plik .github/workflows/sync-check.yml. Zmiana bywa opisywana komunikatem commita ci: sync config, a sam commit jest podpisywany jako właściciel skompromitowanego tokenu, co utrudnia szybką identyfikację anomalii.

Złośliwy workflow uruchamia się po zdarzeniu push i próbuje wypisać do logów zmienne środowiskowe oraz sekrety dostępne w repozytorium. Kluczową rolę odgrywa tu kodowanie danych w Base32, które pozwala ominąć część mechanizmów maskowania sekretów skoncentrowanych na wykrywaniu wartości w postaci jawnej.

Następnie atakujący pobierają logi wykonania przez API GitHub i usuwają ślady aktywności w krótkim czasie. To istotny element tej techniki: eksfiltracja nie wymaga kontaktu z zewnętrznym serwerem dowodzenia, ponieważ cały transfer danych odbywa się przy użyciu legalnych funkcji platformy.

W bardziej zaawansowanych wariantach zaobserwowano także próby wykorzystania self-hosted runnerów. Złośliwy kod wyszukiwał między innymi dodatkowe tokeny, pliki .env, klucze prywatne, stan Terraform, historię powłoki, poświadczenia runnerów oraz metadane chmurowe. Oznacza to możliwość rozszerzenia ataku z poziomu CI/CD na hosta, kontenery i usługi chmurowe.

W środowiskach enterprise badacze odnotowali również działania obejmujące klonowanie prywatnych repozytoriów, osadzanie złośliwego workflow oraz późniejszą enumerację usług takich jak menedżery sekretów w chmurze. To pokazuje, iż Gheist może stanowić etap wstępny do dalszej, znacznie głębszej kompromitacji środowiska.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem kampanii jest utrata sekretów używanych przez repozytoria, organizacje i pipeline’y wdrożeniowe. W praktyce mogą to być tokeny API, klucze dostępu do usług chmurowych, dane logowania do rejestrów kontenerów, poświadczenia baz danych oraz inne informacje pozwalające na dalszy ruch boczny.

Najwyższe ryzyko dotyczy organizacji, które:

korzystają z długowiecznych personal access tokens,
nie ograniczają uprawnień tokenów do minimum,
przechowują sekrety produkcyjne w GitHub Actions bez dodatkowych mechanizmów zatwierdzania,
używają self-hosted runnerów z szerokim dostępem do hosta lub zasobów chmurowych,
nie korelują telemetrii GitHub, CI/CD i logów chmurowych.

Konsekwencje mogą obejmować przejęcie środowisk chmurowych, nieautoryzowane wdrożenia, wyciek kodu źródłowego, utratę własności intelektualnej oraz kolejne ataki na łańcuch dostaw. Samo usunięcie złośliwego workflow nie wystarcza, o ile sekrety zostały już zapisane w logach i pobrane przez przeciwnika.

Rekomendacje

W obszarze detekcji zespoły bezpieczeństwa powinny monitorować zdarzenia charakterystyczne dla tej kampanii.

Nowe branche pasujące do wzorca ci-sync-[0-9a-z]{6}.
Commity z komunikatem ci: sync config.
Pojawienie się pliku .github/workflows/sync-check.yml.
Workflow uruchamiane na gałęziach ci-sync-* i gwałtownie usuwane po zakończeniu.
Nietypową aktywność powiązaną z API oraz nieautoryzowane użycie self-hosted runnerów.

W odpowiedzi na incydent należy działać natychmiast.

Unieważnić tokeny, które wykonywały podejrzane operacje.
Obrócić wszystkie sekrety dostępne dla zaatakowanych repozytoriów.
Sprawdzić urządzenia właścicieli kont pod kątem infekcji infostealerem.
Potraktować self-hosted runner jako potencjalnie skompromitowany host.
Zweryfikować logi chmurowe pod kątem nadużyć poświadczeń ujawnionych przez GitHub Actions.

W zakresie prewencji warto wdrożyć bardziej restrykcyjny model bezpieczeństwa dla tożsamości deweloperskich i automatyzacji CI/CD.

Zastąpić długowieczne tokeny krótkotrwałymi tokenami granularnymi lub aplikacjami GitHub.
Ograniczyć zakres uprawnień do absolutnego minimum.
Wymusić dodatkowe zatwierdzenia dla środowisk przechowujących sekrety produkcyjne.
Zawęzić polityki zaufania OIDC do chronionych branchy i środowisk.
Uruchamiać self-hosted runnery jako zasoby efemeryczne.
Odcinać runnery od niepotrzebnego dostępu do Dockera i metadanych instancji.
Prowadzić pełną inwentaryzację tokenów, sekretów i procesów automatyzacji.

Podsumowanie

Gheist potwierdza, iż przejęty token GitHub może stać się skutecznym punktem wejścia do znacznie szerszego środowiska organizacyjnego. Siła tej kampanii wynika z wykorzystania natywnych mechanizmów GitHub Actions i API, co ogranicza potrzebę używania zewnętrznej infrastruktury i utrudnia wykrycie incydentu tradycyjnymi metodami.

Dla zespołów bezpieczeństwa to wyraźny sygnał, iż tożsamości deweloperskie, workflow CI/CD oraz sekrety repozytoryjne należy traktować jako krytyczny element powierzchni ataku. Szczególnej ochrony wymagają prywatne repozytoria, środowiska enterprise oraz runnerzy self-hosted.