Archiwa: SIEM - Strona 21 z 84

Progress potwierdza lukę zero-day w ShareFile Storage Zone Controller. Aktualizacja jest pilna

Wprowadzenie do problemu / definicja

Progress Software potwierdził, że przyczyną awaryjnego wyłączenia ShareFile Storage Zone Controller była podatność typu zero-day o wysokiej istotności. Problem dotyczy komponentu instalowanego lokalnie w infrastrukturze klienta, który odpowiada za obsługę plików przechowywanych on-premises przy jednoczesnym korzystaniu z chmurowych funkcji ShareFile, takich jak uwierzytelnianie, kontrola uprawnień, audyt i współpraca.

Z perspektywy bezpieczeństwa jest to szczególnie wrażliwy element architektury, ponieważ stanowi połączenie między usługą aplikacyjną a rzeczywistymi zasobami danych organizacji. Każda podatność w takim komponencie może mieć bezpośredni wpływ na poufność, integralność i dostępność plików biznesowych.

W skrócie

Progress potwierdził istnienie luki zero-day w ShareFile Storage Zone Controller.
Podatność została opisana jako błąd path traversal.
Problem obejmuje wszystkie wersje 5.x i 6.x tego komponentu.
Atakujący z uwierzytelnionym kontem administracyjnym może odczytywać pliki, zapisywać kontrolowaną treść w wybranych katalogach i enumerować system plików.
Producent wydał poprawione wersje 5.12.5 oraz 6.0.2.
Zalecane jest wdrożenie aktualizacji przed ponownym uruchomieniem kontrolerów.

Kontekst / historia

Sprawa stała się publiczna po tym, jak producent zalecił klientom natychmiastowe wyłączenie serwerów Windows obsługujących ShareFile Storage Zone Controller w odpowiedzi na wiarygodny zewnętrzny sygnał o zagrożeniu. Równocześnie czasowo ograniczono dostęp do części środowisk korzystających z tego mechanizmu, aby umożliwić przeprowadzenie analizy bezpieczeństwa.

Początkowo komunikacja koncentrowała się na działaniach zapobiegawczych, jednak po zakończeniu wstępnego dochodzenia firma potwierdziła, że źródłem problemu była rzeczywista podatność, a nie jedynie ogólne ryzyko operacyjne. Producent poinformował również, że poprawka została przygotowana przed szerokim ujawnieniem szczegółów technicznych, aby ograniczyć ryzyko szybkiego wykorzystania luki przez cyberprzestępców.

Analiza techniczna

Potwierdzona podatność została sklasyfikowana jako path traversal. Tego typu błąd pojawia się wtedy, gdy aplikacja niewłaściwie waliduje ścieżki dostępu do zasobów, co może umożliwić wyjście poza przewidziany katalog roboczy i dostęp do lokalizacji, które nie powinny być dostępne w ramach danej funkcji.

W analizowanym przypadku skutki nie ograniczają się wyłącznie do nieautoryzowanego odczytu plików. Według informacji producenta uwierzytelniony administrator może wykonywać operacje, które zwiększają potencjał dalszej kompromitacji środowiska.

Odczyt dowolnych plików dostępnych dla konta usługi aplikacji.
Zapis kontrolowanej przez atakującego zawartości w arbitralnych katalogach dostępnych dla procesu.
Enumerację struktury systemu plików serwera.

Technicznie oznacza to możliwość zdobycia szczegółowej wiedzy o środowisku, odnalezienia plików konfiguracyjnych, rozpoznania lokalizacji przechowywania danych oraz potencjalnego przygotowania kolejnych etapów ataku. W środowiskach, w których konto usługi posiada zbyt szerokie uprawnienia, wpływ takiej podatności może istotnie wzrosnąć.

Konsekwencje / ryzyko

Najbardziej narażone są organizacje przechowujące pliki lokalnie z użyciem Storage Zone Controller. Kompromitacja tego komponentu może prowadzić do ekspozycji danych, manipulacji zawartością, zaburzenia integralności repozytorium plików oraz stworzenia warunków do dalszych działań, w tym ataków ransomware lub wymuszeń opartych na kradzieży informacji.

Choć warunkiem wykorzystania luki jest posiadanie uwierzytelnionego konta administracyjnego, nie obniża to automatycznie poziomu ryzyka. Konta uprzywilejowane są częstym celem ataków, a każda podatność zwiększająca możliwości po przejęciu takiego dostępu może znacząco przyspieszyć rozwój incydentu. Dodatkowo komponent działa w infrastrukturze zarządzanej przez klientów, więc poziom zabezpieczeń, segmentacji i monitoringu może być bardzo zróżnicowany.

Nie bez znaczenia pozostaje także aspekt operacyjny. Samo awaryjne wyłączenie kontrolerów pokazało, że reakcja na zagrożenie może wpływać na ciągłość działania procesów zależnych od wymiany i lokalnego przechowywania plików.

Rekomendacje

Organizacje korzystające z ShareFile Storage Zone Controller powinny w pierwszej kolejności ustalić, czy używają podatnych wersji 5.x lub 6.x, a następnie niezwłocznie przejść na wersje naprawcze 5.12.5 albo 6.0.2. Ponowne uruchomienie komponentu powinno nastąpić dopiero po potwierdzonym wdrożeniu aktualizacji i przeprowadzeniu podstawowej weryfikacji bezpieczeństwa.

Zweryfikować wersję wdrożonego Storage Zone Controller.
Zastosować poprawki wskazane przez producenta.
Przeanalizować logi aplikacyjne, systemowe i sieciowe pod kątem nietypowych operacji na plikach.
Sprawdzić, czy nie występowały próby enumeracji katalogów i dostępu do niestandardowych ścieżek.
Ograniczyć uprawnienia konta usługi aplikacyjnej do absolutnego minimum.
Zweryfikować integralność plików konfiguracyjnych oraz katalogów zapisu.
Wzmocnić monitoring serwerów dodatkowymi regułami EDR i SIEM.
Ograniczyć administracyjny dostęp do komponentu i stosować silniejsze mechanizmy MFA.

Dobrą praktyką będzie również przygotowanie procedury szybkiego odłączenia krytycznych komponentów odpowiedzialnych za przechowywanie danych od sieci produkcyjnej w przypadku pojawienia się kolejnych ostrzeżeń o aktywnym zagrożeniu.

Podsumowanie

Potwierdzenie luki zero-day w ShareFile Storage Zone Controller pokazuje, jak wysokie ryzyko niosą podatności w komponentach łączących środowiska chmurowe z lokalnymi repozytoriami danych. Opisany błąd path traversal może wspierać nie tylko odczyt plików, ale także rozpoznanie infrastruktury i manipulację zasobami serwera. Dla organizacji kluczowe pozostaje szybkie wdrożenie poprawek, ograniczenie uprawnień oraz dokładna analiza śladów potencjalnej aktywności w systemach obsługujących ShareFile.

Źródła

Fałszywe repozytoria na GitHubie rozprzestrzeniają malware podszywając się pod legalne oprogramowanie

Wprowadzenie do problemu / definicja

Zaufanie do popularnych platform deweloperskich od lat stanowi istotny element codziennej pracy administratorów, programistów i użytkowników technicznych. Właśnie dlatego GitHub coraz częściej staje się nie tylko miejscem publikacji legalnego kodu, ale również nośnikiem kampanii malware, które wykorzystują wiarygodny kontekst do dystrybucji złośliwego oprogramowania.

W opisywanym przypadku atakujący przygotowali setki fałszywych repozytoriów podszywających się pod znane narzędzia, projekty bezpieczeństwa i aplikacje użytkowe. Celem operacji była dystrybucja infostealera, czyli malware zaprojektowanego do szybkiej kradzieży poświadczeń, danych przeglądarek, portfeli kryptowalutowych oraz innych wrażliwych informacji z zainfekowanego systemu.

W skrócie

Badacze wykryli 292 fałszywe repozytoria na GitHubie, które imitowały legalne projekty i kierowały użytkowników do spreparowanych stron pobierania. Kampania wykorzystywała profesjonalnie przygotowane opisy, branding i elementy wizualne mające zwiększyć wiarygodność publikowanych zasobów.

Końcowym ładunkiem był wariant stealera z rodziny BoryptGrab. Malware koncentrował się na szybkim pozyskaniu maksymalnej ilości danych i działał głównie w modelu jednorazowego uruchomienia, bez utrzymywania trwałości w systemie.

Kontekst / historia

Nadużywanie zaufanych platform do dostarczania malware nie jest nowym zjawiskiem, jednak GitHub pozostaje szczególnie atrakcyjnym środowiskiem dla operatorów takich kampanii. Publiczne repozytoria, pliki README, historia projektu i obecność kodu źródłowego budują wrażenie autentyczności, co obniża czujność użytkowników pobierających narzędzia spoza oficjalnych kanałów producenta.

W analizowanej operacji podszywano się pod wiele kategorii oprogramowania, w tym narzędzia bezpieczeństwa, aplikacje finansowe, usługi kryptowalutowe, oprogramowanie deweloperskie, rozwiązania pocztowe, narzędzia dla macOS oraz projekty związane z grami. Według opublikowanych ustaleń początek kampanii powiązano z 26 czerwca 2026 roku, a jej wykrycie nastąpiło po zaobserwowaniu podszywania się pod jeden z produktów bezpieczeństwa.

Analiza techniczna

Każde fałszywe repozytorium zawierało plik README prowadzący do zewnętrznej strony pobierania. Infrastruktura używana do dostarczania malware była silnie ustandaryzowana: wiele podszywanych marek korzystało z tego samego szablonu HTML i JavaScript, różniącego się głównie warstwą wizualną oraz ścieżką adresu.

Mechanizm strony analizował segmenty URL, aby rozpoznać repozytorium źródłowe i automatycznie podstawić odpowiedni branding. Taka architektura umożliwiała operatorom szybkie klonowanie kolejnych wariantów kampanii i masowe uruchamianie nowych podszyć bez przebudowy całego łańcucha infekcji.

Po stronie ofiary pobierane było duże archiwum ZIP, którego nazwa i zawartość zmieniały się bardzo często, mniej więcej co minutę. W archiwum znajdowały się dwa istotne komponenty: legalnie podpisany aktualizator WinGUP oraz trojanizowana biblioteka libcurl.dll. Po uruchomieniu pliku wykonywalnego dochodziło do bocznego ładowania biblioteki DLL, a następnie do dekodowania i refleksyjnego uruchomienia stealera bezpośrednio w pamięci.

Z perspektywy napastnika taka metoda przynosi kilka korzyści. Użycie podpisanego komponentu zwiększa pozory legalności, natomiast uruchomienie payloadu w pamięci ogranicza liczbę artefaktów pozostawianych na dysku i może utrudniać detekcję opartą wyłącznie na analizie plików.

Zidentyfikowany wariant BoryptGrab zbierał szeroki zakres danych z systemu ofiary, w tym:

hasła, cookies i dane płatnicze z ponad 19 przeglądarek,
dane z 32 marek portfeli kryptowalutowych,
sesje Telegrama, tokeny Discorda i tokeny sesyjne Steam,
poświadczenia z komunikatorów,
dane z Menedżera poświadczeń systemu Windows,
pliki z katalogów Desktop i Documents związane z hasłami, kopiami zapasowymi, portfelami i frazami odzyskiwania,
zrzuty ekranu, informacje o systemie oraz listy zainstalowanego oprogramowania.

Na szczególną uwagę zasługuje zdolność wariantu BoryptGrab do omijania mechanizmu App-Bound Encryption w Chrome poprzez bezpośrednią iniekcję kodu do procesu przeglądarki. To sygnał, że operatorzy rozwijają swoje narzędzia z myślą o obchodzeniu nowoczesnych zabezpieczeń przeglądarek i skuteczniejszym przejmowaniu danych uwierzytelniających.

Po zebraniu informacji malware kompresował dane i wysyłał je do serwera C2. Brak mechanizmu trwałości wskazuje, że kampania była nastawiona przede wszystkim na szybkie pozyskanie danych i ograniczenie czasu ekspozycji w środowisku ofiary.

Konsekwencje / ryzyko

Największe zagrożenie dotyczy użytkowników, którzy pobierają oprogramowanie z niezweryfikowanych repozytoriów lub szukają alternatywnych źródeł dla komercyjnych narzędzi. Kampania łączy klasyczną socjotechnikę z technikami charakterystycznymi dla loaderów i infostealerów, przez co może skutecznie omijać ostrożność mniej doświadczonych odbiorców.

Dla organizacji skutki incydentu mogą być znacznie poważniejsze niż pojedyncza infekcja stacji roboczej. Kradzież danych z przeglądarek, tokenów sesyjnych i systemowych magazynów poświadczeń może otworzyć drogę do wtórnych ataków na środowiska chmurowe, konta administracyjne oraz usługi SaaS.

przejęcie kont deweloperskich i administracyjnych,
kradzież dostępu do SaaS, VPN i poczty,
wykorzystanie tokenów sesyjnych do obejścia MFA w wybranych scenariuszach,
kompromitacja portfeli kryptowalutowych i zasobów finansowych,
dalsze użycie skradzionych danych w phishingu, ransomware lub oszustwach BEC.

Ryzyko zwiększa fakt, że GitHub bywa standardowo dopuszczony w środowiskach firmowych, a ruch do publicznych repozytoriów często nie jest traktowany jako podejrzany. Jeśli użytkownik uruchomi pobrany pakiet poza kontrolowanym procesem dystrybucji oprogramowania, tradycyjne polityki bezpieczeństwa mogą nie zapewnić wystarczającej ochrony.

Rekomendacje

Incydent pokazuje, że sama obecność projektu na zaufanej platformie nie może być traktowana jako dowód autentyczności. Organizacje powinny zaostrzyć kontrolę nad sposobem pobierania, weryfikowania i uruchamiania narzędzi pochodzących z publicznych źródeł kodu.

Stosować allowlisting aplikacji i blokować wykonywanie plików z katalogów pobrań, lokalizacji tymczasowych oraz innych nieautoryzowanych ścieżek użytkownika.
Dopuszczać wyłącznie oficjalne repozytoria producentów, zweryfikowane organizacje i kanały dystrybucji podpisanych binariów.
Rozszerzyć reguły EDR i SIEM o wykrywanie technik DLL side-loading z użyciem legalnych binariów ładujących podejrzane biblioteki.
Monitorować nietypowe procesy odczytujące dane z przeglądarek, menedżerów poświadczeń, katalogów użytkownika i portfeli kryptowalutowych.
Egzekwować separację profili uprzywilejowanych, stosować odporne na phishing metody MFA oraz skracać czas życia sesji tam, gdzie to możliwe.
Prowadzić regularną edukację użytkowników i zespołów deweloperskich na temat fałszywych repozytoriów oraz technik budowania pozorów wiarygodności.
Przeanalizować dostępne wskaźniki kompromitacji i wdrożyć reguły YARA oraz detekcje behawioralne powiązane z rodziną BoryptGrab.

Podsumowanie

Kampania oparta na blisko 300 fałszywych repozytoriach pokazuje, jak łatwo zaufanie do platform deweloperskich może zostać przekształcone w skuteczny wektor infekcji. Połączenie podszywania się pod znane projekty, dynamicznych stron pobierania, DLL side-loading oraz pamięciowego uruchamiania stealera zwiększa skuteczność kradzieży danych i utrudnia wykrycie ataku.

Z punktu widzenia obrony kluczowe znaczenie mają kontrola źródeł oprogramowania, widoczność zachowań procesów, ochrona przeglądarek i ograniczenie uruchamiania nieautoryzowanych binariów. To kolejny sygnał, że bezpieczeństwo łańcucha dostaw oprogramowania musi obejmować również publiczne platformy repozytoryjne.

Źródła

BleepingComputer — https://www.bleepingcomputer.com/news/security/nearly-300-github-repos-pose-as-legit-software-to-push-malware/
Arctic Wolf — Nearly 300 GitHub Repositories Spoofing Legitimate Software Projects Deliver BoryptGrab Malware — https://arcticwolf.com/resources/blog/nearly-300-github-repositories-spoofing-legitimate-software-projects-deliver-boryptgrab-malware/
GitHub Docs — About READMEs — https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes

ScamBuster: AI odpowiada na phishing i zbiera dane o oszustach e-mailowych

Wprowadzenie do problemu / definicja

Phishing i oszustwa e-mailowe od lat należą do najczęściej wykorzystywanych metod ataku w cyberprzestępczości. W tradycyjnym modelu obrony podejrzana wiadomość jest wykrywana, blokowana lub usuwana, a incydent kończy się na etapie filtracji. ScamBuster proponuje odmienne podejście: zamiast jedynie zatrzymać wiadomość, system wykorzystuje sztuczną inteligencję do prowadzenia kontrolowanego dialogu z oszustem i pozyskiwania informacji o jego zapleczu operacyjnym.

To podejście wpisuje się w nurt aktywnej obrony, w której celem nie jest wyłącznie redukcja ryzyka tu i teraz, ale także budowanie wiedzy o infrastrukturze, technikach i mechanizmach monetyzacji stosowanych przez przestępców.

W skrócie

ScamBuster to otwartoźródłowy system oparty na AI, zaprojektowany do odpowiadania wyłącznie na przychodzące wiadomości phishingowe. Narzędzie podszywa się pod wiarygodną ofiarę i prowadzi rozmowę tak, aby skłonić oszusta do ujawnienia przydatnych danych operacyjnych.

działa w modelu inbound-only i nie inicjuje kontaktu samodzielnie,
wykorzystuje persony dopasowane do różnych scenariuszy oszustw,
pozyskuje wskaźniki takie jak IBAN-y, domeny płatnicze i numery telefonów,
porządkuje dane jako ustrukturyzowany threat intelligence,
eksportuje wyniki do formatów STIX 2.1 i MISP.

Projekt ma zostać udostępniony publicznie na licencji MIT, co może zwiększyć jego znaczenie w środowiskach SOC, CTI i DFIR.

Kontekst / historia

Koncepcję ScamBuster opracował Laurent Giovannoni, principal software engineer w Filigran, w ramach pracy dyplomowej realizowanej podczas studiów na École Polytechnique. Według opisu projekt działa produkcyjnie od listopada 2025 roku, a jego formalna prezentacja ma nastąpić podczas Black Hat USA 2026 w Las Vegas.

Geneza rozwiązania jest praktyczna. Nawet jeśli jedna osoba rozpozna próbę oszustwa i usunie wiadomość, ta sama kampania może nadal skutecznie atakować inne ofiary. Z perspektywy obronnej oznacza to utratę potencjalnie cennych danych o przeciwniku. ScamBuster ma zamieniać pojedynczy incydent e-mailowy w źródło informacji o szerszej działalności przestępczej.

Analiza techniczna

Podstawą architektury ScamBuster jest zasada inbound-only. System nie rozpoczyna żadnej komunikacji z własnej inicjatywy i odpowiada wyłącznie na wiadomości, które już trafiły do organizacji. To ważne ograniczenie bezpieczeństwa, ponieważ redukuje ryzyko niekontrolowanych działań wychodzących i ułatwia zachowanie zgodności operacyjnej.

Po wykryciu wiadomości uznanej za próbę oszustwa rozwiązanie przypisuje odpowiednią personę i rozpoczyna dialog. Persony mają imitować profile prawdopodobnych ofiar, takich jak senior, mały przedsiębiorca, zapracowany menedżer czy podróżny. Celem nie jest prowadzenie przypadkowej rozmowy, lecz takie sterowanie konwersacją, aby oszust ujawnił informacje przydatne z punktu widzenia analizy zagrożeń.

Pod warstwą aplikacyjną działa zestaw agentów opartych na dużych modelach językowych. Odpowiadają one za prowadzenie rozmowy, ocenę wartości pozyskanych danych oraz ich zapis w formie ustrukturyzowanych wskaźników. System analizuje także skuteczność konkretnych person i schematów dialogu, aby poprawiać wyniki kolejnych interakcji.

Największa wartość operacyjna pojawia się na etapie, gdy oszust przechodzi do próby wyłudzenia płatności. W tym momencie ScamBuster może pozyskać numery rachunków, dane instytucji finansowych, domeny wykorzystywane do płatności, prefiksy numerów telefonów oraz szczegóły dotyczące przepływu środków. Dane te mogą następnie zostać skorelowane, co pozwala łączyć pozornie odrębne kampanie w jeden profil działalności przestępczej.

Istotnym elementem projektu jest eksport wyników do standardów STIX 2.1 oraz MISP. Dzięki temu zebrane informacje mogą zostać łatwo wykorzystane w istniejących procesach threat intelligence, automatyzacji SOC, systemach SIEM i platformach współdzielenia wskaźników.

Według opisu ScamBuster pozostaje agnostyczny względem dostawcy modelu AI. Oznacza to możliwość użycia zarówno modeli komercyjnych, jak i otwartych, o ile organizacja zapewni odpowiednią integrację. W prezentowanym wariancie wykorzystano niewielki model komercyjny, aby utrzymać niski koszt operacyjny.

Konsekwencje / ryzyko

Z perspektywy obrony ScamBuster zwiększa wartość analityczną incydentów phishingowych. Zamiast traktować wiadomość jako pojedynczy artefakt do usunięcia, organizacja może budować szerszy obraz infrastruktury przeciwnika, jego kanałów komunikacji i mechanizmów monetyzacji. To szczególnie istotne dla zespołów CTI, SOC, DFIR oraz organów ścigania.

Korzyści te nie eliminują jednak ryzyk. Automatyczna interakcja z napastnikiem wymaga ścisłych ograniczeń technicznych, proceduralnych i prawnych. Konieczne jest kontrolowanie zakresu odpowiedzi, retencji danych, zasad ich dalszego udostępniania oraz zgodności z przepisami dotyczącymi prywatności i przechowywania korespondencji.

Dodatkowym wyzwaniem są ograniczenia samych modeli językowych. System może popełniać błędy kontekstowe, generować odpowiedzi wykraczające poza założoną politykę albo ujawniać więcej informacji, niż organizacja planowała. W dłuższej perspektywie należy także brać pod uwagę adaptację przeciwników, którzy mogą zacząć testować, czy rozmawiają z człowiekiem czy zautomatyzowanym systemem.

Rekomendacje

Organizacje rozważające wdrożenie podobnego rozwiązania powinny rozpocząć od ustanowienia jasnego modelu governance. Należy zdefiniować odpowiedzialność za uruchamianie interakcji, dopuszczalny czas prowadzenia rozmów, zakres gromadzonych danych oraz warunki eskalacji do analityków lub organów ścigania.

uruchamiać system w silnie odseparowanym środowisku,
wymuszać zasadę inbound-only na poziomie architektury,
odciąć warstwę konwersacyjną od wrażliwych danych wewnętrznych,
logować pełny przebieg interakcji do celów audytowych,
automatycznie ekstrahować IOC i IOA oraz korelować je z istniejącymi źródłami CTI,
integrować eksport danych ze standardami STIX, MISP, SIEM i TIP.

Od strony operacyjnej warto wdrożyć przegląd jakości odpowiedzi modelu, testy red-teamowe pod kątem prompt injection i nadużyć kontekstowych, a także proces ręcznej eskalacji dla przypadków ujawniających nowe TTP przeciwnika. Niezbędna pozostaje również analiza wymogów prawnych związanych z przetwarzaniem danych osobowych i przechowywaniem korespondencji.

Podsumowanie

ScamBuster pokazuje, że phishing może być traktowany nie tylko jako zagrożenie do zablokowania, ale także jako źródło danych wywiadowczych o przeciwniku. Największą wartością rozwiązania jest zdolność do pozyskiwania i strukturyzowania informacji o infrastrukturze finansowej oraz komunikacyjnej oszustów e-mailowych.

Jednocześnie skuteczne użycie takiego systemu wymaga dojrzałej architektury bezpieczeństwa, nadzoru operacyjnego i zgodności prawnej. Jeśli te warunki zostaną spełnione, podobne narzędzia mogą stać się ważnym uzupełnieniem nowoczesnej obrony przed phishingiem.

Źródła

OAuth Client ID Spoofing w Microsoft Entra ID umożliwia cichą enumerację kont

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa alarmują o rosnącym wykorzystaniu techniki OAuth Client ID Spoofing w środowisku Microsoft Entra ID. Metoda ta pozwala atakującym prowadzić cichą enumerację kont użytkowników oraz wyciągać wnioski o poprawności poświadczeń bez konieczności korzystania z legalnie zarejestrowanej aplikacji OAuth.

Z perspektywy obrony jest to szczególnie niebezpieczne, ponieważ aktywność może być słabiej widoczna w logach i trudniejsza do wykrycia przez zespoły SOC. W praktyce oznacza to, że organizacja może nie zauważyć etapu rekonesansu lub wstępnej walidacji danych logowania aż do momentu dalszej eskalacji incydentu.

W skrócie

Istota ataku polega na podszywaniu się pod identyfikator klienta OAuth przekazywany w parametrze client_id podczas żądań uwierzytelniających. Dzięki różnicom w odpowiedziach usługi napastnik może rozróżnić, czy dane konto istnieje, czy hasło jest błędne, a w wybranych scenariuszach także czy login i hasło są poprawne.

atak nie wymaga użycia prawidłowej aplikacji OAuth,
telemetria może nie wskazywać nazwy aplikacji,
klasyczne detekcje oparte na analizie ruchu per aplikacja tracą skuteczność,
technika była obserwowana w kampaniach o dużej skali przeciw organizacjom korzystającym z Entra ID.

Kontekst / historia

Microsoft Entra ID od lat pozostaje jednym z głównych celów dla operatorów prowadzących rekonesans, password spraying oraz działania związane z uzyskaniem dostępu początkowego do środowisk chmurowych. Dotychczas napastnicy często wykorzystywali znane aplikacje pierwszej strony albo publiczne narzędzia, co zwiększało szansę ich wykrycia dzięki analizie logów logowania i korelacji zdarzeń.

Obecnie obserwowany trend pokazuje zmianę taktyki. Zamiast opierać operacje na jednym łatwo rozpoznawalnym identyfikatorze aplikacji, atakujący rozpraszają ruch pomiędzy ogromną liczbę fałszywych identyfikatorów klienta. Taki model utrudnia łączenie zdarzeń w jedną kampanię i obniża skuteczność prostych mechanizmów analitycznych.

Analiza techniczna

Mechanizm nadużycia opiera się na zachowaniu endpointu OAuth 2.0 podczas żądań kierowanych z parametrem client_id. Napastnik wysyła żądania do endpointu tokenowego, najczęściej wykorzystując przepływ Resource Owner Password Credentials, przekazując nazwę użytkownika, hasło oraz spreparowany identyfikator klienta.

Kluczowe znaczenie mają różnice w odpowiedziach serwera. Jeśli użytkownik nie istnieje, usługa może zwrócić komunikat wskazujący brak konta. Jeśli konto istnieje, ale hasło jest błędne, zwracany jest inny kod błędu. Jeżeli natomiast para login-hasło jest poprawna, lecz podany client_id nie odpowiada prawidłowej aplikacji, pojawia się błąd związany z nierozpoznanym identyfikatorem aplikacji. To właśnie ten wzorzec umożliwia inferencję stanu konta i poprawności poświadczeń bez klasycznego sukcesu logowania.

Istotny problem dotyczy także telemetrii. Gdy client_id jest poprawnie sformatowany, ale nie należy do realnej aplikacji, logi mogą zawierać sam identyfikator bez nazwy aplikacji. W efekcie detekcje zależne od pola nazwy aplikacji stają się mniej użyteczne. W bardziej zaawansowanych wariantach stosowane są nawet losowe identyfikatory UUID v4 generowane niemal dla każdego żądania, co dodatkowo utrudnia korelację.

W opisywanych kampaniach zaobserwowano dwa odmienne wzorce operacyjne. W jednym z nich zmieniano końcową część znanego identyfikatora aplikacji i rozkładano ruch na ponad 700 tysięcy spoofowanych identyfikatorów, obejmując ponad milion unikalnych kont w blisko 4 tysiącach tenantów. W drugim wariancie skala była jeszcze większa: użyto około 3,7 miliona spoofowanych identyfikatorów i wycelowano w ponad 2 miliony użytkowników.

Dodatkowym problemem jest możliwość obchodzenia części polityk Conditional Access, jeśli zostały one zaprojektowane głównie wokół konkretnych aplikacji. Fałszywy identyfikator klienta może nie uruchamiać takich kontroli w oczekiwany sposób, przez co zabezpieczenia nie zawsze zadziałają zgodnie z założeniami architektów bezpieczeństwa.

Konsekwencje / ryzyko

Najpoważniejsze ryzyko polega na tym, że organizacja może błędnie ocenić charakter zdarzeń. To, co wygląda jak seria nieudanych prób logowania lub nietypowych błędów aplikacyjnych, w rzeczywistości może oznaczać skuteczną enumerację użytkowników albo nawet potwierdzenie poprawnych par login-hasło.

Osłabieniu ulega także monitoring oparty na trendach per aplikacja. Puste pole nazwy aplikacji, rozproszenie ruchu i stale zmieniające się identyfikatory klienta rozbijają obraz incydentu na wiele pozornie niezależnych sygnałów. W środowiskach o dużej skali może to prowadzić do obniżenia priorytetu alertów lub całkowitego przeoczenia kampanii.

wyższe ryzyko przejęcia kont,
możliwość nadużyć w usługach Microsoft 365 i aplikacjach SaaS,
większe prawdopodobieństwo ruchu bocznego w środowisku chmurowym,
potencjalne blokady kont i zakłócenia operacyjne dla użytkowników.

Rekomendacje

Organizacje korzystające z Microsoft Entra ID powinny rozszerzyć scenariusze detekcyjne o analizę logów logowania pod kątem brakującej nazwy aplikacji oraz nietypowych lub nierozpoznanych identyfikatorów aplikacji. Szczególną uwagę warto zwrócić na zdarzenia oznaczone kodem AADSTS700016, ponieważ w tym kontekście mogą one wskazywać nie tylko na nieudaną próbę dostępu, ale również na użycie poprawnych poświadczeń z fałszywym client_id.

Zespół SOC powinien korelować takie zdarzenia z szerszym kontekstem operacyjnym:

dużą liczbą prób wobec wielu użytkowników,
nietypowymi agentami użytkownika,
wysoką rotacją adresów IP i wykorzystaniem infrastruktury proxy,
masowymi próbami wobec kont o przewidywalnych schematach nazewniczych.

Równolegle warto ograniczać skutki wykorzystania skradzionych haseł poprzez konsekwentne egzekwowanie MFA, wdrażanie odpornych na phishing metod uwierzytelniania oraz monitoring anomalii tożsamościowych. Polityki Conditional Access nie powinny opierać się wyłącznie na wybranych aplikacjach, ale także na kontekście użytkownika, urządzenia, ryzyku sesji i źródle logowania.

Od strony hardeningu zalecane jest również:

strojenie alertów dla uwierzytelnień bez nazwy aplikacji,
budowa reguł wykrywających masowe użycie unikalnych client_id,
analiza blokad kont jako potencjalnego skutku enumeracji lub password sprayingu,
weryfikacja, czy logi Entra trafiają do SIEM z pełnym zestawem pól wymaganych do korelacji,
testowanie detekcji przeciw technikom obchodzącym monitorowanie per aplikacja.

Podsumowanie

OAuth Client ID Spoofing w Microsoft Entra ID to technika, która łączy prostotę wykonania z wysoką skutecznością operacyjną. Umożliwia cichą enumerację użytkowników, rozpoznawanie poprawności haseł i jednoczesne ograniczanie widoczności działań w logach.

Skala zaobserwowanych kampanii sugeruje, że nie jest to jednorazowy eksperyment, lecz rozwijający się element arsenału wykorzystywanego przeciw środowiskom tożsamościowym w chmurze. Dla obrońców oznacza to konieczność aktualizacji reguł detekcyjnych, reinterpretacji wybranych kodów błędów oraz większego nacisku na monitoring anomalii związanych z tożsamością.

Źródła

Cybersecurity Dive — Hackers find a new trick to collect Microsoft Entra user data without raising red flags — https://www.cybersecuritydive.com/news/microsoft-entra-user-enumeration-bypass-proofpoint/825052/
Proofpoint — OAuth Client ID Spoofing: Why Fake Client IDs Are Gaining Traction for Stealthy Enumeration — https://www.proofpoint.com/us/blog/threat-insight/oauth-client-id-spoofing-why-fake-client-ids-are-gaining-traction-stealthy

UE i Wielka Brytania zaostrzają presję na Rosję. Wspólny pakiet sankcji cybernetycznych

Wprowadzenie do problemu / definicja

Sankcje cybernetyczne to narzędzie polityczne i regulacyjne służące do reagowania na działania w cyberprzestrzeni przypisywane państwom, grupom powiązanym z wywiadem oraz podmiotom wspierającym operacje destabilizacyjne. Obejmują one między innymi zamrożenie aktywów, ograniczenia finansowe, zakazy podróży oraz restrykcje wobec osób i organizacji zaangażowanych w cyberataki, kampanie wpływu i działania sabotażowe.

Wspólny pakiet sankcji ogłoszony przez Unię Europejską i Wielką Brytanię pokazuje, że cyberbezpieczeństwo stało się integralnym elementem polityki odstraszania oraz odpowiedzi na zagrożenia hybrydowe. To także sygnał, że państwa europejskie coraz częściej łączą atrybucję techniczną z narzędziami prawnymi i finansowymi.

W skrócie

UE i Wielka Brytania wspólnie ogłosiły sankcje wobec rosyjskich osób i podmiotów oskarżanych o koordynowanie cyberataków oraz działań hybrydowych wymierzonych w Europę. Restrykcje objęły funkcjonariuszy rosyjskich służb, osoby powiązane z operacjami malware oraz struktury wspierające rekrutację i organizację zaplecza dla kampanii cybernetycznych.

Równolegle publicznie wskazano rosyjskie struktury państwowe jako podmioty nadzorujące znane grupy APT, w tym Turla. Decyzja wpisuje się w szerszy trend wzmacniania odpowiedzi regulacyjnej na zagrożenia dla administracji publicznej, sektora strategicznego i infrastruktury krytycznej.

Kontekst / historia

Przypisywanie Rosji operacji cybernetycznych przeciwko państwom europejskim nie jest zjawiskiem nowym. Od lat służby wywiadowcze, zespoły reagowania i instytucje rządowe wskazują na długotrwałe kampanie cyberszpiegowskie oraz sabotażowe prowadzone przeciwko administracji, obronności, energetyce i innym kluczowym sektorom.

W ostatnich latach szczególną uwagę zwracały działania grup powiązanych z rosyjskimi strukturami państwowymi, takich jak Turla czy Sandworm. W tle pozostają również incydenty dotyczące państw regionu, w tym ataki na sektor energetyczny oraz próby naruszenia systemów instytucji o znaczeniu strategicznym. Obecny pakiet sankcyjny jest więc częścią dłuższego procesu przechodzenia od reakcji wyłącznie technicznej do odpowiedzi politycznej, finansowej i prawnej.

Analiza techniczna

Z technicznego punktu widzenia nowy pakiet sankcji nie odnosi się do pojedynczej podatności ani jednego wektora ataku. Dotyczy całego ekosystemu zagrożeń, w którym służby państwowe, wykonawcy prywatni, cyberprzestępcy oraz podmioty prowadzące operacje wpływu funkcjonują jako wzajemnie wspierające się warstwy.

Publiczne wskazanie struktur rosyjskich służb jako zaplecza dla grup APT ma duże znaczenie operacyjne. Oznacza formalne połączenie między kampaniami cyberszpiegowskimi a instytucjonalnym wsparciem państwa. Dla obrońców to cenna informacja, ponieważ pozwala lepiej mapować przeciwnika do znanych technik, taktyk i procedur oraz trafniej oceniać skalę ryzyka.

Grupy tego typu są kojarzone z długotrwałym utrzymywaniem dostępu do sieci ofiar, eksfiltracją danych, nadużywaniem legalnych narzędzi administracyjnych oraz korzystaniem z wieloetapowej infrastruktury dowodzenia i kontroli. W kampaniach wymierzonych w infrastrukturę krytyczną pojawia się także scenariusz łączenia rozpoznania środowiska IT z próbami przejścia do segmentów OT, a następnie wdrażania komponentów destrukcyjnych, w tym malware typu wiper.

Istotne jest również uwzględnienie osób i podmiotów powiązanych zarówno z kradzieżą informacji, jak i z działalnością dezinformacyjną. To potwierdza, że granica między cyberprzestępczością, wywiadem a operacjami wpływu staje się coraz mniej wyraźna. Dla zespołów bezpieczeństwa oznacza to potrzebę analizowania incydentów nie tylko przez pryzmat IOC i artefaktów malware, ale także w szerszym kontekście geopolitycznym.

Konsekwencje / ryzyko

Najważniejszą konsekwencją wspólnych sankcji jest potwierdzenie, że zagrożenia sponsorowane przez państwo pozostają jednym z głównych czynników ryzyka dla Europy. Dotyczy to przede wszystkim administracji publicznej, operatorów usług kluczowych, energetyki, telekomunikacji, obronności, badań naukowych oraz łańcuchów dostaw IT.

Dla organizacji ryzyko ma kilka wymiarów. Po pierwsze, rośnie prawdopodobieństwo kampanii ukierunkowanych na uzyskanie długotrwałego dostępu do sieci i kradzież danych. Po drugie, realne pozostaje zagrożenie dla środowisk OT, gdzie nawet częściowe zakłócenie procesów może prowadzić do poważnych strat operacyjnych. Po trzecie, trzeba liczyć się z operacjami hybrydowymi, w których incydent cybernetyczny jest połączony z presją informacyjną, manipulacją opinią publiczną lub próbą destabilizacji otoczenia regulacyjnego.

Z perspektywy strategicznej sankcje nie eliminują zagrożenia, ale zwiększają koszt prowadzenia takich operacji i wzmacniają podstawy do koordynacji międzynarodowej. Dla obrońców ważne jest jednak przede wszystkim to, że formalne wskazanie sprawców powinno przełożyć się na aktualizację modeli zagrożeń, priorytetyzację monitoringu i lepsze przygotowanie do reagowania.

Rekomendacje

Organizacje, zwłaszcza działające w sektorach krytycznych, powinny potraktować tę sytuację jako impuls do przeglądu odporności operacyjnej. W praktyce warto skupić się na kilku kluczowych obszarach:

zaktualizować threat modeling o scenariusze związane z aktorami państwowymi i grupami APT,
wzmocnić segmentację sieci oraz ścisłe oddzielenie środowisk IT od OT,
rozbudować detekcję lateral movement, nadużyć legalnych narzędzi i nietypowych połączeń zewnętrznych,
egzekwować MFA dla dostępu administracyjnego, zdalnego i VPN,
przeprowadzić przegląd kont uprzywilejowanych oraz ekspozycji usług zdalnych,
zweryfikować procedury tworzenia kopii zapasowych i odtwarzania po incydencie,
korelować logi z systemów EDR, SIEM, IAM i urządzeń sieciowych,
regularnie ćwiczyć scenariusze destrukcyjne, w tym użycie malware typu wiper,
utrzymywać bieżącą współpracę z CERT-ami, regulatorami i partnerami branżowymi.

W organizacjach o podwyższonym profilu ryzyka warto dodatkowo rozszerzyć monitoring o analizę kampanii wpływu i zdarzeń reputacyjnych. Incydent techniczny może bowiem stanowić tylko jeden z elementów szerszej operacji informacyjnej.

Podsumowanie

Wspólny pakiet sankcji cybernetycznych UE i Wielkiej Brytanii stanowi wyraźny sygnał, że działania w cyberprzestrzeni są traktowane jako element szerszej agresji hybrydowej. Wskazanie konkretnych osób, podmiotów i struktur rosyjskich służb wzmacnia proces publicznej atrybucji oraz pokazuje rosnącą determinację Europy w reagowaniu na cyberataki wymierzone w państwa członkowskie i infrastrukturę krytyczną.

Dla zespołów bezpieczeństwa najważniejszy wniosek pozostaje praktyczny: zagrożenia sponsorowane przez państwo są nadal aktualne, wielowarstwowe i ściśle powiązane z realnym ryzykiem operacyjnym. Odpowiedzią nie może być wyłącznie punktowe łatanie podatności, lecz dojrzałe podejście obejmujące detekcję, segmentację, gotowość do reagowania oraz stałe uwzględnianie kontekstu geopolitycznego.

Źródła

https://www.bleepingcomputer.com/news/security/eu-and-uk-hit-russia-with-first-joint-cyber-sanctions-package/
https://www.consilium.europa.eu/
https://www.gov.uk/

Nadużycie API GitHub przez „ghost accounts” w masowej kampanii rekonesansowej

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

Masowa kampania rozpoznawcza z użyciem „ghost accounts” i API GitHub

Wprowadzenie do problemu / definicja

API GitHub jest jednym z kluczowych elementów nowoczesnych środowisk deweloperskich. Umożliwia automatyzację procesów, integrację narzędzi bezpieczeństwa oraz analizę projektów open source, ale jednocześnie tworzy powierzchnię ataku atrakcyjną dla cyberprzestępców. Najnowsze obserwacje wskazują na kampanię rozpoznawczą, w której wykorzystywane są tzw. „ghost accounts”, czyli konta założone lata wcześniej i przez długi czas pozostające nieaktywne.

Celem takich działań nie jest od razu bezpośrednia kompromitacja środowiska, lecz ciche mapowanie organizacji, repozytoriów i relacji pomiędzy użytkownikami platformy. Tego typu rekonesans może stanowić wstęp do dalszych operacji wymierzonych w kod źródłowy, tożsamości deweloperów oraz łańcuch dostaw oprogramowania.

W skrócie

Kampania polega na nadużywaniu API GitHub do systematycznej enumeracji publicznie dostępnych danych o organizacjach i ich członkach. Atakujący korzystają z sieci uśpionych kont, które aktywują się falami i generują ruch przypominający legalne użycie interfejsów API.

wykorzystywane są konta długo pozostające nieaktywne,
ruch obejmuje zapytania do publicznych danych organizacji i użytkowników,
aktywność miesza się z normalnym ruchem operacyjnym,
w części przypadków doszło także do prób użycia ujawnionych tokenów GitHub,
sporadycznie obserwowano również skuteczną eksfiltrację danych.

Kontekst / historia

Zidentyfikowana aktywność była prowadzona od co najmniej października 2025 roku i obejmowała ponad 50 kont wykorzystywanych do wysyłania zapytań API do wielu organizacji. Charakterystycznym elementem operacji było używanie kont zarejestrowanych od dwóch do pięciu lat wcześniej, które dopiero po długim okresie bezczynności rozpoczęły skoordynowaną aktywność.

To zjawisko wpisuje się w szerszy trend nadużywania legalnych platform developerskich do celów wywiadowczych. GitHub jest dla przeciwników szczególnie cennym źródłem informacji, ponieważ pozwala odtworzyć strukturę organizacji, zależności pomiędzy zespołami, aktywność poszczególnych użytkowników i znaczenie konkretnych projektów.

W praktyce oznacza to, że nawet publiczne dane mogą dostarczyć atakującemu wystarczająco dużo wiedzy do przygotowania ukierunkowanego phishingu, ataków na konta uprzywilejowane lub operacji nastawionych na kradzież kodu i naruszenie bezpieczeństwa łańcucha dostaw.

Analiza techniczna

Technicznie kampania opiera się na połączeniu automatycznych skanerów, koordynacji wielu kont oraz w niektórych przypadkach wykorzystania ujawnionych poświadczeń. Duża część powierzchni API GitHub jest dostępna bez uwierzytelnienia, co pozwala pobierać dane publiczne bez generowania oczywistych błędów autoryzacyjnych.

Atakujący wykorzystywali zarówno zapytania GraphQL, jak i klasyczne endpointy REST. Dzięki temu mogli budować szczegółowy obraz organizacji i zależności pomiędzy użytkownikami oraz projektami.

listowanie publicznych repozytoriów organizacji,
analiza członkostwa w organizacjach,
przegląd list followers i following użytkowników,
identyfikacja gwiazdkowanych repozytoriów i gistów,
budowanie grafu powiązań między osobami, zespołami i projektami.

Szczególnie problematyczne z punktu widzenia detekcji jest to, że takie zapytania zwracają poprawne odpowiedzi HTTP 200 i bardzo łatwo zlewają się z legalnym ruchem. Rekonesans nie musi wykorzystywać exploitów, omijania uwierzytelnienia czy agresywnych prób dostępu, aby pozostać skuteczny.

W badanych przypadkach konta używały nazw user-agentów przypominających legalne narzędzia analityczne, dashboardowe lub związane z transferem danych. To znacząco utrudnia ręczne odróżnienie prawidłowych integracji od działań wrogich. W jednym z incydentów aktywność rozszerzyła się o wykorzystanie przypadkowo ujawnionych tokenów należących do legalnych użytkowników, co umożliwiło kierowanie zapytań do prywatnych ścieżek commitów z wielu kont w krótkim czasie.

Konsekwencje / ryzyko

Sama enumeracja publicznych danych nie zawsze prowadzi bezpośrednio do kompromitacji, ale jej wartość operacyjna jest bardzo wysoka. Atakujący mogą na tej podstawie określić, które repozytoria są kluczowe, kto odpowiada za ich utrzymanie i które konta mogą stanowić najcenniejszy cel dalszych działań.

identyfikacja właścicieli projektów i administratorów,
mapowanie architektury organizacyjnej i technicznej,
przygotowanie kampanii spear phishingowych,
korelacja kont GitHub z innymi tożsamościami i platformami,
wyszukiwanie oznak błędnej konfiguracji lub wycieku sekretów.

Ryzyko znacząco rośnie, gdy dane publiczne zostają połączone z ujawnionymi poświadczeniami. Wówczas przeciwnik może przejść od samego rozpoznania do prób dostępu do prywatnych repozytoriów, historii commitów, sekretów zapisanych w kodzie, workflow CI/CD czy artefaktów budowania. Dla organizacji oznacza to zagrożenie dla własności intelektualnej, ciągłości dostarczania oprogramowania i bezpieczeństwa całego ekosystemu wytwórczego.

Rekomendacje

Organizacje korzystające z GitHub powinny traktować platformę jako krytyczny element powierzchni ataku. Monitoring jej aktywności powinien być porównywalny z nadzorem nad systemami IAM, chmurą i kluczowymi usługami tożsamościowymi.

włączenie strumieniowania logów audytowych GitHub do centralnego systemu SIEM,
zbudowanie bazowej linii normalnych user-agentów, integracji i wzorców dostępu,
wykrywanie rzadkich lub niestandardowych user-agentów wykonujących zapytania do zasobów prywatnych,
monitorowanie nagłych fal aktywności z wielu kont wobec tych samych organizacji i repozytoriów,
przegląd oraz rotacja tokenów używanych przez automatyzację i integracje,
wdrożenie zasady minimalnych uprawnień dla tokenów i aplikacji,
regularne wyszukiwanie wycieków sekretów w kodzie, pipeline’ach i systemach pomocniczych,
korelacja zdarzeń API z aktywnością użytkowników, zmianami uprawnień i klonowaniem repozytoriów,
prowadzenie proaktywnego threat huntingu pod kątem nietypowej enumeracji GraphQL i REST.

W praktyce najcenniejsze są detekcje oparte nie tylko na wolumenie zapytań, ale też na ich semantyce. Sekwencyjne przechodzenie przez organizacje, członków, obserwujących i repozytoria, a następnie próby sięgania po ścieżki prywatne, mogą wskazywać na operację rozpoznawczą przygotowującą dalsze etapy ataku.

Podsumowanie

Kampania wykorzystująca „ghost accounts” pokazuje, że legalne funkcje platform developerskich mogą zostać użyte do długotrwałego i trudnego do wykrycia rekonesansu. Nadużycia API GitHub nie muszą zaczynać się od exploitów ani przejęcia kont — wystarczy cierpliwa i dobrze zautomatyzowana enumeracja danych publicznych, aby zbudować dokładny obraz organizacji.

Gdy do takiego rozpoznania dołączą wyciekłe tokeny lub błędnie zabezpieczone integracje, ryzyko szybko eskaluje do eksfiltracji danych i kompromitacji repozytoriów. Dlatego monitoring aktywności API, kontrola tokenów i analiza anomalii w logach audytowych powinny stać się standardem w programach bezpieczeństwa środowisk programistycznych.

Źródła

SecurityWeek — Ghost Accounts Abuse GitHub API in Mass Recon Campaign — https://www.securityweek.com/ghost-accounts-abuse-github-api-in-mass-recon-campaign/
Datadog Security Labs — badania dotyczące kampanii rozpoznawczej w GitHub — https://securitylabs.datadoghq.com/
GitHub Docs — REST API documentation — https://docs.github.com/en/rest
GitHub Docs — GraphQL API documentation — https://docs.github.com/en/graphql
GitHub Docs — Audit log events and monitoring guidance — https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/audit-log-events-for-your-enterprise