Archiwa: AI - Strona 157 z 177 - Security Bez Tabu

Tag: AI

Anthropic i Mozilla wzmacniają bezpieczeństwo Firefoksa: Claude znalazł 22 podatności (14 high) w 2 tygodnie

Wprowadzenie do problemu / definicja luki

W przeglądarkach internetowych podatności są wyjątkowo groźne, bo przetwarzają niezaufane treści (strony WWW, skrypty, WebAssembly) wprost z internetu. Dlatego Firefox od lat jest intensywnie „hartowany” i audytowany. Mimo to Anthropic i Mozilla pokazali, że nowa generacja modeli AI może radykalnie przyspieszyć wykrywanie błędów bezpieczeństwa nawet w tak dojrzałym projekcie.

Anthropic opisało współpracę z Mozillą, w której model Claude Opus 4.6 wykrył w Firefoksie 22 podatności w dwa tygodnie, z czego Mozilla sklasyfikowała 14 jako high-severity.

W skrócie

  • 22 podatności / 22 CVE wykryte podczas współpracy Anthropic x Mozilla w horyzoncie ~2 tygodni.
  • 14 z nich Mozilla oceniła jako high-severity (Anthropic wskazuje, że to „prawie 1/5” wszystkich high-severity naprawionych w 2025 r.).
  • Poprawki trafiły do użytkowników w Firefox 148.0 (wydanie z lutego 2026; część mniej krytycznych elementów mogła czekać na kolejne wydania).
  • W tym samym nurcie badań Anthropic opublikowało analizę, jak Claude zbudował PoC exploita dla CVE-2026-2796 – ale tylko w środowisku testowym, bez pełnych realnych mitigacji przeglądarki (nie był to „full-chain” sandbox escape).

Kontekst / historia / powiązania

Mozilla wprost podkreśla problem, który dobrze znają maintainerzy open source: AI-generowane zgłoszenia bywają niskiej jakości, pełne fałszywych pozytywów i tworzą dług techniczny w triage. Różnica w tym przypadku miała polegać na tym, że Anthropic dostarczało minimalne przypadki testowe (minimal test cases) umożliwiające szybkie odtworzenie i weryfikację.

Anthropic opisuje też metodykę: zaczęli od prób odtwarzania historycznych CVE (żeby „skalibrować” model), a następnie przeszli do wykrywania nowych crashy i błędów — m.in. w silniku JavaScript.

Analiza techniczna / szczegóły luki

1. Co wiemy o znalezionych błędach (bez nadmiaru „marketingu”)

Z perspektywy praktycznej ważne są dwie rzeczy:

  1. Skala i różnorodność: poza 22 błędami security-sensitive, Mozilla potwierdza też ok. 90 innych bugów, często niższej wagi (np. assertion failures), częściowo podobnych do tego, co tradycyjnie wyłapuje fuzzing — ale też z klasami błędów logicznych, których fuzzer nie musi łatwo dotknąć.
  2. Szybkość iteracji: Mozilla pisze o wdrażaniu poprawek „w ciągu godzin” od pierwszych raportów oraz o rozszerzeniu podejścia na resztę codebase’u.

2. CVE-2026-2796: JIT / WebAssembly i „dziura” na granicy typów

Anthropic opublikowało techniczne rozbicie przypadku CVE-2026-2796, opisując go jako problem JIT miscompilation w komponencie JavaScript/WebAssembly oraz błąd związany z optymalizacją ścieżki Function.prototype.call.bind(...). W skrócie: specyficzny wrapper call.bind wpadał w „fast path”, który prowadził do niebezpiecznego zachowania na granicy JS↔Wasm (type safety boundary), umożliwiając budowę prymitywów read/write w pamięci procesu — ale w warunkach laboratoryjnych.

Kluczowy niuans bezpieczeństwa: Anthropic zaznacza, że to nie był jeszcze przypadek tworzenia „pełnołańcuchowych” exploitów omijających realne, wielowarstwowe zabezpieczenia nowoczesnych przeglądarek (np. pełny sandbox escape).

Praktyczne konsekwencje / ryzyko

  • Dla użytkowników końcowych przekaz jest prosty: „przeglądarka została załatana”, ale okno ryzyka zawsze istnieje między odkryciem a powszechnym wdrożeniem aktualizacji. W tej historii Mozilla podkreśla, że poprawki trafiły do użytkowników w Firefox 148.
  • Dla organizacji to sygnał strategiczny: AI może zwiększyć tempo znajdowania podatności, co oznacza większą presję na procesy patch managementu oraz triage (zwłaszcza w mniejszych projektach i zespołach).
  • Dla ofensywy: obecnie — według publicznych opisów — model był dużo lepszy w „find” niż „exploit”, ale trend capability jest wyraźny i warto go traktować jako wskaźnik kierunku.

Rekomendacje operacyjne / co zrobić teraz

Użytkownicy indywidualni

  • Zaktualizuj Firefoksa do najnowszej wersji (co najmniej 148.0) i włącz automatyczne aktualizacje.
  • Jeżeli używasz wielu profili/urządzeń: upewnij się, że aktualizacja została wykonana na wszystkich stanowiskach (laptopy, domowe PC, testowe VM).

IT / SecOps / organizacje

  • Wymuś compliance wersji przeglądarki (MDM/Intune/Jamf/GPO, zależnie od środowiska) i monitoruj odchylenia.
  • Traktuj przeglądarkę jako element „high-exposure”: rozważ dodatkowe polityki (hardening, ograniczenia rozszerzeń, izolacja profilu, kontrola pobieranych plików).
  • Przygotuj proces na „AI-driven vuln discovery”: więcej zgłoszeń, krótszy czas od „bug” do „patch”, większe znaczenie priorytetyzacji.

Dla maintainerów i zespołów bezpieczeństwa oprogramowania

  • Jeśli dopuszczasz zgłoszenia wspierane przez AI: egzekwuj standard reprodukowalności (minimal test case, wersje, środowisko, expected vs actual) — Mozilla wskazuje, że to było kluczowe, by uniknąć typowej fali fałszywych pozytywów.

Różnice / porównania z innymi przypadkami

AI vs fuzzing (praktycznie, nie ideologicznie):

  • Fuzzing świetnie „mieli” wejścia i crashuje, ale bywa, że nie trafia w subtelne błędy logiczne lub wymaga żmudnej konfiguracji/orkiestracji.
  • W opisie Mozilli model nie tylko generował crashe, ale też pomagał wychwycić klasy problemów wykraczające poza typowy profil fuzzera (przynajmniej w części przypadków).
  • Najbardziej wartościowy obraz to hybryda: fuzzing + statyczna analiza + review + AI jako kolejna warstwa, pod warunkiem twardego triage.

Podsumowanie / kluczowe wnioski

  • Współpraca Anthropic i Mozilli to mocny dowód, że modele AI zaczynają działać jak akcelerator defensywnego bug huntingu nawet w projektach o wysokiej dojrzałości bezpieczeństwa.
  • Największym „sekretem sukcesu” nie jest samo AI, tylko operacyjna jakość zgłoszeń (minimalne testy, możliwość odtworzenia, sensowna selekcja).
  • Z perspektywy użytkownika i firmy: wygrywa ten, kto ma krótki cykl aktualizacji i widoczność wersji przeglądarek w całej flocie.

Źródła / bibliografia

  1. Anthropic: „Partnering with Mozilla to improve Firefox’s security” (6 marca 2026). (Anthropic)
  2. Mozilla: „Hardening Firefox with Anthropic’s Red Team” (6 marca 2026). (Mozilla Blog)
  3. Anthropic (red team): „Reverse engineering Claude’s CVE-2026-2796 exploit” (6 marca 2026). (red.anthropic.com)
  4. Axios: podsumowanie skali i kontekstu (6 marca 2026). (Axios)
  5. The Wall Street Journal: kontekst dot. wykrywania vs zdolności exploitacji (6 marca 2026). (The Wall Street Journal)

AI jako „tradecraft”: jak cyberprzestępcy i APT operacjonalizują sztuczną inteligencję

Wprowadzenie do problemu / definicja luki

Microsoft w najnowszej analizie opisuje przejście od „AI jako ciekawostki” do AI jako elementu rzemiosła operacyjnego (tradecraft) – czyli wpięcia modeli i narzędzi AI w codzienny łańcuch działań atakującego: od rekonesansu, przez socjotechnikę i budowę infrastruktury, po rozwój malware i działania po kompromitacji. Kluczowa obserwacja: AI bywa używana zarówno jako akcelerator (przyspiesza znane TTP), jak i jako broń (umożliwia nowe wektory, np. omijanie zabezpieczeń modeli czy półautonomiczne „agentowe” workflow).

W skrócie

  • Atakujący używają AI do redukcji tarcia (mniej umiejętności → podobny efekt), zwiększenia skali (więcej prób/operacji) i podniesienia wiarygodności (lepszy język, deepfake, dopasowane persony).
  • Microsoft opisuje realne nadużycia m.in. w kampaniach północnokoreańskich „remote IT workers”, gdzie AI wspiera fabrykację tożsamości, rozmowy rekrutacyjne, utrzymanie zatrudnienia i nadużycie legalnego dostępu.
  • Widać sygnały przejścia w kierunku agentic AI (działania celowe w czasie, z użyciem narzędzi), choć na razie ograniczane przez niezawodność i ryzyko operacyjne.

Kontekst / historia / powiązania

Wątek „AI w rękach przeciwnika” nie jest już wyłącznie domeną phishingu. Raport Google Threat Intelligence Group opisuje, że państwowe grupy APT traktują LLM-y jako narzędzie do researchu, targetingu i szybkiego generowania treści socjotechnicznych (często w wielu językach), co skraca cykl przygotowania kampanii.
Z drugiej strony Cloudflare wskazuje, że GenAI pomaga automatyzować działania o wysokiej przepustowości (m.in. rozpoznanie, tworzenie deepfake, przyspieszenie prac nad exploitami) i obniża próg wejścia dla mniej doświadczonych aktorów.
W tle mamy też rosnącą potrzebę „mapowania” zagrożeń na poziomie taksonomii: MITRE ATLAS porządkuje TTP wymierzone w systemy AI/ML (od manipulacji wejściem po eksfiltrację i nadużycia pipeline’ów).

Analiza techniczna / szczegóły

Poniżej najważniejsze obszary, w których Microsoft obserwuje operacyjne użycie AI.

1) Omijanie zabezpieczeń modeli (jailbreak / nadużycia promptów)

Atakujący testują techniki „role-based jailbreak”: wymuszanie na modelu przyjęcia zaufanej roli („odpowiedz jak analityk bezpieczeństwa”) albo budowanie kontekstu legalności, aby uzyskać bardziej wrażliwe instrukcje. Microsoft opisuje też łańcuchowanie poleceń i podszywanie się pod „system/developer prompts”.

2) Rekonesans i research podatności

LLM-y są wykorzystywane jako asystent do analizy publicznych podatności i ścieżek eksploatacji. Microsoft podaje przykład obserwacji (we współpracy z OpenAI), gdzie aktor „Emerald Sleet” używał LLM do researchu CVE (m.in. CVE-2022-30190/MSDT).

3) Budowa zasobów: persony, infrastruktura, domeny

W scenariuszu „remote IT workers” (Jasper Sleet) AI wspiera:

  • generowanie list imion/nazwisk i formatów adresów e-mail dopasowanych kulturowo,
  • analizę ogłoszeń o pracę i ekstrakcję wymaganych umiejętności,
  • dopasowanie CV/persony do konkretnej roli.

Po stronie infrastruktury Microsoft opisuje m.in. automatyzację tworzenia domen look-alike (z użyciem podejść GAN) oraz projektowanie/konfigurację tuneli, reverse proxy, VPN, z naciskiem na skalowanie i odporność.

4) Socjotechnika i „high-trust” impersonation

AI wzmacnia phishing i podszycia poprzez generowanie treści, ale też media: Microsoft wskazuje użycie Faceswap do podmiany twarzy w dokumentach i zdjęciach do CV oraz oprogramowania do zmiany głosu w rozmowach rekrutacyjnych.

5) Rozwój malware i „ślady” kodu tworzonego z AI

W aktywności Coral Sleet Microsoft zauważa szybki wzrost możliwości dzięki AI-asystowanemu iteracyjnemu programowaniu: generowanie, poprawianie i reimplementacja komponentów malware, a nawet end-to-end workflow (lure → fałszywe strony → infrastruktura → testy → wdrożenie).

Ciekawy element obrony: Microsoft wymienia heurystyki „AI-assisted code”, np. emoji jako markery (✅/❌), konwersacyjne komentarze inline oraz „przegadane” nazewnictwo funkcji/zmiennych czy nadmierną modularność.

6) Post-compromise: analiza środowiska, selekcja danych, wymuszenia

Po kompromitacji AI działa jako przyspieszacz: streszcza logi/konfiguracje, pomaga rozpoznać „co tu jest cenne” (DC, bazy, konta uprzywilejowane), a także wspiera etap eksfiltracji i monetyzacji (kategoryzacja danych, przygotowanie komunikacji wymuszeniowej).

7) Trend: agentic AI (jeszcze nie masowo)

Microsoft widzi pierwsze sygnały użycia agentów (planowanie kroków, używanie narzędzi, adaptacja bez ciągłego promptowania), ale podkreśla, że skala jest nadal ograniczona przez niezawodność i ryzyko.

Praktyczne konsekwencje / ryzyko

  1. Większa przepustowość ataków: krótszy czas przygotowania kampanii i szybsze iteracje „co działa”.
  2. Wyższa wiarygodność: lepszy język, dopasowanie kulturowe, deepfake wideo/voice → mniej „czerwonych flag” dla człowieka.
  3. „Insider risk” przez legalny dostęp: wątek remote IT workers przesuwa ciężar obrony z klasycznego „włamania” na wykrywanie nadużyć zaufanych kont i długotrwałej, niskoszumowej aktywności.
  4. Nowa powierzchnia ataku w aplikacjach AI: prompt injection/jailbreak i ryzyka łańcucha danych (training/inference) – to obszar, który wymaga osobnych kontroli i monitoringu.

Rekomendacje operacyjne / co zrobić teraz

A) Jeśli obawiasz się „AI-wzmocnionej” socjotechniki i przejęć kont

  • Egzekwuj MFA wszędzie, bez wyjątków; monitoruj anomalie logowań (np. „impossible travel”).
  • Przenieś detekcję z „języka maila” na sygnały behawioralne i infrastrukturę dostarczenia (linki, wzorce wysyłki, kontekst).

B) Jeśli ryzykiem są „remote IT workers” i nadużycie legalnego dostępu

  • Traktuj to jak scenariusz insider threat: telemetryka użycia danych, nietypowe dostępy, długotrwałe „low and slow”.
  • W procesach HR/IT: wideo-weryfikacja, kontrola spójności tożsamości, analiza artefaktów deepfake (spójność temporalna, okluzje, synchronizacja audio-wideo). Microsoft sugeruje też użycie narzędzi do analizy obrazów, np. FaceForensics++.

C) Jeśli budujesz lub wdrażasz aplikacje oparte o LLM

  • Wprowadź ochronę przed atakami na prompty (np. detekcja prompt injection / indirect attacks) oraz kontrolę „groundedness”, aby ograniczać halucynacje i odpowiedzi „oderwane” od źródeł.
  • Zabezpieczaj dane używane do trenowania i działania AI zgodnie z dobrymi praktykami ochrony danych (integralność, kontrola dostępu, minimalizacja).
  • Użyj MITRE ATLAS jako „checklisty TTP” do threat modelingu systemów AI/ML (mapowanie technik ataku → kontrolki → testy).

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

  • Microsoft mocno akcentuje „AI wpięte w łańcuch operacji” i daje przykłady z działań realnych aktorów (Jasper Sleet, Coral Sleet) – od rekrutacji po malware i nadużycia po kompromitacji.
  • Google GTIG kładzie nacisk na to, że grupy państwowe wykorzystują LLM-y jako narzędzie do researchu, targetingu i tworzenia treści socjotechnicznych szybciej i na większą skalę.
  • Cloudflare opisuje „industrializację” zagrożeń: automatyzację, deepfake, przyspieszenie działań ofensywnych i spadek progu wejścia dla mniej doświadczonych aktorów.

Podsumowanie / kluczowe wnioski

  1. AI nie musi tworzyć „nowych cudownych ataków”, żeby zmienić sytuację obrońców – wystarczy, że przyspiesza i skaluje stare, sprawdzone TTP.
  2. Najbardziej niedoceniane ryzyko to nadużycie zaufanego dostępu (insider-like) i wzrost jakości podszyć (voice/deepfake/persony).
  3. Organizacje powinny równolegle: (a) utwardzać tożsamości i kanały komunikacji, (b) wdrażać zabezpieczenia specyficzne dla aplikacji LLM (prompt injection, groundedness), (c) modelować zagrożenia dla AI w oparciu o ATLAS i dobre praktyki ochrony danych.

Źródła / bibliografia

  1. Microsoft Security Blog – AI as tradecraft: How threat actors operationalize AI (06.03.2026) (microsoft.com)
  2. Google Cloud / GTIG – Distillation, Experimentation, and Integration… (12.02.2026) (Google Cloud)
  3. Cloudflare – Introducing the 2026 Cloudflare Threat Report (ok. 03.2026) (The Cloudflare Blog)
  4. CISA – AI Data Security: Best Practices… (22.05.2025) (CISA)
  5. MITRE – ATLAS (Adversarial Threat Landscape for AI Systems) (MITRE ATLAS)

Iran-nexus APT „Dust Specter” atakuje urzędników w Iraku nowymi rodzinami malware (SPLITDROP, TWINTASK, TWINTALK, GHOSTFORM)

Wprowadzenie do problemu / definicja luki

Nie mamy tu „jednej CVE”, tylko klasyczny scenariusz APT: ukierunkowany spear-phishing, wiarygodne podszycie się pod instytucję państwową i łańcuch infekcji prowadzący do zdalnego wykonania poleceń (RAT/backdoor). W nowej kampanii badacze Zscaler ThreatLabz przypisują z średnio-wysoką pewnością aktywność klastrowi „Dust Specter” (powiązania z Iranem na bazie TTP, doboru celów i podobieństw w kodzie).

Kluczowy element: atakujący podszywają się pod irackie Ministerstwo Spraw Zagranicznych, a do dystrybucji payloadów wykorzystują również skompromitowaną infrastrukturę powiązaną z irackim rządem.

W skrócie

  • Kampania była obserwowana w styczniu 2026 i celowała w urzędników państwowych w Iraku.
  • Zidentyfikowano dwa łańcuchy infekcji z nowymi, wcześniej nieopisywanymi rodzinami: SPLITDROP, TWINTASK, TWINTALK, GHOSTFORM (wszystko w .NET).
  • C2 obejmuje m.in. losowe ścieżki URI z checksumami, geofencing i weryfikację User-Agent, co utrudnia analizę i ogranicza „szum” od badaczy/sandboxów.
  • W kodzie znaleziono ślady sugerujące wsparcie generatywnej AI przy tworzeniu malware (np. „placeholdery”, nietypowe wstawki/znaki).

Kontekst / historia / powiązania

Zscaler opisuje „Dust Specter” jako klaster działający w paradygmacie znanym z operacji iran-nexus: lekkie, customowe backdoory w .NET, dopasowane do kampanii, plus mocne socjotechniczne przynęty i infrastruktura dobrana pod region/cele.

Dodatkowo w tle pojawia się trend „ClickFix-style” (nakłanianie ofiary do uruchomienia poleceń/PowerShell pod pretekstem dołączenia do spotkania/naprawy problemu). The Hacker News wskazuje, że powiązana domena/infrastruktura była wykorzystywana także wcześniej do przynęt udających np. zaproszenia do spotkań i instruujących uruchomienie skryptu PowerShell.

Analiza techniczna / szczegóły „luki” (łańcucha ataku)

Attack Chain 1: SPLITDROP → TWINTASK + TWINTALK (architektura „split”)

Wejście: zaszyfrowane/hasłowane archiwum RAR (przynęta podszyta pod MSZ), w którym znajduje się 32-bitowy dropper .NET „SPLITDROP” podszyty pod WinRAR.

SPLITDROP rozpakowuje/deployuje elementy do katalogu w ProgramData i uruchamia legalny komponent, by przejść do kolejnego etapu (typowy „living off the land” + zaufany binarny ładunek). W opisie kampanii pojawiają się artefakty ścieżek typu:

  • C:\ProgramData\PolGuid\... (m.in. pliki poleceń i wyników)

TWINTASK (worker) działa jako DLL i jest ładowany metodą DLL sideloading przez legalny proces (w opisie: „vlc.exe” sideloaduje „libvlc.dll”). Moduł cyklicznie odczytuje plik z poleceniami (co 15 sekund) i wykonuje je przez PowerShell, zapisując wyniki do osobnego pliku.

TWINTALK (orchestrator) koordynuje pracę z TWINTASK oraz komunikuje się z C2 (pobieranie poleceń, przesył wyników, transfer plików).

Attack Chain 2: GHOSTFORM (skonsolidowany RAT)

W drugim łańcuchu „GHOSTFORM” scala funkcje wcześniejszych modułów w jeden binarny RAT .NET i wyróżnia się m.in. in-memory PowerShell execution (mniej artefaktów na dysku) oraz technikami opóźniania/ukrywania wykonania (np. niewidoczne okna formularzy + timery).

Ciekawostka operacyjna: część próbek GHOSTFORM miała uruchamiać w przeglądarce link do Google Forms wyglądający jak oficjalna ankieta MSZ (treść po arabsku), co może służyć uwiarygodnieniu scenariusza socjotechnicznego lub jako element „distraction/decoy”.

C2 i utrudnianie analizy

Zscaler podkreśla kilka mechanizmów „kontroli dostępu” po stronie serwera C2:

  • losowe ścieżki URI z dołączonym checksumem (żądania mają wyglądać jak pochodzące z realnej infekcji),
  • geofencing (ograniczenie obsługi do wybranych lokalizacji),
  • weryfikacja User-Agent.

Praktyczne konsekwencje / ryzyko

Dla organizacji rządowych i podmiotów współpracujących (dostawcy, NGO, firmy consultingowe obsługujące administrację) ryzyka są bardzo konkretne:

  • Zdalne wykonanie poleceń i kradzież danych: PowerShell jako „uniwersalny interpreter” ułatwia szybkie dostosowanie działań (rekonesans, eksfiltracja, pobranie kolejnych narzędzi).
  • Trudniejsza detekcja: DLL sideloading i użycie legalnych binarek zmniejsza „podejrzaność” na poziomie EDR, jeśli organizacja nie ma twardych polityk allow-listing.
  • Selektywność kampanii: geofencing i walidacje w C2 sugerują, że atak nie jest masowy – celem są konkretne osoby/role, a infrastruktura jest ograniczana, by nie „wypalić” narzędzi.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań „od razu”, możliwie praktyczna dla SOC/Blue Teamu:

Email i wejście (pre-infection)

  • Wzmocnij ochronę przed spear-phishingiem: izolacja załączników (sandbox), blokady na archiwa hasłowane (RAR/ZIP) lub przynajmniej wymuszenie dodatkowej inspekcji dla „password-protected attachments”.
  • Polityki dla plików zewnętrznych: Mark-of-the-Web, blokada uruchamiania binarek z katalogów użytkownika i z nietypowych lokalizacji.

Endpoint/EDR

  • Włącz/zaostrz reguły dla PowerShell: Script Block Logging, AMSI, blokady dla podejrzanych parent-child (np. media player → PowerShell).
  • Monitoruj i alertuj na schemat: vlc.exe (lub inne legalne binarki) ładujące DLL z własnego katalogu + tworzenie/odczyt plików w C:\ProgramData\... (np. „in.txt/out.txt”).
  • Rozważ AppLocker/WDAC (allow-listing) w krytycznych segmentach – to realnie ogranicza DLL sideloading.

Sieć

  • Poluj na wskaźniki TTP: nietypowe beaconing do świeżych domen, żądania z nietypowymi ścieżkami URI (losowe + checksum), anomalie User-Agent (lub jego „sztywna” wartość).
  • Segmentacja i egress control: ogranicz ruch z hostów użytkowników do Internetu (zwłaszcza niepotrzebne porty/usługi) i wymuszaj proxy z inspekcją.

Threat hunting

  • Przeszukaj flotę pod kątem artefaktów z opisu kampanii (katalogi w ProgramData, pliki poleceń/wyników, podejrzane DLL obok legalnych exe, zadania harmonogramu/Run keys, jeśli wykryte w środowisku).
  • Skorzystaj z IOC/sekcji „Zscaler Coverage” w raporcie ThreatLabz jako punktu startowego do detekcji i blokad.

Różnice / porównania z innymi przypadkami

  • Split vs monolit: Chain 1 rozdziela role (worker/orchestrator) i komunikuje się plikami; Chain 2 (GHOSTFORM) ogranicza artefakty na dysku dzięki in-memory PowerShell – to typowa „ewolucja” w stronę mniejszej wykrywalności.
  • ClickFix jako trend: kampanie, które „uczą” użytkownika uruchomić PowerShell, stają się powtarzalnym motywem – nie tylko w przestępczości, ale i w operacjach ukierunkowanych. W tej sprawie podobieństwo zostało wskazane przez THN/Zscaler.
  • AI w wytwarzaniu malware: zamiast „magicznie nowego” wektora, mamy sygnały, że generatywna AI przyspiesza development (szablony, placeholdery, nietypowe artefakty), co obniża koszt iteracji po stronie atakującego.

Podsumowanie / kluczowe wnioski

Dust Specter to przykład dojrzałej operacji APT: wiarygodne podszycie się pod instytucję, dwa równoległe łańcuchy infekcji, nacisk na PowerShell oraz mechanizmy C2 ograniczające ekspozycję kampanii. Największa lekcja obronna jest prosta: blokowanie/ograniczanie PowerShell + kontrola uruchomień (allow-listing) + polowanie na DLL sideloading dają tu największy zwrot z inwestycji.

Źródła / bibliografia

  • Zscaler ThreatLabz – Dust Specter APT Targets Government Officials in Iraq (02.03.2026) (zscaler.com)
  • Security Affairs – Iran-nexus APT Dust Specter targets Iraq officials with new malware (06.03.2026) (Security Affairs)
  • The Hacker News – Dust Specter Targets Iraqi Officials with New SPLITDROP and GHOSTFORM Malware (05.03.2026) (The Hacker News)
  • SC Media / SC World – Iran targets Iraqi government officials with multiple new malware strains (04.03.2026) (SC Media)

2025 Zero-Days w praktyce: co naprawdę zmienia raport Google GTIG i jak przygotować się na 2026

Wprowadzenie do problemu / definicja luki

Zero-day (0-day) to podatność, która jest aktywnie wykorzystywana “w dziczy” zanim publicznie pojawi się łatka (albo zanim obrońcy zdążą ją szeroko wdrożyć). Google Threat Intelligence Group (GTIG) w swoim przeglądzie podsumowuje, jak wyglądał ekosystem eksploatacji 0-day w całym 2025 roku — i dlaczego dla wielu organizacji największy ciężar ryzyka przesuwa się z “typowych” endpointów na warstwę enterprise (edge, urządzenia sieciowe, appliance, krytyczne aplikacje).

W skrócie

Najważniejsze tezy z raportu GTIG (i dlaczego są istotne operacyjnie):

  • 90 podatności 0-day ujawnionych w 2025 zostało wg GTIG wykorzystanych jako zero-day.
  • Prawie połowa dotyczyła środowisk firmowych: 43 (48%) 0-day w oprogramowaniu i urządzeniach enterprise (wzrost względem 2024).
  • Najczęściej eksploatowaną kategorią były systemy operacyjne (desktop + mobile): 39 przypadków (44%).
  • W mobile widać wzrost: 15 0-day vs 9 rok wcześniej, przy czym w praktyce często są to łańcuchy exploitów (kilka CVE na jeden “cel” ataku).
  • GTIG podkreśla rosnącą rolę Commercial Surveillance Vendors (CSV) — po raz pierwszy (w ich ujęciu) przypisano im więcej 0-day niż “klasycznym” grupom państwowym od cyberwywiadu.
  • Równolegle rośnie tempo “wczesnej” eksploatacji: analiza VulnCheck wskazuje, że 28,96% podatności z list KEV (u nich) miało oznaki wykorzystania w dniu publikacji CVE lub wcześniej.

Kontekst / historia / powiązania

Raport GTIG wpisuje się w trend, który obrońcy widzą od kilku lat: liczba 0-day nie eksploduje liniowo, ale utrzymuje się na podwyższonym “plateau” (GTIG wskazuje wahania w granicach ~60–100 rocznie w ostatnich latach, wyżej niż przed 2021).

Nowość polega na dystrybucji celów i dostępu do exploitów:

  • Enterprise/edge daje atakującym ogromny zwrot: jeden udany exploit w urządzeniu brzegowym lub komponencie sieciowym może oznaczać dostęp do wielu segmentów naraz. GTIG zwraca uwagę, że w 2025 aż ok. połowa enterprise 0-day dotyczyła security & networking (wskazując na typowe klasy błędów jak brak walidacji wejścia i niedomknięte autoryzacje).
  • Proliferacja narzędzi eksploatacji: osobny materiał GTIG o exploicie “Coruna” pokazuje, jak zaawansowany zestaw exploitów potrafi “krążyć” między aktorami (od klienta firmy surveillance, przez operacje wywiadowcze, po kampanie masowe), co obniża barierę wejścia.

Analiza techniczna / szczegóły luki

GTIG nie opisuje “jednego CVE”, tylko krajobraz. Kilka wątków technicznych z największym znaczeniem dla SOC/Vuln Mgmt:

1. Enterprise: dlaczego “security & networking” tak często pęka?

GTIG wskazuje, że w produktach enterprise (szczególnie security/networking) powtarzają się fundamentalne problemy inżynieryjne:

  • braki walidacji danych wejściowych,
  • niepełne sprawdzanie uprawnień / błędna autoryzacja,
  • podatności w miejscach, które naturalnie mają wysokie uprawnienia i są wystawione na ruch zewnętrzny.

Efekt: nawet “pojedynczy” błąd w takim komponencie bywa dla atakującego równoważny ze zdalnym przełamaniem perymetru.

2. End-user: OS i mobile jako stały silnik 0-day

Wzrost udziału OS (44%) oraz liczby mobile 0-day (15) jest ważny z dwóch powodów:

  • ataki na OS często wspierają EoP / persistence / credential access,
  • w mobile rośnie znaczenie łańcuchów exploitów (kilka podatności po to, by ominąć kolejne warstwy mitigacji).

3. Komercyjny rynek exploitów (CSV) i “druga ręka”

Jeśli exploit-kit potrafi przejść z operacji “premium” do szerszego użycia, organizacje muszą zakładać krótszy czas od “capability discovery” do “capability commodity”. Przykład Coruna pokazuje właśnie taki wektor: te same techniki mogą zostać szybko przejęte, zmodyfikowane i użyte przez innych aktorów.

Praktyczne konsekwencje / ryzyko

Co z tego wynika dla firm (bez względu na branżę):

  1. Patch management musi wyjść poza endpointy. Skoro ~48% 0-day dotyka enterprise, krytyczne stają się cykle aktualizacji: urządzeń brzegowych, appliance, VPN, systemów sieciowych, middleware i kluczowych aplikacji.
  2. Okno reakcji się kurczy. Jeżeli znacząca część podatności jest eksploatowana bardzo wcześnie (czasem przed formalnym “dniem CVE”), strategia “łatamy w kwartale” przestaje mieć sens dla klas high-risk.
  3. Ryzyko nie jest już tylko “państwowe”. GTIG wskazuje rosnącą rolę CSV i zauważalną aktywność grup finansowych (w raporcie: 9 0-day przypisanych do motywacji finansowej). To zwiększa prawdopodobieństwo, że 0-day dotknie też cele “nie-geopolityczne”.

Rekomendacje operacyjne / co zrobić teraz

Poniżej praktyczny zestaw działań, które dobrze mapują się na wnioski GTIG:

1. Priorytetyzacja “exploited-in-the-wild” jako osobna ścieżka

  • Wdróż regułę: KEV / exploited-in-the-wild → tryb pilny (SLA w dniach, nie tygodniach).
  • Automatyzuj zasilanie procesu danymi z oficjalnych feedów (np. repo z danymi KEV na GitHub, które CISA utrzymuje jako mirror).

2. Twarde zabezpieczenie warstwy edge i urządzeń “security & networking”

  • Inwentaryzacja + ekspozycja: co jest publicznie wystawione, na jakich wersjach, z jakim supportem.
  • Segmentacja i ograniczenie zarządzania: management plane tylko z sieci admin/PAW, MFA, allowlisty.
  • Telemetria: logi z urządzeń brzegowych do SIEM, korelacja z IOC/TTP.

3. Mobile i przeglądarki: polityki, które redukują skutki łańcuchów exploitów

  • MDM/MAM, wymuszanie aktualizacji OS, blokady dla starych wersji.
  • Dla profili wysokiego ryzyka: rozważ tryby “hardening” (np. restrykcyjne konfiguracje przeglądarki, ograniczenia instalacji profili, minimalizacja uprawnień aplikacji).

4. Przygotowanie na przyspieszenie “cyklu exploit”

GTIG prognozuje, że AI przyspieszy rekonesans, discovery i development exploitów, co dołoży presji obrońcom w detekcji i reakcji. W praktyce oznacza to:

  • większy nacisk na monitorowanie anomalii i szybkie containment,
  • “shift-left” w SDLC (SAST/DAST, fuzzing, testy regresji bezpieczeństwa),
  • ćwiczenia IR pod scenariusze: 0-day w edge + lateral movement.

Różnice / porównania z innymi przypadkami

  • 2024 vs 2025: GTIG wskazuje wzrost z 78 do 90 0-day i dalszy wzrost udziału enterprise (z 46% do 48%).
  • Endpointy vs enterprise: mimo że OS nadal dominuje jako kategoria (44%), proporcja enterprise utrzymuje się wysoko i jest opisana jako zmiana strukturalna, a nie “odchył”.
  • Proliferacja capability: przykład Coruna dobrze ilustruje, że “najdroższe” techniki nie muszą zostać niszowe na długo.

Podsumowanie / kluczowe wnioski

Raport GTIG za 2025 rok sprowadza się do jednej, niewygodnej prawdy: organizacje nie przegrywają już dlatego, że nie patchują endpointów — tylko dlatego, że nie potrafią szybko i konsekwentnie zabezpieczać enterprise/edge.

Jeśli masz zrobić trzy rzeczy po tej lekturze:

  1. ustaw osobny, ekspresowy tor dla “exploited-in-the-wild”,
  2. potraktuj urządzenia brzegowe i security/networking jak Tier-0,
  3. skróć cykl reakcji (telemetria + IR), bo okno na “bezpieczne łatki” się zamyka.

Źródła / bibliografia

  1. Google Cloud Blog (GTIG) — Look What You Made Us Patch: 2025 Zero-Days in Review (Google Cloud)
  2. SecurityWeek — omówienie danych z raportu GTIG (liczby, trendy) (SecurityWeek)
  3. Google Cloud Blog (GTIG) — Coruna: The Mysterious Journey of a Powerful iOS Exploit Kit (Google Cloud)
  4. VulnCheck — State of Exploitation 2026 (wnioski o tempie eksploatacji/KEV) (VulnCheck)
  5. CISA (mirror danych) — repozytorium cisagov/kev-data (GitHub)

Bing AI promował fałszywe repozytorium OpenClaw na GitHubie. Efekt: infostealery i proxy GhostSocks na stacjach użytkowników

Wprowadzenie do problemu / definicja luki

To nie jest klasyczna „luka” w sensie CVE. To łańcuch nadużyć z pogranicza SEO/brand-impersonation + zaufania do GitHuba + „AI answer engine”. W praktyce: użytkownik wpisuje w Bing zapytanie w stylu „OpenClaw Windows”, a mechanizm odpowiedzi AI potrafi polecić fałszywe repozytorium na GitHubie z instrukcjami instalacji prowadzącymi do uruchomienia malware.

W skrócie

  • Kampania dotyczyła fałszywych „installerów” OpenClaw hostowanych na GitHubie i polecanych w wynikach Bing (AI).
  • Okno aktywności zidentyfikowane przez Huntress: 2–10 lutego 2026.
  • Dla Windows: dostarczano infostealery (m.in. Vidar) oraz GhostSocks (backconnect proxy); część loaderów była pisana w Rust i wykonywała payloady w pamięci.
  • Dla macOS: instrukcje prowadziły do pobrania/uruchomienia komponentów powiązanych z Atomic macOS Stealer (AMOS).

Kontekst / historia / powiązania

OpenClaw to popularny, open-source’owy „agent”/asystent AI, który z definicji działa lokalnie i ma dostęp do plików oraz integracji (poczta, komunikatory, usługi online). To sprawia, że jest atrakcyjnym celem: jedna infekcja infostealerem = dostęp do haseł + tokenów + potencjalnie sekretów w konfiguracjach narzędzi AI.

W ostatnich tygodniach temat bezpieczeństwa ekosystemu OpenClaw przewijał się również w kontekście „skills”/rozszerzeń i ryzyka dowożonego przez instrukcje uruchamiania poleceń w shellu.

Analiza techniczna / szczegóły kampanii

1) Socjotechnika + wiarygodność GitHuba + „autorytet” AI w wyszukiwarce

Huntress opisał przypadek, w którym użytkownik trafił na repo podszywające się pod instalator Windows, a Bing AI wskazał je jako „top” sugestię dla frazy „OpenClaw Windows”.

Repo wyglądało wiarygodnie m.in. dlatego, że:

  • było podpięte pod organizację w stylu „openclaw-installer” (wrażenie „oficjalności”),
  • zawartość kodu źródłowego częściowo kopiowała legalny projekt (moltworker od Cloudflare), co podbija „legit look” i może mylić zarówno ludzi, jak i systemy automatyczne.

2) Windows: 7z z „OpenClaw_x64.exe”, loadery w Rust, Vidar i GhostSocks

Z perspektywy Windows wektorem był plik wykonywalny (m.in. w archiwum 7-Zip), który prowadził do uruchomienia kilku komponentów:

  • Rust-based loadery, które uruchamiały infostealery w pamięci (utrudnia analizę i detekcję opartą o artefakty na dysku),
  • Vidar stealer – według opisu potrafił pozyskiwać dane C2 m.in. poprzez odwołania do profili na Telegramie i Steam,
  • GhostSocks backconnect proxy – malware zamieniające maszynę ofiary w węzeł proxy.

GhostSocks jest tutaj szczególnie groźny operacyjnie: jeśli infostealer wyciągnie ciasteczka/tokenty/hasła, to operator może logować się „z IP ofiary”, obchodząc antyfraud oparte o geolokację, reputację IP czy „impossible travel”. Huntress wprost wskazuje tę wartość dla atakującego.

Dodatkowo Huntress opisał użycie Stealth Packer (packer/injector), który ma realizować m.in. wstrzykiwanie do pamięci, modyfikacje reguł zapory i artefakty w harmonogramie zadań oraz proste anty-VM (np. warunek ruchu myszy).

3) macOS: „bash one-liner” i AMOS

W wariancie dla macOS repo instruowało użytkownika, by wkleił w Terminalu jednowierszową komendę bash, która pobierała zasoby z innej organizacji/repo. W analizie wskazano, że ładunek odpowiadał schematowi shell script + Mach-O, a finalnie mapował się na Atomic macOS Stealer (AMOS).

Praktyczne konsekwencje / ryzyko

  1. Kradzież danych uwierzytelniających i tokenów
    Infostealery klasy Vidar/AMOS typowo polują na dane przeglądarek, menedżerów haseł, portfeli krypto, komunikatorów itd. W kampanii dodatkowo dochodzi ryzyko przejęcia materiałów do logowania, które potem można monetyzować lub użyć do dalszych włamań.
  2. Bypass antyfraud/MFA przez proxy „z hosta ofiary”
    GhostSocks buduje warstwę „wiarygodnego ruchu” dla napastnika, co w praktyce zwiększa skuteczność przejęć kont i omijania mechanizmów ryzyka.
  3. Eksfiltracja sekretów z narzędzi AI/agentów
    Huntress podkreśla, że nawet przy legalnej instalacji OpenClaw konfiguracje mogą zawierać wrażliwe dane (API keys, tokeny, hasła). Infostealer na zainfekowanej stacji może je po prostu zebrać.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i zespołów IT (szybkie „must do”)

  • Bookmarkuj oficjalne źródła (repo/strony projektu) i instaluj wyłącznie z nich — nie polegaj na wyszukiwaniu „za każdym razem”.
  • Nie uruchamiaj poleceń typu curl|bash / „wklej do Terminala” z README, jeśli nie potrafisz samodzielnie zweryfikować, co pobierasz i wykonujesz (hash, podpis, źródło, historia repo).
  • Weryfikuj reputację repozytorium: data utworzenia konta/org, historia commitów, spójność kodu źródłowego z release’ami, podpisy, powiązanie z oficjalnym projektem.

Detekcja i reakcja (jeśli podejrzewasz kompromitację)

  • Na Windows sprawdź: nietypowe zadania Harmonogramu, reguły firewalla, procesy o „installerowych” nazwach, podejrzane połączenia wychodzące; uruchom pełny skan EDR/Defender. (Kampania była wykrywalna i w analizowanym przypadku pliki były kwarantannowane przez rozwiązania Microsoft).
  • Rotuj hasła i tokeny (zwłaszcza przeglądarkowe, API keys, tokeny sesji) oraz włącz/utwardź MFA tam, gdzie to możliwe — przy założeniu, że infostealer mógł pozyskać ciasteczka/tokenty.
  • Jeśli używasz OpenClaw/agentów AI: traktuj pliki konfiguracyjne jak „sekrety produkcyjne” (min. uprawnienia, separacja kont, trzymanie kluczy w menedżerze sekretów, ograniczenie dostępu na stacji roboczej).

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

  • Ten incydent pokazuje zmianę taktyki: nie trzeba „hakować” modelu ani prowadzić skomplikowanego prompt injection. Wystarczy odpowiednio „opakować” fałszywe repo na zaufanej platformie i sprawić, by system odpowiedzi AI uznał je za relewantne. Huntress zestawia to z wcześniejszymi kampaniami wykorzystującymi mechanizmy AI/udostępniania treści do socjotechniki, ale tu kluczowe było samo „zaufane hostowanie” na GitHubie + widoczność w Bing AI.
  • Równolegle ekosystem OpenClaw bywa nadużywany także przez złośliwe „skills”/rozszerzenia, co wzmacnia tezę, że agentic AI + lokalne uprawnienia + społecznościowy ekosystem dystrybucji to mieszanka wymagająca twardych kontroli bezpieczeństwa.

Podsumowanie / kluczowe wnioski

  • „AI w wyszukiwarce” potrafi zwiększyć skuteczność klasycznych podszyć, bo nadaje im pozór autorytetu.
  • GitHub jako hosting podnosi wiarygodność w oczach użytkowników, a kopiowanie legalnego kodu wzmacnia kamuflaż.
  • Najgroźniejszy miks w tej kampanii to infostealer + proxy (GhostSocks): kradzież materiału do logowania i natychmiastowa możliwość „wejścia jako ofiara” z jej własnego hosta.
  • Jeśli instalujesz popularne narzędzia (zwłaszcza agentów AI): instalacja = procedura bezpieczeństwa, nie „kliknięcie z wyszukiwarki”.

Źródła / bibliografia

  1. BleepingComputer – opis incydentu i elementów ładunku (Windows/macOS, Vidar, GhostSocks). (BleepingComputer)
  2. Huntress – analiza kampanii (okno 2–10 lutego 2026, Stealth Packer, GhostSocks, AMOS, mechanika Bing AI). (Huntress)
  3. The Register – podsumowanie roli Bing AI i GitHuba w dystrybucji fałszywych installerów. (theregister.com)
  4. Trend Micro – kontekst zagrożeń AMOS/kradzieży danych na macOS (tło rodzinne). (www.trendmicro.com)
  5. The Verge – szerszy kontekst ryzyk w ekosystemie OpenClaw (skills/rozszerzenia). (The Verge)

Złośliwe rozszerzenia „AI assistant” kradną historię rozmów z LLM: jak działa kampania i jak się bronić

Wprowadzenie do problemu / definicja luki

Rynek narzędzi „AI sidebar / AI assistant” w przeglądarce rośnie błyskawicznie, a wraz z nim rośnie pokusa nadużyć. Najnowsze ustalenia Microsoft Defender pokazują kampanię złośliwych rozszerzeń Chromium (Chrome/Edge), które podszywają się pod legalne asystenty AI i masowo zbierają treści rozmów z LLM oraz historię przeglądania. Kluczowe ryzyko nie polega tu na „efektownym exploicie”, tylko na tym, że użytkownicy sami instalują dodatek, często w środowisku firmowym, a potem wklejają do okna czatu wrażliwe dane (kod, procedury, koncepcje produktowe, dane klientów).

W skrócie

  • Microsoft opisuje kampanię z ~900 tys. instalacji oraz sygnały aktywności w ponad 20 tys. tenantów enterprise.
  • Rozszerzenia zbierały pełne URL-e (w tym wewnętrzne) oraz fragmenty rozmów z platform takich jak ChatGPT i DeepSeek.
  • Dane były cyklicznie wysyłane metodą HTTPS POST do domen m.in. deepaichats[.]com, chatsaigpt[.]com (oraz wskazywanych wildcardów).
  • W kampanii pojawiają się konkretne ID rozszerzeń wykorzystywane w huntingu i detekcji.

Kontekst / historia / powiązania

To nie jest odosobniony przypadek. Już pod koniec 2025 r. OX Security opisało niemal identyczny motyw: fałszywe rozszerzenia podszywające się pod legalny produkt (AITOPIA), które eksportowały rozmowy z ChatGPT/DeepSeek oraz listę odwiedzanych kart, a jedna z próbek miała nawet wyróżnienie w sklepie.

Równolegle w 2026 r. badacze (m.in. opisywani przez Malwarebytes) zwracali uwagę na inną klasę zagrożeń: rozszerzenia kradnące tokeny sesji ChatGPT, co umożliwia przejęcie konta i dostęp do historii/metadanych.

W tle rośnie jeszcze jedno zjawisko: „agentic” funkcje w przeglądarkach i asystentach webowych rozszerzają powierzchnię ataku (np. wątki o eskalacji uprawnień w komponentach asystenta i nadużyciach przez rozszerzenia).

Analiza techniczna / szczegóły

1. Łańcuch ataku (wg Microsoft)

Microsoft opisuje „klasyczny” łańcuch dla złośliwego rozszerzenia, gdzie największą rolę gra socjotechnika i architektura uprawnień Chromium:

  • Recon: wybór popularnej niszy „AI assistant”, analiza legalnych dodatków (np. AITOPIA) i skopiowanie brandingu oraz zachowań instalacyjnych.
  • Delivery: dystrybucja przez Chrome Web Store, z naturalnym „przenikaniem” także do Edge (obsługa dodatków Chrome).
  • Exploitation (w sensie operacyjnym): po instalacji dodatek wykorzystuje model uprawnień rozszerzeń i zaczyna zbierać dane bez kolejnych kliknięć.
  • C2/Exfil: okresowe wysyłki HTTPS POST na infrastrukturę atakujących (deepaichats[.]com, chatsaigpt[.]com itd.).

2. Co dokładnie było zbierane

Według Microsoft złośliwe rozszerzenie:

  • logowało niemal wszystkie odwiedzane URL-e (w tym zasoby intranetowe),
  • przechwytywało wycinki wiadomości czatu (prompty i odpowiedzi) z narzędzi LLM,
  • zapisywało dane lokalnie jako Base64-encoded JSON, a potem wysyłało je na zewnątrz,
  • dołączało m.in. kontekst nawigacji, nazwy modeli, oraz trwały UUID (identyfikator sesji/instalacji).

3. „Zgoda” jako mechanizm kamuflażu

Ciekawy element opisu Microsoft to mechanika „konsentu”: użytkownik mógł początkowo wyłączyć zbieranie danych, ale aktualizacje miały automatycznie przywracać telemetrię (re-enable), co w praktyce tworzyło trwały kanał wycieku przy minimalnej widoczności dla ofiary.

4. Twarde artefakty: domeny i identyfikatory

Microsoft podaje znane endpointy/domeny do monitoringu oraz ID rozszerzeń używane w przykładowych zapytaniach huntingowych:

  • Domeny/C2 do obserwacji: chatsaigpt.com, deepaichats.com, chataigpt.pro, chatgptsidebar.pro (oraz wildcards).
  • Przykładowe ID: fnmihdojmnkclgjpcoonokmkhjpjechg, inhcgfpbfdjbjogdfjbclgolkmhnooop.

Praktyczne konsekwencje / ryzyko

Dla organizacji to jest przede wszystkim problem DLP i tajemnicy przedsiębiorstwa:

  • Wycieki kodu i IP: prompty często zawierają fragmenty repo, logi, konfiguracje, architekturę.
  • Mapowanie środowiska: pełne URL-e (w tym wewnętrzne) ujawniają nazwy systemów, ścieżki aplikacji, czasem identyfikatory zasobów lub tenantów.
  • Ryzyko zgodności: jeśli w promptach/odpowiedziach lądują dane osobowe lub kontraktowe, organizacja może „nieświadomie” uruchomić incydent naruszenia.
  • Trwałość: rozszerzenie „żyje” tak długo, jak przeglądarka i profil użytkownika — bez klasycznych wskaźników infekcji endpointu.

Rekomendacje operacyjne / co zrobić teraz

1. Szybkie działania (0–24h)

  1. Audyt rozszerzeń w przeglądarkach firmowych (Chrome/Edge) + identyfikacja dodatków AI/sidebar. Microsoft rekomenduje użycie funkcji oceny rozszerzeń w Defender VM.
  2. Blokada ruchu do wskazanych domen (proxy/SWG/DNS/EDR Network Protection) i przegląd logów POST/HTTPS.
  3. Weryfikacja instalacji po ID: polowanie po ExtensionId i ścieżkach katalogów profilu przeglądarki (Windows).
  4. Komunikat do użytkowników: natychmiastowe usunięcie niezweryfikowanych „AI assistant” + krótkie zasady użycia LLM (czego nie wklejać do promptów).

2. Detekcja i hunting (praktycznie)

Microsoft publikuje gotowe przykłady zapytań (Microsoft Defender XDR), m.in.:

  • wykrywanie uruchomień przeglądarki z parametrami zawierającymi znane ID,
  • wykrywanie połączeń do domen kampanii,
  • enumeracja instalacji w tabeli DeviceTvmBrowserExtensions,
  • wykrywanie artefaktów na dysku w folderach profilu Chrome/Edge.

Jeśli nie korzystasz z Defender XDR, przełóż to 1:1 na:

  • reguły w SIEM (DNS/Proxy/Firewall) na domeny,
  • IOC w EDR dla ścieżek katalogów rozszerzeń,
  • polityki Browser Management (allowlist/denylist rozszerzeń).

3. Kontrole długoterminowe (policy + technologia)

  • Allowlist rozszerzeń (preferowane) zamiast „każdy może instalować wszystko”.
  • Microsoft Defender SmartScreen + Network Protection (Microsoft wskazuje je jako warstwę blokowania).
  • Purview / kontrola przepływu danych dla aplikacji GenAI: w praktyce chodzi o to, by prompt i odpowiedź były traktowane jak kanał danych (klasyfikacja, DLP, zasady).
  • Zasady użycia AI: minimalny standard to „prompt hygiene”, etykietowanie danych, zakaz wklejania sekretów i fragmentów kluczy/tokenów.

Różnice / porównania z innymi przypadkami

Warto rozróżnić dwa popularne modele ataku na „AI w przeglądarce”:

  1. Telemetria/Podsłuch (ten przypadek)
  • celem jest ciągłe zbieranie: URL-e + treści czatów, często „po cichu”, długoterminowo, z UUID.
  1. Kradzież tokenów sesji / przejęcie konta
  • rozszerzenie kradnie token uwierzytelnienia (np. do ChatGPT), co daje możliwość przejęcia tożsamości i wglądu w historię konta. Takie kampanie opisywano m.in. w kontekście zestawu złośliwych dodatków dla Chrome/Edge.

Oba scenariusze kończą się podobnie (wyciek treści), ale różnią się tym, gdzie powstaje szkoda: lokalnie w przeglądarce (podsłuch) vs „po stronie usługi/konta” (token).

Podsumowanie / kluczowe wnioski

  • „AI assistant” w formie rozszerzenia to dziś jeden z najłatwiejszych kanałów wycieku danych: wystarczy instalacja i szerokie uprawnienia.
  • Skala jest realna: Microsoft mówi o ~900 tys. instalacji i aktywności w >20 tys. tenantów, co wskazuje na istotny wymiar enterprise.
  • Najlepsza obrona to połączenie allowlisty rozszerzeń, monitoringu domen/C2, i zasad użycia LLM (prompt hygiene + DLP).

Źródła / bibliografia