GhostAction słabnie, ale zagrożenie dla GitHub i łańcucha dostaw oprogramowania nadal rośnie

Wprowadzenie do problemu / definicja

GhostAction to kampania wymierzona w łańcuch dostaw oprogramowania, której celem są konta deweloperskie oraz publiczne repozytoria w GitHub. Mechanizm działania opiera się na przejęciu tożsamości programistów i dodawaniu złośliwych workflow GitHub Actions, które mogą uruchamiać się w zaufanym środowisku CI/CD.

To szczególnie groźny scenariusz, ponieważ atak nie wymaga klasycznego włamania do infrastruktury produkcyjnej. Wystarczy nadużycie legalnych procesów automatyzacji, aby uzyskać dostęp do sekretów, tokenów, poświadczeń chmurowych i innych wrażliwych danych.

W skrócie

Najnowsza fala aktywności GhostAction nie przyniosła atakującym pełnej skuteczności operacyjnej, ponieważ część złośliwych workflow nie została wykonana zgodnie z założeniami. Mimo to skala operacji pozostaje poważna, ponieważ przeciwnicy rozpropagowali dziesiątki tysięcy commitów do tysięcy publicznych repozytoriów.

atak wykorzystywał wcześniej przejęte konta deweloperów,
celem były workflow GitHub Actions oraz sekrety dostępne w pipeline’ach,
obserwowano różne warianty ładunków dostosowane do środowiska ofiary,
napastnicy nadal mogą utrzymywać dostęp do części skompromitowanych kont.

Kontekst / historia

GhostAction nie jest nowym zjawiskiem, lecz rozwinięciem wcześniej obserwowanych nadużyć związanych z GitHub Actions. W poprzednich kampaniach atakujący masowo dodawali pliki workflow zawierające kod służący do wykradania sekretów i poświadczeń z repozytoriów.

W październiku 2026 roku aktywność ponownie wzrosła. Jedna z wcześniejszych fal miała objąć około 30 tysięcy repozytoriów, a w kolejnej fazie liczba commitów i zakres operacji jeszcze się zwiększyły. Nawet jeśli część prób została ograniczona przez zabezpieczenia platformowe, kampania pokazuje wyraźny trend: platformy deweloperskie stają się celem coraz bardziej agresywnych operacji łączących atak na kod, tożsamość i zasoby chmurowe.

Analiza techniczna

Podstawą ataku jest zaufanie, jakim organizacje obdarzają workflow GitHub Actions. Po przejęciu konta dewelopera napastnik może dodać lub zmodyfikować plik workflow, który uruchomi się po zdarzeniach takich jak push, pull request lub inne akcje automatyzacyjne.

W analizowanej kampanii wykorzystywano różne warianty ładunków, dobierane w zależności od rodzaju runnera i możliwości środowiska. Oznacza to, że GhostAction nie ogranicza się wyłącznie do prostego skanowania repozytoriów, ale testuje wiele ścieżek dalszej eskalacji.

payloady przeszukujące repozytoria i wiki w poszukiwaniu sekretów oraz kluczy API,
workflow analizujące kod źródłowy i historię Git pod kątem poświadczeń,
warianty ukierunkowane na self-hosted runnery działające w środowiskach organizacji,
mechanizmy próbujące uzyskać tokeny OIDC i wykorzystać je do dostępu do środowisk chmurowych,
ładunki przypominające infostealery, maskowane jako elementy środowiska deweloperskiego.

Szczególnie niepokojący jest kierunek rozwoju kampanii. Atak nie kończy się już na kradzieży sekretów zapisanych w repozytorium. Coraz wyraźniej widać próbę przejścia z platformy kodowej do stacji roboczych deweloperów, runnerów CI/CD i federacyjnego dostępu do chmury.

W opisywanych przypadkach pojawił się również komponent stylizowany na zadanie Visual Studio Code, którego celem miała być instalacja narzędzia wykradającego poświadczenia z lokalnej maszyny. Taki wektor rozszerza powierzchnię ataku poza sam GitHub i może prowadzić do przejęcia dodatkowych sesji, tokenów oraz danych uwierzytelniających.

Z technicznego punktu widzenia część obserwowanych wariantów nie musi oznaczać całkowicie nowej klasy zagrożenia. Jednak dla obrońców najważniejsze jest to, że przeciwnik eksperymentuje z obejściem zabezpieczeń i szybko dostosowuje swoje narzędzia do warunków operacyjnych.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem kampanii GhostAction jest kompromitacja zaufanego łańcucha dostaw oprogramowania. Jeśli złośliwy workflow zostanie uruchomiony w środowisku CI/CD, skutki mogą objąć nie tylko pojedyncze repozytorium, ale również szerszą infrastrukturę organizacji.

wyciek sekretów GitHub Actions,
przejęcie personal access tokenów,
ujawnienie danych logowania obecnych w kodzie lub historii repozytorium,
kradzież tokenów służących do publikowania pakietów,
naruszenie środowisk CI/CD,
pivot do środowisk chmurowych i sieci wewnętrznych.

Istotnym problemem jest także trwałość kompromitacji. Nawet jeśli dana fala ataku była częściowo nieskuteczna, utrzymanie dostępu do przejętych kont tworzy warunki do kolejnych kampanii. Organizacje mogą błędnie uznać, że brak wykonania payloadu oznacza zakończenie incydentu, podczas gdy rzeczywiste ryzyko pozostaje aktywne.

Zagrożenie rośnie szczególnie w środowiskach korzystających z self-hosted runnerów oraz zaufania federacyjnego między GitHub a dostawcami chmury. W takich przypadkach skutki incydentu mogą wyjść daleko poza warstwę kodu i objąć zasoby produkcyjne.

Rekomendacje

Organizacje korzystające z GitHub powinny potraktować GhostAction jako sygnał ostrzegawczy do przeglądu zabezpieczeń wokół tożsamości deweloperskich, sekretów i procesów CI/CD. Obrona wymaga zarówno działań reaktywnych, jak i trwałego utwardzenia środowiska.

przejrzeć wszystkie gałęzie repozytoriów pod kątem nieautoryzowanych plików workflow,
zidentyfikować i usunąć wskaźniki kompromitacji powiązane z kampanią,
unieważnić tokeny kont, dla których istnieje podejrzenie przejęcia,
przeprowadzić rotację sekretów zapisanych w repozytoriach, historii Git, wiki i Actions Secrets,
wymusić silne MFA dla kont deweloperskich i uprzywilejowanych,
ograniczyć uprawnienia personal access tokenów zgodnie z zasadą najmniejszych uprawnień,
monitorować tworzenie i modyfikacje plików workflow w czasie rzeczywistym,
wdrożyć polityki zatwierdzania workflow i ochrony gałęzi,
przeprowadzić audyt użycia OIDC oraz relacji zaufania do ról chmurowych,
utwardzić i segmentować self-hosted runnery,
wykrywać anomalie w aktywności commitów wykonywanych przez konta użytkowników.

W warstwie detekcyjnej warto korelować logi GitHub, systemów IAM, telemetrykę endpointów deweloperskich oraz aktywność w chmurze. Szczególną uwagę należy zwrócić na nietypowe commity do wielu repozytoriów w krótkim czasie, tworzenie nowych workflow, dostęp do sekretów oraz nagłe próby pobrania tokenów federacyjnych.

Podsumowanie

GhostAction pozostaje istotnym zagrożeniem dla bezpieczeństwa łańcucha dostaw oprogramowania, nawet jeśli ostatnia fala kampanii nie przyniosła pełnego sukcesu napastnikom. Najważniejszy wniosek jest prosty: nieskuteczny payload nie oznacza, że incydent był niegroźny.

Dla zespołów bezpieczeństwa oznacza to konieczność traktowania GitHub, runnerów CI/CD, tożsamości deweloperskich i stacji roboczych jako jednego wspólnego obszaru ochrony. Tylko spójne podejście do kontroli dostępu, sekretów, pipeline’ów i integracji chmurowych może ograniczyć ryzyko podobnych kampanii w przyszłości.