Wprowadzenie do problemu / definicja
GhostAction to kampania wymierzona w ekosystem GitHub oraz procesy CI/CD, w której napastnicy przejmują konta deweloperów i dodają złośliwe pliki workflow do repozytoriów. Celem takich działań jest pozyskanie sekretów, tokenów dostępowych, poświadczeń zapisanych w kodzie oraz otwarcie drogi do dalszej kompromitacji środowisk chmurowych i infrastruktury programistycznej.
Choć ostatnia fala tej operacji została w dużej mierze ograniczona przez mechanizmy ochronne platformy, samo utrzymanie dostępu do wcześniej przejętych kont oznacza, że zagrożenie nie zostało usunięte. Z perspektywy bezpieczeństwa łańcucha dostaw to sygnał ostrzegawczy dla organizacji opierających proces wytwarzania oprogramowania na automatyzacji i zaufaniu do pipeline’ów.
W skrócie
- GhostAction wykorzystuje przejęte konta deweloperów do wstrzykiwania złośliwych workflow GitHub Actions.
- W październiku 2026 roku kampania objęła tysiące publicznych repozytoriów i dziesiątki tysięcy commitów.
- Badacze zaobserwowali kilka wariantów payloadów, w tym moduły do kradzieży poświadczeń, ataki na self-hosted runners oraz próby pozyskania tokenów OIDC.
- Mimo ograniczonej skuteczności operacyjnej ostatniej fali, skompromitowane konta nadal mogą zostać użyte w kolejnych etapach kampanii.
Kontekst / historia
GhostAction nie jest incydentem odosobnionym, lecz elementem szerszego trendu ataków na łańcuch dostaw oprogramowania. W tego typu operacjach przestępcy nie koncentrują się wyłącznie na pojedynczym systemie, ale próbują wykorzystać zaufane komponenty procesu developerskiego, aby uzyskać szerszy dostęp do organizacji i jej partnerów.
W opisywanej fali operatorzy kampanii rozsyłali złośliwe workflow podszywające się pod działania związane z bezpieczeństwem lub audytem. W kolejnych etapach rozszerzali zasięg ataku o nowe repozytoria oraz dodatkowe warianty ładunków. To pokazuje, że celem nie był jedynie jednorazowy wyciek sekretów, ale rozwijanie technik umożliwiających przejście od kompromitacji repozytorium do naruszenia runnerów, usług chmurowych i środowisk deweloperskich.
Analiza techniczna
Mechanizm ataku opiera się na nadużyciu GitHub Actions, czyli natywnego systemu automatyzacji uruchamianego w odpowiedzi na zdarzenia w repozytorium. Gdy napastnik zyska dostęp do konta z uprawnieniami do zapisu, może dodać lub zmodyfikować plik workflow w sposób wyglądający jak zwykła zmiana projektowa. To sprawia, że złośliwy kod uruchamiany jest w zaufanym kontekście procesu CI/CD.
Zaobserwowane warianty payloadów były dostosowane do typu środowiska wykonawczego. W runnerach hostowanych przez platformę workflow wyszukiwały sekrety w kodzie, historii Git, wiki i innych zasobach repozytorium. W środowiskach self-hosted zagrożenie było większe, ponieważ złośliwe zadania mogły próbować sięgać po lokalne zasoby, systemy wewnętrzne oraz elementy infrastruktury organizacji.
Szczególnie groźny był wariant ukierunkowany na tokeny GitHub OIDC wykorzystywane do federacyjnego dostępu do usług chmurowych. Jeżeli organizacja powiązała GitHub Actions z AWS za pomocą ról IAM, przejęcie takiego mechanizmu mogłoby umożliwić eskalację dostępu do środowiska chmurowego bez konieczności kradzieży klasycznych, statycznych kluczy.
Badacze opisali również payload podszywający się pod element zadania deweloperskiego i instalujący narzędzie do kradzieży poświadczeń w ekosystemie Node.js. Tego rodzaju maskowanie wskazuje, że operatorzy GhostAction eksperymentują z różnymi metodami zwiększania skuteczności oraz zacierania śladów wśród legalnych artefaktów projektowych.
Najważniejszy wniosek techniczny jest jednak taki, że ograniczenie skuteczności ostatniej fali wynikało głównie z zablokowania wykonania złośliwych workflow. Nie oznacza to pełnej neutralizacji zagrożenia. Jeśli tokeny nadal są ważne, a konta nie zostały całkowicie oczyszczone, napastnicy mogą wrócić z poprawionymi wariantami kodu.
Konsekwencje / ryzyko
Najpoważniejsze ryzyko dotyczy kompromitacji łańcucha dostaw. Przejęcie konta dewelopera lub repozytorium może doprowadzić do szeregu następstw wykraczających poza samą platformę GitHub.
- wyciek sekretów CI/CD i danych zapisanych w repozytorium,
- kradzież personal access tokens oraz tokenów publikacyjnych,
- dostęp do historii commitów, wiki i artefaktów projektowych,
- eskalacja uprawnień do środowisk chmurowych,
- kompromitacja self-hosted runners i ruch boczny w sieci organizacji,
- zainfekowanie stacji roboczych programistów,
- dalsze rozprzestrzenianie ataku pomiędzy projektami i zespołami.
Ryzyko jest szczególnie wysokie tam, gdzie organizacje korzystają z self-hosted runners. W takim modelu wykonanie workflow odbywa się w zaufanej infrastrukturze wewnętrznej, co oznacza, że skutki incydentu mogą objąć systemy build, rejestry artefaktów, usługi sieciowe, a nawet zasoby produkcyjne.
Dodatkowym problemem pozostaje trwałość kompromitacji. Raz wykradzione tokeny lub nieunieważnione sesje mogą zostać wykorzystane ponownie bez konieczności ponownego łamania zabezpieczeń. Dlatego samo wykrycie podejrzanego workflow nie wystarcza, jeśli organizacja nie przeprowadzi pełnej rotacji poświadczeń i przeglądu śladów pozostawionych przez atakującego.
Rekomendacje
Organizacje powinny traktować GhostAction jako zagrożenie klasy supply chain i reagować zarówno na poziomie operacyjnym, jak i strategicznym. W praktyce oznacza to połączenie analizy repozytoriów, twardych kontroli dostępu oraz monitoringu działań w pipeline’ach.
- przeprowadzić pełny przegląd repozytoriów pod kątem nieautoryzowanych plików workflow i podejrzanych commitów we wszystkich gałęziach,
- unieważnić tokeny powiązane ze skompromitowanymi kontami, w tym PAT, sekrety Actions i poświadczenia zapisane w kodzie lub wiki,
- wymusić zasadę najmniejszych uprawnień oraz krótszy czas życia tokenów,
- wprowadzić obowiązkowy code review dla katalogów workflow i ochronę branchy,
- monitorować nowe lub modyfikowane definicje CI/CD oraz nietypowe użycie sekretów,
- zweryfikować konfigurację OIDC i polityki zaufania ról IAM w chmurze,
- segmentować i izolować self-hosted runners od krytycznych zasobów,
- wdrożyć rejestrowanie procesów oraz mechanizmy EDR na hostach wykonawczych.
Warto również rozszerzyć detekcję o anomalie związane z masowymi commitami z pojedynczych kont, nagłymi zmianami w workflow oraz nietypowymi próbami użycia federacyjnego dostępu do usług chmurowych. W przypadku incydentów tego typu szybkość identyfikacji i pełna higiena poświadczeń mają kluczowe znaczenie.
Podsumowanie
GhostAction pokazuje, że nawet częściowo nieudana kampania może stanowić poważne zagrożenie strategiczne. Atakujący przetestowali wiele wariantów payloadów, utrzymali dostęp do części skompromitowanych kont i wyraźnie zasygnalizowali zainteresowanie nie tylko repozytoriami, ale także runnerami, środowiskami chmurowymi oraz endpointami deweloperskimi.
Dla zespołów bezpieczeństwa oznacza to konieczność traktowania GitHub Actions, tokenów dostępowych i procesów CI/CD jako kluczowego obszaru obrony. Ochrona łańcucha dostaw oprogramowania nie kończy się na repozytorium kodu — obejmuje cały ekosystem automatyzacji, tożsamości i zaufania, na którym opiera się nowoczesne wytwarzanie oprogramowania.
Źródła
- GhostAction Hacking Wave Fizzles, But Attackers Lurk on in GitHub — https://www.darkreading.com/application-security/ghostaction-hacking-wave-fizzles-attackers-github
- GitHub Actions documentation — https://docs.github.com/en/actions
- OpenID Connect in GitHub Actions — https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect
- AWS IAM roles for GitHub Actions — https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html
- GitHub: Security hardening for GitHub Actions — https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions