Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Platformy deweloperskie i usługi DevOps coraz częściej stają się celem działań rozpoznawczych prowadzonych przez cyberprzestępców. W opisywanej kampanii atakujący wykorzystywali tzw. „ghost accounts”, czyli konta GitHub utworzone lata wcześniej i przez długi czas pozostające nieaktywne, aby prowadzić zautomatyzowane mapowanie organizacji, repozytoriów oraz relacji między użytkownikami.
Tego rodzaju aktywność nie musi oznaczać natychmiastowej próby włamania. Jej głównym celem jest zbudowanie szczegółowego obrazu środowiska ofiary, który może zostać wykorzystany w kolejnych etapach ataku, takich jak phishing, nadużycie tokenów, przejęcie kont czy uderzenie w łańcuch dostaw oprogramowania.
W skrócie
Kampania opierała się na automatycznym wykorzystywaniu API GitHub do zbierania informacji o organizacjach, publicznych repozytoriach i kontach użytkowników. Ruch często dotyczył danych publicznie dostępnych, przez co z perspektywy obrony wyglądał jak legalna aktywność i był trudny do odróżnienia od zwykłego użycia platformy.
- W działaniach wykorzystano ponad 50 uśpionych kont aktywowanych falami.
- Okres aktywności pojedynczych kont wynosił zazwyczaj od jednego do trzech tygodni.
- Dominującym wektorem były zapytania GraphQL, uzupełniane przez klasyczne API REST.
- W części przypadków użyto ujawnionych tokenów legalnych użytkowników.
- W nielicznych incydentach kampania zakończyła się eksfiltracją danych.
Kontekst / historia
Rozpoznanie prowadzone w środowiskach SaaS i na platformach programistycznych nie jest nowym zjawiskiem, jednak jego skala oraz poziom automatyzacji wyraźnie rosną. GitHub jest szczególnie atrakcyjnym celem, ponieważ łączy w jednym miejscu kod źródłowy, metadane projektowe, powiązania między użytkownikami i elementy procesów developerskich.
Nawet bez dostępu do prywatnych repozytoriów napastnik może ustalić, kto należy do zespołu, jakie technologie wykorzystuje organizacja, które projekty są aktywne oraz jakie konta warto obrać za cel dalszych działań. To sprawia, że publiczne dane stają się wartościowym zasobem wywiadowczym.
W tej kampanii szczególną rolę odegrały konta wyglądające na historyczne i wiarygodne. Zamiast tworzyć nowe profile, które łatwiej wzbudzają podejrzenia, operatorzy aktywowali konta utworzone dwa do pięciu lat wcześniej. Taki model utrudnia detekcję i zmniejsza ryzyko szybkiego zablokowania aktywności.
Analiza techniczna
Rdzeniem kampanii było wykorzystanie szerokiej powierzchni API GitHub dostępnej bez uwierzytelnienia lub przy ograniczonej autoryzacji. Atakujący pobierali informacje o publicznych repozytoriach, listach obserwowanych projektów, członkostwach organizacyjnych, gistach, relacjach followers/following oraz innych obiektach dostępnych przez API.
Najważniejszym elementem technicznym były zapytania GraphQL. Ten interfejs pozwala bardzo elastycznie pobierać powiązane dane i budować rozbudowane mapy relacji w ramach jednej sesji operacyjnej. W praktyce oznacza to możliwość szybkiego ustalenia struktury organizacji, zależności między kontami i zakresu publicznej ekspozycji projektów.
Uzupełnieniem były klasyczne trasy REST, dzięki którym operatorzy mogli rozszerzać zebrany obraz środowiska. Istotne jest to, że takie zapytania zwracają prawidłowe odpowiedzi HTTP 200 i nie generują typowych sygnałów alarmowych kojarzonych z nieudanymi logowaniami lub próbami eskalacji uprawnień.
Dodatkową techniką maskowania było stosowanie user agentów przypominających legalne narzędzia analityczne, dashboardowe lub eksportujące dane. Tego rodzaju nazewnictwo utrudnia ręczne wychwycenie podejrzanego ruchu w logach. Sama aktywność była też prowadzona falami, co ogranicza skuteczność prostych reguł wykrywających jedynie nagłe wzrosty wolumenu zapytań.
Najbardziej niepokojącym aspektem kampanii było użycie ujawnionych tokenów należących do prawdziwych użytkowników GitHub. W takim scenariuszu operator może wykraczać poza publiczny rekonesans i wykonywać zapytania dotyczące prywatnych ścieżek commitów lub innych zasobów dostępnych z poziomu przejętej tożsamości. To znacząco podnosi ryzyko, ponieważ ruch zaczyna przypominać legalne działania pracownika lub integracji.
Konsekwencje / ryzyko
Pozornie nieszkodliwe zbieranie publicznych danych może znacząco zwiększyć skuteczność późniejszych etapów ataku. Dobrze przeprowadzony rekonesans pozwala napastnikowi wskazać osoby uprzywilejowane, opiekunów krytycznych projektów, konta serwisowe oraz technologie używane w organizacji.
Z perspektywy bezpieczeństwa przekłada się to na kilka istotnych zagrożeń:
- precyzyjniejsze ataki socjotechniczne wymierzone w deweloperów i maintainerów,
- nadużycie wyciekłych tokenów oraz innych sekretów,
- ataki na łańcuch dostaw poprzez przejęcie lub podszycie się pod zaufane konta,
- nieautoryzowane klonowanie repozytoriów,
- ujawnienie wrażliwych informacji zawartych w commitach, metadanych lub błędnie opublikowanych projektach.
Szczególnie groźne są sytuacje, w których organizacja nie monitoruje wzorców dostępu do GitHub albo nie analizuje zachowania tokenów i kont aplikacyjnych. Wówczas przejście od rozpoznania do eksfiltracji może nastąpić bez wyraźnego ostrzeżenia.
Rekomendacje
Podstawowym działaniem obronnym powinno być centralne logowanie i analiza zdarzeń audytowych z GitHub. Przekazywanie logów do systemu SIEM lub platformy detekcyjnej umożliwia budowę linii bazowej dla user agentów, typów zapytań, aktorów oraz częstotliwości dostępu do publicznych i prywatnych zasobów.
W praktyce warto wdrożyć następujące działania:
- zidentyfikować wszystkie tokeny osobiste, aplikacyjne i serwisowe mające dostęp do organizacji,
- rotować tokeny oraz unieważniać te, które są nieużywane lub nadmiernie uprzywilejowane,
- monitorować anomalie w user agentach i nowe wzorce dostępu do prywatnych repozytoriów,
- wykrywać skoki aktywności GraphQL i REST związane z masową enumeracją obiektów,
- analizować zdarzenia klonowania repozytoriów, pobrań i dostępu do prywatnych ścieżek commitów,
- prowadzić threat hunting ukierunkowany na konta wykonujące szeroki rekonesans bez proporcjonalnej aktywności deweloperskiej,
- ograniczać ekspozycję danych w publicznych repozytoriach, w tym sekretów, metadanych i dokumentacji operacyjnej,
- wymuszać zasadę najmniejszych uprawnień dla użytkowników, botów i integracji CI/CD.
Dojrzałe organizacje powinny również regularnie przeglądać relacje między członkostwem w organizacjach, uprawnieniami do repozytoriów i historią użycia tokenów. Ważne jest też tworzenie reguł detekcyjnych dostosowanych do własnego profilu działania, a nie wyłącznie poleganie na ogólnych wskaźnikach kompromitacji.
Podsumowanie
Kampania wykorzystująca „ghost accounts” pokazuje, że publiczne API platform developerskich może stać się skutecznym narzędziem rozpoznania na dużą skalę. Nawet jeśli początkowy ruch dotyczy wyłącznie publicznych zasobów, jego wartość operacyjna dla atakującego jest wysoka, a granica między rekonesansem a realnym incydentem bywa bardzo cienka.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że GitHub należy traktować nie tylko jako narzędzie programistyczne, ale również jako krytyczny zasób wymagający monitoringu, detekcji anomalii, kontroli tokenów i aktywnego threat huntingu.
Źródła
- https://www.securityweek.com/ghost-accounts-abuse-github-api-in-mass-recon-campaign/
- https://securitylabs.datadoghq.com/
- https://docs.github.com/en/rest
- https://docs.github.com/en/graphql
- https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/auditing-the-audit-log-for-your-enterprise