Wprowadzenie do problemu / definicja
Bezpieczeństwo nowoczesnego łańcucha dostaw oprogramowania nie kończy się na jakości kodu źródłowego. Równie ważna jest ochrona procesów CI/CD, sekretów wykorzystywanych podczas budowania i wdrażania aplikacji oraz tożsamości maszynowych powiązanych z platformami deweloperskimi. Opisana kampania pokazuje, że przejęcie kont GitHub może stać się punktem wejścia do znacznie szerszego ataku obejmującego repozytoria, workflow GitHub Actions i środowiska chmurowe.
Głównym celem napastników była kradzież tokenów, kluczy i innych danych uwierzytelniających, które mogą posłużyć do dalszej eskalacji uprawnień, przejęcia infrastruktury oraz utrwalenia dostępu w systemach ofiary.
W skrócie
- Atakujący wykorzystali 4 837 przejętych kont GitHub.
- Kampania objęła sondowanie dostępu zapisu do 61 764 repozytoriów.
- Napastnicy otwierali złośliwe pull requesty podszywające się pod audyt zależności.
- W przypadku odpowiednich uprawnień modyfikowali workflow GitHub Actions lub osadzali mechanizmy wykradające sekrety.
- Potwierdzono kradzież danych uwierzytelniających z co najmniej 1 835 celów.
Kontekst / historia
Ataki wymierzone w platformy deweloperskie i procesy budowania oprogramowania nie są nowością, ale ich skala i poziom automatyzacji stale rosną. Cyberprzestępcy coraz częściej skupiają się na kompromitacji środowisk CI/CD, rejestrów pakietów i mechanizmów federacji tożsamości, ponieważ pojedynczy ujawniony sekret może otworzyć drogę do produkcji, chmury lub narzędzi wydawniczych.
W analizowanym przypadku kampania rozpoczęła się 10 listopada 2026 roku około 12:45 UTC. Atakujący posłużyli się wcześniej skradzionymi danymi logowania do GitHub i masowo sprawdzali, czy przejęte konta mają możliwość wprowadzania zmian w repozytoriach. Charakterystycznym elementem operacji były pull requesty wyglądające jak rutynowe notatki z audytu zależności, co zwiększało szansę na przeoczenie zagrożenia przez właścicieli projektów.
Analiza techniczna
Mechanizm działania był wieloetapowy i nastawiony na szybkie, zautomatyzowane wykorzystanie uprawnień. Najpierw przejęte konta służyły do weryfikacji, czy mają prawo zapisu do repozytorium albo wpływ na workflow. Następnie napastnicy wstrzykiwali złośliwe elementy do procesu CI/CD na kilka sposobów: przez modyfikację istniejącego workflow GitHub Actions, dodanie nowego workflow w krótkotrwałej gałęzi lub osadzenie hooka instalacyjnego npm.
Ładunek obejmował skrypt powłoki zaprojektowany do zebrania jak najszerszego zestawu sekretów dostępnych w kontekście uruchomienia workflow. Interesowały go zarówno tokeny samej platformy, jak i poświadczenia do usług zewnętrznych oraz pliki zawierające dane dostępowe.
- tokeny GitHub Actions, zmienne i sekrety workflow,
- tokeny OIDC oraz tokeny runtime,
- poświadczenia do AWS, Microsoft Azure i Google Cloud,
- dane dostępowe do Git, SSH, GPG, Docker, Kubernetes, npm, PyPI, Vault i Terraform,
- sekrety przechowywane w zmiennych środowiskowych, plikach .env, kluczach prywatnych, keystore’ach, historii poleceń i artefaktach workflow,
- dane związane z narzędziami AI i lokalnym środowiskiem deweloperskim.
Szczególnie groźny był aspekt wykorzystania tokenów OIDC GitHub do uzyskania tymczasowych sesji w chmurze. Oznacza to, że kompromitacja pipeline’u mogła prowadzić nie tylko do kradzieży sekretów aplikacyjnych, ale również do przejścia z warstwy kodu bezpośrednio do zasobów chmurowych. W praktyce dawało to możliwość dalszej eskalacji uprawnień, przejmowania dodatkowych ról i generowania bardziej trwałych poświadczeń.
Wykradzione dane były kompresowane do archiwów i przesyłane metodą HTTP POST do infrastruktury kontrolowanej przez atakujących. Na końcowym etapie przestępcy usuwali ślady operacji, cofając zmiany, kasując uruchomienia workflow i czyszcząc logi. Taki model działania znacząco utrudnia detekcję oraz późniejszą analizę incydentu.
Dodatkowym skutkiem kampanii było przedostanie się złośliwego kodu do wybranych pakietów publikowanych automatycznie. To pokazuje, że atak nastawiony początkowo na kradzież sekretów CI/CD może szybko przerodzić się w pełnowymiarowy incydent supply chain wpływający na odbiorców końcowych pobierających skażone artefakty.
Konsekwencje / ryzyko
Ryzyko związane z tego typu incydentem jest bardzo wysokie, ponieważ obejmuje jednocześnie konta deweloperskie, systemy automatyzacji oraz infrastrukturę chmurową. Procesy CI/CD z natury posiadają uprzywilejowany dostęp do sekretów, środowisk build i mechanizmów publikacji, dlatego ich kompromitacja może mieć daleko idące skutki operacyjne i biznesowe.
- utrata poufnych sekretów i kluczy API,
- nieautoryzowany dostęp do środowisk AWS, Azure i GCP,
- modyfikacja relacji zaufania i polityk IAM,
- utrzymanie dostępu przez wygenerowanie długoterminowych poświadczeń,
- skażenie pipeline’ów oraz artefaktów publikowanych do rejestrów pakietów,
- utrudnione dochodzenie z powodu kasowania logów i szybkiego wycofywania zmian.
Szczególnie niepokojące jest to, że wiele złośliwych pull requestów mogło przez pewien czas pozostać otwartych, co sugeruje ograniczoną widoczność takich działań po stronie właścicieli repozytoriów. W praktyce część organizacji mogła nie zauważyć ani etapu rozpoznania, ani samego wykonania złośliwego workflow.
Rekomendacje
Organizacje korzystające z GitHub i GitHub Actions powinny potraktować ten incydent jako sygnał do natychmiastowego przeglądu zabezpieczeń w pipeline’ach oraz relacjach zaufania do chmury. Kluczowe jest założenie, że każdy workflow uruchomiony z nieautoryzowanej zmiany mógł doprowadzić do pełnej kompromitacji dostępnych sekretów.
- zweryfikować historię pull requestów, gałęzi i workflow pod kątem nietypowych zmian oraz krótkotrwałych branchy,
- sprawdzić anomalie w logach i luki w numeracji uruchomień workflow,
- przyjąć, że sekrety dostępne dla podejrzanych workflow są skompromitowane, i przeprowadzić ich rotację,
- przejrzeć relacje zaufania OIDC między GitHub a dostawcami chmury,
- ograniczyć uprawnienia tokenów GitHub Actions, kont serwisowych i ról chmurowych do absolutnego minimum,
- zablokować automatyczną publikację pakietów bez dodatkowej walidacji i zatwierdzenia,
- wymusić silne uwierzytelnianie wieloskładnikowe dla kont deweloperskich,
- wdrożyć monitoring nieautoryzowanych modyfikacji workflow oraz nietypowych połączeń wychodzących z runnerów,
- oddzielić środowiska build, release i production,
- przeanalizować opublikowane zależności pod kątem nieoczekiwanych wersji i anomalii wydawniczych.
W organizacjach o podwyższonym profilu ryzyka warto dodatkowo rozważyć czasowe ograniczenie automatycznej publikacji, obowiązkowy przegląd zmian w plikach workflow oraz stosowanie podpisywania artefaktów i polityk dopuszczających wyłącznie zaufane buildy.
Podsumowanie
Kampania „wfx-loot” pokazuje, że przejęcie kont GitHub może być początkiem ataku wykraczającego daleko poza samo repozytorium. Połączenie kompromitacji kont, nadużycia workflow CI/CD i wykorzystania federacji tożsamości tworzy bardzo niebezpieczny scenariusz, w którym napastnik może szybko przejść od kodu źródłowego do zasobów chmurowych i procesów publikacji.
Dla zespołów bezpieczeństwa i DevSecOps oznacza to konieczność ścisłej kontroli workflow, tokenów, sekretów i relacji zaufania z chmurą. W każdym przypadku potwierdzonego wykonania złośliwego workflow należy działać tak, jakby wszystkie dostępne poświadczenia zostały już ujawnione.