Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Platformy deweloperskie od dawna stanowią atrakcyjny cel dla cyberprzestępców, ale coraz częściej zagrożenie nie wynika z głośnych exploitów czy masowych włamań. W opisywanym scenariuszu napastnicy wykorzystują publicznie dostępne funkcje GitHuba, przejęte tokeny dostępu oraz długo nieaktywne konta użytkowników do prowadzenia cichego rekonesansu przeciwko organizacjom.
Taka aktywność pozwala systematycznie zbierać informacje o strukturach firmowych, repozytoriach, relacjach między kontami deweloperów i potencjalnych ścieżkach dalszej kompromitacji. Problem polega na tym, że pojedyncze działania często wyglądają jak zwykłe, legalne użycie API.
W skrócie
- Atakujący wykorzystują ponad 50 długo nieaktywnych kont GitHub do ukrywania działań rozpoznawczych.
- Kampanie obejmują automatyczne enumerowanie publicznych zasobów przez GitHub API.
- W części przypadków użyto ujawnionych lub przejętych tokenów PAT i OAuth należących do legalnych użytkowników.
- Zaobserwowano także incydenty wykraczające poza rekonesans, w tym sklonowanie prywatnego repozytorium jednej z organizacji.
- Charakterystyczne są konta utworzone kilka lat wcześniej, które pozostawały nieaktywne aż do momentu użycia operacyjnego.
Kontekst / historia
GitHub jest dziś jednym z najważniejszych elementów łańcucha dostaw oprogramowania. Publiczne repozytoria, profile użytkowników, listy obserwowanych projektów, aktywność wokół Gistów czy członkostwa w organizacjach mogą dostarczać szczegółowych danych o tym, jak zbudowane są zespoły i projekty.
Dla napastników takie informacje mają dużą wartość wywiadowczą. Mogą posłużyć do przygotowania ukierunkowanego phishingu, przejęć kont, ataków na pipeline CI/CD albo prób kompromitacji bibliotek i zależności używanych w projektach. Nowością nie jest więc samo wykorzystanie GitHub API, lecz sposób maskowania aktywności poprzez używanie „dojrzałych” kont, które z perspektywy telemetrii platformy wyglądają bardziej wiarygodnie niż świeżo założone profile.
Analiza techniczna
Zaobserwowane kampanie bazują na zautomatyzowanych narzędziach skanujących, które wysyłają serie zapytań do GitHub API. Celem jest stopniowe budowanie mapy organizacji: publicznych repozytoriów, kont użytkowników, relacji followers i following, członkostw organizacyjnych, aktywności związanej z Gistami, oznaczeń gwiazdką oraz danych dostępnych przez GraphQL.
Technicznie każde pojedyncze żądanie może wyglądać niegroźnie. Trafia do publicznego endpointu, zwraca poprawną odpowiedź i nie musi od razu wzbudzać alarmu. Istotna staje się jednak korelacja: wiele kont wykonuje podobne zapytania wobec różnych organizacji, a aktywność utrzymywana jest przez dłuższy czas.
Kluczowym elementem operacji są także przejęte lub nieumyślnie ujawnione tokeny PAT oraz tokeny OAuth należące do prawdziwych użytkowników. Dzięki nim ruch zyskuje większą wiarygodność, a napastnik może uzyskać dostęp nie tylko do danych publicznych, lecz także do zasobów prywatnych, jeśli uprawnienia tokenu są zbyt szerokie. W opisywanych przypadkach potwierdzono sytuacje, w których skutkiem było sklonowanie prywatnego repozytorium.
Z perspektywy obrony jest to szczególnie trudny scenariusz, ponieważ atakujący nie muszą wykorzystywać podatności typu zero-day. Zamiast tego łączą legalne funkcje platformy, publiczny rekonesans, kradzież poświadczeń i długoterminowe przygotowanie infrastruktury kont.
Konsekwencje / ryzyko
Ryzyko dla organizacji jest wielowarstwowe. Szczegółowe mapowanie ekosystemu GitHub pozwala lepiej dobrać kolejne etapy ataku, w tym kampanie phishingowe skierowane do konkretnych deweloperów, maintainerów i administratorów. Analiza zależności między użytkownikami i projektami może też ujawnić komponenty krytyczne dla działania firmy oraz obszary warte dalszej kompromitacji.
Wykorzystanie legalnych kont i prawidłowo działających tokenów znacząco utrudnia detekcję. Klasyczne reguły oparte na prostych wskaźnikach kompromitacji mogą nie wystarczyć, bo ruch przypomina standardowe użycie API. Jeśli dodatkowo dochodzi do dostępu do repozytoriów prywatnych, stawką staje się wyciek kodu źródłowego, sekretów zapisanych w historii commitów, konfiguracji CI/CD oraz wiedzy architektonicznej przydatnej w kolejnych etapach ataku.
Szczególnie niebezpieczne są kampanie o niskiej intensywności pojedynczych zdarzeń, ale dużej spójności w czasie. Bez centralnej analizy logów i profilowania behawioralnego taka operacja może pozostać niezauważona przez wiele tygodni.
Rekomendacje
Organizacje powinny traktować GitHuba jako krytyczny element powierzchni ataku i objąć go monitoringiem na poziomie zbliżonym do systemów IAM oraz środowisk chmurowych. W praktyce warto wdrożyć następujące działania:
- Regularnie analizować logi audytowe dotyczące dostępu do organizacji, repozytoriów, tokenów i operacji klonowania.
- Ograniczać liczbę aktywnych tokenów PAT i OAuth oraz egzekwować zasadę najmniejszych uprawnień.
- Wdrożyć cykliczną rotację poświadczeń i automatyczne wykrywanie sekretów ujawnionych w kodzie, commitach i pipeline’ach.
- Monitorować nietypowe wzorce użycia API, zwłaszcza rozproszone zapytania enumeracyjne wykonywane przez wiele kont.
- Analizować aktywność starych, wcześniej nieużywanych kont, które nagle zaczynają intensywnie korzystać z API.
- Wymuszać silne uwierzytelnianie wieloskładnikowe dla kont deweloperskich.
- Przeglądać członkostwa organizacyjne i segmentować dostęp do repozytoriów prywatnych.
- Budować detekcje korelujące sekwencje działań: enumerację, użycie tokenu, rozszerzenie zakresu zapytań i finalne klonowanie.
- Szkolić zespoły deweloperskie w zakresie bezpiecznego zarządzania tokenami i rozpoznawania phishingu ukierunkowanego.
W środowiskach podwyższonego ryzyka warto dodatkowo analizować user-agenty, reputację kont oraz czasową korelację aktywności między wieloma profilami, nawet jeśli każde żądanie osobno wygląda poprawnie.
Podsumowanie
Opisane kampanie pokazują, że współczesne zagrożenia dla platform deweloperskich coraz częściej przyjmują formę cichego, długoterminowego rekonesansu. Uśpione konta GitHub, przejęte tokeny i legalne funkcje API tworzą połączenie, które pozwala atakującym wtopić się w normalny ruch i stopniowo budować obraz organizacji.
Najważniejszy wniosek jest praktyczny: bezpieczeństwo GitHuba nie może ograniczać się wyłącznie do ochrony kodu. Musi obejmować widoczność dostępu, ścisłą kontrolę poświadczeń oraz zdolność wykrywania subtelnych anomalii behawioralnych, zanim rozpoznanie przerodzi się w realne naruszenie bezpieczeństwa.
Źródła
- Dormant GitHub Accounts Help Attackers Blend In While Mapping Corporate Orgs — https://thehackernews.com/2026/07/dormant-github-accounts-help-attackers.html