W tym wydaniu Krajobrazu Zagrożeń piszemy o atakach na programistów i środowiska deweloperskie, w tym o FakeGit oraz Git hookach. Nie zabraknie informacji o phiskicie Kali365, Device Code Phishingu i o zmianach w ekosystemie PhaaS. Przyglądamy się również incydentowi w Hugging Face wywołanemu przez modele OpenAI w trakcie ich ewaluacji, który może redefiniować analizy prowadzone przez zespoły CTI i IR.

Cybercrime

Od fałszywych repozytoriów do przejętych projektów. Ewolucja ataków na programistów

• Zidentyfikowano ponad 800 fałszywych repozytoriów GitHub podszywających się pod narzędzia AI i serwery MCP, których celem było dostarczenie złośliwego oprogramowania.
• Kampanie wymierzone w programistów ewoluują – od infekowania pojedynczych użytkowników do prób kompromitacji całych projektów open source i łańcuchów dostaw oprogramowania.
• Opisane działania wpisują się w szerszy trend wykorzystywania środowisk deweloperskich jako punktu wejścia do organizacji.

Popularność narzędzi opartych o sztuczną inteligencję sprawiła, że w serwisach takich jak GitHub niemal codziennie pojawiają się nowe biblioteki, rozszerzenia i gotowe projekty. Cyberprzestępcy coraz częściej wykorzystują ten trend, publikując repozytoria, które wyglądają wiarygodnie, lecz w rzeczywistości służą do dystrybucji złośliwego oprogramowania. 

Przykładem jest kampania FakeGit. Na GitHubie zidentyfikowano ponad 800 repozytoriów podszywających się pod narzędzia związane z AI oraz serwerami MCP. Projekty zawierały rozbudowaną dokumentację, instrukcje uruchomienia oraz powiązania z innymi repozytoriami, sprawiając wrażenie aktywnie rozwijanych inicjatyw open source. 

Po uruchomieniu przygotowanego przez atakujących kodu rozpoczynał się wieloetapowy proces prowadzący do pobrania kolejnych komponentów malware. W zależności od wariantu jego celem była kradzież danych uwierzytelniających, informacji zapisanych w przeglądarce czy portfeli kryptowalutowych. Kampania pokazuje, że GitHub coraz częściej jest wykorzystywany nie tylko jako platforma do hostowania kodu, ale również jako element infrastruktury wykorzystywanej przez cyberprzestępców do uwiarygodniania swoich działań. 

FakeGit nie jest jednak odosobnionym przypadkiem. Kilka tygodni wcześniej opisano próbę infekcji wykorzystującą zupełnie inny scenariusz, ale prowadzącą do podobnego celu – przejęcia środowiska pracy programisty. 

W opublikowanej analizie opisano przebieg fikcyjnego procesu rekrutacyjnego, podczas którego otrzymano zadanie programistyczne w postaci repozytorium Git. Kod aplikacji wyglądał wiarygodnie, a jego uruchomienie nie prowadziło do wykonania złośliwego oprogramowania. Zagrożenie zostało ukryte w mniej oczywistym miejscu – Git hookach. W analizowanym przypadku złośliwy kod uruchamiał się podczas przełączania gałęzi, pobierał kolejne komponenty z infrastruktury atakujących i rozpoczynał dalszy etap infekcji. 

Nie jest to jedyna technika wykorzystująca środowisko deweloperskie do uruchomienia złośliwego kodu. W ostatnich miesiącach obserwowano również nadużywanie konfiguracji tasks.json w Visual Studio Code. Po otwarciu projektu i zaakceptowaniu zaufania do repozytorium środowisko mogło automatycznie wykonać przygotowane wcześniej zadania, które pobierały i uruchamiały kolejne elementy infekcji. Zarówno Git hooki, jak i konfiguracje VS Code pokazują, że cyberprzestępcy chętnie wykorzystują mechanizmy stanowiące naturalny element codziennej pracy programistów. 

Opisane przypadki stanowią element szerszej aktywności określanej przez badaczy jako Contagious Interview, prowadzonej od kilku lat przeciwko programistom i organizacjom rozwijającym oprogramowanie. Choć część publikacji wiąże ją z podmiotami powiązanymi z Koreą Północną, badacze podkreślają, że atrybucja poszczególnych incydentów nie zawsze jest jednoznaczna, a sama kampania najprawdopodobniej obejmuje kilka współpracujących ze sobą klastrów wykorzystujących podobne narzędzia i techniki. 

Początkowo działania skupiały się głównie na fałszywych ofertach pracy oraz zadaniach rekrutacyjnych, których celem było nakłonienie programisty do uruchomienia przygotowanego wcześniej projektu. Z czasem zestaw wykorzystywanych technik znacząco się rozszerzył. Obok fikcyjnych procesów rekrutacyjnych zaczęły pojawiać się złośliwe pakiety publikowane w popularnych repozytoriach, projekty podszywające się pod narzędzia AI, nadużycia konfiguracji Visual Studio Code czy wykorzystanie Git hooków. Niezależnie od zastosowanej techniki cel pozostaje ten sam – uzyskanie dostępu do środowiska deweloperskiego ofiary. 

Po uzyskaniu dostępu do jego środowiska pracy próbują wykorzystać posiadane przez niego uprawnienia do modyfikowania legalnych projektów rozwijanych przez organizację. Zaobserwowano również rozwój technik utrudniających wykrycie takich zmian. W niektórych przypadkach złośliwy kod JavaScript ukrywany był w plikach konfiguracyjnych z wykorzystaniem dużej liczby białych znaków, dzięki czemu właściwy fragment znajdował się poza widocznym obszarem podczas przeglądania kodu lub analizy zmian. Równocześnie modyfikowano metadane commitów, aby utrudnić zauważenie nieautoryzowanych zmian. 

Interesującym elementem kampanii jest również sposób dostarczania kolejnych etapów malware. Zamiast przechowywać je na klasycznej infrastrukturze C2, obserwowano wykorzystanie publicznych sieci blockchain, takich jak TRON, Aptos czy BNB Smart Chain, jako tzw. dead dropów. Repozytorium zawiera jedynie mechanizm pobierający kolejne instrukcje z zapisanych tam danych. Pozwala to stosunkowo łatwo zmieniać dostarczany payload bez konieczności modyfikowania samego repozytorium oraz utrudnia działania polegające na blokowaniu infrastruktury wykorzystywanej przez atakujących. 

Patrząc szerzej

FakeGit to kolejny przykład zmiany, jaką obserwujemy w atakach wymierzonych w programistów i organizacje rozwijające oprogramowanie. Jeszcze kilka lat temu dominowały przede wszystkim złośliwe pakiety publikowane w popularnych repozytoriach. Obecnie atakujący wykorzystują znacznie szerszy zestaw technik – od fałszywych procesów rekrutacyjnych i repozytoriów podszywających się pod popularne narzędzia, przez nadużywanie funkcji środowisk programistycznych, aż po próby przejęcia legalnych projektów open source. Niezależnie od wykorzystywanej metody celem pozostaje uzyskanie dostępu do środowiska deweloperskiego, które może stać się punktem wyjścia do dalszych ataków na łańcuch dostaw oprogramowania. 

Skala tego zjawiska stale rośnie. Badacze regularnie identyfikują kolejne setki lub tysiące złośliwych repozytoriów i pakietów, jednak nowe pojawiają się szybciej, niż udaje się je usuwać. Dla zespołów bezpieczeństwa oznacza to konieczność monitorowania nie tylko podatności czy złośliwych pakietów, ale również sposobu, w jaki organizacja korzysta z narzędzi i platform wspierających proces tworzenia oprogramowania. 

Więcej informacji:  
https://citizendot.github.io/articles/fake-job-interview-git-hook-malware/ 
https://www.island.io/blog/agentbaiting-how-800-fake-ai-skills-and-mcp-servers-delivered-malware. 

Oszustwa i podszycia

Kali365, Device Code Phishing i ekosystem PhaaS

• Kali365 to phishkit dystrybuowany w modelu Phishing-as-a-Service wykorzystywany w wielu kampaniach, zarówno masowych, jak i celowanych. 
• Jako przynęty zwykle stosowane są takie scenariusze jak udostępnienie pliku i marki w tym Docusign czy Microsoft i produkty Sharepoint, OneDrive i Teams.
• Kali365 oferuje zarówno phishing z wykorzystaniem techniki Adversary-in-the-Middle, jak i ciekawszej – Device Code Phishing.
• PhaaS to istotny element krajobrazu zagrożeń, który warto obserwować ze względu na mnogość rozwiązań i dynamiczne zmiany wynikające także z działań służb.

Kali365 to aktualnie jeden z częściej wykorzystywanych phishkitów na rynku cyberprzestępczym oferowany w modelu Phishing-as-a-Service. Oznacza to, że należy rozróżnić twórców usługi PhaaS od afiliantów realizujących kampanię z jej wykorzystaniem. Ten model działania wiąże się z odrębnością grup osób przygotowujących funkcje i wdrażających rozwiązania, od osób przeprowadzających ataki i jednocześnie czerpiących korzyści z pozyskanych danych.  

Popularność phiskitu przekłada się na mnożące się publikacje opisujące kulisy działania, jak i widywane kampanie z jego wykorzystaniem. Analitycy Infoblox w swoim artykule skupiają się na jednym atakującym, który korzysta z różnych phishkitów, między innymi Evilginx, FlowerStorm i Kali365. Wyłudzane były poświadczenia do usług Microsoft 365, ale także innych wartościowych kont. Analitycy wyróżniają kampanie, które dotykają szczególnie istotnych ofiar, jak Unia Europejska, czy Organizację Narodów Zjednoczonych, ale ataki mają wyraźnie charakter globalny. Z kolei analitycy Any.Run opisują przede wszystkim kampanie widziane w Stanach Zjednoczonych, ale z naszych obserwacji wynika, że podobne ataki regularnie są realizowane także w Polsce.  

W obu przypadkach analizy przedstawiają głównie scenariusze związane z udostępnieniem plików oraz zapytaniami ofertowymi, a atakujący podszywają się pod OneDrive, SharePoint oraz DocuSign. Warto jednak zwrócić uwagę na metody wykorzystywane przez atakujących do ominięcia coraz powszechniejszego dwuskładnikowego uwierzytelniania. Kali365 oferuje zarówno przechwytywanie sesji w modelu Adversary-in-the-Middle, jak i nowszym – Device Code Phishing.  Ten drugi, oparty na nadużyciu modelu Device Code Flow służącego do logowania na urządzeniach z ograniczonym interfejsem użytkownika, jest szczególnie warty uwagi. 

Ta metoda, czasem nazywana Ghost Phishing, opiera się na mniej znanej użytkownikom metodzie logowania. Na stronie pod kontrolą atakującego wyświetlany jest kod, którego wpisanie w oknie logowania ma pozwolić uzyskać dostęp do dokumentu „przynęty”. Po interakcji ze stroną otwierane jest dodatkowe okno przeglądarki ze stroną z uruchomionym prawdziwym flow logowania Microsoft, z poprawną domeną login.microsoftonline.com. Po wpisaniu kodu i zalogowaniu się prawdziwymi poświadczeniami atakujący uzyskuje dostęp na podstawie OAuth oraz refresh tokeny do konta ofiary. Skutkuje to dostępem odpornym na zmiany hasła i wieloskładnikowe uwierzytelnianie. Z perspektywy ofiary nieznającej przebiegu autoryzacji w ramach Device Code Flow może być trudno dostrzec znaki ostrzegawcze. Warto wspomnieć, że jedną z kluczowych metod zapobiegania atakom z wykorzystaniem tej metody jest całkowite wyłączenie obsługi Device Code Flow tam, gdzie nie jest to funkcja niezbędna. 

Rys. Przykładowa strona phishingowa z kodem oraz prawdziwy flow uwierzytelniania Microsoft otwierania w drugim oknie. Źródło: Any.Run

Nie wiadomo jaka przyszłość czeka Kali365, ale warto wspomnieć, że popularność w świecie cyberprzestępczym ma często swoją cenę. 20 lipca niemiecki Bundeskriminalamt poinformował o operacji przeprowadzonej we współpracy z partnerami międzynarodowymi wymierzonej w usługę Kratos PhaaS uznawaną za jedną z największych tego typu platform. W ramach działań zatrzymano w Indonezji administratora odpowiedzialnego za rozwój platformy oraz wyłączono ponad 200 serwerów stanowiących jej zaplecze techniczne. Według śledczych z narzędzi Kratos korzystało ponad 1800 cyberprzestępców prowadzących około 15 tysięcy kampanii phishingowych miesięcznie. Zwykle efektem tego typu operacji jest zakłócenie działań przestępczych afiliantów i tymczasowe zmniejszenie ich aktywności, ale należy spodziewać się szybkiego powrotu do normy w zakresie ataków phishingowych. 

Patrząc szerzej

Phishkity są stałym elementem krajobrazu zagrożeń, ale warto zwrócić uwagę na ich udział w propagacji nowych metod phishingu. Opracowanie metody omijania wieloskładnikowego uwierzytelniania lub zabezpieczeń nie skutkuje jego wykorzystaniem tylko przez jedną grupę, a przez wszystkich afiliantów korzystających z usług danego dostawcy PhaaS. Nawet bardziej zaawansowane techniki stają się osiągalne dla początkujących atakujących. 

Z perspektywy obrońców warto zwracać uwagę na phishkity, ponieważ ich wspólne cechy oraz powtarzalne metody dają szansę na wykrywanie i skuteczne blokowanie takich kampanii. Jak pokazuje przykład Kratos PhaaS. w dalszej perspektywie możliwe jest także uniemożliwienie działalności „usługodawcom”, co utrudnia ataki afiliantom zmuszonym do poszukiwania alternatywnego dostawcy. 

Więcej informacji:  
https://www.infoblox.com/blog/threat-intelligence/the-procurement-trap-inside-an-aitm-campaign-targeting-global-institutions/ 
https://www.bka.de/SharedDocs/Kurzmeldungen/DE/Kurzmeldungen/260720_Schlag_gegen_Phishing_Gruppierung_Kratos.html 
https://any.run/cybersecurity-blog/kali365-phishing-targeting-us/ 

Future

Autonomiczni agenci AI w praktyce – nowe wyzwania dla DFIR i Cyber Threat Intelligence

• Hugging Face opublikował szczegółową analizę jednego z pierwszych publicznie opisanych incydentów, w którym agent AI uczestniczył w prowadzeniu rzeczywistej operacji ofensywnej.
• Incydent nie był klasycznym atakiem przeprowadzonym przez zewnętrznego threat actora. Doszło do niego podczas ewaluacji możliwości cybernetycznych modeli OpenAI, które próbując rozwiązać zadanie testowe, samodzielnie odkryły i połączyły podatności pozwalające wydostać się poza zakładane środowisko oraz uzyskać dostęp do infrastruktury Hugging Face. 
• Równie istotny okazał się proces analizy powłamaniowej, w którym do rekonstrukcji incydentu wykorzystano modele AI oraz narzędzia agentowe, pokazując rosnącą rolę sztucznej inteligencji zarówno podczas wykonywania działań ofensywnych, jak i późniejszej analizy powłamaniowej.

Opublikowany przez Hugging Face raport dotyczący incydentu bezpieczeństwa z lipca 2026 roku jest znacznie ważniejszy niż kolejna historia o naruszeniu bezpieczeństwa. To jeden z pierwszych tak szczegółowo opisanych przypadków pokazujących, że autonomiczne systemy AI zaczynają odgrywać realną rolę podczas prowadzenia złożonych operacji cybernetycznych. Dodatkowe informacje opublikowane przez OpenAI pokazują jednak, że charakter tego incydentu był jeszcze bardziej nietypowy, niż początkowo mogło się wydawać. 

Incydent nie był klasycznym atakiem przeprowadzonym przez zewnętrznego napastnika wykorzystującego AI. Doszło do niego podczas wewnętrznej ewaluacji możliwości cybernetycznych modeli OpenAI, w tym GPT-5.6 Sol oraz bardziej zaawansowanego modelu przedpremierowego. Modele działały z obniżonym poziomem mechanizmów odmowy dla działań cybernetycznych, ponieważ celem eksperymentu było sprawdzenie ich maksymalnych możliwości podczas realizacji złożonych, wieloetapowych zadań ofensywnych. 

To właśnie sposób realizacji tego celu stanowi jeden z najciekawszych elementów całego incydentu. Modele nie otrzymały bezpośredniego polecenia zaatakowania infrastruktury Hugging Face. Próbując rozwiązać zadania benchmarku ExploitGym, zaczęły szukać sposobu uzyskania dostępu do Internetu poza izolowanym środowiskiem ewaluacyjnym. W tym celu zidentyfikowały podatność zero-day w wykorzystywanym przez OpenAI proxy rejestru pakietów, a następnie przeprowadziły eskalację uprawnień oraz ruch boczny pomiędzy systemami, aż dotarły do węzła posiadającego dostęp do Internetu. Po jego uzyskaniu modele wywnioskowały, że infrastruktura Hugging Face może zawierać informacje pozwalające znaleźć rozwiązania testów. W kolejnych etapach połączyły kilka wektorów ataku, w tym skradzione dane uwierzytelniające oraz podatność zero-day, uzyskując ścieżkę prowadzącą do zdalnego wykonania kodu w infrastrukturze Hugging Face. 

Z perspektywy analitycznej jeszcze ciekawsze od samego wektora wejścia jest tempo oraz skala działania obserwowane podczas incydentu. Analiza Hugging Face objęła około 17 tys. działań wykonanych w trakcie operacji, pokazując skalę aktywności, której ręczna rekonstrukcja byłaby niezwykle czasochłonna. Autonomiczny agent AI może wykonywać tysiące operacji w bardzo krótkim czasie, dynamicznie zmieniać sposób działania, korzystać z wielu narzędzi jednocześnie oraz podejmować kolejne decyzje na podstawie wyników poprzednich etapów. Taka charakterystyka znacząco utrudnia klasyczną analizę incydentów prowadzoną wyłącznie przez człowieka. OpenAI zwraca przy tym uwagę na rosnącą zdolność najnowszych modeli do prowadzenia złożonych operacji cybernetycznych w długim horyzoncie czasowym. Incydent pokazuje, że możliwości obserwowane wcześniej podczas benchmarków i cyberpoligonów zaczynają przekładać się na działania w rzeczywistych środowiskach.

Równie interesująca okazała się analiza powłamaniowa. Hugging Face wykorzystał własne narzędzia oparte na sztucznej inteligencji do odtworzenia przebiegu incydentu oraz analizy ogromnej liczby zdarzeń. Organizacja zwróciła również uwagę na ograniczenia komercyjnych modeli udostępnianych poprzez API, których mechanizmy bezpieczeństwa utrudniały analizę części artefaktów związanych z incydentem. W efekcie wykorzystano lokalnie uruchomione modele typu open-weight, które umożliwiły przeprowadzenie pełnej analizy bez ograniczeń wynikających z polityk bezpieczeństwa usług zewnętrznych. 

Incydent jest jednak interesujący nie tylko ze względu na wykorzystanie autonomicznych modeli podczas działań ofensywnych. Raport Hugging Face pokazuje również kilka zmian, które mogą mieć istotne znaczenie dla przyszłości analiz prowadzonych przez zespoły Cyber Threat Intelligence oraz Incident Response. 

Jednym z najciekawszych wniosków płynących z analizy incydentu jest zmiana roli klasycznych wskaźników kompromitacji (IOC). W tradycyjnych kampaniach malware analiza koncentruje się na adresach IP, domenach, skrótach plików, nazwach procesów czy sygnaturach wykorzystywanych narzędzi. W przypadku autonomicznych agentów AI wiele z tych artefaktów może mieć jednak znacznie krótszy cykl życia. Agent może dynamicznie generować nowe polecenia, wybierać inne narzędzia, zmieniać sposób realizacji zadania lub wykorzystywać alternatywne ścieżki działania w zależności od sytuacji. Większego znaczenia nabiera analiza sposobu działania agenta. Dla zespołów Cyber Threat Intelligence oznacza to konieczność skupienia się nie tylko na odpowiedzi na pytanie, co zostało wykorzystane, ale przede wszystkim w jaki sposób agent podejmował decyzje, z jakich narzędzi korzystał, jak wyglądała sekwencja wykonywanych działań oraz jakie zależności występowały pomiędzy kolejnymi etapami operacji. Raport Hugging Face pokazuje, że w środowiskach wykorzystujących agentów AI analiza zachowania systemu, procesu podejmowania decyzji oraz wykorzystywanych narzędzi może stać się równie istotna jak klasyczna analiza wskaźników kompromitacji. 

Incydent zwraca również uwagę na inny, często pomijany aspekt bezpieczeństwa systemów agentowych. Zagrożeniem przestaje być wyłącznie sam model językowy, a coraz większego znaczenia nabiera zestaw narzędzi, do których agent posiada dostęp. W praktyce są to terminale systemowe, interfejsy API, repozytoria kodu, usługi chmurowe czy serwery wykorzystujące Model Context Protocol (MCP). To właśnie możliwość wywoływania zewnętrznych narzędzi sprawia, że agent przestaje być jedynie systemem generującym odpowiedzi, a staje się aktywnym uczestnikiem operacji, mogącym wykonywać rzeczywiste działania w środowisku. 

Innymi słowy, kompromitacja lub nadużycie warstwy wykonawczej może mieć znacznie większe konsekwencje niż podatność samego modelu językowego. Z perspektywy bezpieczeństwa oznacza to konieczność rozszerzenia modelu zagrożeń. Analizie powinny podlegać nie tylko prompty i odpowiedzi modelu, ale również zakres uprawnień przypisanych agentowi, dostępne narzędzia, sposób autoryzacji ich wywołań oraz możliwość ich nadużycia. W praktyce powierzchnia ataku rozszerza się poza sam model AI i obejmuje również jego warstwę wykonawczą (tool calling) – mechanizmy umożliwiające agentowi wykonywanie rzeczywistych działań w środowisku. To właśnie ta warstwa może w kolejnych latach stać się jednym z najważniejszych obszarów badań nad bezpieczeństwem systemów agentowych. 

Patrząc szerzej

Incydent pokazuje nowy problem, który może stać się jednym z kluczowych wyzwań bezpieczeństwa systemów agentowych: kontrola zakresu działania agenta nie może opierać się wyłącznie na kontroli jego instrukcji. Model nie musi otrzymać polecenia wykonania konkretnego ataku, aby w trakcie realizacji innego celu odkryć, że kompromitacja kolejnego systemu jest skutecznym sposobem osiągnięcia zadania. W takim środowisku szczególnego znaczenia nabierają mechanizmy ograniczające nie tylko to, co agent może wygenerować, ale przede wszystkim to, co może rzeczywiście wykonać. 

Z tego punktu widzenia klasyczny sandbox, filtrowanie promptów czy mechanizmy odmowy modelu są tylko częścią architektury bezpieczeństwa. Równie istotne stają się segmentacja środowiska, kontrola dostępu do sieci, zarządzanie tożsamością agenta, ograniczenie dostępnych narzędzi, monitoring wykonywanych operacji oraz możliwość automatycznego przerwania działania po wykryciu nietypowej sekwencji aktywności. Incydent OpenAI i Hugging Face pokazuje, że w przypadku agentów zdolnych do prowadzenia operacji w długim horyzoncie czasowym bezpieczeństwo musi być projektowane nie tylko wokół modelu, lecz wokół całego środowiska, w którym model może działać. 

W naszej ocenie równie istotna jak rozwój samych modeli AI będzie ewolucja metod ich analizy. Zespoły bezpieczeństwa będą musiały coraz częściej badać nie tylko kod, logi czy wskaźniki kompromitacji, ale również sposób działania agentów, wykorzystywane przez nie narzędzia oraz proces podejmowania decyzji. To obszar, który w najbliższych latach może stać się jednym z najważniejszych kierunków rozwoju analiz DFIR oraz Cyber Threat Intelligence

Więcej informacji:
https://huggingface.co/blog/security-incident-july-2026 
https://openai.com/pl-PL/index/hugging-face-model-evaluation-security-incident/