Archiwa: AI - Strona 76 z 87 - Security Bez Tabu

Tag: AI

VoidLink: cloud-native framework malware dla Linuksa, który (prawdopodobnie) powstał „prawie w całości” z pomocą AI

Wprowadzenie do problemu / definicja zagrożenia

VoidLink to zaawansowany, „cloud-first” framework malware dla Linuksa zaprojektowany pod długotrwały, dyskretny dostęp do środowisk chmurowych i kontenerowych (Kubernetes/Docker). Z perspektywy obrońców najważniejsze jest to, że nie wygląda jak typowy „jednofunkcyjny trojan” – bardziej przypomina kompletne C2/post-exploitation narzędzie z loaderami, implantami, mechanizmami rootkit oraz rozbudowanym systemem wtyczek.

W styczniu 2026 temat zyskał dodatkowy ciężar: Check Point Research wskazuje na rzadko spotykane dowody sugerujące, że znacząca część rozwoju VoidLink mogła zostać wykonana w trybie „AI-driven development” (agent + specyfikacje + sprinty), co radykalnie skraca czas tworzenia złożonych narzędzi ofensywnych.

W skrócie

  • Cel i środowisko: Linux w chmurze i kontenerach; rozpoznawanie dostawcy chmury oraz kontekstu (K8s/Docker) i dopasowanie zachowania.
  • Architektura: loader 2-etapowy + implant + in-memory plugin system (ponad 30 modułów; panel wskazywał ok. 37 wtyczek).
  • Stealth i rootkity: LD_PRELOAD / LKM / eBPF – wybór techniki zależny od wersji kernela i „postury” środowiska.
  • C2/łączność: wiele kanałów (m.in. HTTP/HTTPS, DNS, ICMP) oraz mechanizmy kamuflażu ruchu; w próbkach widać też kierunek „mesh/P2P”.
  • AI w wytwarzaniu: Check Point opisuje metodykę SDD (Spec Driven Development) i artefakty po narzędziu TRAE SOLO; THN i Sysdig przytaczają dodatkowe sygnały „LLM-owego” boilerplate’u.
  • Status: brak potwierdzonych infekcji „w realu” w momencie publikacji analiz; wygląda na projekt w fazie intensywnego rozwoju.

Kontekst / historia / powiązania

  • Wykrycie: Check Point Research trafił na próbki w grudniu 2025; część binariów zawierała artefakty developerskie (np. symbole debug), co sugerowało buildy „w trakcie” a nie masowo wdrożone malware.
  • Atrybucja (ostrożnie): w raportach pojawia się wątek środowiska developerskiego powiązanego językowo/operacyjnie z Chinami, ale bez twardego przypisania do konkretnej grupy.
  • Tempo rozwoju: Check Point wskazuje, że narzędzie urosło do ~88 tys. linii kodu do początku grudnia 2025; THN podkreśla „pierwszy funkcjonalny implant” w czasie krótszym niż tydzień.
  • „Wgląd w warsztat”: kluczowe w tej historii jest to, że badacze mieli wyjątkowy wgląd w artefakty planowania i budowy (m.in. przez błędy OPSEC autora i wyciek plików).

Analiza techniczna / szczegóły luki

Poniżej najważniejsze elementy „tradecraftu” VoidLink, z perspektywy obrony chmury i Linuksa.

1) Cloud-first rozpoznanie i działania w kontenerach

VoidLink potrafi identyfikować popularnych dostawców chmury (m.in. AWS, Azure, GCP, Alibaba, Tencent) i pobierać dane z mechanizmów metadata/instancji. Dodatkowo wykrywa, czy działa w Dockerze lub w podzie Kubernetes, a następnie dobiera moduły post-exploitation (np. pod kątem eksfiltracji sekretów, prób „container escape”, ruchu lateralnego).

2) Modularność: Plugin API inspirowane Cobalt Strike

Check Point opisuje architekturę z własnym Plugin API inspirowanym podejściem Beacon Object Files (BOF). Wtyczki są ładowane w runtime i wykonywane in-memory, co sprzyja „cichym” operacjom i ogranicza artefakty na dysku. Kategorie modułów obejmują m.in. recon, cloud/container, credential harvesting, persistence, anti-forensics, lateral movement.

3) Rootkity i ukrywanie: LD_PRELOAD, LKM oraz eBPF

VoidLink ma „rootkit-style capabilities” w kilku wariantach:

  • LD_PRELOAD (user-mode hooking),
  • LKM (kernel module),
  • eBPF (hooking ścieżek w sposób lepiej dopasowany do nowszych, „utwardzonych” systemów).

Mechanizm doboru techniki zależy od kernela i dostępnych funkcji; celem jest m.in. ukrywanie procesów, plików i socketów, a także maskowanie samych komponentów.

4) C2 i kamuflaż ruchu

VoidLink obsługuje wiele transportów (HTTP/1.1, HTTP/2, WebSocket, DNS, ICMP) oraz warstwy kamuflażu (udawanie „legitnego” ruchu, pakowanie danych w obiekty przypominające treści webowe/grafiki itp.). W kodzie widać też kierunek rozwoju w stronę mesh/P2P.

5) Adaptive stealth i OPSEC: „ryzyko” środowiska wpływa na zachowanie

Jedna z mocniejszych cech: po starcie malware ma enumerować zabezpieczenia (np. EDR/hardening), wyliczać risk score i na tej podstawie modyfikować agresywność działań (np. wolniejsze skanowanie w środowisku monitorowanym). Do tego dochodzą: runtime code encryption, mechanizmy anty-debug, integralność runtime oraz self-deletion przy wykryciu manipulacji.

6) „Server-Side Rootkit Compilation” (Sysdig)

Sysdig zwraca uwagę na element, który rozwiązuje klasyczny problem LKM rootkitów: portowalność względem wersji kernela. Według analizy, serwer C2 ma budować moduły kernela „na żądanie” pod konkretną wersję kernela ofiary (SRC). To może znacząco podnieść skuteczność w heterogenicznych flotach linuksowych w chmurze.

Praktyczne konsekwencje / ryzyko

Dla większości organizacji ryzyko nie sprowadza się do „jeszcze jednego malware”, tylko do możliwego przejęcia warstwy sterującej chmurą:

  • Kradzież poświadczeń i sekretów (cloud creds, tokeny, klucze, dane do repozytoriów/SCM typu Git) → ryzyko kompromitacji CI/CD, „secrets sprawl” i dostępu do kodu.
  • Trwała obecność w klastrach i node’ach dzięki persistence + ukrywaniu (rootkit/eBPF/LKM) oraz adaptacji do monitoringu.
  • Cichy post-exploitation w K8s/Docker (recon, eskalacje, potencjalne ucieczki z kontenera) → dostęp do workloadów i danych.
  • Zmiana ekonomii ataku dzięki AI: jeśli Check Point ma rację, bariera wejścia dla budowy „pełnego frameworka” spada – pojedynczy actor może iterować szybciej, niż zespoły defensywne aktualizują detekcje i polityki.

Jednocześnie warto trzymać w głowie fakt, że w analizach na styczeń 2026 nie ma potwierdzonych, masowych infekcji w środowiskach produkcyjnych – ale projekt wygląda jak „prawie gotowy” ekosystem C2.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań, które mają sens nawet wtedy, gdy VoidLink nie jest (jeszcze) „w wild”.

1) Detekcja runtime dla Linuksa i kontenerów

  • Postaw na runtime monitoring (syscall/activity-based), bo część technik jest „fileless” lub ukrywa artefakty na dysku. Sysdig podkreśla, że mimo zaawansowania zachowania na poziomie syscalls są widoczne dla narzędzi klasy runtime (np. Falco).
  • W K8s: reguły na nietypowe exec w kontenerach, dostęp do socketów dockera, nietypowe mounty, operacje na /proc, manipulacje BPF, ładowanie modułów kernela.

2) Ograniczenie „blast radius” w chmurze

  • Przejrzyj IAM: minimalne uprawnienia, krótkie TTL tokenów, rotacja kluczy, rozdzielenie ról CI/CD i adminów.
  • Uszczelnij dostęp do instance metadata (IMDS/metadata proxy), bo VoidLink aktywnie pyta o dane środowiska chmurowego.
  • Zredukuj ekspozycję sekretów: używaj menedżerów sekretów (i audytuj, gdzie lądują w env/args).

3) Twarde kontrole na hoście

  • Rozważ ograniczenia dla eBPF i ładowania modułów (tam, gdzie to możliwe operacyjnie).
  • Hardening: kontrola integralności, ograniczenie narzędzi developerskich na serwerach produkcyjnych, monitoring zmian w usługach/systemd/cron (persistence).

4) Kontrola egress i anomalii C2

  • Monitoruj/ogranicz: DNS tunneling, nietypowe ICMP, WebSocket/HTTP2 do nieznanych destynacji. VoidLink ma wiele kanałów C2 i kamuflaż ruchu, więc „allow-all egress” w chmurze to proszenie się o kłopoty.

5) Przygotuj proces IR „pod cloud-native”

  • Playbook na incydent w K8s (izolacja node/pod, snapshoty, artefakty runtime, eksport audit logs).
  • Zbieraj dane, które przetrwają anti-forensics (telemetria runtime, logi z warstwy kontrolnej chmury).

Różnice / porównania z innymi przypadkami

  • VoidLink vs „klasyczne Linux malware”: tu mamy platformę C2 + post-exploitation z pluginami, dashboardem operatorskim i adaptacją do cloud/K8s – to bardziej „Linuxowy odpowiednik” ekosystemów znanych z Windows.
  • Inspiracje Cobalt Strike: podobieństwo jest jawne w warstwie API/wtyczek (BOF-like). To ważne, bo pokazuje przenoszenie sprawdzonych wzorców ofensywnych do chmury opartej o Linuksa.
  • AI-assisted malware (nowa jakość): Check Point argumentuje, że wcześniejsze „AI malware” bywało niskiej jakości lub wtórne, a VoidLink ma być pierwszym dobrze udokumentowanym przypadkiem, gdzie AI przyspieszyło budowę złożonego, oryginalnego frameworka przy udziale kompetentnego twórcy.

Podsumowanie / kluczowe wnioski

VoidLink to sygnał ostrzegawczy w dwóch wymiarach: (1) technicznie – bo łączy cloud awareness, pluginową architekturę i rootkity (LD_PRELOAD/LKM/eBPF) z wielokanałowym C2; (2) metodycznie – bo według Check Point znacząca część wytwarzania mogła być „napędzana” przez podejście agentowe (SDD + sprinty + automatyzacja), co skraca cykl tworzenia ofensywnych platform.

Dobra wiadomość: w momencie publikacji analiz (styczeń 2026) nie ma twardych dowodów na szerokie użycie w atakach. Zła: projekt wygląda jak „prawie gotowy” i może zostać szybko dopięty do kampanii szpiegowskich, kradzieży sekretów w chmurze lub działań supply-chain.

Źródła / bibliografia

  1. Check Point Research – „Unveiling VoidLink – A Stealthy, Cloud-Native Linux Malware Framework” (13.01.2026). (Check Point Research)
  2. Sysdig Threat Research – „VoidLink threat analysis: Sysdig discovers C2-compiled kernel rootkits” (16.01.2026). (sysdig.com)
  3. Check Point Research – „VoidLink: Evidence That the Era of Advanced AI-Generated Malware Has Begun” (20.01.2026). (Check Point Research)
  4. The Hacker News – „VoidLink Linux Malware Framework Built with AI Assistance Reaches 88,000 Lines of Code” (21.01.2026). (The Hacker News)
  5. SecurityWeek – „VoidLink Linux Malware Framework Targets Cloud Environments” (15.01.2026). (SecurityWeek)

ChainLeak w Chainlit: dwie luki (CVE-2026-22218 i CVE-2026-22219) mogą wyciekać pliki, sekrety i dane z infrastruktury AI

Wprowadzenie do problemu / definicja luki

Chainlit to popularny, otwartoźródłowy framework w Pythonie do budowania aplikacji konwersacyjnych (chatbotów i interfejsów dla agentów/LLM), często integrowany z ekosystemem narzędzi LLM. Zafran Labs opisał dwie podatności wysokiej wagi (zbiorczo nazywane „ChainLeak”), które w pewnych konfiguracjach mogą prowadzić do ujawnienia plików z serwera oraz do SSRF (Server-Side Request Forgery), czyli wykonywania żądań sieciowych z wnętrza serwera aplikacji do zasobów wewnętrznych (w tym endpointów metadanych chmurowych).

W skrócie

  • Dotknięte wersje: Chainlit < 2.9.4 (łatka w 2.9.4).
  • CVE-2026-22218 (arbitrary file read): uwierzytelniony klient może doprowadzić do skopiowania wskazanego pliku do swojej „sesji” i następnie pobrać go po identyfikatorze (m.in. przez endpoint /project/file/<chainlitKey>).
  • CVE-2026-22219 (SSRF): w konfiguracji z backendem warstwy danych opartym o SQLAlchemy uwierzytelniony klient może podać kontrolowany url, który serwer pobierze metodą HTTP GET, co umożliwia sięgnięcie do usług wewnętrznych i/lub metadanych chmurowych.
  • Skutek biznesowy: wyciek sekretów (np. kluczy API), danych aplikacji i potencjalnie danych innych użytkowników w środowiskach współdzielonych.

Kontekst / historia / powiązania

W aplikacjach opartych o LLM typowe „stare” klasy podatności webowych (IDOR, SSRF, file read) są szczególnie groźne, bo te systemy:

  • często działają internet-facing (boty wsparcia, portale dla klientów),
  • trzymają sekrety do modeli/agentów (API keys), konektory do baz danych i zasobów firmowych,
  • bywają wielowarstwowe (UI → orkiestracja → narzędzia → dane), co zwiększa powierzchnię ataku.

Zafran wskazuje, że podatności zostały potwierdzone w rzeczywistych, publicznie dostępnych wdrożeniach.

Analiza techniczna / szczegóły luki

CVE-2026-22218 — Arbitrary File Read przez „element update flow”

Z opisu podatności wynika następujący łańcuch:

  1. Uwierzytelniony klient wysyła spreparowany „Element” z kontrolowaną ścieżką (path).
  2. Serwer kopiuje wskazany plik do obszaru sesji atakującego.
  3. Serwer zwraca identyfikator (np. chainlitKey), który pozwala pobrać treść pliku przez API (w opisie pada ścieżka /project/file/<chainlitKey>).

Dlaczego to jest groźne w AI-app?
Jeśli proces Chainlit ma uprawnienia do odczytu wrażliwych plików (konfiguracje, klucze, cache, logi), atakujący może sukcesywnie „wydzierać” informacje z hosta.

CVE-2026-22219 — SSRF przez url w elementach (SQLAlchemy data layer)

Ten wektor dotyczy sytuacji, gdy aplikacja używa backendu warstwy danych opartego o SQLAlchemy. Mechanizm (z perspektywy opisu) wygląda tak:

  1. Atakujący (uwierzytelniony) tworzy element z kontrolowanym polem url.
  2. Logika serwera pobiera zawartość spod tego URL (HTTP GET) „z wnętrza” infrastruktury serwera.
  3. Odpowiedź może zostać zapisana w skonfigurowanym storage providerze, co ułatwia eksfiltrację.

W praktyce SSRF bywa wykorzystywane do:

  • skanowania usług wewnętrznych (panele admin, Redis/Elastic, wewnętrzne API),
  • uderzenia w cloud metadata endpoints (np. poświadczenia ról/instancji), co bywa początkiem eskalacji w chmurze.

Praktyczne konsekwencje / ryzyko

Najbardziej „nośne” scenariusze ryzyka w kontekście Chainlit/LLM to:

  • Wyciek sekretów i konfiguracji (zmienne środowiskowe, pliki .env, konfiguracje konektorów) – Zafran wskazuje m.in. możliwość odczytu /proc/self/environ jako przykład pozyskania wrażliwych wartości.
  • Wyciek danych aplikacyjnych: logi, cache, artefakty sesji, pliki tymczasowe – szczególnie jeśli serwer pracuje na wspólnym hoście/klastrze i ma szerokie uprawnienia.
  • Ryzyko w środowiskach multi-tenant: jeśli aplikacja przechowuje treści promptów/odpowiedzi w warstwach cache/plikach, file read może prowadzić do ujawnienia danych innych użytkowników.
  • SSRF jako „pomost” do chmury: dostęp do metadanych instancji lub wewnętrznych usług może skończyć się przejęciem uprawnień i ruchem bocznym (lateral movement).

Warto podkreślić: oba CVE wymagają uwierzytelnionego klienta, więc najczęściej nie jest to „drive-by” bez logowania. Z drugiej strony, w realnych wdrożeniach często istnieją konta o niskim poziomie zaufania (np. self-service), integracje SSO, konta testowe lub źle skonfigurowane role — i to zwykle wystarcza, by podatność stała się praktycznie wykorzystywalna.

Rekomendacje operacyjne / co zrobić teraz

1) Patch management (najważniejsze)

  • Zaktualizuj Chainlit do wersji 2.9.4 lub nowszej (to wersja wskazana jako naprawiająca problem).

2) Zmniejsz skutki, jeśli nie możesz patchować natychmiast

  • Ogranicz ekspozycję: jeśli to możliwe, zdejmij instancję z publicznego internetu (VPN / allowlista / reverse proxy z MFA). (To dobra praktyka dla paneli LLM i aplikacji wewnętrznych, nawet niezależnie od tej konkretnej luki.)
  • Zasada najmniejszych uprawnień dla procesu: uruchamiaj usługę na użytkowniku systemowym bez dostępu do katalogów z sekretami; rozważ kontenery z read-only FS tam, gdzie da się. (Zmniejsza to realny „zasięg” arbitrary file read.)
  • Egress filtering dla serwera (firewall/SG/NACL): ogranicz ruch wychodzący tylko do niezbędnych domen/usług (to kluczowe w obronie przed SSRF).
  • Ochrona metadanych chmurowych: w zależności od chmury i architektury — blokuj dostęp do adresów metadanych z poziomu aplikacji lub wymagaj nowszych mechanizmów autoryzacji (np. tokenów dla metadanych), by SSRF nie mógł pobrać poświadczeń „za darmo”.

3) Detekcja i monitoring

  • Przejrzyj logi pod kątem nietypowych żądań związanych z tworzeniem/aktualizacją „elementów” oraz pobieraniem plików po identyfikatorach.
  • Monitoruj nietypowy ruch wychodzący HTTP z hostów aplikacji (kierunki wewnętrzne, nietypowe hosty, próby dostępu do metadanych).

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

To dobry przykład, że „AI framework” nie musi mieć „AI-specyficznej” podatności, by doprowadzić do poważnego incydentu. W praktyce:

  • Arbitrary file read w aplikacji LLM to często natychmiastowy wyciek: kluczy API do modeli, konfiguracji narzędzi (tooling), poświadczeń do baz i integracji.
  • SSRF w środowisku chmurowym jest klasycznym wektorem do pozyskania tokenów/poświadczeń i eskalacji.

Wniosek operacyjny: traktuj warstwę aplikacji LLM jak każdą krytyczną aplikację webową — z pełnym zestawem kontroli (hardening, segmentacja, egress, least privilege), bo „nowoczesny” stos technologiczny dziedziczy „klasyczne” ryzyka.

Podsumowanie / kluczowe wnioski

  • Chainlit < 2.9.4 jest narażony na dwie podatności (CVE-2026-22218, CVE-2026-22219), które mogą prowadzić do wycieku plików i/lub SSRF.
  • W realnych wdrożeniach AI ryzyko jest podbite przez obecność sekretów (API keys), konektorów do danych firmowych i częstą ekspozycję usług na internet.
  • Najszybsza i najpewniejsza redukcja ryzyka: upgrade do 2.9.4+, a dodatkowo ograniczenie egress i uprawnień procesu.

Źródła / bibliografia

  1. SecurityWeek — opis podatności i kontekst ekspozycji instancji w internecie. (SecurityWeek)
  2. Zafran Labs — „ChainLeak” (analiza techniczna, scenariusze eksfiltracji i wpływ na AI stack). (Zafran Security)
  3. GitHub Advisory Database — CVE-2026-22218 (arbitrary file read, warunki i wersje). (GitHub)
  4. GitHub Advisory Database — CVE-2026-22219 (SSRF, warunki dot. SQLAlchemy, wersje). (GitHub)
  5. Tenable — opis CVE-2026-22218 i przykładowe ścieżki/endpointy eksfiltracji. (Tenable®)

Weaponized Invite: jak zaproszenie w Kalendarzu Google umożliwiało kradzież danych przez Google Gemini

Wprowadzenie do problemu / definicja luki

Badacze Miggo opisali podatność (a właściwie cały łańcuch nadużyć) w ekosystemie Google, w którym Google Gemini zintegrowany z Kalendarzem Google mógł zostać „nakłoniony językiem” do ujawnienia prywatnych informacji z kalendarza. Atak polegał na pośrednim prompt injection: złośliwa instrukcja była ukryta w treści zaproszenia (opisie wydarzenia), a następnie wykonywana przez model w momencie, gdy użytkownik zadawał niewinne pytanie o plan dnia.

Kluczowe w tej historii jest to, że nie mówimy o klasycznym bug-u typu RCE, tylko o obejściu kontroli autoryzacji/ochron prywatności przez semantykę (intencję) w naturalnym języku, wykorzystujące uprawnienia narzędzi (tooling) dostępnych Gemini w kontekście Kalendarza.

W skrócie

  • Atakujący wysyłał ofierze zaproszenie kalendarzowe z ukrytą instrukcją prompt injection w polu opisu wydarzenia.
  • Gdy ofiara pytała Gemini np. „czy mam spotkania we wtorek?”, Gemini parsował dane wydarzeń (w tym złośliwy opis) i tworzył nowe wydarzenie zawierające podsumowanie prywatnych spotkań w opisie.
  • W typowych konfiguracjach firmowych takie nowo utworzone wydarzenie mogło być widoczne dla atakującego, co zamieniało kalendarz w kanał eksfiltracji danych.
  • Miggo zgłosiło problem odpowiedzialnie; Google potwierdziło i złagodziło podatność.

Kontekst / historia / powiązania

Google (podobnie jak inni dostawcy GenAI) jawnie przyznaje, że prompt injection może pochodzić nie tylko z bezpośredniej rozmowy z modelem, ale też z treści współdzielonych w narzędziach produktywności (mail, pliki, kalendarz), które użytkownik później „przypadkiem” wciągnie do kontekstu zapytania.

Opisywany przypadek jest ważny, bo pokazuje przesunięcie wektora ataku: z e-maili i dokumentów na zaproszenia kalendarzowe, które w wielu organizacjach są traktowane jako „mniej ryzykowne” i rzadziej podlegają rygorystycznej filtracji treści.

Analiza techniczna / szczegóły luki

1) Warunek brzegowy: integracja Gemini ↔ Google Calendar

Gemini w roli asystenta kalendarza analizuje pełny kontekst wydarzeń (tytuły, czas, uczestników, opis), aby odpowiadać na pytania o harmonogram. To oznacza, że złośliwy tekst w opisie trafia do modelu jako kontekst, mimo że użytkownik nie „wkleił” go ręcznie do czatu.

2) Payload jako „niewinna” instrukcja

Miggo podkreśla różnicę między:

  • syntaktycznie niewinnym tekstem (brak podejrzanych wzorców), a
  • semantycznie złośliwym efektem, gdy model wykona polecenie mając dostęp do narzędzi (np. tworzenia wydarzeń).

W praktyce payload instruował model, aby:

  1. zebrał i streścił spotkania ofiary z danego dnia (włącznie z prywatnymi),
  2. użył funkcji tworzenia wydarzenia,
  3. wkleił streszczenie do opisu nowego wydarzenia,
  4. zwrócił ofierze „uspokajającą” odpowiedź, maskując działanie.

3) Trigger: zwykłe pytanie użytkownika

Ładunek pozostawał uśpiony do momentu, aż użytkownik zadał Gemini rutynowe pytanie o plan („czy mam konflikty we wtorek?”, „co mam jutro?”). Wtedy model pobierał zdarzenia, trafiał na payload i wykonywał instrukcję.

4) Eksfiltracja przez „legalny” artefakt: nowe wydarzenie

Najciekawszy element to kanał wycieku: nie „wysyłka na zewnętrzny serwer”, tylko zapis danych w opisie nowego eventu. Jeśli taki event był widoczny dla atakującego (np. przez udostępnienie lub ustawienia organizacyjne), następował wyciek bez dodatkowych kliknięć ofiary.

Praktyczne konsekwencje / ryzyko

Dane z kalendarza często zawierają wrażliwe metadane nawet wtedy, gdy „treść spotkania” nie jest jawnie poufna:

  • nazwy projektów, klientów, inicjatyw,
  • listy uczestników (mapowanie relacji, struktury zespołów),
  • lokalizacje, linki do spotkań,
  • opisy, notatki, czasem numery telefonów lub identyfikatory konferencji.

W środowisku firmowym taki wyciek może być paliwem do:

  • spear-phishingu i BEC (bardziej wiarygodne preteksty),
  • rekonesansu (kto z kim i kiedy),
  • planowania ataków w czasie (np. w trakcie zarządu/spotkań kryzysowych).

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów bezpieczeństwa (IT/SecOps)

  1. Ogranicz automatyczne zaufanie do zaproszeń z zewnątrz
    Przejrzyj polityki przyjmowania zaproszeń i domyślne ustawienia widoczności wydarzeń (zwłaszcza dla eventów tworzonych automatycznie).
  2. Segmentuj i minimalizuj uprawnienia “AI-asystenta”
    Tam, gdzie to możliwe, ogranicz akcje narzędziowe (np. tworzenie/edycja eventów) lub włącz mechanizmy wymagające potwierdzenia. (To rekomendacja architektoniczna — konkrety zależą od planu Workspace i konfiguracji).
  3. Monitoring i detekcja anomalii w kalendarzu
    Szukaj: nagłego tworzenia eventów o schematycznych tytułach, masowego dopisywania opisów z danymi wielu spotkań, nietypowych zależności między zaproszeniami a nowymi wydarzeniami.
  4. Edukacja użytkowników o prompt injection
    Google samo wskazuje, że prompt injection może pochodzić z treści współdzielonych; ucz użytkowników, by traktowali AI-skróty/odpowiedzi jako potencjalnie podatne na manipulację.

Dla użytkowników i administratorów Workspace

  • Uważaj na niespodziewane zaproszenia oraz eventy, które wyglądają „normalnie”, ale mają długie/niezrozumiałe opisy.
  • Jeśli korzystasz z Gemini do pytań o plan dnia, zwróć uwagę na sytuacje, gdy w kalendarzu pojawiają się nowe wydarzenia, których nie tworzyłeś/aś.
  • Śledź zmiany w mechanizmach ochrony: Google opisuje, że Gemini może filtrować/blokować odpowiedzi przy wykryciu prompt injection, ale to nie jest gwarancja i wymaga ciągłego dostrajania.

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

  • Klasyczne prompt injection często kończy się „tylko” zmanipulowaną odpowiedzią. Tutaj stawką było nadużycie integracji z narzędziem (Kalendarz) i wykonanie akcji w tle (utworzenie wydarzenia), co zbliża problem do kategorii agentic/tool misuse.
  • Wyróżnikiem jest też kanał eksfiltracji: wewnętrzny artefakt (event) zamiast zewnętrznego exfil endpointu — trudniej to zauważyć w klasycznych kontrolach sieciowych.

Podsumowanie / kluczowe wnioski

  • „Broń” w tym ataku to język: payload nie musiał wyglądać podejrzanie, bo jego szkodliwość ujawniała się dopiero w kontekście uprawnień i intencji.
  • Integracje GenAI z aplikacjami produktywności tworzą nową klasę ryzyk: autoryzacja i prywatność mogą zostać ominięte semantycznie, bez klasycznego exploita w kodzie.
  • Google i Miggo informują, że problem został złagodzony po zgłoszeniu, ale lekcja pozostaje aktualna: trzeba traktować dane z kalendarza, maila i dokumentów jako potencjalny nośnik prompt injection.

Źródła / bibliografia

  1. Miggo – „Weaponizing Calendar Invites: A Semantic Attack on Google Gemini” (miggo.io)
  2. SecurityWeek – „Weaponized Invite Enabled Calendar Data Theft via Google Gemini” (SecurityWeek)
  3. The Hacker News – „Google Gemini Prompt Injection Flaw Exposed Private Calendar Data via Malicious Invites” (The Hacker News)
  4. Malwarebytes – „Malicious Google Calendar invites could expose private data” (Malwarebytes)
  5. Google Calendar Help – „How Google Workspace with Gemini helps protect users from malicious content and prompt injection” (Google Help)

Krytyczne luki w serwerach MCP: SSRF, RCE i ryzyko przejęć chmury w ekosystemie agentów AI (Microsoft, Anthropic)

Wprowadzenie do problemu / definicja luki

Model Context Protocol (MCP) to standard łączący modele językowe i agentów AI z narzędziami (np. repozytoriami Git, systemem plików, usługami chmurowymi czy konwerterami dokumentów). W praktyce MCP „wystawia” funkcje (tools), które agent może wywoływać w odpowiedzi na polecenia użytkownika… albo na polecenia przemycone w danych wejściowych (np. w README, stronie WWW, pliku).

Nowy problem nie polega wyłącznie na tym, że „gdzieś jest błąd”. Chodzi o to, że serwery MCP często działają jako uprzywilejowane pośredniki: mają dostęp do sieci, plików, tokenów, repozytoriów, a czasem wręcz do zasobów chmurowych. Jeśli da się nimi sterować (bez ograniczeń) albo jeśli agent da się nakłonić do uruchomienia sekwencji narzędzi — powstaje prosta ścieżka do SSRF, kradzieży sekretów i RCE.

W skrócie

  • Badacze opisali poważne ryzyka w popularnych serwerach MCP: SSRF w Microsoft MarkItDown MCP oraz łańcuch prowadzący do RCE w oficjalnych serwerach MCP Anthropic (Git + Filesystem).
  • W przypadku MarkItDown problemem jest możliwość pobierania dowolnych URI bez ograniczeń, co otwiera drogę do SSRF i np. odczytu metadanych instancji w chmurze.
  • W przypadku Anthropic zidentyfikowano trzy luki (CVE-2025-68145 / -68143 / -68144), które można łączyć z innymi narzędziami MCP, by doprowadzić do wykonania kodu.
  • Kluczowa lekcja: kompozycja narzędzi (tool chaining) + pośrednictwo agentów = ryzyko wykraczające poza „pojedynczą podatność” — to problem architektoniczny.

Kontekst / historia / powiązania

W artykule Dark Reading (20 stycznia 2026) podkreślono, że MCP powstał jako otwarty standard, a kwestie bezpieczeństwa w dużej mierze pozostawiono implementatorom. Efekt: część serwerów MCP „dowiozła funkcjonalność”, ale bez twardych barier bezpieczeństwa.

Microsoft równolegle publikuje materiały o zabezpieczaniu serwerów MCP (np. autentykacja/autoryzacja JWT, dobre praktyki dla wdrożeń oraz zarządzanie dostępem). To ważny sygnał: dostawcy widzą, że MCP szybko staje się infrastrukturą krytyczną, a nie tylko „wtyczką do LLM”.

Analiza techniczna / szczegóły luki

1) Microsoft MarkItDown MCP: SSRF przez „nieograniczone URI”

Z opisu wynika, że MarkItDown MCP przyjmuje od użytkownika/klienta URI wskazujące źródło pliku do konwersji i pobiera je bez mechanizmów ograniczających (brak sensownego allowlist/denylist, brak twardej walidacji docelowych adresów). To klasyczny wzorzec SSRF, tylko osadzony w nowym workflow: „agent → narzędzie MCP → sieć”.

Najbardziej niebezpieczny wariant to środowisko chmurowe: gdy serwer działa np. na instancji AWS EC2, możliwe jest odpytywanie usługi metadanych instancji (IMDS) i pozyskanie tymczasowych poświadczeń (access key/secret/session token) przypiętych do roli IAM. Dark Reading wskazuje też na różnicę odporności IMDSv2 vs IMDSv1.

Wniosek techniczny: w świecie MCP SSRF nie jest „tylko SSRF-em” — to często most do przejęcia chmury, bo serwer MCP bywa uruchamiany blisko sekretów, tokenów i metadanych infrastruktury.

2) Anthropic Git MCP + Filesystem MCP: łańcuch do RCE

Opisane błędy w oficjalnym Git MCP (mcp-server-git) obejmują m.in.:

  • obejście walidacji ścieżek (CVE-2025-68145),
  • możliwość inicjalizacji repozytorium w dowolnej lokalizacji (CVE-2025-68143),
  • wstrzyknięcie argumentów/niebezpieczne obchodzenie się z parametrami w kontekście git_diff (CVE-2025-68144).

Kluczowe jest jednak to, jak dochodzi do RCE: podatności stają się groźne, gdy agent potrafi wykonać sekwencję działań przez różne narzędzia MCP (np. Git + Filesystem). Dark Reading opisuje scenariusz, w którym atakujący przemyca instrukcje poprzez indirect prompt injection (np. „złośliwe README”), a następnie agent wykonuje działania prowadzące do przygotowania repozytorium i uruchomienia poleceń (np. przez mechanizmy git związane z filtrami/atrybutami).

Wniosek techniczny: tu nie chodzi o „magiczne RCE w LLM”, tylko o bardzo klasyczny łańcuch: błąd kontroli ścieżek + możliwość zapisu plików + uruchomienie procesu (git) z podatnymi parametrami — tyle że zautomatyzowany przez agenta.

Praktyczne konsekwencje / ryzyko

Najbardziej realistyczne scenariusze nadużyć w organizacjach:

  • Kradzież sekretów i eskalacja w chmurze: SSRF do IMDS / usług metadanych, odczyt tokenów, a potem przejęcie zasobów (storage, bazy, pipeline CI/CD).
  • RCE na stacjach dev / runnerach CI: jeśli MCP serwery (Git/Filesystem) działają lokalnie lub w środowiskach build, skutkiem może być przejęcie repozytoriów, podmiana artefaktów, wstrzyknięcia do łańcucha dostaw.
  • „Confused deputy” w architekturach pośredniczących: serwer MCP jako proxy do innych API może zostać użyty do uzyskania niezamierzonego dostępu, jeśli źle zaprojektowano autoryzację i zgody.
  • Ataki przez dane, nie przez użytkownika: indirect prompt injection sprawia, że bodźcem jest treść (plik/WWW), a nie „zły użytkownik w czacie”. To zmienia monitoring i model zagrożeń.

Rekomendacje operacyjne / co zrobić teraz

Twarde ograniczenia dla SSRF (priorytet #1)

  • Wprowadź allowlist schematów i hostów dla narzędzi pobierających zasoby (np. tylko https do zatwierdzonych domen/bucketów).
  • Zablokuj dostęp sieciowy z procesu MCP do adresów link-local i usług metadanych (np. 169.254.169.254), a także do prywatnych zakresów, jeśli nie są potrzebne (egress filtering).
  • W chmurze wymuś IMDSv2 tam, gdzie to możliwe (zmniejsza podatność na część klas SSRF).

Minimalizacja uprawnień i „blast radius”

  • Uruchamiaj serwery MCP w izolacji (kontener, sandbox, osobna tożsamość) i dawaj im tylko minimalne uprawnienia (RBAC/least privilege).
  • Rozdziel narzędzia „read” i „write”; operacje zapisu/niszczenia wymagaj jako jawnie zatwierdzane (human-in-the-loop dla krytycznych akcji).

Uwierzytelnianie i autoryzacja (bez tego MCP to „otwarta brama”)

  • Zaimplementuj authn/authz dla MCP (np. JWT/OAuth) oraz kontroluj, kto może wywoływać które tool’e. Microsoft pokazuje podejście z JWT i praktycznymi wzorcami wdrożeniowymi dla serwerów MCP.
  • Jeśli wystawiasz MCP przez warstwę zarządzania API, rozważ centralne egzekwowanie polityk dostępowych (klucze/subskrypcje, tokeny, walidacja) i spójny audyt wywołań.

Ochrona przed indirect prompt injection i „tool chaining”

  • Traktuj treści zewnętrzne (WWW/pliki) jako dane nieufne i projektuj agenta tak, by oddzielać „instrukcje” od „kontekstu”.
  • Dodaj reguły: agent nie może wykonywać operacji wysokiego ryzyka na podstawie niezweryfikowanej treści (np. z README). W praktyce: polityki wykonywania narzędzi, klasyfikacja ryzyka tool’i, oraz walidacje parametrów po stronie serwera MCP.

Różnice / porównania z innymi przypadkami

To nie jest „kolejna podatność w web appce”.
W klasycznym SSRF atakujący zwykle bije w endpoint aplikacji. W MCP często bije w narzędzie uruchamiane przez agenta, które działa z innym poziomem zaufania i uprawnień.

To nie jest też „tylko prompt injection”.
Prompt injection jest wyzwalaczem, ale realne szkody wynikają z tego, że agent ma dostęp do narzędzi o mocy porównywalnej z kontem uprzywilejowanym (chmura, system plików, repo). To przesuwa ciężar obrony na: tożsamość, granice sieciowe, walidację parametrów i polityki wykonywania narzędzi.

Podsumowanie / kluczowe wnioski

  • MCP przyspiesza budowę agentów AI, ale jednocześnie tworzy nową, bardzo „twardą” powierzchnię ataku: SSRF → sekrety → przejęcie chmury oraz kompozycja narzędzi → RCE.
  • Największe ryzyko wynika z braku ograniczeń na wejściu (URI/ścieżki/argumenty) i z faktu, że serwer MCP działa jako uprzywilejowany wykonawca.
  • Skuteczna obrona to kombinacja: walidacji + izolacji + least privilege + kontroli tożsamości + polityk wykonywania narzędzi (a nie tylko „lepszego promptu”).

Źródła / bibliografia

  1. Dark Reading — „Microsoft & Anthropic MCP Servers At Risk of RCE, Cloud Takeovers” (20.01.2026). (Dark Reading)
  2. The Register — opis podatności i CVE w Anthropic Git MCP (20.01.2026). (The Register)
  3. Microsoft Learn — „Foundry MCP Server best practices and security guidance” (aktualizacje i governance). (Microsoft Learn)
  4. Microsoft TechCommunity — „It’s time to secure your MCP servers. Here’s how.” (JWT, podejście wdrożeniowe). (TECHCOMMUNITY.MICROSOFT.COM)
  5. Model Context Protocol — „Security Best Practices” (ryzyka i mitigacje specyficzne dla MCP, m.in. confused deputy). (Model Context Protocol)

Korea Północna i „Contagious Interview”: jak złośliwe projekty VS Code uruchamiają malware przez tasks.json

Wprowadzenie do problemu / definicja luki

Kampania powiązana z aktorami DPRK (Korea Północna), znana jako Contagious Interview, ewoluuje w stronę ataków „zero-click-ish” z perspektywy programisty: ofiara nie musi świadomie uruchamiać malware, wystarczy że sklonuje repo i otworzy je w Visual Studio Code. Najnowszy wariant wykorzystuje mechanizm VS Code Tasks (.vscode/tasks.json) do automatycznego wykonania poleceń po otwarciu folderu projektu, prowadząc do instalacji backdoora z funkcjami zdalnego wykonania kodu.

Kluczowe w tym łańcuchu jest zachowanie użytkownika: VS Code pyta o zaufanie do repozytorium (Workspace Trust), a udzielenie zaufania może uruchomić przetwarzanie zadań i wykonanie osadzonych komend.

W skrócie

  • APT powiązany z DPRK podszywa się pod rekruterów/CTO i dostarcza „zadania rekrutacyjne” jako repozytoria Git.
  • Repo zawiera .vscode/tasks.json z runOptions.runOn: "folderOpen", co pozwala na uruchomienie zadania przy otwarciu projektu (po zgodzie na automatyczne taski).
  • W obserwacjach Jamf na macOS dochodziło do uruchomienia w tle polecenia pobierającego zdalny JavaScript (hostowany m.in. na Vercel) i „wpinającego” go bezpośrednio do Node.js (pipe), co realizuje backdoora i pętlę beaconingu.
  • Kampania wykorzystuje i rozwija rodziny malware powiązane z Contagious Interview: BeaverTail (warstwa Node/infostealer/downloader) i InvisibleFerret (backdoor, często Python).

Kontekst / historia / powiązania

Contagious Interview jest śledzona od co najmniej 2023 r. jako kampania nastawiona na programistów i osoby szukające pracy w branży tech. Unit 42 opisywał scenariusze, w których fałszywi rekruterzy nakłaniali ofiary do instalacji/uruchomienia „aplikacji” (np. podszywających się pod narzędzia do rozmów), co prowadziło do infekcji BeaverTail oraz finalnie InvisibleFerret.

W styczniu 2026 r. obserwujemy przesunięcie ciężaru z „uruchom plik” na „otwórz repo w IDE”: socjotechnika pozostaje podobna (LinkedIn, zadanie techniczne, code review), ale technika wykonania payloadu coraz mocniej wpasowuje się w domyślne workflow deweloperskie.

Analiza techniczna / szczegóły luki

1) Mechanizm: VS Code Tasks + runOn: folderOpen

VS Code pozwala definiować zadania w .vscode/tasks.json. Dokumentacja opisuje runOptions.runOn, gdzie folderOpen oznacza uruchomienie taska przy otwarciu folderu. Co ważne: przy pierwszym otwarciu folderu z takim taskiem użytkownik dostaje pytanie, czy zezwolić na automatyczne uruchamianie zadań w tym folderze.

W praktyce atakujący:

  • ukrywa złośliwy task wśród „normalnych” zadań (np. udających lint/build),
  • ustawia runOn: "folderOpen",
  • dobiera komendę tak, aby wyglądała niegroźnie (np. uruchomienie pliku udającego font), ale w rzeczywistości wykonywała kod (np. node ...).

2) Punkt krytyczny: Workspace Trust

Jamf wskazuje, że przy otwarciu projektu VS Code pyta o zaufanie do autora repozytorium, a po jego udzieleniu aplikacja może automatycznie przetwarzać tasks.json, co „otwiera drzwi” do wykonania arbitralnych poleceń osadzonych w taskach.

3) Łańcuch infekcji obserwowany przez Jamf (macOS)

W badanym wariancie na macOS uruchamiane było polecenie w tle (m.in. z nohup bash -c), które pobierało zdalny JavaScript i przekazywało go bezpośrednio do runtime Node.js. Payload (hostowany na infrastrukturze typu vercel.app) implementował logikę backdoora: rozpoznanie hosta, utrzymywanie pętli wykonywania, komunikacja z serwerem i możliwość zdalnego wykonania kodu.

4) „Dual-stack” i dodatkowe wektory (wg Security Alliance)

Security Alliance opisuje architekturę „dual-stack”:

  • warstwa Node.js: szybka kradzież danych (m.in. klucze, screeny, pliki, przeglądarki) i uruchomienie kanału zdalnego sterowania,
  • warstwa Python: komponenty długotrwałe, w tym kradzież portfeli i elementy monetizacji (np. mining).

W raporcie pojawiają się też warianty awaryjne: jeśli wektor VS Code nie zadziała, malware może „zahaczać” o logikę aplikacji (uruchomi się dopiero przy starcie projektu) lub próbować dociągnąć złośliwą zależność npm.

Praktyczne konsekwencje / ryzyko

Dlaczego to groźne dla organizacji, nie tylko dla kandydatów?

  • Programista często pracuje na urządzeniu z dostępem do repozytoriów firmowych, sekretów CI/CD, tokenów chmurowych, kluczy SSH i portfeli kryptowalutowych (szczególnie w fintech/crypto).
  • Atak może zadziałać nawet wtedy, gdy ofiara „tylko zerknie na kod” lub pozwoli narzędziu AI przeanalizować repo (bo w tle uruchamia się task/Trusted Workspace).
  • Skutki obejmują: przejęcia kont, exfiltrację IP/source code, kradzież środków, a także lateral movement do środowisk firmowych.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów developerskich (natychmiast)

  1. Nie ufaj repo „z rekrutacji” domyślnie: jeśli VS Code pyta o Workspace Trust — traktuj to jak prompt bezpieczeństwa (tak jak ostrzeżenie o makrach).
  2. Przeglądaj .vscode/tasks.json zanim otworzysz projekt
    • Szukaj runOptions + runOn: "folderOpen" oraz zadań o mylących nazwach (lint, eslint-check, build).
  3. Otwieraj nieznane repo w izolacji: VM / kontener / osobny profil użytkownika bez dostępów do firmowych sekretów (kluczy SSH, tokenów chmurowych). (To wynika bezpośrednio z wektorów i celów kampanii opisanych w źródłach.)
  4. Polityka zależności: instaluj pakiety npm tylko z weryfikowanych źródeł i unikaj „npm install” na niezweryfikowanych repozytoriach.

Dla SOC / Blue Team (detekcja i hunting)

  • Telemetria procesów: wzorce typu bash -c ... curl ... | node, nietypowe uruchomienia Node przy otwieraniu folderu w VS Code, oraz procesy potomne VS Code uruchamiające shell.
  • Polowanie po artefaktach: nietypowe pliki w .vscode/, zadania z runOn: folderOpen, podejrzane „zasoby” udające fonty uruchamiane przez node.
  • Egress/IOC: podwyższona czujność na krótkotrwałe domeny/hosting używany do stagingu payloadów (w obserwacjach pojawia się Vercel).

Różnice / porównania z innymi przypadkami

  • Wcześniej (2023–2024): częsty schemat to nakłonienie ofiary do instalacji/uruchomienia „aplikacji” lub kodu w ramach rozmowy rekrutacyjnej; BeaverTail i InvisibleFerret były rozwijane i przenoszone między platformami (macOS/Windows).
  • Teraz (2025–2026): nacisk przesuwa się na łańcuch dostawy przez repozytoria i IDE — otwarcie folderu w VS Code może uruchomić złośliwy task (folderOpen), a dodatkowe wektory (hook w runtime aplikacji, zależności npm) zwiększają „odporność” ataku na niepowodzenie jednego sposobu.

Podsumowanie / kluczowe wnioski

  • Mechanizmy automatyzacji w IDE (Tasks) są funkcją produktywności, ale w rękach APT stają się wektorem initial access — szczególnie gdy łączą się z socjotechniką „zadania rekrutacyjnego”.
  • Największe ryzyko wynika z „małego” kliknięcia: Workspace Trust i zgoda na automatyczne taski.
  • Organizacje powinny traktować nieznane repozytoria jak nieznane załączniki: izolacja, przegląd przed uruchomieniem, polityki zależności i telemetryka procesów.

Źródła / bibliografia

  1. The Hacker News – opis kampanii i najnowszego wariantu z VS Code Tasks (20 stycznia 2026). (The Hacker News)
  2. Jamf Threat Labs – analiza nadużyć VS Code i łańcucha infekcji (20 stycznia 2026). (jamf.com)
  3. Microsoft (VS Code Docs) – dokumentacja tasks.json, runOptions i runOn: folderOpen. (code.visualstudio.com)
  4. Security Alliance (Radar) – raport techniczny: „VS Code Tasks Abuse by Contagious Interview (DPRK)” (13 stycznia 2026). (Radar | Security Alliance)
  5. Unit 42 (Palo Alto Networks) – tło kampanii Contagious Interview oraz BeaverTail/InvisibleFerret (9 października 2024). (Unit 42)

Evelyn Stealer: jak złośliwe rozszerzenia VS Code przeradzają się w pełny atak na środowisko deweloperskie

Wprowadzenie do problemu / definicja luki

Evelyn Stealer to kampania malware typu information stealer, która uderza w szczególnie wrażliwy punkt nowoczesnych firm: środowisko pracy programistów. Zamiast atakować klasyczne stacje użytkowników końcowych, operatorzy kampanii wykorzystują zaufanie do narzędzi developerskich — w tym przypadku ekosystem rozszerzeń Microsoft Visual Studio Code — aby dostarczyć wieloetapowy ładunek kradnący dane.

Z perspektywy bezpieczeństwa to nie jest „kolejny stealer”. To przykład ataku, w którym pojedyncza kompromitacja laptopa developera może stać się przyczółkiem do dalszego dostępu: tokenów chmurowych, sekretów w repozytoriach, danych produkcyjnych i — coraz częściej — zasobów kryptowalutowych.

W skrócie

  • Wejście: złośliwe rozszerzenia VS Code podszywające się pod użyteczne dodatki (m.in. warianty: BigBlack.bitcoin-black, BigBlack.codo-ai, BigBlack.mrbigblacktheme).
  • Etap 1: zrzut i uruchomienie Lightshot.dll (udającej komponent narzędzia) oraz ukryty PowerShell pobierający kolejny etap (runtime.exe).
  • Etap 2: process hollowing — wstrzyknięcie finalnego stealera do legalnego procesu Windows grpconv.exe.
  • Kradzione dane: m.in. cookies i hasła przeglądarek, dane systemowe, schowek, Wi-Fi, portfele crypto, zrzuty ekranu.
  • Eksfiltracja: przesyłanie archiwum ZIP do C2 po FTP (np. server09.mentality[.]cloud).
  • Malware ma rozbudowane anti-analysis / anti-VM, by utrudniać sandboxing i pracę analitykom.

Kontekst / historia / powiązania

Trend Micro opisuje Evelyn jako przykład „operacjonalizacji” ataków na społeczność deweloperską: narzędzie pracy (IDE + dodatki) staje się mechanizmem dostarczania malware.

Co ważne: Microsoft od dawna deklaruje wielowarstwowe zabezpieczenia Marketplace (skanowanie antywirusowe, analiza zachowania w sandboxie, weryfikacja wydawców, blocklista i wymuszone odinstalowanie złośliwych rozszerzeń). To jednak nie eliminuje ryzyka „tu i teraz” — zanim rozszerzenie zostanie wykryte i usunięte, okno czasowe wystarcza na infekcję i kradzież sekretów.

W tle mamy też szerszy trend: złośliwe kampanie w VSCode Marketplace regularnie wracają w nowych wariantach (np. ukrywanie trojana w zależnościach i plikach podszywających się pod obrazy).

Analiza techniczna / szczegóły luki

1) Initial access: złośliwe rozszerzenie VS Code

Według opisu kampanii, ofiara instaluje złośliwe rozszerzenie, które dostarcza element udający legalny komponent „Lightshot” (DLL). W relacji Trend Micro ten „downloader” podszywa się pod Lightshot.dll, a jego uruchomienie następuje w procesie legalnego Lightshot.exe (uruchomienie ma sensowny „trigger” — załadowanie DLL).

2) Etap 1: downloader (Lightshot.dll) + PowerShell

Po załadowaniu DLL malware uruchamia ukryte polecenie PowerShell, które pobiera i uruchamia kolejny etap, zapisując go w katalogu tymczasowym jako runtime.exe. Dodatkowo stosuje mechanizmy „single instance” (mutex), by nie uruchamiać się wielokrotnie.

3) Etap 2: injector i process hollowing do grpconv.exe

Drugi etap działa jako injector: odszyfrowuje payload (AES-256-CBC) i wstrzykuje go do legalnego procesu Windows grpconv.exe uruchomionego w stanie zawieszonym (CREATE_SUSPENDED), po czym wznawia wykonanie — klasyczny wzorzec process hollowing dla redukcji artefaktów i utrudnienia detekcji.

4) Final payload: Evelyn Stealer (anti-analysis + kradzież danych)

Trend Micro podkreśla warstwy unikania analizy: wykrywanie VM (m.in. po GPU/driverach), analiza hostname, dysku (np. progi pojemności), procesów narzędzi VM oraz kluczy rejestru typowych dla środowisk wirtualnych i sandboxów.

Po „weryfikacji środowiska” stealer:

  • tworzy strukturę roboczą w AppData,
  • odzyskuje dane przeglądarkowe, kończy procesy przeglądarek,
  • pobiera/odtwarza krytyczny komponent do ekstrakcji danych przeglądarkowych (abe_decrypt.dll),
  • pakuje dane i eksfiltruje je do C2 po FTP.

Praktyczne konsekwencje / ryzyko

W kampaniach celujących w developerów ryzyko jest zwykle większe niż „wyciek haseł”:

  • Kompromitacja łańcucha CI/CD: jeśli na stacji są tokeny do repozytoriów, registry (npm/pypi), pipeline’ów czy chmury, atakujący może wykonać ruch w kierunku supply chain (podmiana paczek, backdoory w buildach).
  • Dostęp do środowisk produkcyjnych: Trend Micro wprost wskazuje, że celem są organizacje mające dostęp do systemów produkcyjnych, zasobów chmurowych lub aktywów cyfrowych.
  • Kradzież kryptowalut / tożsamości: stealer obejmuje portfele crypto, cookies i dane sesyjne — to skraca drogę do przejęcia kont bez łamania MFA (np. przez hijack sesji).
  • Trudniejsza detekcja: process hollowing do legalnego procesu + anti-VM zwiększają szanse, że infekcja „przeżyje” pierwsze godziny incydentu.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „na już”, ułożony praktycznie (DevSecOps/SOC/IT):

1) Zabezpiecz ekosystem rozszerzeń VS Code

  • Wdróż allowlistę dozwolonych rozszerzeń (polityki organizacyjne) i blokuj instalacje ad-hoc tam, gdzie to możliwe. Microsoft wprost opisuje możliwość egzekwowania dozwolonych rozszerzeń w organizacji.
  • Preferuj rozszerzenia od zweryfikowanych wydawców (sygnał zaufania), ale traktuj to jako heurystykę, nie gwarancję.
  • Rozważ proces wewnętrznego „review” rozszerzeń (SCA na paczce rozszerzenia, analiza połączeń sieciowych, uprawnień i telemetrii).

2) Polowanie/detekcja w endpointach (EDR/XDR)

Szukaj telemetrii typowej dla łańcucha:

  • powershell.exe uruchamiany w sposób ukryty po akcji w VS Code / po instalacji rozszerzenia,
  • nowe binaria typu runtime.exe w katalogach TEMP,
  • nietypowe uruchomienia grpconv.exe i anomalie procesu (np. „hollowing” widoczny w EDR),
  • obecność podejrzanych DLL jak Lightshot.dll w nietypowych ścieżkach związanych z rozszerzeniami.

3) Kontrola egress i protokołów „legacy”

  • Zablokuj / monitoruj FTP egress tam, gdzie nie jest absolutnie konieczny (w wielu firmach to szybkie zwycięstwo). Kampania używa FTP do C2 i eksfiltracji ZIP.
  • Dodaj alertowanie na domeny/hosty anormalne dla stacji developerskich (w przykładach pojawia się server09.mentality[.]cloud).

4) Higiena sekretów i ograniczanie blast radius

  • Wymuś krótkie TTL dla tokenów, rotację i ograniczenie uprawnień (least privilege) dla: repo, CI, chmury, rejestrów paczek.
  • Egzekwuj przechowywanie sekretów w vaultach (a nie w plikach konfiguracyjnych, schowku, zmiennych środowiskowych bez kontroli).
  • Włącz skanowanie sekretów w kodzie i na endpointach (w tym pre-commit / pre-push).

5) Reakcja na incydent

Jeśli podejrzewasz infekcję:

  • izoluj host, zrób triage artefaktów (VS Code extensions folder, TEMP, AppData),
  • rotuj wszystkie potencjalnie wykradzione sekrety,
  • przeglądnij logi dostępu do repozytoriów i chmury pod kątem nietypowych akcji z czasu infekcji.

Różnice / porównania z innymi przypadkami

Evelyn Stealer wpisuje się w serię incydentów, gdzie Marketplace rozszerzeń jest traktowany jak kanał dystrybucji malware:

  • W grudniu 2025 opisywano kampanię z 19 złośliwymi rozszerzeniami, w których payload ukryto w zależnościach i plikach podszywających się pod obrazy (np. „fake PNG”), a kod wykonywał się przy starcie IDE.
  • Microsoft jednocześnie rozwija mechanizmy obronne (skanowanie, sandbox, blocklista, automatyczne odinstalowanie) i podkreśla rolę zgłoszeń społeczności. Dla obrońców oznacza to jedno: nie można zakładać, że „Marketplace = bezpieczne”, a kontrola organizacyjna (allowlista + monitoring) pozostaje kluczowa.

Na tle innych kampanii wyróżnia się tu dojrzałość łańcucha: DLL-loader → PowerShell → process hollowing → anti-analysis → FTP exfil — czyli konstrukcja typowa raczej dla bardziej „profesjonalnych” operacji niż masowego malware z reklam.

Podsumowanie / kluczowe wnioski

  • Deweloperzy są celem wysokiej wartości, bo ich stacje to magazyn tokenów, dostępów i artefaktów łańcucha dostaw.
  • W kampanii Evelyn kluczowy jest wektor VS Code extension, a potem klasyczne techniki stealth (process hollowing do grpconv.exe) i bogata kradzież danych.
  • Największy efekt obronny dają: allowlista rozszerzeń, monitoring PowerShell/grpconv.exe, oraz ograniczenie egress (zwłaszcza FTP).

Źródła / bibliografia

  1. Trend Micro — From Extension to Infection: An In-Depth Analysis of the Evelyn Stealer Campaign Targeting Software Developers (19 stycznia 2026). (trendmicro.com)
  2. The Hacker News — Evelyn Stealer Malware Abuses VS Code Extensions to Steal Developer Credentials and Crypto (20 stycznia 2026). (The Hacker News)
  3. Microsoft (VS Code Docs) — Extension runtime security (opis mechanizmów ochronnych Marketplace). (Visual Studio Code)
  4. Microsoft for Developers — Security and Trust in Visual Studio Marketplace (11 czerwca 2025). (Microsoft Developer)
  5. BleepingComputer — Malicious VSCode Marketplace extensions hid trojan in fake PNG file (11 grudnia 2025). (BleepingComputer)

Google Chrome pozwala wyłączyć i usunąć lokalny model AI od wykrywania scamów (Enhanced Protection)

Wprowadzenie do problemu / definicja luki

Google rozwija w Chrome dodatkową warstwę ochrony przed oszustwami (scamami) w ramach Safe Browsing → Enhanced Protection. Kluczowym elementem stał się lokalny (on-device) model AI, który ma szybciej rozpoznawać podejrzane strony i zachowania — w tym takie, które „żyją” zaledwie kilka minut i nie zdążą trafić na klasyczne listy blokad.

Nowość opisana 17 stycznia 2026 r. dotyczy kontroli użytkownika: w Chrome pojawiła się opcja pozwalająca wyłączyć „On-device GenAI” i tym samym usunąć lokalne modele AI wykorzystywane m.in. do mechanizmów anty-scam w Enhanced Protection (na razie w kanale Canary).

W skrócie

  • W Chrome (Canary) dodano przełącznik Settings → System → “On-device GenAI”, który pozwala wyłączyć i usunąć lokalny model AI używany przez Enhanced Protection.
  • Ochrona anty-scam w Chrome korzysta z podejścia on-device (Gemini Nano) do wyciągania sygnałów bezpieczeństwa ze strony, po czym Safe Browsing może wystawić „ostateczny werdykt”.
  • Funkcja (i wysyłanie streszczonych sygnałów) działa dla użytkowników, którzy świadomie włączyli Enhanced Protection.
  • W środowiskach firmowych poziom Safe Browsing można kontrolować polityką SafeBrowsingProtectionLevel.

Kontekst / historia / powiązania

  • Enhanced Protection istnieje od lat jako „mocniejszy” tryb Safe Browsing, ale w 2025 r. został istotnie rozbudowany o komponenty AI do ochrony „w czasie rzeczywistym”, szczególnie przeciw scamom typu tech support scam (fałszywe alerty o wirusach, blokowanie wyjścia ze strony, wymuszanie kontaktu telefonicznego itd.).
  • Google opisywało, że dzięki analizie on-device można reagować na zagrożenia szybciej — m.in. dlatego, że przeciętnie złośliwa strona potrafi istnieć bardzo krótko (rzędu minut).
  • Równolegle Google rozwija „wbudowane AI” w Chrome (Gemini Nano), poszerzając kompatybilność sprzętową (np. wsparcie inferencji także na CPU w wybranych konfiguracjach).

Analiza techniczna / szczegóły luki

Jak działa anty-scam z modelem on-device

Z perspektywy architektury bezpieczeństwa Chrome wygląda to (w uproszczeniu) tak:

  1. Trigger / sygnał uruchamiający: Chrome obserwuje zachowania typowe dla tech support scam (np. użycie Keyboard Lock API do utrudnienia zamknięcia karty/ucieczki).
  2. Analiza lokalna (on-device): treść bieżącej strony jest oceniana przez Gemini Nano w celu wyciągnięcia sygnałów bezpieczeństwa (np. „intencja strony”, wzorce socjotechniczne).
  3. Werdykt Safe Browsing: streszczone sygnały trafiają do Safe Browsing, który podejmuje decyzję o ostrzeżeniu/interstitialu.
  4. Ograniczenia wydajności i prywatności: Google deklaruje mechanizmy ograniczające koszty (rzadkie uruchamianie, limity, throttling, kontrola zasobów), a wysyłanie sygnałów ma dotyczyć użytkowników, którzy opt-in w Enhanced Protection.

Co zmienia przełącznik „On-device GenAI”

Według opisu BleepingComputer, aby usunąć lokalny model AI, użytkownik ma wejść w:
Chrome → Settings → System → wyłączyć “On-device GenAI”.

Ważne: wygląda na to, że „On-device GenAI” może docelowo zasilać więcej funkcji niż tylko scam detection, więc wyłączenie może mieć szerszy wpływ na przyszłe mechanizmy bezpieczeństwa/AI w Chrome.

Kontekst enterprise / Android

W notatkach dla Chrome Enterprise pojawia się opis, że np. w Chrome 145 na Androidzie wykrycie scam „on-device” może skutkować zapytaniem do Safe Browsing o końcowy werdykt, a funkcja ma być aktywna tylko przy Enhanced Protection; administratorzy mogą sterować poziomem ochrony polityką.

Praktyczne konsekwencje / ryzyko

Dla użytkowników indywidualnych

  • Wyłączenie/usuń model może oznaczać utratę dodatkowej warstwy ochrony przed scamami, zwłaszcza tymi szybko zmieniającymi domeny i treści (typowe dla kampanii krótkotrwałych). Logika on-device była właśnie odpowiedzią na ten problem.
  • Pojawia się „trade-off” kontrola i zasoby vs. bezpieczeństwo: niektórzy będą chcieli ograniczyć lokalne AI (np. zasoby, polityka prywatności), ale trzeba to świadomie zbilansować z ryzykiem.

Dla organizacji (IT/SOC)

  • Jeśli pracownicy mogą samodzielnie wyłączać komponent on-device, rośnie znaczenie:
    • standaryzacji ustawień Safe Browsing,
    • monitoringu zgodności,
    • oraz edukacji o skutkach „odchudzania” ochrony w przeglądarce.
  • W środowiskach enterprise warto traktować przeglądarkę jak element kontroli dostępu do SaaS, a nie tylko „aplikację użytkownika” — szczególnie gdy scam pages próbują wymuszać działania (płatności, zdalny dostęp, instalacje).

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów bezpieczeństwa (firmy)

  1. Wymuś poziom ochrony Safe Browsing tam, gdzie to uzasadnione ryzykiem (np. grupy o podwyższonej ekspozycji: finanse, HR, support). W ekosystemie Chrome Enterprise kluczowa jest polityka SafeBrowsingProtectionLevel.
  2. Zdefiniuj politykę dot. funkcji AI w przeglądarce: czy dopuszczasz on-device AI w ramach ochrony (zwykle tak), czy wymagasz określonych ustawień — i dlaczego.
  3. Komunikacja do użytkowników: krótka instrukcja „co daje Enhanced Protection” i jakie są skutki wyłączania „On-device GenAI” (mniej ochrony przed scamami).
  4. Testy kompatybilności i wpływu: jeśli organizacja wykorzystuje kanały Canary/Dev do testów, sprawdź, czy przełącznik nie wpływa na inne elementy (bo według obserwacji może dotyczyć szerszego zestawu funkcji).

Dla użytkowników indywidualnych

  • Jeśli zależy Ci na ochronie anty-scam: upewnij się, że masz włączone Safe Browsing → Enhanced Protection, a wyłączanie „On-device GenAI” rób tylko świadomie (np. do testów). Mechanizm AI był projektowany do wykrywania m.in. technik wymuszających działania na stronie.

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

Enhanced Protection vs Standard Protection

  • Enhanced Protection: dodatkowe sygnały i mechanizmy, w tym warstwa AI on-device oraz przesyłanie streszczonych sygnałów do Safe Browsing (opt-in).
  • Standard Protection: bardziej „klasyczny” model ochrony; użytkownicy mogą korzystać pośrednio, bo nowe zidentyfikowane domeny/scamy trafiają potem na bloklisty.

On-device AI vs klasyczne bloklisty

  • On-device AI ma wykrywać „wzorce i intencje” nawet wtedy, gdy domena/kreacja jest nowa.
  • Bloklisty są skuteczne, ale wymagają czasu na obserwację, klasyfikację i dystrybucję — co przy „życiu” stron scam bywa zbyt wolne.

Podsumowanie / kluczowe wnioski

Dodanie w Chrome opcji wyłączenia „On-device GenAI” to sygnał większej transparentności i kontroli użytkownika nad lokalnymi modelami AI — ale jednocześnie otwiera dyskusję o tym, czy i gdzie warto wyłączać warstwy ochronne.

Dla bezpieczeństwa praktyczny wniosek jest prosty: jeśli Enhanced Protection ma realnie łapać krótkotrwałe scamy, to usunięcie lokalnego modelu AI może osłabić ten scenariusz ochrony. W organizacjach warto przygotować polityki i komunikację, zanim funkcja trafi szerzej ze środowisk testowych do stabilnych wydań.

Źródła / bibliografia

  1. BleepingComputer – „Google Chrome now lets you turn off on-device AI model powering scam detection” (17 stycznia 2026). (BleepingComputer)
  2. Google Online Security Blog – „Using AI to stop tech support scams in Chrome” (8 maja 2025). (Google Online Security Blog)
  3. Chrome Enterprise and Education release notes – wzmianka o „On-device scam detection on Android” i kontroli polityką. (Google Help)
  4. Malwarebytes – omówienie wdrożenia Gemini Nano w Chrome 137 i kontekstu tech support scams. (Malwarebytes)
  5. Chrome for Developers – „Expanding built-in AI to more devices with Chrome” (1 października 2025). (Chrome for Developers)