Archiwa: AI - Strona 42 z 58 - Security Bez Tabu

Tag: AI

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)

UAT-9921 i VoidLink: „cloud-native” malware w Zig, które celuje w Linuxa i środowiska chmurowe

Wprowadzenie do problemu / definicja luki

VoidLink to rozbudowany, modułowy framework implantów i C2 ukierunkowany na systemy Linux — ze szczególnym naciskiem na nowoczesną infrastrukturę (chmura, Kubernetes, Docker). W kampaniach zaobserwowanych przez Cisco Talos narzędzie jest używane przez nowo nazwany klaster aktywności UAT-9921, który po uzyskaniu dostępu instaluje elementy C2 na przejętych hostach i wykorzystuje je m.in. do skanowania oraz rekonesansu wewnątrz i na zewnątrz sieci.

W praktyce nie mówimy o „pojedynczym backdoorze”, tylko o ekosystemie: implant + system pluginów + mechanizmy ukrywania (w tym kernel-level) + zaplecze zarządzania, które przypomina komercyjne platformy red-teamowe, ale jest obserwowane w realnych włamaniach.

W skrócie

  • Aktor: UAT-9921 (Talos: aktywność co najmniej od 2019 r.).
  • Cele: przede wszystkim technologia, ale też finanse; zachowanie wskazuje na skanowanie i oportunizm (np. całe sieci klasy C).
  • Initial access (Talos): pre-pozyskane poświadczenia lub RCE przez Java serialization, m.in. w kontekście Apache Dubbo; sygnały o możliwym użyciu złośliwych dokumentów, ale bez próbek.
  • Post-compromise: implant VoidLink + SOCKS proxy + narzędzie FSCAN do rekonesansu i ruchu bocznego.
  • Technologia: Zig (implant), C (pluginy), Go (backend); kompilacja pluginów „na żądanie” pod różne dystrybucje Linuksa.
  • Chmura/kontenery: rozpoznawanie dostawców chmury, pobieranie poświadczeń (m.in. z env/config/metadata), scenariusze eskalacji w Kubernetes i ucieczki z kontenerów.
  • Stealth: rootkitowe mechanizmy (m.in. LD_PRELOAD/LKM/eBPF), adaptacja do środowiska i wykrytych zabezpieczeń.
  • C2: Ontinue opisuje AES-256-GCM po HTTPS, maskowane jako zwykły ruch web; zbieżności „w stylu” beaconów znanych z Cobalt Strike.
  • Zarządzanie: RBAC (SuperAdmin/Operator/Viewer), audytowalność akcji — nietypowe dla czysto „przestępczych” frameworków.

Kontekst / historia / powiązania

VoidLink został szeroko opisany wcześniej przez Check Point Research jako „cloud-first” framework malware dla Linuksa, rozwijany dynamicznie i wyposażony w bogaty zestaw funkcji (od user-mode po kernel-level), z elementami sugerującymi chińskojęzyczne środowisko wytwórcze (bez jednoznacznego przypisania afiliacji).

Kluczowe jest to, że obrazy sytuacji różnią się w czasie:

  • Check Point podkreślał, że w momencie publikacji nie widział dowodów realnych infekcji (bardziej „widać rozwój narzędzia” niż kampanię).
  • Talos raportuje natomiast ofiary powiązane z VoidLink od okolic września (aktywność do stycznia 2026) i wskazuje na konkretne TTP UAT-9921 w intruzjach.

W tle pojawia się jeszcze jeden trend: przyspieszenie cyklu tworzenia implantów. Talos wiąże rozwój VoidLink z użyciem AI-wspomaganego środowiska wytwórczego i ostrzega, że „kompilacja na żądanie” to fundament pod coraz bardziej automatyzowane (a w przyszłości także autonomiczne) łańcuchy ataku.

Analiza techniczna / szczegóły luki

1) Łańcuch ataku (w ujęciu Talos)

  1. Wejście: użycie pozyskanych wcześniej poświadczeń lub eksploatacja podatności typu Java serialization prowadzącej do RCE (Talos wskazuje m.in. Apache Dubbo).
  2. Utrwalenie i ukrycie: wdrożenie implantu VoidLink na przejętym serwerze.
  3. Rekonesans / lateral movement: uruchomienie SOCKS na skompromitowanych hostach i wykorzystanie FSCAN do rekonesansu wewnętrznego.
  4. Skalowanie: skanowanie zasobów także „na zewnątrz” (Talos wspomina o skanowaniu całych sieci klasy C), co sugeruje bardziej szerokie poszukiwanie okazji niż ręcznie dobierane cele.

2) Architektura: implant + pluginy + backend

VoidLink jest zbudowany jak platforma:

  • Zig jako język implantu,
  • C jako język pluginów,
  • Go jako backend,
  • oraz mechanizm kompilacji pluginów na żądanie, co ułatwia dopasowanie do dystrybucji/środowiska ofiary (i utrudnia obronę sygnaturową).

Check Point dodaje, że framework ma plugin system in-memory i obsługuje różne kanały C2 (w tym bardziej „nietypowe” jak ICMP czy DNS tunneling, obok HTTP/HTTPS).

3) Chmura i DevOps jako „naturalne” środowisko działania

Ontinue opisuje implant jako nastawiony na:

  • fingerprinting środowisk AWS/GCP/Azure/Alibaba/Tencent,
  • pozyskiwanie poświadczeń z env/config oraz API metadanych instancji,
  • wykrywanie runtime kontenerów,
  • oraz posiadanie pluginów pod container escape i eskalację w Kubernetes.

To spina się z obserwacjami Check Point, że VoidLink potrafi rozpoznać, czy działa w Kubernetes/Docker i dostosować zachowanie.

4) Stealth i komponent „rootkitowy”

Check Point wskazuje na wachlarz mechanizmów OPSEC i ukrywania: m.in. szyfrowanie kodu w runtime, reakcje na manipulację/tampering oraz rootkitowe podejście (LD_PRELOAD, LKM, eBPF).

Talos dodaje warstwę praktyczną: wykrywanie rozwiązań EDR i dobór strategii uniku, a także funkcje typu eBPF/LKM oraz scenariusze eskalacji/ucieczki z sandboxa.

5) C2, kryptografia i „pozory normalności”

Ontinue opisuje AES-256-GCM po HTTPS, maskowane tak, by wyglądało jak normalny ruch web. Wskazuje też podobieństwa wzorców komunikacji do architektury beaconów znanych z Cobalt Strike.

6) Zarządzanie kampanią: RBAC, audyt i „defense-contractor grade”

Jedna z najbardziej nietypowych cech VoidLink (w porównaniu do wielu narzędzi stricte przestępczych) to:

  • audytowalność akcji
  • i RBAC z rolami SuperAdmin / Operator / Viewer.

Talos zaznacza wprost, że to może pasować do środowisk, gdzie potrzebny jest nadzór prawny/korporacyjny — oraz że z tego powodu nie da się całkowicie wykluczyć scenariusza „red team”, mimo iż w obserwowanych działaniach pojawiają się też exploity i użycie cudzych poświadczeń.

7) Wątek Windows i DLL side-loading

Talos widzi przesłanki, że istnieje także implant dla Windows, ładujący pluginy przez DLL side-loading (bez pozyskanego próbki do pełnego potwierdzenia).
W terminologii MITRE ATT&CK jest to jedna z odmian Hijack Execution Flow (DLL Sideloading).

Praktyczne konsekwencje / ryzyko

Dlaczego to jest istotne operacyjnie (a nie tylko „kolejny malware”)?

  • Cloud-native post-exploitation: jeśli implant realnie umie „czytać” chmurę, kontenery i API dostawców, to kompromitacja pojedynczego hosta może szybciej przełożyć się na dostęp do sekretów, repozytoriów i tożsamości workloadów.
  • Stealth na poziomie kernela + adaptacja do EDR: rośnie ryzyko długiej obecności (dwell time), a klasyczne artefakty user-mode mogą w ogóle się nie pojawić albo być niewiarygodne.
  • „Kompilacja na żądanie”: obrona oparta wyłącznie na statycznych sygnaturach/IOC ma krótszą „przydatność”, bo funkcje mogą być dogrywane w locie, pod konkretną ofiarę.
  • Skalowanie przez skanowanie i proxy: obserwowane SOCKS+FSCAN oraz skanowanie sieci klasy C zwiększa ryzyko „rozlania się” incydentu na kolejne segmenty i usługi.

Rekomendacje operacyjne / co zrobić teraz

1) Ogranicz wektory wejścia

  • Zweryfikuj ekspozycję usług JVM/Java, a szczególnie komponentów, gdzie realnie występuje ryzyko Java serialization → RCE (Talos wskazuje Apache Dubbo jako przykład kontekstu).
  • Wymuś MFA, ogranicz logowanie administracyjne z Internetu, zredukuj „credential sprawl”, rotuj hasła/tokeny w systemach, gdzie podejrzewasz wyciek.

2) Utwardź chmurę i kontenery „pod kradzież sekretów”

  • Ogranicz dostęp do instance metadata (tam gdzie to możliwe), stosuj polityki minimalnych uprawnień dla ról/identity workloadów.
  • Przejrzyj miejsca, z których zwykle „wyciekają” sekrety: zmienne środowiskowe, pliki konfiguracyjne, katalogi narzędzi CI/CD, integracje Git/registry.

(Uzasadnienie: Ontinue opisuje pozyskiwanie poświadczeń właśnie z env/config/metadata i scenariusze ataku na kontenery/Kubernetes.)

3) Poluj na TTP po kompromitacji

  • Monitoruj anomalie: SOCKS proxy na serwerach aplikacyjnych, skanowanie portów i ruch narzędzi typu FSCAN.
  • Wdróż sensowne egress filtering (zwłaszcza z workloadów, które „nie powinny” rozmawiać z Internetem) oraz alerty na nietypowe beacony HTTPS.

4) Detekcja na hostach Linux: kernel, eBPF, LKM

  • Zwiększ telemetrię wokół ładowania modułów jądra (LKM) i nietypowych aktywności eBPF; szukaj sygnałów „rootkitowych” oraz zachowań anty-analizowych.
  • Tam, gdzie to realne: ogranicz możliwość ładowania niepodpisanych modułów, rozważ twardsze profile (np. lockdown mode, odpowiednie polityki w środowiskach produkcyjnych).

5) Jeśli masz komponenty Windows: kontroluj DLL side-loading

  • W audytach aplikacji i EDR uwzględnij scenariusze DLL side-loading (MITRE: DLL Sideloading), szczególnie przy binarkach uruchamianych z katalogów, gdzie atakujący może dopisać pliki.

6) Wykorzystaj sygnatury i coverage od dostawców

Talos podaje konkretne elementy coverage (m.in. zakresy reguł Snort oraz sygnaturę ClamAV dla VoidLink). Jeśli korzystasz z tych technologii lub integracji Cisco, to szybki „health check” pokrycia ma sens.

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

W porównaniu do klasycznych frameworków C2 używanych powszechnie w kampaniach (np. „rodziny” podejścia Cobalt-Strike-like), VoidLink wyróżnia się kilkoma rzeczami:

  • Linux-first i cloud-first zamiast „Windows jako domyślny target”.
  • Kompilacja pluginów na żądanie (bardziej dynamiczny dobór funkcji pod ofiarę).
  • RBAC + audytowalność, co wygląda jak projektowanie z myślą o „nadzorze” i procesie.
  • Głębokie mechanizmy stealth (kernel/eBPF/LKM/LD_PRELOAD) oraz adaptacja do narzędzi obronnych.

Podsumowanie / kluczowe wnioski

UAT-9921 to nowo nazwany klaster, który — według Talos — używa VoidLink jako platformy post-exploitation do ukrywania się, skanowania i poruszania po sieciach ofiar, zwłaszcza w kontekście Linuksa i środowisk chmurowych.

VoidLink jest istotny nie tylko przez „feature listę”, ale przez kierunek: cloud-native, modularnie rozbudowywany implant z elementami kernel-stealth i automatyzacją wytwarzania, który może skracać czas od kompromitacji do skutecznego ruchu bocznego i eksfiltracji.

Źródła / bibliografia

  1. Cisco Talos: New threat actor, UAT-9921, leverages VoidLink framework in campaigns (Cisco Talos Blog)
  2. Check Point Research: VoidLink – The Cloud-Native Malware Framework (Check Point Research)
  3. Ontinue: VoidLink: Dissecting an AI-Generated C2 Implant (Ontinue)
  4. MITRE ATT&CK: Hijack Execution Flow: DLL (DLL Sideloading) (attack.mitre.org)
  5. The Hacker News: UAT-9921 Deploys VoidLink Malware to Target Technology and Financial Sectors (The Hacker News)

Google: Chiny, Iran, Rosja i Korea Płn. nasilają skoordynowane operacje przeciw sektorowi zbrojeniowemu (DIB)

Wprowadzenie do problemu / definicja luki

Google Threat Intelligence Group (GTIG) opisuje obecną presję na Defense Industrial Base (DIB) jako stały, wielowektorowy „nacisk” obejmujący jednocześnie szpiegostwo państwowe, elementy sabotażu/hacktivizmu oraz cyberprzestępczość (np. wymuszenia). Kluczowe jest to, że atak nie musi zaczynać się od klasycznego włamania do sieci firmy: coraz częściej zaczyna się od człowieka (pracownika, kandydata do pracy, podwykonawcy) albo od słabo monitorowanych urządzeń brzegowych (VPN, firewalle, koncentratory), które omijają widoczność EDR.

W skrócie

  • GTIG wskazuje cztery dominujące motywy: (1) uderzenia w podmioty wdrażające technologie na polu walki (szczególnie kontekst wojny Rosja–Ukraina), (2) ataki „direct-to-person” oraz nadużycia procesu rekrutacji (m.in. Korea Płn. i Iran), (3) rosnącą rolę edge devices jako punktu wejścia (szczególnie aktorzy powiązani z Chinami), (4) ryzyko łańcucha dostaw wynikające z naruszeń w sektorze wytwórczym.
  • W praktyce oznacza to przesunięcie z „atakujemy firmę” na „atakujemy ludzi + perymetr + dostawców”, często poza klasyczną telemetrią SOC.
  • Równolegle Google opisuje rosnące wykorzystanie narzędzi genAI (np. Gemini) do OSINT, tworzenia person i dopracowania socjotechniki.

Kontekst / historia / powiązania

Raport GTIG „Beyond the Battlefield” (10 lutego 2026) został opublikowany tuż przed Monachijską Konferencją Bezpieczeństwa (MSC 2026) i podkreśla, że w nowoczesnych konfliktach „front” rozciąga się na serwery oraz łańcuchy dostaw firm rozwijających technologie obronne.

Co istotne, Google wiąże aktywność z wieloma klastrami/grupami APT (w zależności od kraju i celu): od kampanii nastawionych na wsparcie działań w Ukrainie (np. próby pozyskiwania danych z komunikatorów czy ataki na jednostki dronowe), po operacje długoterminowego pozyskania dostępu i kradzieży R&D.

Analiza techniczna / szczegóły luki

GTIG opisuje kilka powtarzających się „ścieżek” wejścia do organizacji DIB. Najważniejsze technicznie wzorce:

1) Ataki na ludzi i proces zatrudnienia (persona, phishing, „job lures”)

  • Korea Płn.: kampanie podszywające się pod rekruterów oraz scenariusze „Dream Job” mają nakłonić ofiary do uruchomienia złośliwych plików lub oddania poświadczeń; w raporcie podkreślono też profilowanie ofiar i dopasowanie przynęt do roli/kompetencji.
  • Iran: wykorzystywanie fałszywych portali rekrutacyjnych, ofert pracy i narzędzi typu resume-builder/personality test jako nośników malware oraz do kradzieży danych uwierzytelniających; GTIG opisuje także pivotowanie przez zaufanych dostawców i legalne kanały zdalnego dostępu (np. Citrix/VMware).

2) „Edge-first”: urządzenia brzegowe i luki 0-day zamiast stacji roboczych

W przypadku aktorów powiązanych z Chinami Google podkreśla strategię wejścia przez perymetr: VPN-y, firewalle, routery/switche i inne appliance’y, które często:

  • nie są objęte EDR,
  • mają opóźnione patchowanie,
  • zapewniają „cichy” przyczółek do długiego utrzymania dostępu.

GTIG ocenia z wysoką pewnością, że od 2020 r. chińskie grupy wykorzystywały ponad dwa tuziny 0-day w urządzeniach brzegowych u wielu producentów, a także stosowały metody utrudniające atrybucję (np. ORB/relay).

3) Ataki kontekstowe „z pola walki” i na komunikatory

Wątek rosyjski w raporcie i omówieniach medialnych kładzie nacisk na ataki wspierające działania w Ukrainie: przejmowanie urządzeń, próby pozyskania treści z komunikatorów, kampanie pod tematyką systemów pola walki oraz operacje wymierzone w jednostki dronowe.

4) Łańcuch dostaw i „efekt uboczny” naruszeń w produkcji

Nawet jeśli docelowe firmy obronne są dobrze zabezpieczone, wąskim gardłem pozostają dostawcy (komponenty dual-use, logistyka, produkcja). GTIG wskazuje, że naruszenia i wymuszenia w szeroko rozumianym przemyśle wytwórczym mogą przełożyć się na realne ryzyko dla zdolności wytwarzania/utrzymania sprzętu w warunkach kryzysu.

Praktyczne konsekwencje / ryzyko

  1. Utrata IP i przewagi technologicznej: kampanie „R&D theft” (zwłaszcza długotrwałe, edge-first) są ryzykiem strategicznym, nie tylko incydentem IT.
  2. Naruszenia tożsamości i przejęcia kont: gdy celem jest pracownik (często na prywatnym urządzeniu lub e-mailu), organizacja traci kontrolę nad telemetrią i czasem reakcji.
  3. Kompromitacja procesu rekrutacji: HR i zewnętrzne platformy rekrutacyjne stają się „systemem krytycznym” – bo to tam zaczyna się infekcja.
  4. Ryzyko operacyjne łańcucha dostaw: ataki na mniejszych dostawców (czasem nawet „spoza” ścisłej zbrojeniówki) mogą wpływać na dostępność komponentów i realizację kontraktów.
  5. Przyspieszenie socjotechniki dzięki AI: generatywna AI skraca czas od rozpoznania do personalizowanej przynęty i zwiększa skalę „dobrze brzmiących” scenariuszy phishingowych.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które realnie adresują opisane przez GTIG wzorce (ludzie + perymetr + dostawcy):

1) Uodpornij rekrutację i HR (to nowa „strefa DMZ”)

  • Wprowadź oddzielne środowisko do analizy CV/załączników (sandbox, CDR), blokuj makra i nietypowe formaty.
  • Zabezpiecz kanały kontaktu kandydata: SPF/DKIM/DMARC, monitoring domen podobnych (typosquatting), jasne procedury weryfikacji rekruterów.
  • Ustal „zero trust” dla narzędzi rekrutacyjnych i testów (assessment, personality tests) – dopuszczaj tylko zatwierdzone platformy.

2) Priorytet: urządzenia brzegowe i ich widoczność

  • Zrób pełny asset inventory edge (VPN, FW, proxy, WAF, load balancery, IAM gateways) + właścicieli + SLA patchingu.
  • Wymuś szybkie łatanie krytycznych CVE, ogranicz dostęp administracyjny, włącz centralne logowanie (syslog/NetFlow) i korelację.
  • Traktuj urządzenia brzegowe jako „high-value targets” – segmentacja, zasada minimalnych uprawnień, regularne huntowanie na anomaliach.

3) Ochrona pracowników poza siecią firmową

  • Polityka dla kont prywatnych używanych do pracy: phishing-resistant MFA (np. FIDO2), menedżer haseł, minimalizacja przekierowań na prywatne e-maile.
  • Program „high-risk users” (inżynierowie R&D, admini, osoby w projektach Ukrainy/MSC/kontraktach obronnych): dodatkowe zabezpieczenia i monitoring.

4) Dostawcy i łańcuch dostaw

  • Wymuś wymagania bezpieczeństwa dla dostawców (MFA, patching, log retention, minimalne standardy IR) oraz przeglądy uprzywilejowanych integracji.
  • Wykrywaj pivotowanie: monitoring kont serwisowych, zdalnych dostępów (Citrix/VDI/VPN), nietypowych godzin i geolokalizacji.

5) Aktualizacja playbooków SOC/IR pod „evasion of detection”

  • Poluj na techniki, które omijają EDR (perymetr, konta, urządzenia mobilne).
  • Ćwicz scenariusze: przejęcie konta rekrutera/HR, kompromitacja VPN, kampania spearphishing na prywatne skrzynki.

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

  • „Klasyczny” APT vs DIB 2026: wcześniej dominowały włamania do sieci firm. Teraz GTIG mocno akcentuje atak na człowieka i procesy biznesowe (rekrutacja) oraz wejście przez edge zamiast endpointów.
  • Espionage vs extortion: raport wskazuje współistnienie motywacji państwowych i finansowych. Dla DIB to trudne, bo skutki wymuszeń na „pobocznych” dostawcach mogą uderzać w ciągłość dostaw nawet bez bezpośredniego ataku na wykonawcę obronnego.
  • AI jako „force multiplier”: z relacji GTIG wynika, że Gemini bywa używane do OSINT, person i wsparcia technicznego, ale nie (jeszcze) do pełnej automatyzacji ataków end-to-end — jednak przyspiesza przygotowanie i jakość socjotechniki.

Podsumowanie / kluczowe wnioski

Najważniejszy sygnał z ustaleń Google jest prosty: DIB przestaje być atakowany „wyłącznie jako sieć”. Jest atakowany jako ekosystem ludzi, procesów, urządzeń perymetru i dostawców. Dlatego program bezpieczeństwa, który skupia się tylko na stacjach roboczych i serwerach, będzie regularnie spóźniony.

Jeżeli masz ograniczony budżet na „next steps”, zacznij od: (1) uszczelnienia rekrutacji i obsługi załączników, (2) pełnej kontroli patchingu i logowania na edge, (3) ochrony kont i urządzeń osób wysokiego ryzyka, (4) wzmocnienia wymagań wobec dostawców.

Źródła / bibliografia

  1. Google Threat Intelligence Group (GTIG), “Beyond the Battlefield: Threats to the Defense Industrial Base” (10 lutego 2026). (Google Cloud)
  2. The Hacker News, “Google Links China, Iran, Russia, North Korea to Coordinated Defense Sector Cyber Operations” (13 lutego 2026). (The Hacker News)
  3. The Guardian, “State-sponsored hackers targeting defence sector employees, Google says” (10 lutego 2026). (The Guardian)
  4. The Record (Recorded Future News), “Nation-state hackers ramping up use of Gemini…” (12 lutego 2026). (The Record from Recorded Future)
  5. CyberScoop, “Google finds state-sponsored hackers use AI…” (12 lutego 2026). (CyberScoop)

Google łączy rosyjsko-powiązanego aktora z kampaniami CANFAIL przeciw Ukrainie. W tle: phishing, JavaScript (*.pdf.js) i „LLM-generated lures”

Wprowadzenie do problemu / definicja luki

W połowie lutego 2026 r. Google Threat Intelligence Group (GTIG) opisało wcześniej nieudokumentowanego aktora zagrożeń, którego działania wiąże z kampaniami wymierzonymi w ukraińskie organizacje i dystrybucją malware’u nazwanego CANFAIL. To istotne z dwóch powodów:

  1. Sektorowe ukierunkowanie – cele obejmują obszary krytyczne dla państwa (obrona, administracja, energetyka).
  2. Ewolucja TTP – GTIG zauważa, że aktor zaczął wykorzystywać LLM do rozpoznania, tworzenia przynęt socjotechnicznych i wsparcia działań po kompromitacji.

W praktyce oznacza to bardziej „skalowalny” phishing (lepsza jakość treści, dopasowanie do branży/regionu) nawet u grup, które nie mają zasobów porównywalnych z topowymi rosyjskimi APT.

W skrócie

  • GTIG przypisuje kampanie z CANFAIL nowemu aktorowi, prawdopodobnie powiązanemu z rosyjskimi służbami.
  • Główne cele: obrona, wojsko, administracja, energetyka w Ukrainie; dodatkowo rosnące zainteresowanie aerospace, firmami powiązanymi z dronami, badaniami nuklearnymi/chemicznymi oraz organizacjami humanitarnymi i monitorującymi konflikt.
  • Wektor: phishing podszywający się m.in. pod ukraińskie podmioty energetyczne; w kampanii pojawiają się linki do Google Drive z archiwum RAR zawierającym CANFAIL.
  • Plik jest maskowany jako PDF poprzez podwójne rozszerzenie typu *.pdf.js.
  • CANFAIL to zaciemniony JavaScript, uruchamiający łańcuch z PowerShell, w tym etap pobierający i wykonujący dropper „memory-only”.
  • GTIG łączy aktora również z kampanią PhantomCaptcha, opisaną w 2025 r. przez SentinelLabs, wykorzystującą technikę ClickFix i końcowy ładunek w postaci WebSocket RAT.

Kontekst / historia / powiązania

GTIG umieszcza tę aktywność w szerszym krajobrazie zagrożeń wobec defense industrial base (DIB) – gdzie obserwuje się zarówno klasyczne włamania w infrastrukturę organizacji, jak i coraz częstsze ataki „na ludzi” (pracowników, procesy rekrutacyjne, prywatne skrzynki), co utrudnia detekcję po stronie EDR/korporacyjnego SOC.

Wątek PhantomCaptcha jest tu szczególnie ważny, bo pokazuje, że (1) celowanie w ekosystem wsparcia Ukrainy i (2) social engineering „na klik” potrafią być bardzo dopracowane operacyjnie – SentinelLabs opisywało kampanię aktywną zaledwie jeden dzień, ale przygotowywaną miesiącami.

Analiza techniczna / szczegóły

1. Initial access: phishing + dopasowane listy adresowe

GTIG wskazuje na kampanie phishingowe, w których aktor:

  • podszywa się pod krajowe i lokalne organizacje energetyczne w Ukrainie w celu przejęcia skrzynek (organizacyjnych i prywatnych),
  • potrafi też udawać rumuńską firmę energetyczną współpracującą z klientami w Ukrainie, a wątek operacyjny dotyka także Rumunii i rozpoznania w Mołdawii.
  • buduje listy adresowe dopasowane do regionów i branż, co zwiększa trafność i wiarygodność kampanii.

2. Przynęty generowane przez LLM

Najbardziej „nowoczesnym” elementem jest to, że GTIG zauważa użycie LLM do:

  • rozpoznania i profilowania celów,
  • tworzenia treści przynęt (lures),
  • uzyskiwania odpowiedzi na podstawowe pytania techniczne dot. działań po kompromitacji oraz budowy C2.

To nie musi oznaczać „AI-malware”, ale w praktyce znacząco podnosi jakość socjotechniki i skraca czas przygotowania kampanii.

3. Delivery: Google Drive → RAR → *.pdf.js

W łańcuchu dostarczenia pojawia się:

  • link do Google Drive,
  • archiwum RAR,
  • plik udający dokument PDF dzięki podwójnemu rozszerzeniu *.pdf.js.

To klasyczny trik na zmylenie użytkownika (i czasem pobieżnej kontroli), bo ikona/„nazwa” sugerują PDF, a faktycznie uruchamiany jest skrypt.

4. CANFAIL: zaciemniony JavaScript → PowerShell → dropper w pamięci

GTIG opisuje CANFAIL jako:

  • obfuscated JavaScript malware,
  • którego rolą jest uruchomienie PowerShell,
  • a dalej pobranie i wykonanie memory-only PowerShell droppera (czyli bez klasycznego zapisu „payloadu” na dysk),
  • równolegle z wyświetleniem fałszywego komunikatu „error”, który ma obniżyć czujność ofiary.

Dlaczego to groźne? Etapy „memory-only” utrudniają analizę artefaktów na dysku i mogą ograniczać widoczność dla części narzędzi, jeśli telemetryka PowerShell/AMSI/logowanie jest słabe lub wyłączone.

5. Powiązanie z PhantomCaptcha (ClickFix + WebSocket RAT)

GTIG łączy aktora także z kampanią PhantomCaptcha, w której:

  • użytkownik jest wciągany w „instrukcję” typu ClickFix (np. skopiuj/uruchom komendę PowerShell),
  • a finalny payload to WebSocket RAT umożliwiający zdalne polecenia i eksfiltrację danych.

To ciekawe zestawienie: CANFAIL to „klasyczne” dostarczenie przez archiwum i plik-przynętę, a PhantomCaptcha to bardziej interaktywny social engineering, ale cel (kompromitacja) i profil ofiar pozostają spójne.

Praktyczne konsekwencje / ryzyko

  1. Wzrost skuteczności phishingu dzięki LLM: lepsza polszczyzna/angielski, formalny styl, dopasowanie do procedur instytucji, szybsze tworzenie wariantów.
  2. Ryzyko przejęcia skrzynek e-mail (organizacyjnych i prywatnych) jako punktu startowego do dalszych ataków (BEC, lateral movement, podszycia w korespondencji).
  3. Trudniejsza detekcja etapów „in-memory” i nadużyć PowerShell, zwłaszcza w środowiskach z ograniczonym logowaniem.
  4. Szeroki profil celów (od energetyki po organizacje humanitarne) zwiększa prawdopodobieństwo, że skutki będą „łańcuchowe” – kompromitacja jednego partnera potrafi otworzyć drogę do kolejnych.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które mają sens niezależnie od tego, czy jesteś bezpośrednim celem (Ukraina), czy partnerem/kontrahentem w regionie:

E-mail i przeglądanie plików

  • Blokuj lub oznaczaj pliki z podwójnymi rozszerzeniami oraz nietypowymi kombinacjami typu *.pdf.js; rozważ reguły w bramkach e-mail.
  • Ogranicz uruchamianie skryptów z archiwów (RAR/ZIP) i wdrażaj polityki „Mark of the Web”/ASR tam, gdzie to możliwe.

Telemetria i detekcja

  • Włącz/utwardź logowanie PowerShell (Script Block Logging, Module Logging) oraz integrację AMSI – to realnie zwiększa szanse wykrycia łańcuchów JS→PS.
  • Szukaj korelacji: procesy skryptowe + pobrania z chmur plikowych (np. dyski online) + nietypowe komunikaty „error” w tym samym czasie.

Kontrola tożsamości

  • Wymuś MFA na poczcie oraz rozważ odporne metody (FIDO2/WebAuthn) dla kont uprzywilejowanych.
  • Monitoruj anomalie logowania, reguły przekierowań w skrzynkach, OAuth consent i aplikacje pocztowe.

Odporność na ClickFix

  • Przeszkol użytkowników, że „CAPTCHA/strona ochrony” nigdy nie powinna wymagać uruchamiania komend w PowerShell/Terminalu. PhantomCaptcha pokazała, że to działa, gdy jest dobrze opakowane.

Różnice / porównania z innymi przypadkami

CANFAIL vs PhantomCaptcha/ClickFix:

  • Wektor:
    • CANFAIL: archiwum RAR + plik *.pdf.js (podszycie pod dokument).
    • PhantomCaptcha: przynęta prowadzi do „instrukcji” uruchomienia komendy (ClickFix) i końcowo RAT.
  • Wspólny mianownik:
    • dominacja socjotechniki i korzystanie z „zaufanych” elementów (np. usługi chmurowe, wiarygodne szablony, formalny język),
    • profil ofiar związany z Ukrainą i jej ekosystemem wsparcia/obrony.
  • Trend:
    • przesunięcie akcentu w stronę działań, które omijają klasyczną widoczność enterprise (prywatne konta, indywidualne cele, procesy HR).

Podsumowanie / kluczowe wnioski

CANFAIL to kolejny przykład tego, że nawet aktor oceniany jako „mniej zaawansowany” może szybko zwiększać skuteczność dzięki LLM: lepsze rozpoznanie, lepsze treści phishingowe, szybsze iteracje kampanii.
Technicznie łańcuch jest pragmatyczny: RAR → *.pdf.js → JS → PowerShell → memory-only dropper, a w tle podobna filozofia „user-execution” jak w ClickFix.
Dla obrońców oznacza to konieczność połączenia: (1) higieny pocztowej i świadomości użytkowników, (2) solidnej telemetrii PowerShell, (3) twardej kontroli tożsamości.

Źródła / bibliografia

  • The Hacker News: opis aktora i łańcucha CANFAIL (13 lutego 2026). (The Hacker News)
  • Google Cloud Blog (GTIG): „Beyond the Battlefield: Threats to the Defense Industrial Base” (10 lutego 2026). (Google Cloud)
  • SentinelOne SentinelLabs: raport „PhantomCaptcha: Multi-Stage WebSocket RAT…” (22 października 2025). (SentinelOne)
  • BleepingComputer: omówienie PhantomCaptcha/ClickFix (22 października 2025). (BleepingComputer)
  • The Record: tło operacyjne i cele PhantomCaptcha (22 października 2025). (The Record from Recorded Future)

Claude „Artifacts” nadużywane do dystrybucji macOS infostealerów w ataku ClickFix

Wprowadzenie do problemu / definicja luki

Atakujący zaczęli wykorzystywać publicznie udostępniane „Artifacts” w Claude (Anthropic) jako element łańcucha infekcji w kampaniach ClickFix, kierując ofiary (macOS) do uruchomienia poleceń w Terminalu. To nie jest „luka” typu CVE w samym Claude, tylko nadużycie funkcji publikowania treści i wysokiej wiarygodności, jaką użytkownicy przypisują materiałom „wyglądającym na wygenerowane przez AI / poradnik”.

W skrócie

  • Kampania jest promowana m.in. przez reklamy Google i pozycjonowanie pod konkretne zapytania (np. narzędzia sieciowe lub macOS CLI).
  • Użytkownik trafia na publiczny Artifact Claude lub stronę podszywającą się pod Apple Support (np. artykuł na platformie blogowej), gdzie dostaje instrukcję wklejenia komendy do Terminala.
  • Wykonanie polecenia pobiera i uruchamia loader, który finalnie instaluje infostealera (w opisywanym przypadku: MacSync).
  • Skala: badacze raportują dziesiątki tysięcy wyświetleń złośliwych instrukcji (wskaźnik ekspozycji, niekoniecznie liczba skutecznych infekcji).

Kontekst / historia / powiązania

ClickFix to technika socjotechniczna, w której kluczowym „bypassem” jest wciągnięcie użytkownika w wykonanie komendy samodzielnie (np. Run/PowerShell na Windows albo Terminal na macOS). Z perspektywy obrony to istotne, bo część kontroli bezpieczeństwa widzi aktywność jako inicjowaną przez użytkownika, a nie klasyczny dropper.

W 2025–2026 obserwowano rozwój ClickFix w różnych wariantach: od prostych fałszywych CAPTCHA po bardziej wyrafinowane łańcuchy, np. z użyciem zaufanych komponentów systemu (LotL) na Windows.
Jednocześnie ekosystem macOS infostealerów rośnie — popularne rodziny (Atomic/AMOS, Poseidon, Cthulhu) są często dystrybuowane przez malvertising i „trojanizowane instalatory”, co dobrze pasuje do mechaniki ClickFix (reklama → landing → instrukcja → uruchomienie).

Analiza techniczna / szczegóły ataku

1) Wejście: reklamy i SEO pod „techniczne” zapytania

Badacze opisali scenariusz, w którym użytkownik szuka narzędzi lub porad dla macOS (np. resolver DNS, analizator miejsca na dysku, Homebrew), a w wynikach pojawia się promowany link prowadzący do:

  • publicznego Artifact Claude, albo
  • strony udającej wsparcie Apple.

2) Rdzeń ClickFix: komenda „naprawcza”

W obu wariantach użytkownik jest zachęcany do uruchomienia w Terminalu polecenia, którego efekt jest typowy dla downloaderów:

  • dekodowanie zakodowanej treści i wykonanie w powłoce (np. schemat „base64 → shell”), lub
  • pobranie treści przez narzędzie sieciowe i bezpośrednie przekazanie do interpretera (np. „curl → shell”).

Nie przytaczam pełnych komend 1:1, bo są to instrukcje wykonawcze dla złośliwego łańcucha — ale ważne jest, że oba wzorce są klasycznymi „red flagami” w środowiskach macOS/Unix.

3) Payload: MacSync infostealer i AppleScript jako „silnik kradzieży”

Po uruchomieniu, łańcuch pobiera loader dla MacSync. Według opisu kampanii:

  • komunikacja z C2 ma być realizowana z użyciem osadzonych tokenów/kluczy oraz z podszywaniem się user-agentem przeglądarki,
  • a właściwe kradzieże danych mają być realizowane przez osascript (AppleScript), obejmując m.in. keychain, dane przeglądarek i portfele krypto,
  • dane są pakowane do archiwum w /tmp/…zip, a następnie wysyłane do C2 metodą HTTP POST, z mechanizmem retry i „sprzątaniem” po udanej eksfiltracji.

4) Wspólna infrastruktura

Badacze wskazują, że oba warianty pobierają drugi etap z tego samego adresu C2, co sugeruje jednego operatora/kampanię (lub przynajmniej współdzieloną infrastrukturę).

Praktyczne konsekwencje / ryzyko

  1. Ryzyko kradzieży tożsamości i przejęć kont – infostealery celują w hasła/cookies/sesje przeglądarkowe, dane w pęku kluczy, komunikatory i portfele.
  2. Ryzyko wtórnej eskalacji – skradzione sesje (SSO/VPN), tokeny i klucze API często stają się wejściem do sieci firmowej lub chmury. (To wprost wynika z typowych następstw incydentów infostealerowych; sama kampania opisuje komponent C2 i eksfiltrację danych).
  3. Nowy „wektor wiarygodności” – publiczne treści hostowane na rozpoznawalnej domenie usługi AI mogą wyglądać „bezpieczniej” niż przypadkowy landing, a jednocześnie zawierają gotowe instrukcje do samodzielnego uruchomienia.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i helpdesku (macOS)

  • Zasada zero-trustu dla komend: nie uruchamiaj w Terminalu poleceń z reklamy/wyników wyszukiwania/poradnika, jeśli nie rozumiesz dokładnie każdego fragmentu (zwłaszcza wzorców „pobierz i wykonaj”, „base64 → shell”).
  • Weryfikuj źródło narzędzi: Homebrew i narzędzia systemowe pobieraj z oficjalnych stron/projektów, nie z „poradników” z reklam.
  • W razie podejrzenia wykonania komendy: odłącz urządzenie od sieci, zabezpiecz logi (Unified Logs), sprawdź nietypowe procesy/uruchomienia osascript, przeanalizuj ruch wychodzący i rozważ reset tokenów/sesji oraz zmianę haseł na czystym urządzeniu.

Dla SOC/Blue Team

  • Detekcja zachowań: reguły/alerty na nietypowe uruchomienia osascript w kontekście pobierania treści z sieci i dostępu do artefaktów przeglądarek/keychain.
  • Kontrola egress: monitorowanie POST/egress do świeżych domen, korelacja z procesami powłoki i osascript.
  • Higiena reklam i wyszukiwania: w środowiskach firmowych ogranicz/filtruj malvertising, rozważ polityki przeglądarkowe i DNS security. (To spójne z obserwacją, że kampania startuje z wyników Google i reklam).

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

  • ClickFix na Windows vs macOS: na Windows coraz częściej pojawiają się warianty „living-off-the-land”, gdzie wykonanie jest proxy’owane przez zaufany komponent (np. skrypty/komponenty Microsoft), aby ominąć proste detekcje „PowerShell.exe”. Na macOS nacisk bywa kładziony na shell + AppleScript (osascript) jako warstwę kradzieży.
  • Rola malvertising: Unit 42 zwraca uwagę, że macOS infostealery są często dystrybuowane przez reklamy i fałszywe instalatory — tutaj malvertising jest połączony z „poradnikiem” w Artifact, co zwiększa perswazyjność.
  • „Hosted trust”: to kolejny przykład, że atakujący testują różne platformy (AI, blogi, serwisy udostępniania treści) jako „nośniki” instrukcji ClickFix, bo łatwo skalują zasięg i utrudniają blokowanie.

Podsumowanie / kluczowe wnioski

  • To kampania ClickFix, w której „payloadem” jest instrukcja — a nie exploit: użytkownik sam uruchamia łańcuch w Terminalu.
  • „Claude Artifacts” działają tu jako wiarygodnie wyglądający hosting treści (publiczny link na domenie usługi AI), wzmacniany przez reklamy i SEO.
  • Na macOS w centrum technicznym stoi kombinacja shell → pobranie loadera → osascript do kradzieży danych i eksfiltracji do C2.
  • Obrona powinna łączyć edukację (nie uruchamiaj niezweryfikowanych komend), kontrolę reklam/wyszukiwania oraz detekcję zachowań osascript/shell + egress.

Źródła / bibliografia

  1. BleepingComputer — opis kampanii: Claude Artifacts + Google Ads → ClickFix → MacSync infostealer (13 lutego 2026). (BleepingComputer)
  2. Microsoft Security Blog — analiza techniki ClickFix i jej łańcucha ataku (21 sierpnia 2025). (Microsoft)
  3. Unit 42 (Palo Alto Networks) — przegląd rosnącego zagrożenia macOS infostealerami i typowych TTP (4 lutego 2025). (Unit 42)
  4. InfoQ — kontekst funkcji Claude Artifacts i ich roli jako przestrzeni do udostępniania/organizacji „wytworów” AI (30 czerwca 2025). (InfoQ)
  5. The Hacker News — przykład ewolucji ClickFix (fałszywe CAPTCHA + zaufane komponenty Windows/App-V) (27 stycznia 2026). (The Hacker News)