Twórcy złośliwego oprogramowania nie ograniczają się już tylko do haseł przeglądarkowych i portfeli kryptowalutowych, ale zbierają również tokeny dostępu, konfiguracje MCP, historie poleceń oraz dane projektowe przechowywane przez narzędzia AI.
Nasza analiza najnowszych reguł zbierania danych przez programy kradnące informacje ujawniła znacznie nowszą kategorię obok znanych już celów, takich jak przeglądarki, portfele i dane uwierzytelniające: dane lokalne związane z narzędziami Claude, Cline, Codex, Continue, Cursor, OpenCode oraz innymi narzędziami programistycznymi wspomaganymi przez sztuczną inteligencję.
Nie był to odosobniony przypadek: w ciągu trzech miesięcy nasza telemetria systemu Windows zarejestrowała wykrycia złośliwego oprogramowania Amatera i Remus wśród dziesiątek tysięcy chronionych użytkowników. Amatera atakuje dane związane z Cline i Continue, natomiast Remus atakuje Claude, Cursor i OpenCode. Dane liczbowe mogą się pokrywać i odnosić raczej do wykryć niż do udanych infekcji, ale pokazują one, że dane agentów AI stały się już częścią rynku złośliwego oprogramowania służącego do kradzieży informacji.
Dane gromadzone przez złośliwe oprogramowanie wykraczają daleko poza nieszkodliwe preferencje. W zależności od agenta i jego konfiguracji lokalne pliki mogą zawierać tokeny dostępu i odświeżania, dane uwierzytelniające przechowywane w konfiguracjach MCP, historie monitów, bazy danych rozmów, szczegóły kont oraz ślady projektów, nad którymi pracował programista. W jednym archiwum osoba atakująca może uzyskać zarówno środki dostępu do konta, jak i kontekst niezbędny do zrozumienia, co wartościowego się za nim kryje.
Nasze ustalenia skupiają się przede wszystkim na lokalnie zainstalowanych agentach programistycznych i narzędziach programistycznych opartych na agentach; nie wskazują one na nowy sposób przejęcia kontroli nad urządzeniem ani na lukę w modelu sztucznej inteligencji lub agencie. Program kradnący informacje już działa; zmieniła się natomiast koncentracja cennych informacji w przewidywalnych lokalizacjach, czasami w postaci zwykłego tekstu, oraz łatwość, z jaką lokalizacje te można dodać do istniejącej listy miejsc gromadzenia danych.
Zasady gromadzenia danych już uległy zmianie
CallbackBeaver, szybko zyskujący na popularności program do kradzieży danych, dodał Cursor i Claude do zakresu gromadzonych danych, a w ciągu ostatnich 30 dni zaobserwowaliśmy ponad 5 000 próbek. Rodziny o mniejszym rozpowszechnieniu, w tym BeeStealer, STG Stealer, HydraStealer, APEX Stealer i Otter Stealer, wskazują, że zjawisko to wykracza poza zakres jednej lub dwóch większych operacji. Tempo upowszechniania się tego zjawiska jest uderzające – dane dotyczące agentów AI pojawiają się w regułach gromadzenia danych innego programu kradnącego dane niemal codziennie.
To samo zachowanie jest widoczne w różnych systemach operacyjnych – na przykład program Djinn Stealer działający w systemie macOS jest powiązany z gromadzeniem danych z narzędzi Claude, Codex, Gemini, Cline, OpenCode i Kilo.
Przedstawione poniżej zrekonstruowane reguły pokazują, w jaki sposób kilka narzędzi programistycznych wspomaganych przez sztuczną inteligencję zostało bezpośrednio dodanych do zakresu gromadzenia danych przez program kradnący dane. Lista ta stanowi raczej migawkę niż kompletny obraz ekosystemu, ale uwidacznia zachodzącą zmianę: dane agentów znajdują się obecnie obok celów, które programy kradnące informacje śledziły od lat.
Ataki na dane agentów AI pojawiają się w kontekście znacznie większego problemu związanego z programami kradnącymi dane. W pierwszej połowie 2026 roku nasza telemetria odnotowała wykrycia programów kradnących dane wśród ponad 3,3 miliona unikalnych, chronionych użytkowników, przy czym miesięczna liczba konsekwentnie przekraczała 500 000. Liczby te obejmują wszystkie rodziny programów kradnących dane, nie tylko te znane z ataków na dane agentów AI, ale pokazują one skalę ekosystemu, w którym rozprzestrzenia się to zachowanie.
Dostęp i kontekst w tym samym archiwum
Lokalny katalog agenta zawiera znacznie więcej niż tylko preferencje interfejsu. Konkretne pliki, ścieżki i zabezpieczenia różnią się w zależności od produktów, systemów operacyjnych i ustawień użytkownika, ale znalezione przez nas materiały można podzielić na dwie szerokie kategorie: dostęp do kont i powiązanych usług oraz kontekst, który może naruszyć prywatność użytkownika, ujawniając jego tożsamość i to, nad czym pracuje.
Niektóre agenty buforują lokalnie tokeny dostępu lub inne dane logowania, dzięki czemu użytkownik nie musi uwierzytelniać się przy każdej sesji. Token dostępu może pozwolić atakującemu na korzystanie z konta do momentu jego wygaśnięcia, natomiast token odświeżający można czasem wymienić na nowe tokeny dostępu i w ten sposób przedłużyć okres nadużycia. Skradzione tokeny mogą służyć do wykorzystywania płatnych zasobów API, a działający dostęp do konta może zostać spakowany i odsprzedany, tak aby ktoś inny mógł korzystać z komercyjnej usługi AI na koszt ofiary. Wynik zależy od zakresu działania tokenu, jego okresu ważności oraz mechanizmów kontroli właściwych dla danej usługi, więc kradzież pliku nie gwarantuje trwałego dostępu, ale plik ten może być równie wrażliwy jak magazyn haseł.
Model Context Protocol, powszechnie znany jako MCP, może rozszerzyć ten dostęp poza samą usługę AI. Pozwala on agentowi łączyć się z zewnętrznymi narzędziami i źródłami danych, a lokalne konfiguracje mogą zawierać punkty końcowe, nagłówki, zmienne środowiskowe, klucze API lub inne dane uwierzytelniające. Skradziona konfiguracja nie odblokowuje automatycznie wszystkich podłączonych usług, ponieważ niektóre integracje wykorzystują krótkotrwałe poświadczenia, pamięć chronioną przez system operacyjny lub interaktywny proces autoryzacji. Jednak w przypadku, gdy klucze wielokrotnego użytku są przechowywane lokalnie, naruszenie bezpieczeństwa może dotrzeć do systemów kontroli wersji, platform zgłoszeń, baz danych, usług w chmurze lub narzędzi do współpracy połączonych z agentem, potencjalnie poszerzając powierzchnię ataku.
Kontekst może być równie cenny, ponieważ programiści używają asystentów AI do przeglądania kodu, interpretowania logów, rozwiązywania problemów, podsumowywania dokumentacji wewnętrznej oraz analizowania niedokończonych zadań. Ich polecenia i transkrypcje mogą zawierać zastrzeżony kod źródłowy, nazwy repozytoriów, wewnętrzne nazwy hostów oraz klucze API lub inne poufne dane wklejone do rozmowy. Jeśli pracownik korzystał z asystenta podczas opracowywania poufnego prototypu, skradziona historia rozmów mogłaby ujawnić nieopatentowany wynalazek lub inną tajemnicę handlową, co miałoby konsekwencje wykraczające daleko poza kradzież konta AI. Transkrypcja może również dostarczyć informacji rozpoznawczych, których zebranie zajęłoby atakującemu w innym przypadku wiele dni, w tym struktury kodu źródłowego, znanych problemów technicznych, narzędzi bezpieczeństwa oraz osób zaangażowanych w projekt.
Dane lokalne mogą również ujawnić adres e-mail, identyfikatory konta lub organizacji, nazwę wyświetlaną, typ subskrypcji, status rozliczeniowy, poziom licencji, limity szybkości, preferencje użytkownika oraz historię ostatnich plików lub projektów. Żadne z tych pól nie jest tak istotne jak token, ale razem mogą one naruszyć prywatność użytkownika, tworząc szczegółowy obraz tego, kim jest i czym się zajmuje. W połączeniu z danymi osobowymi skradzionymi z urządzenia w innym miejscu mogą one również przyczynić się do kradzieży tożsamości, pomagając jednocześnie przestępcom w identyfikacji wartościowych ofiar oraz w uwiarygodnieniu ukierunkowanych ataków typu spear phishing lub prób wymuszeń.
Niebezpieczeństwo polega na połączeniu dostępu z kontekstem: plik cookie przeglądarki może otworzyć drzwi, ale archiwum agenta AI może również wskazać atakującemu, do kogo należą te drzwi, jakie projekty się za nimi kryją oraz do jakich powiązanych systemów można uzyskać dostęp z tego samego obszaru roboczego. Osoby reagujące na incydenty powinny zatem traktować poświadczenia agenta i lokalne historie jako część szerszej powierzchni tożsamości i dostępu, a nie jako odizolowane konto AI.
Dodanie kolejnego agenta może wymagać jedynie jednej aktualizacji konfiguracji
Wiele programów kradnących informacje otrzymuje już zdalnie zarządzane reguły gromadzenia danych, określające katalogi, nazwy plików, rozszerzenia, bazy danych, głębokość wyszukiwania lub limity rozmiaru plików. Gdy operator dowie się, gdzie agent przechowuje przydatne dane, rozszerzenie tej listy może być tak proste, jak dodanie kolejnej ścieżki.
Nie ma potrzeby ponownego kompilowania ani redystrybucji złośliwego oprogramowania. Zaktualizowaną regułę można dostarczyć do istniejących instalacji, co pozwala operatorowi rozpocząć gromadzenie plików nowo popularnego agenta na już zainfekowanych urządzeniach. Nie dotyczy to wszystkich programów kradnących dane, a niektóre narzędzia wymagają analizy lub deszyfrowania specyficznego dla danego produktu, jednak podstawowa bariera wejścia jest niska, gdy celem jest przewidywalny plik lokalny.
Jeśli obecnie duże narzędzie typu „stealer” nie gromadzi danych konkretnego agenta, jego brak na liście należy traktować jedynie jako chwilowy stan, a nie jako dowód, że agent ten pozostanie poza zakresem gromadzenia danych, gdy przestępcy zauważą wystarczającą liczbę użytkowników, wartościowe konta lub popyt na odsprzedaż.
Co powinni zrobić użytkownicy i zespoły ds. bezpieczeństwa
Dane agentów opartych na sztucznej inteligencji powinny być uwzględniane w tych samych rozmowach dotyczących bezpieczeństwa, co profile przeglądarek, poświadczenia programistów, magazyny haseł oraz narzędzia wiersza poleceń w chmurze. Reakcja musi obejmować zarówno zapobieganie, jak i działania podejmowane po podejrzeniu infekcji programem kradnącym dane.
- Należy wiedzieć, co jest przechowywane lokalnie. Należy sporządzić spis używanych agentów, sprawdzić ich ustawienia dotyczące przechowywania i historii oraz zrozumieć, gdzie przechowują one poświadczenia, rozmowy, zapisy projektów i konfigurację MCP.
- Należy preferować zabezpieczone magazyny poświadczeń. Jeśli produkt oferuje wybór, należy korzystać z magazynu poświadczeń systemu operacyjnego, pęku kluczy lub klucza zamiast przechowywania tokenów w plikach. Lokalny plik uwierzytelniający zawierający tokeny dostępu należy traktować jak hasło.
- Nie ujawniaj poufnych informacji w monitach i historii. Unikaj wklejania haseł, kluczy prywatnych, sekretów API lub danych klientów do rozmowy. Jeśli poufna informacja została ujawniona w celu rozwiązania problemu, zmień ją i usuń zachowaną rozmowę, jeśli to możliwe.
- Ogranicz możliwości podłączonych narzędzi. Przyznaj integracjom MCP tylko te uprawnienia, których potrzebują, preferuj tokeny krótkotrwałe i o wąskim zakresie oraz oddziel dostęp osobisty, deweloperski i produkcyjny. Przejrzyj stare serwery i unieważnij połączenia, które nie są już używane.
- Chroń punkt końcowy. Aktualizuj system operacyjny i aplikacje, korzystaj z renomowanych rozwiązań do ochrony punktów końcowych i zachowaj szczególną ostrożność w przypadku instrukcji ClickFix/FakeCaptcha, złamanych programów, nieoficjalnych instalatorów i innych popularnych metod wykorzystywanych do dostarczania programów kradnących informacje.
- Rozszerz zakres reagowania na incydenty. Po infekcji programem kradnącym dane sama zmiana haseł w przeglądarce nie wystarczy. Z czystego urządzenia unieważnij sesje usług AI, rotuj klucze API i inne poświadczenia używane przez połączenia MCP, sprawdź podłączone aplikacje i aktywność na kontach oraz oceń, czy lokalne monity lub transkrypcje ujawniły informacje firmowe. Uwierzytelnianie wieloskładnikowe pozostaje ważne, ale może nie powstrzymać nadużycia tokenu sesji, który został już skradziony.
Bezpieczniejsze ustawienia domyślne muszą pochodzić również od samych produktów
Użytkownicy nie mogą ponosić tej odpowiedzialności samodzielnie, dlatego twórcy oprogramowania powinni zminimalizować ilość poufnych informacji przechowywanych lokalnie, oddzielić dane uwierzytelniające od zwykłej historii przeglądania, w miarę możliwości korzystać z chronionego przez system operacyjny magazynu danych uwierzytelniających oraz sprawić, by mechanizmy kontroli przechowywania danych były łatwe do znalezienia i zrozumienia. Tokeny powinny mieć krótki okres ważności, być ograniczone do najmniejszej praktycznej grupy uprawnień oraz łatwe do unieważnienia. Połączenia MCP wymagają równie przejrzystej widoczności, aby użytkownicy i administratorzy mogli sprawdzić, co jest podłączone, do czego ma dostęp oraz kiedy zostało użyte po raz ostatni.
Szyfrowanie danych w spoczynku może pomóc, ale nie powinno stać się jedynie uspokajającą etykietą bez modelu zagrożeń, który za tym stoi. Jeśli klucz deszyfrujący jest przechowywany obok bazy danych lub aplikacja automatycznie odblokowuje wszystko dla dowolnego procesu działającego pod uprawnieniami użytkownika, osoba kradnąca informacje nadal może uzyskać dostęp do danych. Ograniczenie zakresu przechowywanych danych oraz wartości i okresu ważności poświadczeń są równie ważne jak szyfrowanie plików.
Agenci AI stają się nową warstwą pamięci roboczej w naszych urządzeniach, przechowując nie tylko to, o co ich prosimy, ale także to, kim jesteśmy, co tworzymy i do jakich usług zezwoliliśmy im na dostęp. Programy kradnące informacje dostosowały już swoje zasady gromadzenia danych, aby odzwierciedlić tę wartość, a ponieważ czasami wystarczy prosta aktualizacja konfiguracji, by dodać kolejnego agenta, lista celów będzie się zmieniać wraz z rosnącą popularnością tej technologii.
Gdy agent AI posiada dane uwierzytelniające, historię rozmów oraz mapę pracy użytkownika, jego lokalne pliki nie są już jedynie danymi konfiguracyjnymi. Stały się one kolejnym magazynem danych o wysokiej wartości na urządzeniu, a atakujący już traktują je w ten sposób.
Źródło zdjęć: depositphotos.com
Materiał przygotowany przez CORE - Norton, Avast i AVG w Polsce