Tag: LLM

Wprowadzenie do problemu / definicja luki

W lutym 2026 r. opisano podatność, w której zwykły opis zgłoszenia (GitHub Issue) może stać się nośnikiem złośliwych instrukcji dla GitHub Copilot uruchomionego wewnątrz GitHub Codespaces. Kluczowy problem nie polega na „błędzie w LLM”, tylko na zbyt głębokiej automatyzacji: podczas tworzenia Codespace z kontekstu Issue treść zgłoszenia jest automatycznie wykorzystywana jako prompt dla asystenta, co otwiera drogę do passive prompt injection.

To typ zagrożenia klasyfikowany szerzej jako prompt injection (LLM01 w OWASP Top 10 dla aplikacji LLM), gdzie atakujący manipuluje zachowaniem modelu przez odpowiednio spreparowane dane wejściowe.

W skrócie

• Atak nazwany RoguePilot pokazuje łańcuch, w którym Issue → automatyczny prompt w Codespaces → działania Copilota → eksfiltracja tokenu.
• W wariancie opisanym przez badaczy możliwe było doprowadzenie do wycieku uprzywilejowanego GITHUB_TOKEN z Codespaces, co w konsekwencji umożliwiało przejęcie repozytorium (zależnie od uprawnień tokenu).
• Wykorzystano m.in. ukryte instrukcje w HTML comments w treści Issue oraz mechanizm automatycznego pobierania JSON schema w VS Code jako kanał eksfiltracji.
• GitHub wdrożył poprawki po zgłoszeniu (responsible disclosure).

Kontekst / historia / powiązania

RoguePilot wpisuje się w rosnącą klasę zagrożeń, gdzie LLM staje się „pośrednikiem wykonawczym”: nie tylko generuje tekst, ale też steruje narzędziami w środowisku deweloperskim. To zmienia model ryzyka z „halucynacji” na AI-mediated supply chain attack — złośliwe instrukcje mogą pochodzić z treści, które dotąd traktowano jako „bezpieczne metadane projektu” (Issues, komentarze, opisy PR).

OWASP podkreśla, że prompt injection jest ryzykiem numer 1 dla systemów LLM, bo modele nie mają naturalnej granicy między „danymi” a „instrukcją”.

Analiza techniczna / szczegóły luki

1) Punkt wejścia: Issue jako „prompt”

W opisywanym scenariuszu uruchomienie Codespace z poziomu Issue powodowało, że Copilot w środowisku miał zostać automatycznie zapromptowany treścią zgłoszenia. To wystarcza, aby atakujący (np. w repo publicznym lub w repo, gdzie może tworzyć Issues) umieścił w opisie instrukcje dla agenta.

2) Ukrycie instrukcji: HTML comments

Badacze wskazali, że złośliwe polecenia można ukryć w <!-- -->, dzięki czemu człowiek „na oko” widzi zwykłe zgłoszenie, a model nadal przetwarza pełną treść.

3) Pozyskanie sekretu: GITHUB_TOKEN z Codespaces

W Codespaces dostępny jest GITHUB_TOKEN jako domyślna zmienna środowiskowa; GitHub opisuje go jako podpisany token uwierzytelniający użytkownika w codespace, możliwy do użycia np. do wywołań GitHub API.
W łańcuchu RoguePilot token miał zostać odczytany z pliku wewnątrz środowiska Codespaces (wskazywanego w analizie badaczy) i następnie wyprowadzony na zewnątrz.

4) Ominięcie ograniczeń ścieżki: symlink + PR checkout

W opisie ataku pojawia się wykorzystanie symbolicznego linku w repozytorium oraz nakłonienie Copilota do przełączenia się na przygotowany PR, w którym symlink wskazuje na wrażliwy plik w obszarze współdzielonym Codespaces.

5) Kanał eksfiltracji: automatyczne pobieranie JSON schema

Kluczowa sztuczka: VS Code potrafi automatycznie pobierać schema dla JSON, gdy w pliku występuje pole $schema. Badacze opisują, że ustawienie json.schemaDownload.enable jest w Codespaces włączone domyślnie, więc można je nadużyć jako „legalny” outbound request i dopiąć wykradane dane do URL schemy (np. w query string).
Istnienie przełącznika json.schemaDownload.enable jako opcji, która ma umożliwić wyłączenie pobierania schem, jest udokumentowane w ekosystemie VS Code.

Praktyczne konsekwencje / ryzyko

1. Przejęcie repozytorium i supply chain
   Jeśli GITHUB_TOKEN ma uprawnienia zapisu, atakujący może wypchnąć zmiany, otworzyć/zmodyfikować PR-y, wstrzyknąć backdoora, podmienić workflow itp. To klasyczny scenariusz supply chain, tylko uruchamiany przez „zainfekowany kontekst” dla agenta AI.
2. Atak bez „klikania w link” i bez socjotechniki wprost
   W wielu organizacjach tworzenie Codespace do „szybkiego ogarnięcia issue” jest normalnym nawykiem. Wtedy atak jest bliski „zero-interaction”: nie trzeba, by ofiara wkleiła prompt — wystarczy, że otworzy Codespace z Issue.
3. Trudniejsza detekcja
   Instrukcje ukryte w komentarzach HTML i eksfiltracja przez „normalny” request po schema wyglądają jak działania narzędzia, a nie malware.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów dev / AppSec

• Traktuj Issue/PR/README jako dane nieufne dla agentów AI: jeśli narzędzie automatycznie wciąga kontekst, załóż, że będzie on adversarial.
• Ogranicz tokeny w środowiskach developerskich: skróć TTL, minimalizuj scope, rozważ rozdzielenie tokenów „do odczytu” i „do zapisu” w zależności od tasku. (Ryzyko dotyczy tego, że Codespaces udostępnia GITHUB_TOKEN do działań w repo).
• Wyłącz lub ogranicz automatyczne pobieranie schem JSON w środowiskach, gdzie ma to sens (np. polityka organizacyjna/konfiguracje VS Code/Dev Container) — to usuwa prosty kanał eksfiltracji oparty o $schema.
• Wykrywanie ukrytych promptów: automatyczne skanowanie treści Issue/PR pod kątem podejrzanych wzorców (np. długie instrukcje, „system prompt”-like frazy, fragmenty nakazujące pobieranie z URL, polecenia dot. tokenów/sekretów).
• Blokada/monitoring outbound z Codespaces (jeśli to możliwe w modelu sieciowym): allowlisty domen, detekcja anomalii w żądaniach HTTP GET z parametrami przypominającymi dane.

Dla maintainerów repozytoriów

• Ogranicz możliwość tworzenia Issues (w publicznych repo rozważ moderację/triage, szablony, wymaganie konta o określonym zaufaniu).
• Polityka „nie odpalamy Codespace bez weryfikacji treści Issue”: szczególnie dla zgłoszeń od nowych kont.

Dla vendorów / dostawców narzędzi AI

• Fail-safe defaults: nie wolno pasywnie promptować agenta treścią z repo bez wyraźnego „consent” i warstwy sanitizacji; trzeba też blokować ścieżki eksfiltracji (np. automatyczne fetchowanie zasobów po URL).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

• Klasyczny prompt injection zwykle dotyczy czatu/aplikacji, gdzie użytkownik wkleja treść. W RoguePilot mamy passive prompt injection: model „sam” konsumuje treść z Issue przy starcie środowiska.
• W odróżnieniu od ataków stricte na zależności (typosquatting, dependency confusion), tutaj „wejściem” jest artefakt procesowy SDLC (Issue), a „wykonawcą” — agent AI z uprawnieniami do narzędzi i tokenów.

Podsumowanie / kluczowe wnioski

RoguePilot to mocny przykład, że integracje agentów AI w narzędziach deweloperskich mogą tworzyć nowe łańcuchy ataku: dane, które do tej pory były „tylko tekstem w trackerze”, stają się instrukcją sterującą automatem z dostępem do sekretów i operacji na repo.

Najważniejsze działania obronne to:

• odcięcie pasywnego zaufania do kontekstu (Issues/PR jako untrusted),
• minimalizacja i kontrola GITHUB_TOKEN,
• redukcja automatycznych mechanizmów pobierania zasobów (np. schema),
• oraz polityki operacyjne „jak bezpiecznie używać agent mode”.

Źródła / bibliografia

1. Orca Security Research Pod – „RoguePilot: Exploiting GitHub Copilot for a Repository Takeover” (16 lutego 2026). (Orca Security)
2. SecurityWeek – „GitHub Issues Abused in Copilot Attack Leading to Repository Takeover” (24 lutego 2026). (SecurityWeek)
3. GitHub Docs – „Default environment variables for your codespace” (opis GITHUB_TOKEN). (GitHub Docs)
4. OWASP GenAI – LLM01: Prompt Injection (oraz OWASP Top 10 for LLM Applications). (OWASP Gen AI Security Project)
5. Microsoft VS Code – issue dot. ustawienia json.schemaDownload.enable (wyłączenie pobierania schem). (GitHub)

Wprowadzenie do problemu / definicja luki

PromptSpy to rodzina złośliwego oprogramowania na Androida opisana przez ESET jako pierwszy znany przypadek użycia generatywnej AI w „execution flow” malware – nie do tworzenia treści phishingowych, lecz do dynamicznego sterowania interfejsem (UI) w celu zwiększenia odporności na zamknięcie aplikacji i uzyskania „trwałości” działania. Kluczowym elementem jest wykorzystanie Google Gemini do interpretacji aktualnego ekranu (w formie zrzutu struktury UI) i zwracania instrukcji działań (np. kliknięcia/tapy) tak, by aplikacja została „przypięta” w widoku ostatnich aplikacji (Recent Apps).

W skrócie

• PromptSpy występuje jako dropper + payload; dropper nakłania do ręcznej instalacji „aktualizacji”, która jest właściwym ładunkiem.
• GenAI (Gemini) służy do automatyzacji gestów w UI: malware wysyła do modelu XML z hierarchią elementów ekranu, a dostaje JSON z instrukcjami kliknięć/gestów.
• Celem operacyjnym nie jest sama AI, tylko zdalna kontrola przez VNC po uzyskaniu uprawnień Dostępności (Accessibility).
• ESET wskazuje na prawdopodobne ukierunkowanie na Argentynę (m.in. „MorganArg”, hiszpańskie elementy, ślady dystrybucji), przy jednoczesnym braku potwierdzenia w telemetrii ESET (możliwy PoC).

Kontekst / historia / powiązania

ESET opisuje dwie powiązane linie rozwoju:

• VNCSpy – wcześniejsza wersja widziana w serwisach analitycznych w połowie stycznia 2026.
• PromptSpy – bardziej zaawansowana wersja (próbki z lutego 2026), w której dodano moduł „AI-assisted UI manipulation”.

Łańcuch dystrybucji, jaki ESET zrekonstruował na podstawie danych z analiz, miał obejmować domeny dystrybucyjne oraz stronę podszywającą się pod bank (brandowanie sugerujące „Chase/Morgan”), a także powiązany trojan phishingowy podpisany tym samym certyfikatem deweloperskim.

Analiza techniczna / szczegóły luki

1) Dropper → payload („fałszywa aktualizacja”)

Dropper zawiera w zasobach (assets) właściwe APK (payload). Po uruchomieniu wyświetla komunikat sugerujący instalację aktualizacji, którą ofiara musi zainstalować ręcznie.

2) Uprawnienia Accessibility jako „master key”

Po instalacji payload prosi o Accessibility Service, co daje zdolność odczytu elementów na ekranie i wykonywania interakcji (kliknięć/gestów). To klasyczny, ale nadal skuteczny wzorzec nadużyć Dostępności w malware na Androida.

3) GenAI jako silnik „adaptacyjnej automatyzacji UI”

Najciekawszy element: PromptSpy próbuje uzyskać „trwałość” poprzez zablokowanie/przypięcie aplikacji w Recent Apps (mechanizm widoczny w wielu launcherach jako ikona kłódki). Ponieważ ścieżka do tej opcji różni się między producentami/wersjami UI, twarde skrypty łatwo się psują.

PromptSpy rozwiązuje to tak:

• zbiera XML dump aktualnego ekranu (teksty, opisy, klasy, pakiety, współrzędne/bounds),
• wysyła do Gemini prompt + XML,
• odbiera JSON z instrukcjami (np. „tap w środek bounds elementu X”),
• wykonuje akcje przez Accessibility i powtarza pętlę, aż model potwierdzi, że aplikacja jest „locked”.

To oznacza, że GenAI jest tu użyte jak „planner” dla automatyzacji UI, a nie generator tekstu.

4) Funkcje szpiegowskie i zdalna kontrola (VNC)

ESET wskazuje, że głównym „ładunkiem wartości” jest wbudowany VNC, pozwalający operatorowi widzieć ekran i sterować urządzeniem w czasie rzeczywistym po uzyskaniu Dostępności. Dodatkowo malware ma funkcje typu: zbieranie informacji o urządzeniu, screenshoty, nagrywanie aktywności ekranu, przechwytywanie danych ekranu blokady i inne działania opisane w materiałach ESET.

5) Utrudnianie usunięcia (anti-removal)

PromptSpy ma mechanizm obrony: przy próbie odinstalowania lub wyłączenia Dostępności nakłada niewidoczne nakładki (overlay) – przezroczyste prostokąty przechwytujące kliknięcia na kluczowych przyciskach (np. „Uninstall”, „Stop” itp.). ESET podaje, że praktyczną metodą usunięcia jest Safe Mode, gdzie aplikacje firm trzecich nie działają.

6) Atrybucja i pochodzenie

W kodzie zauważono debug stringi i obsługę zdarzeń Dostępności opisaną po chińsku, co sugeruje (ze średnią pewnością) środowisko developerskie chińskojęzyczne.

Praktyczne konsekwencje / ryzyko

• Dla użytkowników: po przejęciu Dostępności i uruchomieniu VNC atakujący może wykonywać działania „jak użytkownik” (otwieranie aplikacji bankowych, zatwierdzanie okien, przełączanie ekranów), a mechanizmy anti-removal utrudniają szybkie pozbycie się zagrożenia.
• Dla zespołów SOC / IR: pojawia się nowa klasa TTP: malware, które zamiast utrzymywać zestaw reguł per producent/UI, deleguje „rozumienie ekranu” do modelu. To może zwiększyć skalowalność ataków na różnorodny ekosystem Androida.
• Ryzyko adaptacji: nawet jeśli w tym przypadku prompt i model są „na sztywno” w kodzie, sam wzorzec (UI → LLM → akcje) jest łatwy do skopiowania przez innych aktorów.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i administratorów MDM

1. Zablokuj sideloading (instalacje spoza oficjalnych sklepów) politykami MDM, gdzie to możliwe; PromptSpy nie był dystrybuowany przez Google Play.
2. Audyt Accessibility: regularnie sprawdzaj, które aplikacje mają aktywną Dostępność; odbieraj ją aplikacjom, które nie są absolutnie zaufane.
3. Jeśli podejrzewasz infekcję: uruchom urządzenie w Trybie awaryjnym (Safe Mode) i odinstaluj podejrzaną aplikację (ESET opisuje to jako realną drogę obejścia overlay).
4. Upewnij się, że Google Play Protect jest aktywny (ESET wskazuje, że użytkownicy są chronieni przed znanymi wariantami, a ustalenia przekazano Google).

Dla SOC/Blue Team

1. Polityki detekcji na urządzeniach mobilnych: alertuj na podejrzane żądania Dostępności + nakładki/overlays + nietypowe usługi w foreground.
2. Threat hunting po artefaktach dystrybucji: domeny i infrastruktura wskazana w analizie ESET (np. serwisy dystrybucyjne/phishingowe) mogą służyć jako IOC do blokad na poziomie DNS/SWG (tam, gdzie dotyczy).
3. Procedury IR: w playbookach mobilnych uwzględnij scenariusz, w którym UI automatyzacja jest adaptacyjna (LLM), a nie skryptowa — to wpływa na ocenę „dlaczego to działa na tylu modelach urządzeń”.

Różnice / porównania z innymi przypadkami

• Klasyczne malware na Androida automatyzuje UI przez stałe współrzędne, selektory lub heurystyki, co często pęka na różnych wersjach nakładek producentów. PromptSpy wykorzystuje LLM do „czytania” UI i generowania akcji w locie.
• ESET zwraca uwagę, że to drugi przypadek „AI-powered malware” wykryty przez ich badaczy, po PromptLock (sierpień 2025) – ale tutaj AI jest użyte w innym miejscu łańcucha ataku (persistencja/automatyzacja UI, nie planowanie ataku jako takiego).

Podsumowanie / kluczowe wnioski

PromptSpy to ważny sygnał zmiany: GenAI przestaje być wyłącznie „akceleratorem socjotechniki”, a zaczyna pełnić rolę warstwy adaptacyjnej automatyzacji w samym malware. W praktyce oznacza to, że atakujący mogą łatwiej skalować kampanie na zróżnicowane urządzenia i wersje Androida, zwłaszcza gdy osiągną Dostępność i zdalne sterowanie (VNC). Nawet jeśli obecne próbki mogą być PoC, wzorzec jest na tyle czytelny, że warto już teraz uwzględniać go w detekcji, politykach MDM oraz edukacji użytkowników.

Źródła / bibliografia

1. Analiza techniczna ESET na WeLiveSecurity: „PromptSpy ushers in the era of Android threats using GenAI” (We Live Security)
2. Komunikat ESET Newsroom: „ESET Research discovers PromptSpy, the first Android threat to use generative AI” (ESET)