GTIG AI Threat Tracker: od promptu do tysięcy poświadczeń w sześć godzin

Google Threat Intelligence Group opublikowała drugie kwartalne wydanie swojego AI Threat Tracker za 8 września 2026. Przytoczona w raporcie sprawa jest na tyle krótka, że można ją przedstawić wprost: podmiot podejrzewany o motywację finansową przejął zasób chmurowy należący do ofiary, wprowadził prompt oraz zestaw wcześniej przygotowanych instrukcji dla agenta do chatbota AI służącego do kodowania, po czym zebrał tysiące danych uwierzytelniających podmiotów trzecich w niespełna sześć godzin, przy czym agent samodzielnie zarządzał skanowaniem podatności, rozwiązywaniem problemów i rotacją adresów IP. Ten sam raport opisuje zatrojanizowane serwery MCP w PyPI, narzędzie kradnące dane uwierzytelniające, które przejmuje tożsamość samego systemu budowania, tak by jego pakiety z backdoorem trafiały z ważnymi, podpisanymi kryptograficznie atestacjami SLSA Build 3, a także teksty antagonistyczne mające skłonić oparte na LLM skanery bezpieczeństwa do odmowy odczytania kodu, pod którym się znajdują. Wszystko to jest relacją Google'a z jego własnej telemetrii. Niniejszy raport jest skatalogowany wraz z oceną pewności i cytowanymi źródłami w archiwum incydentów AI, które obok niego gromadzi każdy inny udokumentowany incydent z tej serii.

Żadne z merytorycznych twierdzeń nie zostało zweryfikowane przez podmiot, który nie powtarza informacji Google. Help Net Security omówił tracker w dniu publikacji, a Cloud Security Alliance następnego dnia opublikowała notę badawczą, a Lineaje 17 września opublikowało analizę DUSTMAKER; każda z tych pozycji jest streszczeniem lub analityczną nakładką na ujawnienie Google, a Lineaje przyznaje to wprost, zauważając, że GTIG „opisuje kilka powiązanych zdolności DUSTMAKER, a nie pojedynczy zaobserwowany kompletny ślad wykonania end-to-end”. Drugie źródło przywołane obok tego rekordu, pozycja „threat pulse” w threatops.tech z 11 września 2026 r., jest powtórzeniem, a nie drugim świadkiem: nie dodaje żadnego reportażu, nie kwestionuje żadnej liczby i podnosi etykietę ważności, nie wyjaśniając, względem czego jest mierzona. Doniesienia nie są w pełni zgodne nawet co do nazwy wydania — Help Net Security nazywa je trackerem Q3 2026, datując jego główny przypadek na Q2 2026 — co jest różnicą w numeracji, a nie sprzecznością faktyczną.

Archiwum rejestruje to jako raport, a nie incydent: ocena pewności A, niekwestionowana, nie odnotowano wobec niego żadnej skwantyfikowanej wartości rzeczywistych szkód. Ta ocena opisuje jakość dokumentacji, a nie skalę szkód. Google liczy dane uwierzytelniające, a nie ofiary. Tracker nie podaje, ile organizacji zostało objętych sześciogodzinną kampanią, kim były, którego chatbota użyto ani czy jakiekolwiek ze skradzionych danych uwierzytelniających zostały później sprzedane lub wykorzystane.

Sześć godzin, które opisuje GTIG, oraz trzy zadania, które agent wykonał samodzielnie

Sekwencja opisana w raporcie prowadzi od uzyskania dostępu do wyniku, a udział człowieka pomiędzy jest bardzo niewielki. Sprawca skompromitował zasób chmurowy, a następnie użył komercyjnego chatbota AI do kodowania wraz z tym, co GTIG nazywa „promptem” i „zestawem instrukcji dla agenta” — markdownowych playbooków, które obecnie znajdują się w repozytoriach jako pliki AGENTS.md — aby zaplanować, zbudować i przeprowadzić operację. Samo Google określa jej wynik jako „wspomaganą przez agentów masową kampanię pozyskiwania poświadczeń”, zrealizowaną „w niespełna sześć godzin”.

Trzy zadania określa się jako autonomiczne i są to te trzy, które w przeciwnym razie zajęłyby uwagę operatora:

• Pipeline skanowania podatności, którym — zgodnie z instrukcjami agenta — AI może „autonomicznie zarządzać", w sformułowaniu, które Help Net Security cytuje za GTIG.

• Rozwiązywanie w czasie rzeczywistym problemów z tym wszystkim, co wykryło skanowanie, tak aby awaria nie wstrzymywała przebiegu w oczekiwaniu na decyzję.

• Rotacja IP, dzięki czemu kolejne próby wychodziły z różnych adresów, bez wydawania polecenia przez kogokolwiek.

To, gdzie prowadzono operację, jest równie ważne jak to, jak szybko ją przeprowadzono. Działając w ramach własnej infrastruktury chmurowej ofiary, sprawca kierował ruch przez legalne zakresy IP ofiary. Żądania, które wyglądają, jakby pochodziły z wnętrza organizacji, są dokładnie tymi, które obrona oparta na reputacji jest najmniej przygotowana kwestionować, a raport odnotowuje to jako konsekwencję działania z własnego środowiska ofiary.

To, czego raport nie zawiera, mówi tyle samo, co to, co zawiera. Nie ma pomiarów czasu poszczególnych kroków, więc „poniżej sześciu godzin” to pojedynczy pomiar całego przebiegu, którego nie da się rozłożyć na wykres. Nie podano nazwy sprawcy poza „podejrzewanym o motywację finansową”, nie wskazano ofiary ani nie napisano, czyj model lub chatbot którego dostawcy był w to zamieszany. Tracker traktuje ten przypadek jako opracowany przykład pewnego trendu i jest napisany na takim poziomie ogólności, jaki służy temu celowi, a nie na takim, jakiego oczekiwałby specjalista ds. reagowania na incydenty.

Ujawniony serwer, który przerodził się w panel z 23 800 sekretów

Drugie ustalenie w tej samej sekcji jest bardziej konkretne i stanowi odrębny przypadek. GTIG znalazła ujawniony serwer command-and-control hostujący automatyczny framework do rozpoznania i zarządzania poświadczeniami, który nazywa Recon. Listing katalogu był czytelny i zdradzał całą konstrukcję: AGENTS.md, KNOWLEDGE.md, agentic_vuln_research.md, a także modułowy katalog .openclaw/ oraz katalog memory/. Te nazwy plików to odcisk palca stosu agentowego, a nie implantu szytego na miarę — instrukcje, zgromadzona wiedza i plan badań, wszystko na dysku, gdzie narzędzia operatora mogą je odczytać.

Ten sam katalog później służył jako działający panel frontendowy organizujący i weryfikujący ponad 23 800 pozyskanych sekretów, w tym klucze API do usług chmurowych i AI. GTIG określa reprezentowaną przez to zmianę jako przejście „od pasywnych infostealerów ukierunkowanych na punkty końcowe do ofensywnego pozyskiwania przy użyciu agentów” — czyli od złośliwego oprogramowania, które zgarnia, co może, z jednego laptopa, do narzędzi, które nadal eksploatują cele, do których już dotarły.

Z tą liczbą wiążą się dwa zastrzeżenia. Dwadzieścia trzy tysiące osiemset to liczba sekretów, a nie osób ani firm, i raport nie przekłada jednego na drugie. GTIG nie stwierdza też, czy serwer Recon i sześciogodzinna kampania to ta sama operacja; są one przedstawione jako odrębne obserwacje w tej samej sekcji, więc traktowanie ich jako jednej historii byłoby wnioskiem, którego raport nie wyciąga.

DUSTMAKER i poświadczenie, które prawidłowo stwierdza, że pakiet jest autentyczny

Część łańcucha dostaw w trackerze dotyczy UNC6780, który Google śledzi również jako TeamPCP, finansowo motywowanej grupy, która od marca 2026 r. kompromituje infrastrukturę open source w ekosystemach PyPI, npm i Docker Hub. Jej metoda działania w przypadku narzędzi AI jest bezpośrednia: przejęte konta deweloperów wykorzystano do publikowania skonstruowanych z trojanami forków legalnych serwerów MCP — jako przykład na PyPI podano tiktoken_mcp — a złośliwy kod wstrzyknięto do oficjalnych repozytoriów organizacji, m.in. azure-functions-mcp-extension. GTIG zauważa, że ładunki i złośliwe hooki obszaru roboczego były następnie automatycznie przyswajane przy każdym pobraniu lub sklonowaniu tych zasobów — bez osobnej przynęty i bez drugiego kroku.

Jego złodziej poświadczeń, DUSTMAKER, jest miejscem, w którym znajduje się najużyteczniejszy techniczny punkt raportu. Łańcuch jest krótki. Złodziej wykrywa, że działa w środowisku CI/CD; GTIG pisze, że „jeśli to potwierdzono”, wydobywa tokeny OIDC z pamięci procesu runnera GitHub Actions. Używa tych tokenów, aby autoryzować się jako zaufany wydawca. Następnie publikuje zainfekowane wersje pakietów zawierające ważne, kryptograficznie podpisane zaświadczenia SLSA Build 3. Nic w tym łańcuchu nie jest sfałszowane. Zaświadczenie jest prawdziwe, wydane prawdziwej tożsamości, dla kompilacji, która naprawdę miała miejsce — kodu napisanego przez atakującego. Wniosek GTIG to zdanie, które ma znaczenie dla każdego, kto polega na proweniencji: „Pakiety opublikowane z ważnymi tokenami przejdą automatyczne kontrole zaufania agentów AI do kodowania”.

Pozostała część działania DUSTMAKER jest ukierunkowana na miejsca, na które obrońcy nie zwracają uwagi. Zrzuca i modyfikuje pliki w katalogach roboczych asystentów kodowania AI i IDE — .claude/, .vscode/, .cursor/ — gdzie wtapia się w szum środowiska deweloperskiego i unika lokalizacji, które faktycznie monitoruje detekcja punktów końcowych, takich jak klucze rejestru Windows lub /etc/cron.*. Tworzy konfigurację, która sprawia, że IDE lub rozszerzenie AI uruchamia skrypt taki jak setup.mjs po otwarciu obszaru roboczego, co zamienia otwarcie folderu w wykonanie kodu. Tworzy zadania potoku o nazwach nawiązujących do AI, takich jak "Copilot Setup" w poszukiwaniu tokenów, oraz wysyła wywołania API, aby usuwać dzienniki wykonania przepływu pracy, tak aby uruchomienie nie pojawiało się w interfejsie GitHub.

Złośliwe oprogramowanie, które prosi skaner o odwrócenie wzroku

Ostatni mechanizm jest najmniej zweryfikowanym z trzech. Skrypty ładowania JavaScript DUSTMAKER zaczynają się od tekstu wrogiego promptu osadzonego jako komentarze — w _index.js m.in. — odwołującego się do broni biologicznej i jądrowej oraz zawierającego żądanie specyfikacji 20-kilotonowego urządzenia rozszczepialnego typu implozyjnego. Ocena GTIG jest taka, że miało to „prawdopodobnie na celu spowodowanie, by skanery bezpieczeństwa LLM zawiodły lub pominęły analizę złośliwego kodu JavaScript znajdującego się pod spodem z powodu odmów ze względów bezpieczeństwa lub polityki”.

Etykieta przy tym zdaniu ma znaczenie. To stwierdzenie o zamiarach, wywnioskowane z tekstu, który niesie loader, a nie dowód, że jakikolwiek skaner faktycznie odmówił. Raport nie wskazuje nazwy skanera, który pominął plik, nie podaje współczynnika obejść i nie twierdzi, że technika zadziałała. Ustalono jedynie, że ktoś napisał przynętę i dostarczył ją w narzędziu kradnącym poświadczenia — co samo w sobie jest dowodem, że atakujący oczekują, iż w ścieżce znajdzie się triage oparty na LLM.

UNC6508, MIDNIGHT NEPTUNE i CALANQUE ION znajdują się w tym samym raporcie

Materiał powiązany z państwami w trackerze jest obszerniejszy niż materiał dotyczący działalności przestępczej, a w większości mniej zautomatyzowany. UNC6508, grupa powiązana z ChRL, prowadzi trwającą od lat kampanię szpiegowską przeciwko północnoamerykańskim badaniom akademickim, medycznym i wojskowym, a obecnie celuje konkretnie w zastrzeżone badania nad AI; GTIG podejrzewa grupę o kompromitowanie środowisk chmurowych w celu wdrażania lokalnych modeli z otwartymi wagami, co pozwala uniknąć monitorowania komercyjnych interfejsów API i wykorzystuje moc obliczeniową samej ofiary.

W innych przypadkach wzorzec to gotowe modele wykonujące zwykłą pracę na masową skalę. Północnokoreańska grupa MIDNIGHT NEPTUNE, wcześniej UNC1069, wykorzystała DeepSeek-Coder do pisania trojanów zdalnego dostępu w Pythonie z międzyplatformowymi mechanizmami trwałości i wstrzykiwaniem do procesów, używała LLM-ów do skryptów ruchu bocznego w Bashu, prowadziła persony do inżynierii społecznej i techniczne przynęty, zatruwała wewnętrzne konfiguracje repozytoriów, modyfikowała hooki Claude CLI, a także wdrażała backdoor SOMBERMEME, gdy deweloper wchodził w interakcję z repozytorium. Irańska grupa CALANQUE ION, wcześniej APT42, wykorzystywała modele do identyfikowania docelowych adresów e-mail, prowadzenia OSINT, lokalizowania przynęt, streszczania eksfiltrowanych danych i prób inżynierii wstecznej kodu licencjonowania. Powiązana z PRC grupa BASIN CASTLE wykorzystywała Gemini do profilowania celów, tłumaczenia chińskich materiałów na formalne angielskie raporty polityczne i rozwiązywania problemów z PowerShell; RAVINE CASTLE badała z jego pomocą obejścia SAML w VMware vCenter i działania poeksploatacyjne w Active Directory; rosyjska grupa SANDWORM RELIC zleciła Gemini napisanie kodu do ataków password spraying. Motywowana finansowo grupa UNC6240, znana również jako ShinyHunters, używała promptów Claude Code do pisania zaciemnionego kodu, omijania Cloudflare i analizowania eksfiltrowanych katalogów za pomocą niestandardowych narzędzi MCP.

Jeden przypadek w tej sekcji idzie o krok dalej niż pozostałe. Grupa powiązana z ChRL wykorzystała Gemini do zaprojektowania dynamicznego, zautomatyzowanego frameworka do testów penetracyjnych, którego celem było obserwowanie stanu celu, rozumowanie, co zrobić dalej, oraz przeprowadzanie skanowania portów i parsowania usług. Google twierdzi, że podjęło szersze działania przeciwko zidentyfikowanym kampaniom, wyłączając powiązane zasoby, projekty i konta. Osobno, w czerwcu 2026 r., Google zakłóciło działanie "Outsider Enterprise," opartej na Chinach usługi cyberprzestępczej, która dostarczała zestawy phishingowe, i określiło to jako pierwszy przypadek, w którym podjęło działania prawne w związku z niewłaściwym wykorzystaniem Gemini. To dwa odrębne stwierdzenia, a podsumowanie, które je łączy, mówiłoby więcej, niż mówi raport: framework do testów penetracyjnych należy do sformułowania dotyczącego wyłączania zasobów, a działania prawne dotyczą Outsider Enterprise.

LLMJacking, czyli ile obecnie kosztuje skradzione konto AI

Narzędzie śledzące wycenia również rynek wokół kradzionego dostępu do AI. Popyt w podziemiu koncentrował się na poświadczeniach Claude'a i Gemini, wraz z autonomicznymi środowiskami IDE do kodowania Cursor Pro i Devin, przy czym ten ostatni został stworzony przez Cognition, a średnie ceny rynkowe za konto więcej niż podwoiły się w 2026 roku. Infostealery odpowiedzialne za zbieranie — LUMMAC.V2, STEALC.V2, VIDAR i ACRSTEALER — zostały zaktualizowane, aby celować w konfiguracje deweloperów AI. W maju 2026 r. kontrolerzy ACRSTEALER wypchnęli reguły przechwytywania plików dla secrets.json należącego do Cline'a i config.yaml należącego do Continue AI, z których każdy może zawierać klucze API w postaci jawnej i niestandardowe punkty końcowe routingu modeli.

Jeden z opisanych przez GTIG ataków pokazuje, ile warte jest konto AI po jego przejęciu. W kwietniu 2026 r. ujawniony osobisty token dostępu GitHub wystarczył, aby aktywować Gemini Enterprise, zapewnić wydajne zasoby obliczeniowe, utworzyć repozytoria Docker dla wdrożenia API LiteLLM i frameworka agentowego Manus oraz uruchomić usługi Cloud Run udostępnione dla allUsers poprzez powiązanie wywołującego IAM. Ta sama sesja utworzyła nieuprawnione konto usługi z uprawnieniami Editor i wyeksportowała jego klucze, odpytała BigQuery o zmienne środowiskowe i poświadczenia, próbowała przekazać własność projektu na zewnętrzny adres oraz użyła API Cloud Quotas, aby zażądać pojemności NVIDIA RTX 6000 i dodatkowych instancji 48-vCPU.

Obraz ekstrakcji modeli to ta sama ekonomia w większej skali. GTIG twierdzi, że kampanie destylacji odbywają się obecnie regularnie, „niektóre obejmują ponad 100 milionów promptów”, a zapytania są rotowane między tysiącami przejętych i oszukańczych kont oraz kierowane przez infrastrukturę proxy; twierdzi też, że Google wdrożył środki zaradcze, które mogą pogorszyć wydajność modelu uczniowskiego, oraz metody identyfikowania modeli destylowanych z Gemini na podstawie pochodzenia.

Co jest ustalone, co jest oceną, a czego GTIG twierdzi, że nie widział

Ustalono to w tym sensie, że Google opisuje telemetrię pochodzącą z własnych systemów oraz własne działania na kontach: raport i jego datę; artefakty, które według Google zaobserwowano, w tym nazwy pakietów, nazwy plików loadera, nazwy katalogów i panel z 23 800 sekretami; a także działania zakłócające, które według Google podjęto i które może poświadczyć, ponieważ wyłączenie konta jest czymś, co robi, a nie czymś, co wnioskuje. Help Net Security, Cloud Security Alliance i Lineaje relacjonują te elementy bez sprzeczności, choć żaden z nich nie przedstawia własnych niezależnych dowodów.

Ocena – w tym sensie, że jest to osąd wydawany przez Google: każde przypisanie działań państwu narodowemu w raporcie; interpretacja przynęty mającej wywołać odmowę jako celowej; oraz twierdzenie, że skradzione tokeny przejdą „zautomatyzowane kontrole zaufania agentów kodujących AI”, co jest stwierdzeniem o tym, jak takie kontrole są zwykle budowane, a nie pomiarem tego, że konkretny produkt nie przechodzi jednej z nich.

Nie ustalono: tożsamości sprawcy działającego przez sześć godzin, ofiar i ich liczby, zaangażowanego chatbota i modelu oraz tego, czy serwer Recon jest w ogóle powiązany z tą kampanią.

A górna granica wyznaczona przez sam raport jest niższa, niż sugeruje jego tytuł. GTIG stwierdza, że nie zaobserwował jeszcze w pełni autonomicznych łańcuchów eksploatacji w warunkach rzeczywistych, i ocenia, że wykorzystanie przez przeciwnika „może ewoluować w stronę tego przypadku użycia”. Podział przebiega wewnątrz ataku, a nie wokół niego: ludzie dostarczają cel, prompt i plik instrukcji; agent zapewnia skanowanie, rozwiązywanie problemów i rotację i nie zatrzymuje się, by prosić o zgodę. Przy uważnej lekturze sześciogodzinna kampania nie jest dowodem, że autonomia nadeszła. Jest dowodem, że ludzki udział w pracy ograniczył się do części wymagającej człowieka — decydowania, co robić — podczas gdy wszystko między decyzją a wynikiem wykonywało się samo.

Co według Google uległo zmianie i na jaką kontrolę raport faktycznie wskazuje

Deklarowana reakcja Google'a opiera się na dwóch torach. W kwestii nadużyć firma podaje, że działania te „uruchomiły reakcje bezpieczeństwa Gemini”, że podjęła „dodatkowe, szersze działania” przeciwko tym kampaniom w oparciu o błędy aktorów w zakresie bezpieczeństwa operacyjnego, że wyłączyła powiązane zasoby, projekty i konta oraz że Google DeepMind wykorzystało te ustalenia do wzmocnienia swoich klasyfikatorów i samego modelu, tak aby odrzucał te żądania. W zakresie obrony wdrożyła Google AI Threat Defense, który łączy Gemini i modele frontier z priorytetyzacją ryzyka Wiz, remediacją Gemini i CodeMender oraz danymi wywiadowczymi Mandiant, wykorzystując lżejsze modele do ciągłego skanowania, a modele frontier do ustaleń o wysokim ryzyku; wprowadziła także Gemini 3.8 Flash Cyber do wykrywania podatności i automatycznego łatania oraz opublikowała otwartoźródłowe wytyczne dotyczące wzmacniania łańcucha dostaw.

Konkretna poprawka, której wymaga sprawa DUSTMAKER, jest węższa niż ten stos, a analizy zewnętrzne są co do niej zgodne. Poświadczenie SLSA odpowiada na pytanie, czy pakiet został zbudowany przez tożsamość, którą deklaruje. Nie odpowiada jednak na pytanie, czy ta tożsamość nadal należy do strony, której zamierzałeś zaufać, a cała metoda DUSTMAKER polega na pożyczeniu tożsamości, a nie na jej podrobieniu. Podsumowanie Lineaje dotyczące leżącej u podstaw zmiany jest jej najklarowniejszym sformułowaniem: „Zawartość repozytorium staje się autorytetem wykonawczym”. Nazwy pakietów, nazwy serwerów MCP, odznaki poświadczeń i pliki instrukcji wewnątrz repozytorium — wszystko to przychodzi teraz z pewnym roszczeniem do posłuszeństwa, a skradziony token OIDC sprawia, że roszczenie wygląda na zweryfikowane.