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

Tag: AI

Amazon ostrzega: „AI-wspomagany” atak przejął ponad 600 zapór FortiGate w 5 tygodni – bez użycia 0-day

Wprowadzenie do problemu / definicja luki

Amazon Threat Intelligence opisał kampanię, w której rosyjskojęzyczny aktor (najpewniej finansowy, a nie APT) uzyskał dostęp do ponad 600 urządzeń Fortinet FortiGate w 55 krajach w ciągu ok. pięciu tygodni. Kluczowe: nie wykorzystywano podatności FortiOS/0-day – powodzenie zapewniły wystawione do internetu interfejsy zarządzania oraz słabe hasła bez MFA, a generatywna AI miała przyspieszać i automatyzować kolejne kroki operacji.

W skrócie

  • Okres aktywności: 11 stycznia – 18 lutego 2026.
  • Skala: 600+ urządzeń, 55 krajów.
  • Wejście: skanowanie i ataki na wystawione porty zarządzania oraz brute-force na popularnych hasłach, bez eksploita.
  • Po przejęciu: wyciągnięcie konfiguracji (m.in. dane SSL-VPN, konta admin, polityki), rozpoznanie i pivot w sieci ofiary; wskazania, że to może przygotowywać grunt pod ransomware.
  • Rola AI: użycie komercyjnych narzędzi GenAI do planowania, generowania poleceń/skryptów i skalowania działań mimo ograniczonych umiejętności aktora.

Kontekst / historia / powiązania

To kolejny przykład trendu „AI jako akcelerator”: AI nie musi dawać atakującym nowych, magicznych technik – wystarczy, że podnosi tempo i automatyzuje żmudne elementy (rozpoznanie, generowanie komend, modyfikacje skryptów, wariantowanie działań). Google GTIG w swoich raportach również opisuje coraz powszechniejsze użycie AI przez różne klasy aktorów w całym cyklu ataku (research, socjotechnika, malware/tooling).

W praktyce ta kampania uderza w najbardziej „przyziemny” problem: higiena dostępu do urządzeń brzegowych. Jeżeli panel administracyjny jest dostępny z internetu, a do tego nie ma MFA i są słabe hasła, to organizacja sama redukuje koszt ataku do poziomu „sprytnej automatyzacji”.

Analiza techniczna / szczegóły kampanii

Na bazie opisu Amazona i relacji branżowych można odtworzyć typowy łańcuch działań:

(1) Odkrywanie celów (scanning)

  • Aktor miał skanować internet pod kątem FortiGate/GUI management wystawionego na typowych portach 443, 8443, 10443, 4443.

(2) Uzyskanie dostępu (initial access)

  • Zamiast 0-day: brute-force / password spraying na powszechnych hasłach oraz kontach chronionych wyłącznie hasłem (single-factor).

(3) Eksfiltracja konfiguracji i danych dostępowych

  • Po zalogowaniu napastnik miał pobierać konfigurację, która zwykle zawiera m.in.:
    • dane użytkowników SSL-VPN (w tym hasła możliwe do odzyskania/zrekonstruowania w zależności od konfiguracji),
    • poświadczenia administracyjne,
    • reguły firewall/NAT, architekturę sieci,
    • konfiguracje IPsec VPN, routing/topologię.

(4) Rozpoznanie i pivot w sieci

  • Amazon wskazuje, że po uzyskaniu dostępu przez VPN aktor wdrażał własne narzędzia rozpoznawcze (wspominane są warianty w Go i Pythonie) i próbował poruszać się po sieci.

(5) „AI w pętli” (gdzie realnie pomaga GenAI)

  • Raport sugeruje, że AI była używana jako multiplikator produktywności: generowanie i poprawianie komend, tworzenie/ulepszanie prostych narzędzi, przyspieszenie planowania kolejnych kroków oraz automatyzacja działań na większej liczbie ofiar.

Praktyczne konsekwencje / ryzyko

Przejęcie FortiGate to nie tylko „kolejne urządzenie”. To często mapa drogowa do całej sieci:

  • Ujawnienie topologii i polityk: atakujący widzi, które segmenty istnieją, jak jest realizowany dostęp, jakie są wyjątki w regułach.
  • Poświadczenia VPN/administracyjne: ryzyko przejęcia sesji, kolejnych urządzeń, a także kont uprzywilejowanych (w zależności od tego, co zapisano w konfiguracji).
  • Przygotowanie do ransomware: Bloomberg wskazuje, że uzyskany dostęp był wykorzystywany do ruchu w głąb sieci w sposób wyglądający jak staging pod ataki ransomware/wymuszenia.
  • Skala i tempo: 600 urządzeń w 5 tygodni pokazuje, że przy słabej higienie uwierzytelniania granica między „średniakiem” a masową kampanią mocno się zaciera.

Rekomendacje operacyjne / co zrobić teraz

Poniżej checklista „minimum”, która adresuje dokładnie ten scenariusz (bez czekania na patche, bo tu nie chodzi o exploit):

Natychmiast (0–24h)

  • Wyłącz zarządzanie z WAN (admin GUI/SSH) albo ogranicz je do allowlist IP (np. tylko VPN / bastion / ZTNA).
  • Wymuś MFA na wszystkich kontach administracyjnych i wszędzie, gdzie to możliwe (również dla zdalnego dostępu).
  • Zrób audit kont: usuń nieużywane, zmień domyślne nazwy/hasła, wprowadź polityki długości i złożoności oraz blokady po wielu próbach.
  • Sprawdź, czy interfejsy zarządzania nie są wystawione na portach typowych dla GUI (w tym 8443/10443/4443).

Krótki termin (1–7 dni)

  • Rotuj poświadczenia (admin, VPN, klucze PSK/IPsec, konta serwisowe) – zakładaj kompromitację, jeśli panel był publicznie dostępny bez MFA.
  • Przejrzyj logi (FortiGate + upstream SIEM): nietypowe logowania admin/VPN, skoki geolokacji, próby wielu haseł, nowe konta, zmiany polityk.
  • Wdróż monitoring ekspozycji (external attack surface management) – urządzenia brzegowe potrafią „wypłynąć” przez zmiany w NAT/ISP.

Średni termin (1–4 tygodnie)

  • Segmentuj zarządzanie: osobny VRF/VLAN, dostęp tylko przez VPN z MFA, PAM dla kont uprzywilejowanych.
  • Wymuś standard „no public management” jako kontrolę bazową, z testami zgodności.

Różnice / porównania z innymi przypadkami

  • Klasyczny schemat FortiGate w mediach: „0-day w FortiOS → masowa eksploatacja”.
  • Ten przypadek: „brak eksploita → sukces przez ekspozycję panelu + słabe hasła + brak MFA”, a AI zwiększa przepustowość działań.
    Wniosek: nawet jeśli organizacja świetnie patchuje, ale zostawia zarządzanie na WAN bez MFA, to nadal jest w strefie wysokiego ryzyka.

Podsumowanie / kluczowe wnioski

  • Kampania z 2026 r. pokazuje, że AI nie musi tworzyć „nowych” technik, żeby realnie podnieść skuteczność ataku – wystarczy, że skaluje wykorzystanie podstawowych błędów konfiguracyjnych.
  • Największą dźwignią obrony jest „nudna baza”: brak zarządzania z internetu, MFA, higiena haseł, monitoring logowań.
  • Jeżeli Twoje FortiGate miało publiczny panel administracyjny bez MFA w okresie 11.01–18.02.2026, potraktuj to jako sygnał do pilnego przeglądu ekspozycji i rotacji poświadczeń.

Źródła / bibliografia

  1. AWS Security Blog (Amazon Threat Intelligence), CJ Moses – opis kampanii i wnioski techniczne. (Amazon Web Services, Inc.)
  2. BleepingComputer – szczegóły dot. wektora wejścia i danych z konfiguracji. (BleepingComputer)
  3. Bloomberg – kontekst skali i interpretacja możliwego „stagingu” pod ransomware. (Bloomberg.com)
  4. Google Cloud Threat Intelligence (GTIG) – raport/aktualizacje o nadużyciach AI przez aktorów. (Google Cloud)
  5. Google Threat Intelligence – „Advances in Threat Actor Usage of AI Tools” (aktualizacja i tło trendu). (Google Cloud)

CVE-2026-21513 w MSHTML: jak APT28 omija MotW i doprowadza do wykonania plików (analiza Akamai)

Wprowadzenie do problemu / definicja luki

CVE-2026-21513 to podatność typu Security Feature Bypass w MSHTML (Trident) – historycznym silniku renderowania HTML kojarzonym z Internet Explorerem, który nadal bywa wykorzystywany przez różne komponenty Windows. Luka została załatana w ramach Patch Tuesday z lutego 2026, a co ważniejsze: Microsoft i społeczność bezpieczeństwa potwierdzili aktywną eksploatację “in the wild”.

W praktyce mówimy o scenariuszu, w którym atakujący doprowadza do ominięcia mechanizmów ochronnych (m.in. zaufania/ostrzeżeń związanych z uruchamianiem zasobów), a następnie do uruchomienia wskazanych zasobów/plików poza oczekiwanym kontekstem bezpieczeństwa.

W skrócie

  • Komponent: MSHTML / IEFRAME (m.in. ieframe.dll)
  • Typ: protection mechanism failure / security feature bypass (CWE-693)
  • CVSS (CNA Microsoft): 8.8 (HIGH), wektor: AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
  • Wymagana interakcja użytkownika: tak (np. otwarcie pliku HTML lub skrótu .lnk)
  • Status: w CISA KEV + termin działań (KEV “due date”) 2026-03-03
  • Atrybucja kampanii: Akamai wiąże obserwowaną eksploatację z APT28

Kontekst / historia / powiązania

Choć Edge nie używa MSHTML jako silnika przeglądarki, legacy komponenty Windows wciąż mogą opierać się o IE/Trident. To otwiera furtkę do “powrotu” starych klas ataków – szczególnie tam, gdzie istnieją osadzone kontrolki, WebBrowser control lub inne elementy, które potrafią parsować HTML przez MSHTML.

W lutym 2026 tematy “security feature bypass” w Windows pojawiały się grupowo (np. analogiczne klasy problemów w Shell/Word), co sugeruje szerszy trend: atakujący konsekwentnie szukają sposobów, by zwiększyć niezawodność initial access poprzez obchodzenie ostrzeżeń i mechanizmów zaufania.

Analiza techniczna / szczegóły luki

Root cause (wg Akamai / PatchDiff-AI)

Akamai opisuje analizę “inside the fix” wykonaną z użyciem PatchDiff-AI, która wiąże CVE-2026-21513 z konkretną ścieżką kodu w ieframe.dll (Internet Explorer frame). Kluczowy problem: niewystarczająca walidacja docelowego URL podczas obsługi nawigacji hyperlinków, co pozwala doprowadzić sterowane dane do ścieżki wywołującej ShellExecuteExW. Efekt: wykonanie zasobu lokalnego lub zdalnego poza zamierzonym kontekstem bezpieczeństwa przeglądarki.

Akamai wskazuje też nazwę funkcji widoczną w call stack / analizie różnic: _AttemptShellExecuteForHlinkNavigate.

Jak wygląda łańcuch eksploatacji (kampania “in the wild”)

Z perspektywy kampanii przypisanej do APT28, Akamai opisuje próbkę wykorzystującą złośliwy skrót Windows (.lnk), w którym osadzono HTML (doklejony zaraz po standardowej strukturze LNK). Taki plik ma inicjować komunikację z infrastrukturą atakującego (wskazany domenowy IOC), a sama technika eksploatacji używa m.in. zagnieżdżonych iframe’ów i wielu kontekstów DOM do manipulacji granicami zaufania.

Istotny szczegół: mechanika ma pozwalać na obejście Mark of the Web (MotW) oraz Internet Explorer Enhanced Security Configuration (IE ESC), czyli elementów, które normalnie utrudniają automatyczne/nieświadome uruchamianie treści i ostrzegają użytkownika.

Co zmienia poprawka

Według Akamai, fix polega na ostrzejszej walidacji protokołów w nawigacji hyperlinków tak, aby wspierane protokoły (np. file://, http://, https://) były obsługiwane w kontekście przeglądarki, zamiast trafiać “wprost” do ShellExecuteExW.

Praktyczne konsekwencje / ryzyko

  • Ryzyko operacyjne: to nie jest “tylko bypass ostrzeżenia”. W realnym łańcuchu ataku omijanie MotW/ostrzeżeń znacząco podnosi skuteczność infekcji (większa szansa, że payload uruchomi się bez podejrzanych promptów).
  • Powierzchnia ataku: Akamai podkreśla, że podatna ścieżka może zostać wywołana przez dowolny komponent osadzający MSHTML, więc wektory dostarczenia mogą wykraczać poza .lnk (np. inne scenariusze z osadzonym renderowaniem HTML).
  • Priorytet patchowania: obecność w CISA KEV to silny sygnał, że podatność jest praktycznie wykorzystywana i wymaga szybkich działań (KEV due date 2026-03-03).

Rekomendacje operacyjne / co zrobić teraz

  1. Pilne wdrożenie poprawek z lutego 2026
    To podstawowa i docelowa mitigacja. Tenable i Akamai jednoznacznie wskazują, że aktualizacje z February 2026 Security Updates / Patch Tuesday zamykają podatność.
  2. Hunting/Detekcja pod kątem IOC (z raportu Akamai)
    Akamai publikuje konkretne wskaźniki, które warto wrzucić do SIEM/EDR oraz kontroli DNS/Proxy:
    • SHA-256 próbki LNK: aefd15e3c395edd16ede7685c6e97ca0350a702ee7c8585274b457166e86b1fa
    • Domena: wellnesscaremed[.]com
    • (mapowanie TTP) MITRE ATT&CK: T1204.001, T1566.001
  3. Hardening “initial access” (jeśli patching nie jest natychmiastowy)
    • ogranicz uruchamianie/otwieranie .lnk i plików HTML z niezaufanych źródeł (polityki, ASR/EDR, ograniczenia w mail gateway)
    • wzmocnij kontrolę nad treściami pobieranymi z Internetu oraz strefami (gdzie możliwe) – bo celem ataku jest obejście ostrzeżeń kontekstowych (MotW)
  4. Identyfikacja miejsc, gdzie MSHTML jest nadal osadzone
    Skoro wektor może dotyczyć komponentów wykorzystujących legacy renderowanie, warto zidentyfikować aplikacje/komponenty w organizacji, które używają WebBrowser control / MSHTML i potraktować je jako podwyższone ryzyko.

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

W lutym 2026 obok CVE-2026-21513 pojawiły się podobne klasowo problemy (np. security feature bypass w Windows Shell oraz w Word). SANS ISC zwraca uwagę, że wspólnym mianownikiem jest sytuacja, w której użytkownik nie jest właściwie ostrzegany przed uruchomieniem pobranego kodu/zasobów, a mechanizmy typu SmartScreen mają być obchodzone.

W praktyce: jeśli organizacja miała już procesy “MotW/SmartScreen bypass triage”, CVE-2026-21513 pasuje do tej samej półki priorytetu.

Podsumowanie / kluczowe wnioski

  • CVE-2026-21513 to aktywnie wykorzystywany bypass mechanizmów ochronnych w MSHTML/IEFRAME, który w realnych kampaniach prowadzi do uruchomienia zasobów przez ścieżkę z ShellExecuteExW.
  • Kampania opisana przez Akamai używa sprytnie spreparowanego .lnk z osadzonym HTML i technik manipulacji kontekstem DOM, aby ominąć MotW/IE ESC.
  • Najważniejsze działania: patchowanie lutego 2026 + szybkie polowanie na IOC (hash + domena) i kontrola wektorów initial access opartych o .lnk/HTML.

Źródła / bibliografia

  1. Akamai, Inside the Fix: Analysis of In-the-Wild Exploit of CVE-2026-21513 (20 Feb 2026). (akamai.com)
  2. NVD (NIST), CVE-2026-21513 Detail (publ. 10 Feb 2026; KEV info, CVSS 8.8, CWE-693). (NVD)
  3. Tenable, Microsoft’s February 2026 Patch Tuesday Addresses 54 CVEs… (10 Feb 2026). (Tenable®)
  4. Rapid7 Vulnerability DB, Microsoft Windows: CVE-2026-21513… (10 Feb 2026). (Rapid7)
  5. SANS ISC Diary, Microsoft Patch Tuesday – February 2026 (10 Feb 2026). (SANS Internet Storm Center)

Starkiller: nowy phishing-as-a-service, który „proxy’uje” prawdziwe strony logowania i neutralizuje MFA

Wprowadzenie do problemu / definicja luki

Klasyczny phishing „na login” zwykle polega na podsunięciu ofierze statycznej kopii strony logowania (HTML/CSS), która zbiera hasło i czasem kod 2FA. Problem dla przestępców jest prosty: takie klony szybko się „starzeją”, łatwo je fingerprintować i blokować, a każda zmiana interfejsu po stronie prawdziwego serwisu może zdradzić fałszywkę.

Starkiller idzie krok dalej: realizuje atak typu Adversary-in-the-Middle (AiTM) / reverse-proxy phishing, gdzie ofiara wchodzi na stronę pośredniczącą, ale… ogląda prawdziwą stronę logowania serwisu (renderowaną i podawaną przez infrastrukturę napastnika). Dzięki temu MFA może „zadziałać poprawnie”, a mimo to konto zostaje przejęte — bo kluczowy artefakt to nie sam kod MFA, tylko cookie / token sesyjny pozyskany po udanym logowaniu.

W skrócie

  • Starkiller to phishing-as-a-service, który dynamicznie ładuje prawdziwe strony logowania i działa jako reverse proxy między użytkownikiem a właściwym serwisem.
  • Platforma uruchamia kontener Docker z headless Chrome, co pomaga renderować realny frontend i „nadążać” za zmianami po stronie brandu.
  • W pakiecie: keylogger, kradzież cookies/tokenów, podgląd sesji ofiary w czasie rzeczywistym, geotracking, alerty (np. Telegram) oraz analityka kampanii jak w legalnym SaaS.
  • To uderza w organizacje, które opierają ochronę tożsamości na „zwykłym” MFA (SMS/TOTP/push), bez mechanizmów phishing-resistant.

Kontekst / historia / powiązania

Reverse-proxy phishing nie jest nowy — od lat istnieją narzędzia i zestawy PhaaS, które pomagają przechwytywać sesje i omijać MFA. Cisco Talos opisywał, że dzięki gotowym „zestawom” prawie każdy może uruchomić taki atak bez zrozumienia warstwy technicznej, a operatorzy dodają techniki utrudniające automatyczne skanowanie linków czy analizę statyczną.

Nowość Starkillera polega przede wszystkim na opakowaniu (SaaS-owe UX, automatyzacja infrastruktury, niski próg wejścia) i na tym, że zamiast polegać na szablonach stron logowania, platforma podaje ofierze realną treść z prawdziwej domeny — przez pośrednika.

Analiza techniczna / szczegóły

1. Łańcuch ataku (uproszczony)

  1. Ofiara dostaje link, który wizualnie przypomina prawdziwy adres (np. sztuczki z formatem URL). Krebs opisuje m.in. wariant z użyciem znaku „@” w URL, gdzie wszystko przed „@” jest traktowane jak „dane użytkownika”, a faktyczny host jest po nim.
  2. Po kliknięciu Starkiller uruchamia/wykorzystuje przygotowane środowisko: Docker container + headless Chrome, który ładuje prawdziwą stronę logowania brandu.
  3. Kontener działa jako man-in-the-middle reverse proxy: przekazuje żądania do prawdziwego serwisu i odsyła odpowiedzi do ofiary. Użytkownik widzi autentyczny UI, bo to w praktyce „prawdziwa strona przez pośrednika”.
  4. W trakcie logowania Starkiller rejestruje każde naciśnięcie klawisza, dane formularzy i — co kluczowe — tokeny/cookies sesji po udanym logowaniu.
  5. Po przechwyceniu sesji atakujący może wykonać account takeover bez ponownego przechodzenia MFA (bo ma już „gotową” sesję).

2. Dlaczego to omija MFA „mimo że działa”

W modelu reverse proxy MFA nie jest „łamane” kryptograficznie. Ofiara naprawdę loguje się do prawdziwego serwisu i naprawdę wpisuje kod/potwierdza push. Różnica polega na tym, że cały przepływ przechodzi przez infrastrukturę przestępcy, więc ten może przejąć rezultat udanego logowania (cookie/token).

3. Funkcje „platformowe”, które podnoszą skuteczność

  • „Panel” operatora do uruchamiania kampanii i kontenerów bez dłubania w certyfikatach/proxy.
  • Real-time session monitoring (podgląd interakcji ofiary), alerty i analityka konwersji.
  • Elementy maskowania linków (w tym klasyczne triki z URL) i łatwe podszywanie się pod popularne marki.

Praktyczne konsekwencje / ryzyko

Najbardziej narażone są środowiska, gdzie:

  • dostęp do poczty, M365/Google Workspace, VPN/SSO i systemów finansowych opiera się na hasło + TOTP/push,
  • brakuje spójnej polityki urządzeń (device posture), ograniczeń sesji i analityki tożsamości,
  • reakcja na przejęcie konta jest opóźniona (np. brak korelacji logów, brak wykrywania „token replay”, brak reguł „impossible travel”).

W takich warunkach Starkiller ułatwia przejęcie kont uprzywilejowanych i uruchomienie dalszych etapów ataku: BEC, kradzież danych, lateral movement i utrzymanie dostępu przez dodanie nowych metod MFA po stronie konta (częsty pattern w AiTM).

Rekomendacje operacyjne / co zrobić teraz

Ochrona tożsamości (priorytet)

  • Włącz i egzekwuj phishing-resistant MFA tam, gdzie to możliwe: FIDO2/WebAuthn / passkeys / klucze sprzętowe (wiązanie z originem utrudnia reverse-proxy phishing). Cisco Talos wprost wskazuje, że WebAuthn ogranicza ten typ ataku, bo poświadczenia są związane z konkretną domeną/originem.
  • Ogranicz żywotność sesji, stosuj Conditional Access: ryzykowne logowania, nowe urządzenia, nietypowe lokalizacje → dodatkowa weryfikacja lub blokada.

Detekcja i telemetry

  • Poluj na sygnały AiTM: token/cookie reuse, dwa różne UA/IP na tej samej sesji, „impossible travel”, anomalie w logach SSO.
  • W e-mail security ogranicz zaufanie do „ładnego wyglądu” strony: tu strona będzie wyglądać perfekcyjnie, bo jest prawdziwa. Stawiaj na analizę behawioralną i korelację tożsamości.

Higiena kampanii phishingowych

  • Twarde reguły dla użytkowników: zawsze sprawdzaj host po „@” i finalną domenę po przekierowaniach; promuj logowanie przez bookmarki/portale, nie z linków w mailu.
  • Wdróż szybkie playbooki IR dla przejęcia konta: unieważnianie sesji, reset poświadczeń, przegląd reguł skrzynki (forwarding/inbox rules), przegląd zaufanych urządzeń/metod MFA.

Różnice / porównania z innymi przypadkami

  • Klasyczne PhaaS często bazuje na szablonach i „wstrzykniętym” JS. Starkiller w większym stopniu rozwiązuje problem „psujących się” klonów, bo proxy’uje live content.
  • Evilginx i podobne narzędzia są znane i szeroko omawiane jako baza dla AiTM; Starkiller jest bliżej gotowego produktu „dla mas” z automatyzacją, panelem i metrykami, co obniża barierę wejścia i przyspiesza skalowanie kampanii.

Podsumowanie / kluczowe wnioski

Starkiller to kolejny dowód, że „MFA ≠ koniec phishingu”. Gdy atakujący staje się pośrednikiem sesji (AiTM), najcenniejszym łupem są tokeny i cookies, a nie samo hasło czy kod. W praktyce oznacza to konieczność przesunięcia ciężaru obrony z blokowania „fałszywych stron” na ochronę tożsamości, telemetrię sesji oraz phishing-resistant MFA (WebAuthn/FIDO2).

Źródła / bibliografia

  1. KrebsOnSecurity — “‘Starkiller’ Phishing Service Proxies Real Login Pages, MFA” (20 lutego 2026). (Krebs on Security)
  2. Abnormal AI — “Starkiller: New Phishing Framework Proxies Real Login Pages to Bypass MFA” (19 lutego 2026). (Abnormal AI)
  3. Cisco Talos — “State-of-the-art phishing: MFA bypass” (1 maja 2025). (Cisco Talos Blog)
  4. Dark Reading — “Best-in-Class ‘Starkiller’ Phishing Kit Bypasses MFA” (19 lutego 2026). (Dark Reading)
  5. ITPro — “Starkiller: … proxies real login pages” (19 lutego 2026). (IT Pro)

PromptSpy: pierwsze znane malware na Androida, które używa GenAI (Gemini) do utrzymania się na urządzeniu

Wprowadzenie do problemu / definicja luki

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

W skrócie

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

Kontekst / historia / powiązania

ESET opisuje dwie powiązane linie rozwoju:

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

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

Analiza techniczna / szczegóły luki

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

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

2) Uprawnienia Accessibility jako „master key”

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

3) GenAI jako silnik „adaptacyjnej automatyzacji UI”

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

PromptSpy rozwiązuje to tak:

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

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

4) Funkcje szpiegowskie i zdalna kontrola (VNC)

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

5) Utrudnianie usunięcia (anti-removal)

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

6) Atrybucja i pochodzenie

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

Praktyczne konsekwencje / ryzyko

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

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i administratorów MDM

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

Dla SOC/Blue Team

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

Różnice / porównania z innymi przypadkami

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

Podsumowanie / kluczowe wnioski

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

Źródła / bibliografia

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

Microsoft 365 Copilot: błąd powodował streszczanie „poufnych” e-maili mimo etykiet i DLP

Wprowadzenie do problemu / definicja luki

Microsoft potwierdził incydent związany z Microsoft 365 Copilot Chat: przez błąd logiki/konfiguracji narzędzie potrafiło przetwarzać (i streszczać) wiadomości e-mail oznaczone etykietą poufności mimo tego, że w organizacji skonfigurowano sensitivity labels oraz Data Loss Prevention (DLP), które miały wykluczać takie treści z użycia przez Copilota.

To nie „wyciek” w klasycznym rozumieniu (np. do innych tenantów), ale złamanie oczekiwanego modelu ochrony danych: treści, które miały być „niewidoczne” dla funkcji AI, znalazły się w zakresie przetwarzania przez Copilot Chat.

W skrócie

  • Problem dotyczył Copilot Chat w „Work tab” i obejmował e-maile w folderach Drafts i Sent Items (Outlook desktop).
  • Zdarzenie było śledzone jako CW1226324; pierwsze wykrycie/zgłoszenia pojawiają się przy dacie 21 stycznia 2026.
  • Microsoft wskazał „code issue” jako przyczynę oraz poinformował o wdrażaniu poprawki od początku lutego.
  • W oświadczeniu (aktualizacja w artykule) Microsoft podkreślił, że nie dawało to dostępu do informacji osobom nieuprawnionym oraz że wdrożono globalną aktualizację konfiguracyjną dla klientów enterprise.

Kontekst / historia / powiązania

Microsoft od miesięcy promuje Copilota jako warstwę produktywności „osadzoną” w danych organizacji. W tym modelu kluczowe są dwie linie obrony:

  1. Sensitivity labels (Microsoft Purview Information Protection) – klasyfikują i (opcjonalnie) egzekwują ochronę, m.in. poprzez szyfrowanie i prawa użycia.
  2. DLP (Microsoft Purview Data Loss Prevention) – zestaw zasad ograniczających „nadmierne udostępnianie” danych w aplikacjach i usługach M365.

Incydent jest ważny, bo uderza w zaufanie do tego, że „etykieta + DLP” rzeczywiście wycina treści z przepływu AI w każdej ścieżce produktu (tu: Copilot Chat / Work tab).

Analiza techniczna / szczegóły luki

Co dokładnie działo się „źle”

Według komunikatów przytoczonych przez media i treści alertu serwisowego, Copilot Chat błędnie przetwarzał e-maile z nałożoną etykietą „confidential” i aktywną polityką DLP, a źródłem była usterka powodująca, że elementy z Sent Items i Drafts „wpadały” do indeksu/streszczeń Copilota mimo wykluczeń.

Dlaczego to jest newralgiczne dla bezpieczeństwa

W praktyce firmy budują polityki tak, by:

  • część korespondencji (np. umowy, dane HR, dane medyczne, M&A) była oznaczona etykietą poufności,
  • a DLP miało ograniczać przetwarzanie/ujawnianie tych treści w nowych kanałach (w tym przez narzędzia generatywne).

Microsoft opisuje DLP jako mechanizm ochrony przed oversharingiem w aplikacjach enterprise i usługach M365.
Jednocześnie dokumentacja Microsoft Learn wskazuje, że etykiety poufności są rozpoznawane przez Copilot i Copilot Chat, a przy treściach szyfrowanych znaczenie mają konkretne prawa użycia (np. EXTRACT).

W tym incydencie problem polegał na tym, że „intencja polityki” (wykluczyć) rozmijała się z „rzeczywistą ścieżką przetwarzania” w Copilot Chat dla określonych folderów Outlooka.

Praktyczne konsekwencje / ryzyko

  1. Ryzyko niezamierzonego ujawnienia w ramach tej samej tożsamości
    Nawet jeśli Microsoft podkreśla, że nie rozszerzyło to uprawnień dostępowych, streszczenie w narzędziu AI może ułatwić przypadkowe „wyciąganie” wrażliwych informacji w toku pracy (np. kopiowanie fragmentów, wklejanie do innych kanałów).
  2. Ryzyko naruszeń zgodności
    W wielu reżimach (RODO/GDPR, tajemnice przedsiębiorstwa, regulacje sektorowe) liczy się nie tylko „kto miał uprawnienie”, ale też czy kontrola techniczna działała zgodnie z polityką i czy dane nie były przetwarzane w nieautoryzowanym scenariuszu.
  3. Erozja zaufania do sterowania AI przez etykiety i DLP
    Jeżeli wykluczenia potrafią zawieść w jednym kanale (Work tab), organizacje zaczną traktować integracje AI jak „kolejny kanał exfiltracji”, który wymaga osobnego hardeningu i monitoringu.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań „bezpiecznych domyślnie” dla środowisk enterprise korzystających z Copilot/Outlook:

  1. Zweryfikuj komunikat serwisowy (CW1226324) i status w Twoim tenancie
    Jeśli masz Microsoft 365 Admin Center, sprawdź, czy poprawka/aktualizacja konfiguracyjna została zastosowana oraz czy Microsoft wskazuje dodatkowe kroki po stronie klienta. (W samych publikacjach brak pełnej listy tenantów dotkniętych problemem).
  2. Upewnij się, że DLP obejmuje Copilot i Copilot Chat – dedykowana lokalizacja polityk
    Microsoft opisuje możliwość tworzenia zasad DLP ukierunkowanych na Microsoft 365 Copilot i Copilot Chat (m.in. blokowanie przetwarzania treści oznaczonych etykietami w kontekście generowania odpowiedzi).
    W praktyce: jeśli polegasz wyłącznie na „etykietach w Outlook/Exchange”, rozważ dodanie/utwardzenie reguł stricte dla „Copilot and Copilot Chat policy location”.
  3. Wzmocnij ochronę najbardziej wrażliwych etykiet przez szyfrowanie i prawa użycia
    Microsoft wskazuje, że przy etykietach z szyfrowaniem Copilot sprawdza prawa użycia użytkownika (np. EXTRACT), zanim zwróci dane.
    To nie rozwiązuje wszystkich przypadków, ale podnosi poprzeczkę dla „łatwego streszczenia” treści klasy Highly Confidential/HR/Legal.
  4. Przegląd „gdzie leżą wrażliwe rzeczy” – Drafts i Sent Items też są danymi krytycznymi
    Ten incydent pokazuje, że ochrona często jest projektowana „pod Inbox i udostępnienia”, a robocze wersje dokumentów i korespondencji (Drafts/Sent) bywają jeszcze bardziej wrażliwe.
  5. Ogranicz ekspozycję Copilot Chat w okresie weryfikacji
    Jeśli Twoja organizacja ma wysoką wrażliwość danych (prawo, finanse, medycyna), rozważ tymczasowe ograniczenia użycia Copilot Chat w scenariuszach e-mailowych do czasu potwierdzenia skuteczności poprawek (np. poprzez polityki dostępu/konfigurację Copilota na poziomie tenantów i ról).

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

  • „Naruszenie uprawnień” vs „naruszenie oczekiwanego wykluczenia”:
    Microsoft twierdzi, że nie doszło do nadania nowego dostępu do danych, ale doszło do sytuacji, w której Copilot działał niezgodnie z zamierzoną separacją treści chronionych od funkcji AI.
  • DLP w klasycznych kanałach M365 vs DLP w interakcjach AI:
    DLP historycznie „pilnowało” Exchange/SharePoint/Teams. Teraz dochodzą interakcje prompt/response i scenariusze streszczania – Microsoft rozwija dedykowane mechanizmy DLP dla Copilota.

Podsumowanie / kluczowe wnioski

  • Incydent z Copilot Chat (Work tab) ujawnił, że nawet przy włączonych etykietach poufności i DLP mogą wystąpić ścieżki, w których AI przetwarza treści w sposób niezamierzony.
  • Microsoft wskazał przyczynę jako błąd kodu, a następnie wdrożył aktualizację konfiguracyjną globalnie dla enterprise, podkreślając brak eskalacji uprawnień.
  • Dla organizacji to sygnał, by traktować Copilota jak nową powierzchnię przetwarzania danych, którą trzeba objąć: dedykowanym DLP dla Copilot/Copilot Chat, twardszymi etykietami dla „top secret”, oraz przeglądem ryzyka dla Drafts/Sent.

Źródła / bibliografia

  1. BleepingComputer – opis incydentu i cytaty z alertu/stanowiska Microsoft. (BleepingComputer)
  2. The Register – kontekst DLP/sensitivity labels i stanowisko Microsoft. (The Register)
  3. TechRadar Pro – streszczenie wpływu (Drafts/Sent), identyfikator CW1226324, timeline. (TechRadar)
  4. Microsoft Learn – Sensitivity labels (Purview) i ich relacja do Copilot/Copilot Chat. (Microsoft Learn)
  5. Microsoft Learn – Data Loss Prevention (DLP): definicja, zakres i lokalizacje ochrony. (Microsoft Learn)

Infostealer po raz pierwszy kradnie „sekrety” OpenClaw: nowy wektor ryzyka dla lokalnych agentów AI

Wprowadzenie do problemu / definicja luki

Klasyczne infostealery kojarzą się z kradzieżą haseł z przeglądarek, ciasteczek sesyjnych, danych portfeli krypto i plików konfiguracyjnych popularnych aplikacji. Teraz obserwujemy przesunięcie ciężaru: ten sam „hurtowy” mechanizm wykradania plików zaczyna zbierać także sekrety agentów AI uruchamianych lokalnie – na przykład OpenClaw, który przechowuje tokeny, klucze i trwałą pamięć kontekstu na stacji roboczej użytkownika.

To nie jest „exploit w OpenClaw” w rozumieniu CVE. To raczej zmiana wartości kradzionych danych: agent AI staje się koncentratorem dostępu do usług (poczta, komunikatory, kalendarze, API), więc jego konfiguracja jest dla atakujących wyjątkowo opłacalna.

W skrócie

  • Odnotowano pierwszy przypadek „in-the-wild”, gdzie infostealer wykradł środowisko konfiguracyjne OpenClaw i pliki zawierające tokeny/klucze/pamięć agenta.
  • Według relacji badaczy, próbka wyglądała na wariant Vidar; kradzież nastąpiła 13 lutego 2026 (data infekcji/eksfiltracji wskazana w opisie incydentu).
  • Nie był to jeszcze „dedykowany moduł pod OpenClaw” – raczej szerokie file-grabbing po słowach kluczowych typu „token”, „private key”, które „zahaczyło” o katalog konfiguracyjny OpenClaw.

Kontekst / historia / powiązania

OpenClaw to agent AI uruchamiany lokalnie, utrzymujący trwałą konfigurację i pamięć na urządzeniu użytkownika oraz integrujący się z usługami online (co oznacza realne tokeny, klucze API i dane sesyjne).

Równolegle rośnie drugi front ryzyka: ekosystem rozszerzeń/„skills”. 1Password opisywał przypadki, w których popularne „skills” pełniły rolę nośnika malware (instrukcje instalacji, socjotechnika, skrypty etapowe), a autorzy podkreślali, że przenośny format „skills” może stać się problemem między różnymi platformami agentów.

Na to nakłada się szerszy trend: infostealery coraz częściej wychodzą poza klasyczne scenariusze Windows i intensywnie uderzają też w macOS, wykorzystując socjotechnikę, malvertising i „ClickFix” (nakłanianie do wklejania komend w Terminalu), aby kraść hasła, tokeny, dane przeglądarek, keychain i „developer secrets”.

Analiza techniczna / szczegóły luki

Co zostało skradzione?

W opisywanym incydencie skradzione miały zostać m.in. pliki:

  • openclaw.json – zawierał m.in. (zredagowany) e-mail, ścieżki workspace oraz token uwierzytelniający bramę (gateway token) o wysokiej entropii. Taki token może umożliwić podszycie się w zapytaniach uwierzytelnionych, a w pewnych warunkach także zdalne połączenie do lokalnej instancji (jeśli jest wystawiona/osiągalna z sieci).
  • device.json – zawierał parę kluczy (public/private) do parowania i podpisywania. Prywatny klucz może potencjalnie umożliwić podpisywanie komunikatów jak „zaufane urządzenie” i obejście niektórych kontroli opartych o tożsamość urządzenia.
  • soul.md oraz pliki pamięci (np. AGENTS.md, MEMORY.md) – opis zachowania agenta i trwały kontekst: logi aktywności, wiadomości prywatne, zdarzenia z kalendarza itp.

Jak to zostało zebrane?

Wg opisu, stealer nie „polował” na OpenClaw z precyzją modułu, tylko realizował masowe przeszukiwanie i eksfiltrację plików na podstawie rozszerzeń, ścieżek i słów kluczowych typu „token” / „private key”. Katalog konfiguracyjny OpenClaw po prostu pasował do heurystyki.

Dlaczego to ważne dla obrońców?

To sygnał, że agent AI staje się dla przestępców tym, czym kiedyś stała się przeglądarka: „portfelem” sesji, tokenów i tożsamości. Hudson Rock (cytowany w mediach) przewiduje, że kolejnym krokiem będą dedykowane moduły rozumiejące strukturę plików agentów, analogicznie do modułów pod Chrome/Telegram.

Praktyczne konsekwencje / ryzyko

  1. Przejęcie usług spiętych z agentem
    Tokeny i klucze API mogą otworzyć dostęp do poczty, kalendarzy, komunikatorów czy integracji automatyzacji – zależnie od tego, co użytkownik podpiął do agenta.
  2. „Kradzież tożsamości” agenta i kontekstu
    Wykradzenie pamięci (logów, wiadomości, zdarzeń) to nie tylko prywatność. To także materiał do: BEC, spear phishingu, oszustw „na kontekst”, szantażu, a w firmach – do dalszej eskalacji (np. poprzez znajomość procesów i narzędzi).
  3. Łatwiejsze ataki następcze
    Infostealery bywają „etapem 0” przed ransomware lub włamaniami domenowymi: kradną dostęp, który potem jest monetyzowany przez inne grupy. Trend skali i zasięgu infostealerów (w tym na macOS) wzmacnia prawdopodobieństwo, że takie incydenty będą częstsze.

Rekomendacje operacyjne / co zrobić teraz

Jeśli używasz OpenClaw (indywidualnie lub w firmie)

  • Rotuj i unieważnij sekrety: klucze API, tokeny dostępu, tokeny bramy/gateway, sesje wpiętych usług. Zacznij od tych o najszerszych uprawnieniach.
  • Sprawdź ekspozycję instancji: upewnij się, że lokalna instancja nie jest przypadkiem wystawiona na świat (port-forward, publiczny adres, błędna konfiguracja). Zasada: agent lokalny ≠ usługa publiczna.
  • Ogranicz dostęp do plików konfiguracyjnych: uruchamiaj agenta na osobnym koncie systemowym, minimalne uprawnienia do katalogów, wrażliwe pliki tylko dla właściciela (chmod/ACL).
  • Przenieś sekrety do menedżera sekretów (tam gdzie to możliwe): ogranicz przechowywanie długowiecznych tokenów w plaintext w katalogach użytkownika.
  • Podejście „zero-trust dla integracji”: przyznawaj agentowi najmniejsze możliwe scope’y, osobne konta techniczne, krótkie TTL tokenów, regularny przegląd integracji.

Jeśli bronisz organizacji (SOC/IR)

  • Telemetria i detekcje na eksfiltrację: poluj na nietypowe archiwizowanie i wysyłkę katalogów konfiguracyjnych, zwłaszcza w katalogach użytkownika (tworzenie ZIP w /tmp itp.) oraz na podejrzane POST-y do świeżych domen. Microsoft opisuje te wzorce jako typowe w kampaniach stealerów.
  • Zabezpieczenia przed socjotechniką: bloki na „ClickFix”, malvertising, fałszywe instalatory (DMG/PKG), polityki uruchamiania, App Control – bo to dziś jeden z głównych kanałów dostarczania stealerów również na macOS.
  • Kontrola łańcucha dostaw „skills”: traktuj rozszerzenia agenta jak kod wykonywalny. Weryfikuj źródła, podpisy, review, skanuj repozytoria, izoluj środowisko uruchomieniowe. Case’y opisane w analizach „skills” pokazują, że sama „bramka narzędziowa” (policy gating) nie wystarczy, jeśli skill skłoni użytkownika/agenta do uruchomienia komend.

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

  • Tu nie ma (jeszcze) „modułu pod OpenClaw” – to istotna różnica. Incydent pokazuje, że nawet prymitywne heurystyki kradzieży plików już trafiają w agentów AI, bo ich foldery zawierają klasyczne „sekretne” słowa/artefakty.
  • „Skills” jako wektor dostarczenia vs. stealer jako etap kradzieży
    Kampanie złośliwych „skills” dotyczą częściej dostarczenia malware i przejęcia hosta przez social engineering/uruchamianie skryptów. Opisywany przypadek to etap po infekcji – stealer zbiera wartościowe dane, które teraz obejmują także „duszę” agenta (kontekst + sekrety).
  • Szerszy trend: infostealery idą wieloplatformowo
    Microsoft wskazuje eskalację kampanii na macOS i użycie cross-platform (np. Python) oraz nadużywanie zaufanych kanałów dystrybucji. To zwiększa szansę, że „sekrety agentów” będą kradzione niezależnie od systemu, jeśli pliki leżą lokalnie.

Podsumowanie / kluczowe wnioski

  • Agent AI uruchamiany lokalnie to magnes na infostealery, bo kumuluje dostęp do wielu usług i przechowuje długowieczne sekrety.
  • Pierwsze obserwacje pokazują „zwykłe” file-grabbing, ale logika rynku cyberprzestępczego sugeruje szybkie pojawienie się dedykowanych modułów do parsowania/odszyfrowywania danych agentów.
  • Obrona powinna łączyć: rotację sekretów, ograniczenie ekspozycji instancji, twarde uprawnienia plików, kontrolę integracji oraz detekcje eksfiltracji, a także rygor dla „skills” jako kodu wykonywalnego.

Źródła / bibliografia

  1. BleepingComputer – opis incydentu i lista wykradzionych plików OpenClaw (16 lutego 2026). (BleepingComputer)
  2. The Hacker News – dodatkowy kontekst techniczny (gateway token, device keys, perspektywa rozwoju stealerów) (16 lutego 2026). (The Hacker News)
  3. Microsoft Security Blog – „Infostealers without borders…” (kampanie na macOS, ClickFix, kradzież keychain/developer secrets, rekomendacje obrony) (2 lutego 2026). (Microsoft)
  4. 1Password – analiza ryzyka „skills” jako powierzchni ataku i mechanizmów dostarczania malware (luty 2026). (1password.com)
  5. Infostealers.com – tło dot. Vidar (charakterystyka kradzieży danych/telemetria infrastruktury) (31 grudnia 2023). (InfoStealers)

500 tys. kont VKontakte przejętych przez złośliwe rozszerzenia Chrome: jak działa kampania „VK Styles” i jak się bronić

Wprowadzenie do problemu / definicja luki

Przeglądarkowe rozszerzenia to dziś jeden z najbardziej niedoszacowanych wektorów ataku. Mają uprzywilejowany dostęp do treści stron (content scripts), sesji użytkownika i często szerokich uprawnień „host permissions”. Jeśli takie rozszerzenie okaże się złośliwe (lub zostanie przejęte), atakujący może działać „w środku” przeglądarki – tam, gdzie użytkownik jest już zalogowany, a mechanizmy ochronne serwisów (CSRF, restrykcje UI) bywają łatwiejsze do obejścia.

Właśnie ten scenariusz zmaterializował się w kampanii wymierzonej w VKontakte (VK): według ustaleń Koi Security i opisu incydentu w Recorded Future News / The Record, sieć pięciu powiązanych rozszerzeń Chrome doprowadziła do przejęcia ponad 500 tys. kont.

W skrócie

  • Skala: ~502 tys. potwierdzonych ofiar (łączna liczba instalacji/poszkodowanych w badaniu).
  • Wektor: 5 rozszerzeń Chrome udających narzędzia do „stylów”, motywów i ulepszania VK.
  • Efekt: aktywna manipulacja kontem (m.in. wymuszane subskrypcje grup, cykliczne resety ustawień), a nie tylko „śledzenie” czy adware.
  • Trwałość: mechanizmy utrzymania kontroli i wieloetapowe doładowywanie kodu z zewnętrznych źródeł.

Kontekst / historia / powiązania

Badacze Koi opisują kampanię jako działającą co najmniej od połowy 2025 r., z ciągłymi aktualizacjami do początku 2026 r. (czyli miesiące „cichej” obecności).
Co istotne, co najmniej jedno z rozszerzeń miało być wcześniej usunięte przez Google (już w 2024 r.) za naruszenia zasad – ale operator szybko „przesiadł się” na nowe identyfikatory rozszerzeń i kontynuował operację. To klasyczny wzorzec „whack-a-mole” w ekosystemie dodatków.

MITRE ATT&CK od lat opisuje nadużycia rozszerzeń przeglądarkowych jako technikę utrzymania dostępu i realizacji działań na stacji roboczej użytkownika – w praktyce to wygodny kanał persystencji i manipulacji ruchem/treścią stron.

Analiza techniczna / szczegóły luki

1) „Legalnie wyglądające” rozszerzenia + zaufanie użytkownika

„VK Styles” i powiązane dodatki były promowane jako kosmetyczne ulepszenia VK (motywy, poprawa UX). W opisie Koi kluczowe jest to, że na poziomie listingu i recenzji nic nie musiało wyglądać podejrzanie – a użytkownicy często akceptują szerokie uprawnienia, bo „inaczej nie zadziała”.

2) Uprawnienia i uruchamianie kodu na vk.com

Mechanika ataku opiera się o typowe możliwości rozszerzeń: host permissions oraz content scripts, które pozwalają wykonywać kod w kontekście odwiedzanych stron (np. vk.com) i reagować na zdarzenia sesji użytkownika.

3) Wieloetapowy ładunek i „C2” w serwisie społecznościowym

Najciekawszy element badania Koi: złośliwy kod miał być doładowywany dynamicznie z metadanych profilu VK (w tekście pada przykład profilu pełniącego rolę infrastruktury C2). Dzięki temu operator mógł zmieniać zachowanie kampanii bez klasycznych aktualizacji binarki rozszerzenia.

4) Manipulacja ochronami aplikacji webowej (CSRF) i wymuszone akcje

Według Koi, malware wykonywał manipulacje tokenami CSRF i automatyzował działania na koncie, m.in. dopisywanie do grup z wysokim prawdopodobieństwem przy sesji, a także cykliczne „odkręcanie” ustawień co ~30 dni, aby ofiara nie odzyskała kontroli na stałe.

5) Wskaźniki kompromitacji (IOC) – identyfikatory rozszerzeń

Koi publikuje listę ID pięciu rozszerzeń i ich przybliżoną popularność (największe miało ok. 400 tys. instalacji). To praktyczny punkt zaczepienia dla SOC/IR (telemetria przeglądarek, EDR, polityki przeglądarkowe).

Praktyczne konsekwencje / ryzyko

  1. Przejęcie konta „bez hasła” – jeśli rozszerzenie działa w przeglądarce zalogowanego użytkownika, może wykonywać akcje w jego imieniu (session riding), nawet gdy MFA jest włączone.
  2. Rozprzestrzenianie i monetyzacja – wymuszane dołączanie do grup i manipulacja ustawieniami może budować „zasięg” operatora, generować ruch, a nawet wspierać kampanie dezinformacyjne czy scam.
  3. Ryzyko dla firm – jeśli pracownik używa przeglądarki do pracy i prywatnie, rozszerzenie z szerokimi uprawnieniami jest realnym zagrożeniem dla danych firmowych (wgląd w treści stron, formularze, sesje).

W tle jest też problem systemowy: mimo procesu weryfikacji i zasad Web Store, złośliwe dodatki wciąż przenikają do marketplace’u (a potem wracają pod nowymi identyfikatorami).

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników indywidualnych (VK / Chrome)

  • Odinstaluj podejrzane rozszerzenia i sprawdź listę dodatków po ID (IOCs z raportu Koi).
  • Zmień hasło do VK i wyloguj wszystkie sesje (jeśli VK oferuje „log out of all devices/sessions”).
  • Zweryfikuj ustawienia konta: prywatność, powiązane aplikacje, nieznane grupy/subskrypcje, przekierowania, e-mail/telefon odzyskiwania.
  • Jeśli używałeś podobnych dodatków w innych serwisach: rotacja haseł i przegląd logów bezpieczeństwa.

Dla organizacji (IT/SOC)

  • Wymuś allow-listę rozszerzeń (polityki przeglądarkowe/MDM) i zablokuj instalację „z wolnej ręki”.
  • Monitoruj instalacje po extension ID (telemetria endpointów) oraz wykrywaj anomalia: nowe rozszerzenia z szerokimi host permissions, nietypowe aktualizacje, komunikacja z nietypowymi domenami.
  • Zredukuj uprawnienia: promuj dodatki korzystające z minimalnych/„optional permissions”, bo to ogranicza blast radius.
  • Edukacja użytkowników: „motywy”, „ulepszacze” i „darmowe funkcje premium” to częsty pretekst do wyłudzania uprawnień.

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

W porównaniu do „klasycznych” złośliwych rozszerzeń kradnących dane (np. hasła, treści stron), ta kampania wyróżnia się aktywną manipulacją kontem w serwisie społecznościowym oraz pomysłowym wykorzystaniem platformy (VK) jako elementu infrastruktury sterującej. To nie tylko eksfiltracja – to operacja wpływu na zachowanie kont i budowanie trwałego kanału dystrybucji.
Z perspektywy ATT&CK to dobrze wpisuje się w nadużycia rozszerzeń przeglądarkowych jako techniki zapewniającej persystencję i wykonywanie akcji po stronie klienta.

Podsumowanie / kluczowe wnioski

  • Rozszerzenia przeglądarki to pełnoprawny wektor przejęcia kont – szczególnie gdy działają na stronach, gdzie użytkownik jest stale zalogowany.
  • Kampania „VK Styles” pokazuje, że atakujący potrafią łączyć socjotechnikę (motywy/ulepszenia) z dynamicznym doładowywaniem kodu i automatyzacją akcji na koncie na masową skalę.
  • Najskuteczniejsze środki obrony to: redukcja liczby dodatków, minimalizacja uprawnień, allow-lista w firmach oraz szybka reakcja (odinstalowanie + reset sesji/hasła).

Źródła / bibliografia

  1. The Record (Recorded Future News) – opis incydentu i odniesienie do raportu Koi Security. (The Record from Recorded Future)
  2. Koi Security (Koi Research) – raport techniczny „VK Styles: 500K Users Infected…”, IOC i szczegóły kampanii. (koi.ai)
  3. Chrome for Developers – model uprawnień (host permissions, content scripts, optional permissions). (Chrome for Developers)
  4. Chrome Web Store – zasady programu i proces weryfikacji (malware/spyware zakazane, ochrona użytkowników). (Chrome for Developers)
  5. MITRE ATT&CK – technika nadużyć rozszerzeń przeglądarkowych (Browser Extensions). (MITRE ATT&CK)