Wprowadzenie do problemu / definicja
GhostAction to kampania ataków typu supply chain wymierzona w ekosystem deweloperski GitHub. Jej celem jest przejęcie legalnych kont maintainerów, a następnie wstrzyknięcie złośliwych workflow GitHub Actions do repozytoriów, aby wykradać sekrety z procesów CI/CD, tokeny dostępowe, poświadczenia chmurowe oraz klucze API.
Z perspektywy bezpieczeństwa to szczególnie groźny scenariusz, ponieważ atakujący wykorzystują zaufane konta i legalne mechanizmy automatyzacji. Dzięki temu szkodliwe zmiany mogą wyglądać jak zwykłe działania administracyjne lub operacyjne związane z utrzymaniem projektu.
W skrócie
Najnowsza fala aktywności GhostAction objęła ponad 30 tysięcy repozytoriów należących do około 3 tysięcy użytkowników i organizacji. Według ujawnionych ustaleń skutkiem kampanii było skompromitowanie około 1900 kont GitHub.
Atakujący próbowali pozyskiwać sekrety z publicznych repozytoriów poprzez złośliwe workflow uruchamiane w pipeline’ach automatyzacji. Część kolejnych prób została zablokowana przez mechanizmy platformy, które zaczęły uniemożliwiać wykonanie niektórych szkodliwych zadań.
Kontekst / historia
GhostAction nie jest nowym zjawiskiem. Kampania była już wcześniej wiązana z atakami na infrastrukturę deweloperską i była obserwowana w 2025 roku. Jej model operacyjny opiera się na przejęciu zaufanych kont programistów lub opiekunów projektów, a następnie wykorzystaniu ich uprawnień do modyfikacji repozytoriów.
W praktyce pozwala to obejść część klasycznych mechanizmów ochronnych, ponieważ złośliwe zmiany są wprowadzane z poziomu legalnego konta mającego prawo zapisu. W analizowanej fali ataków widać wyraźną eskalację skali oraz bardziej iteracyjny rozwój ładunku, co sugeruje aktywne testowanie skuteczności technik eksfiltracji i dostosowywanie działań do metod detekcji.
Analiza techniczna
Mechanizm GhostAction koncentruje się na nadużyciu GitHub Actions. Po uzyskaniu dostępu do konta napastnicy dodają do repozytorium plik workflow podszywający się pod legalne zadanie bezpieczeństwa, skanowania lub audytu. Nazwy takich plików są zwykle dobierane tak, aby nie wzbudzać podejrzeń i wyglądały jak standardowe elementy procesu DevSecOps.
Źródłem początkowego dostępu są najczęściej skradzione tokeny Personal Access Token, poświadczenia pochodzące z logów infostealerów lub inne wykradzione dane uwierzytelniające. Po przejęciu konta z uprawnieniami do zapisu atakujący mogą uruchomić workflow, który przeszukuje środowisko CI, historię repozytorium oraz dostępne sekrety przekazywane do jobów.
Istotnym elementem tej kampanii jest rozwijanie funkcji analizy historii Git. Złośliwy kod został rozszerzony o wyrażenia regularne identyfikujące różne klasy sekretów, w tym identyfikatory kluczy AWS, tokeny platform deweloperskich, dane dostępowe do rejestrów pakietów oraz klucze usług AI.
W kolejnych wariantach payloadu dodano także pobieranie fragmentów kontekstu wokół wykrytych wpisów. Taka technika zwiększa szansę na poprawne powiązanie identyfikatorów z odpowiadającymi im sekretami, co może ułatwiać dalsze wykorzystanie przejętych danych, zwłaszcza w środowiskach chmurowych.
Z punktu widzenia obrońcy szczególnie niebezpieczne jest to, że atak nie ogranicza się do pojedynczego wycieku z jednego projektu. Kompromitacja maintainera umożliwia seryjne modyfikowanie wielu repozytoriów i masowe zbieranie sekretów z uruchamianych pipeline’ów. To klasyczny przykład kompromitacji łańcucha dostaw o dużym promieniu rażenia.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem GhostAction jest przejęcie sekretów wykorzystywanych przez systemy CI/CD. Mogą to być klucze chmurowe, tokeny do publikacji pakietów, dane dostępowe do rejestrów kontenerów, sekrety integracji oraz klucze API usług zewnętrznych. Taki zestaw informacji otwiera drogę do dalszej eskalacji ataku poza samo repozytorium źródłowe.
- nieautoryzowany dostęp do środowisk chmurowych,
- przejęcie procesu publikacji artefaktów i pakietów,
- podszywanie się pod legalne oprogramowanie lub maintainerów,
- lateral movement do innych systemów developerskich,
- utrzymanie dostępu dzięki niewymienionym sekretom,
- wtórne kampanie wymierzone w użytkowników zależnych projektów.
Szczególnie niepokojące jest to, że część ofiar była kompromitowana również we wcześniejszych falach. Może to wskazywać, że organizacje nie zawsze przeprowadzają pełną rotację wszystkich wykradzionych sekretów po incydencie, co pozwala napastnikom wracać do tych samych środowisk i ponownie je wykorzystywać.
Rekomendacje
Organizacje rozwijające oprogramowanie na GitHub powinny traktować tego typu kampanię jako incydent wysokiego ryzyka dla łańcucha dostaw. Minimalny zestaw działań obronnych powinien obejmować:
- natychmiastową rotację wszystkich sekretów używanych w GitHub Actions, szczególnie tokenów chmurowych, PAT, kluczy do rejestrów pakietów i kluczy API,
- przegląd ostatnich commitów i workflow pod kątem nieautoryzowanych plików YAML, zwłaszcza tych podszywających się pod audyty bezpieczeństwa,
- wymuszenie silnego uwierzytelniania wieloskładnikowego dla maintainerów oraz ograniczenie użycia długowiecznych tokenów,
- redukcję uprawnień dla GitHub Actions zgodnie z zasadą najmniejszych przywilejów,
- włączenie monitoringu zmian w katalogach
.github/workflowsoraz alertowania o nowych lub zmodyfikowanych definicjach pipeline’ów, - skanowanie historii Git i aktualnego stanu repozytoriów pod kątem sekretów, a następnie usuwanie ich z kodu i historii wraz z rotacją,
- audyt kont uprzywilejowanych oraz weryfikację, czy poświadczenia programistów nie pojawiają się w znanych wyciekach lub logach malware typu infostealer,
- ograniczenie zaufania do automatyzacji uruchamianej na podstawie zmian wprowadzanych przez konta maintainerów bez dodatkowej walidacji.
Dodatkowo warto wdrożyć podejście oparte na krótkotrwałych poświadczeniach i federacji tożsamości dla pipeline’ów. Dzięki temu nawet w razie przejęcia sekretów ich wartość operacyjna dla napastników może zostać znacząco ograniczona.
Podsumowanie
GhostAction pokazuje, że GitHub Actions i procesy CI/CD pozostają atrakcyjnym celem dla operatorów ataków supply chain. Skala najnowszej fali, obejmująca tysiące kont i dziesiątki tysięcy repozytoriów, potwierdza, że kompromitacja pojedynczych maintainerów może prowadzić do bardzo szerokiego efektu kaskadowego.
Kluczowym problemem nie jest wyłącznie samo przejęcie konta, lecz możliwość uruchomienia zaufanej automatyzacji mającej dostęp do wrażliwych sekretów i infrastruktury publikacyjnej. Dla zespołów bezpieczeństwa oznacza to konieczność stałego monitorowania workflow, rygorystycznej rotacji sekretów oraz twardego ograniczania uprawnień w całym łańcuchu dostarczania oprogramowania.