Archiwa: LLM - Strona 5 z 9 - Security Bez Tabu

Google: hakerzy nadużywają Gemini na każdym etapie ataku — od rekonesansu po eksfiltrację danych

Wprowadzenie do problemu / definicja luki

Google Threat Intelligence Group (GTIG) ostrzega, że państwowe grupy APT oraz cyberprzestępcy wykorzystują Gemini (zarówno jako aplikację, jak i przez API) do „podkręcania” praktycznie całego łańcucha ataku: od OSINT i profilowania celu, przez generowanie przynęt phishingowych, aż po development C2 i wsparcie eksfiltracji. To nie jest jedna „luka” w rozumieniu CVE — to systemowe ryzyko nadużycia generatywnej AI jako akceleratora TTP (tactics, techniques, procedures).


W skrócie

  • GTIG opisuje, że Gemini jest nadużywane w każdej fazie kampanii (rekonesans → phishing → kodowanie/narzędzia → C2 → działania post-compromise → eksfiltracja).
  • Wskazano przykłady użycia przez aktorów z Chin, Iranu, Korei Płn. i Rosji (m.in. APT31, APT42, UNC2970).
  • Obok „klasycznych” zastosowań (tłumaczenia, research, troubleshooting) rośnie zainteresowanie agentic AI (bardziej autonomiczne przepływy pracy) w kontekście ofensywnym.
  • Google sygnalizuje też wzrost ataków typu model extraction / knowledge distillation: masowe odpytywanie modeli w celu „skopiowania” ich zachowań i przeniesienia know-how do innych modeli (ryzyko głównie biznesowe/IP, ale potencjalnie wpływowe systemowo).

Kontekst / historia / powiązania

GTIG od co najmniej 2025 r. publikuje cykliczne materiały o nadużyciach GenAI. W styczniu 2025 Google wskazywał, że AI pomaga aktorom głównie w zadaniach „produktywnościowych” (research, generowanie treści, pomoc w skryptach), ale nie widać „game-changera” w postaci zupełnie nowych technik.

Jesienią 2025 narracja przesunęła się w stronę operacyjnej integracji AI z toolingiem, w tym koncepcji „just-in-time AI w malware” (LLM wykorzystywany w trakcie działania złośliwego kodu do generowania/transformacji elementów w locie).

Dzisiejsza aktualizacja (12 lutego 2026) wzmacnia tezę, że jesteśmy w fazie „integracji i eksperymentowania”: AI ma być nie tylko asystentem analityka/przestępcy, ale komponentem procesów i narzędzi.


Analiza techniczna / szczegóły luki

1) „Pełny kill chain” wspierany przez Gemini

Z perspektywy obrony ważne jest to, że GTIG nie opisuje jednego scenariusza nadużycia, tylko powtarzalny wzorzec:

  • Rekonesans i profilowanie (OSINT): zbieranie danych o organizacji, rolach, technologii, podatnościach, identyfikacja „soft targets”.
  • Phishing i social engineering: generowanie dopasowanych przynęt, dopracowywanie narracji, wariantów językowych i stylu.
  • Tooling i kodowanie: debugowanie, generowanie fragmentów kodu, przygotowanie prostych komponentów (np. skrypty, webshell, elementy C2) oraz „pomoc techniczna” w trakcie prac.
  • Vulnerability research / testowanie: w raporcie pojawia się przykład aktora z Chin, który miał prosić model o analizę podatności i plan testów (np. RCE/WAF bypass/SQLi) w kontekście spreparowanego scenariusza.
  • Post-compromise / eksfiltracja: wsparcie w działaniach po uzyskaniu dostępu, w tym elementy związane z wynoszeniem danych.

2) Przykłady nadużyć i „AI w malware”

BleepingComputer, streszczając wnioski Google, wskazuje m.in. na:

  • wykorzystywanie Gemini do rozbudowy funkcji w narzędziach/malware (np. elementy związane z phishing kitami czy downloaderami),
  • wzmiankę o frameworku PoC, który używa Gemini API do generowania kodu drugiego etapu (istotne jako sygnał kierunku, nawet jeśli to jeszcze nie „masowa broń”).

3) Model extraction i knowledge distillation

Drugi wątek, który warto wyciągnąć na pierwszy plan (bo bywa pomijany w dyskusji o „AI dla hakerów”), to kradzież własności intelektualnej modeli:

  • poprzez legalny (na papierze) dostęp do API i masowe odpytywanie modelu,
  • z celem odtworzenia zachowania/zdolności i „przeniesienia” tego do innego modelu (distillation).

To może uderzać w biznes AI-as-a-service, ale długofalowo może też zwiększać dostępność „dobrych” zdolności w modelach mniej kontrolowanych.


Praktyczne konsekwencje / ryzyko

  1. Szybsze kampanie i większa skala „tailored” ataków
    Jeśli rekonesans, copywriting phishingu i iteracje narzędzi trwają krócej, rośnie wolumen prób i jakość socjotechniki — zwłaszcza w językach lokalnych.
  2. Niższy próg wejścia dla części przestępców, ale też lepsza „ergonomia” pracy APT
    Raporty GTIG sugerują, że nawet jeśli AI nie tworzy „magicznych” nowych technik, to realnie poprawia efektywność operacyjną.
  3. Ryzyko reputacyjne i regulacyjne związane z użyciem GenAI w organizacji
    W praktyce zespoły IT/SecOps mogą mieć do czynienia z: wrażliwymi danymi w promptach, problemami licencyjnymi/IP, oraz koniecznością monitorowania użycia narzędzi AI.
  4. Nowa klasa zagrożeń dla dostawców modeli (ekstrakcja/dystylacja)
    To ryzyko „platformowe” — może wpływać na to, jak szybko i gdzie pojawiają się modele o zbliżonych zdolnościach, ale słabszych barierach bezpieczeństwa.

Rekomendacje operacyjne / co zrobić teraz

Dla SOC / Blue Team

  • Zaktualizuj playbooki phishingowe o scenariusze „hiper-dopasowanych” przynęt (język, styl, kontekst stanowiska) i wzmocnij procesy weryfikacji poza e-mailem (np. callback, zasady dla zmian płatności/danych).
  • Monitoruj wzorce ClickFix / „uruchom polecenie z instrukcji” i inne kampanie oparte o nakłanianie użytkownika do wykonania kroków w systemie (to trend, który napędza też content generowany przez AI).
  • Wzmocnij detekcje wokół etapów: initial access → execution → C2 → exfil (AI przyspiesza przygotowanie, ale w środowisku nadal zostają artefakty).

Dla bezpieczeństwa aplikacji i DevSecOps

  • Załóż, że przeciwnik szybciej iteruje payloady i skrypty: zwiększ nacisk na hardening, kontrolę egress, segmentację i polityki uprawnień.
  • Traktuj „prompt injection” i ryzyka LLM w produktach jako osobną kategorię, ale nie zaniedbuj podstaw — raporty GTIG wciąż wskazują, że przeciwnicy często bazują na znanych technikach, tylko szybciej je wdrażają.

Dla governance (CISO / IT)

  • Wprowadź jasne zasady użycia GenAI: klasyfikacja danych, zakaz wklejania sekretów, logowanie i audyt użycia (zwłaszcza integracji przez API).
  • Oceń ryzyko vendorów i narzędzi „AI coding” pod kątem: wycieku IP, zależności, oraz ścieżek nadużyć.

Różnice / porównania z innymi przypadkami

  • Styczeń 2025: „AI pomaga, ale nie zmienia gry” — dużo researchu, treści i troubleshooting, mało dowodów na nowe techniki.
  • Listopad 2025 → luty 2026: rośnie sygnał integracji AI w narzędziach i w trakcie operacji (w tym zainteresowanie agentic AI) oraz tematy „platformowe” jak dystylacja/ekstrakcja modeli.

Podsumowanie / kluczowe wnioski

  • Gemini (i szerzej: GenAI) staje się uniwersalnym akceleratorem dla atakujących: szybciej robią OSINT, lepiej piszą przynęty, sprawniej iterują narzędzia i kod.
  • Największe ryzyko „tu i teraz” to skala i personalizacja socjotechniki oraz krótszy cykl przygotowania kampanii.
  • Równolegle rośnie wątek model extraction / distillation — nie tyle „atak na użytkownika”, co na ekosystem AI i ekonomię usług AI.
  • Obrona powinna łączyć: twarde podstawy (MFA, segmentacja, egress, monitoring) + procesy anty-phishing + governance użycia AI w organizacji.

Źródła / bibliografia

  1. BleepingComputer — „Google says hackers are abusing Gemini AI for all attacks stages” (12.02.2026). (BleepingComputer)
  2. Google Cloud Blog (GTIG) — „Distillation, Experimentation, and (Continued) Integration of AI for Adversarial Use” (12.02.2026). (Google Cloud)
  3. Google Cloud Blog (GTIG) — „Advances in Threat Actor Usage of AI Tools” (05.11.2025). (Google Cloud)
  4. Google Cloud Blog (GTIG) — „Adversarial Misuse of Generative AI” (29.01.2025). (Google Cloud)
  5. The Register — kontekst dot. APT31 i wątku dystylacji/agentic AI (12.02.2026). (The Register)

Od automatyzacji do infekcji: jak „skille” OpenClaw stały się nowym kanałem dystrybucji malware

Wprowadzenie do problemu / definicja luki

Rynek „agentów AI” działających lokalnie na komputerze rośnie, bo obiecuje realną automatyzację: wykonywanie komend w shellu, operacje na plikach, sieci, integracje z API. Problem zaczyna się w momencie, gdy te agenty rozszerzamy o zewnętrzne dodatki — „skille” — które w praktyce stają się łańcuchem dostaw (supply chain) dla atakujących.

VirusTotal opisuje, że ekosystem OpenClaw (wcześniej Clawdbot/Moltbot) — wraz z publicznym marketplace’em ClawHub — zaczął być wykorzystywany jako nowy kanał dostarczania malware, często w formie „instrukcji instalacji”, które nakłaniają użytkownika do pobrania i uruchomienia zewnętrznego kodu.


W skrócie

  • VirusTotal wykrył setki złośliwych skillów w ekosystemie OpenClaw; w momencie publikacji przeanalizowano ponad 3 016 pakietów skill, z czego „setki” miały cechy złośliwe.
  • Atak nie zawsze polega na tym, że ZIP „jest malware”. Często „malware jest workflow”: markdown (SKILL.md) prowadzi użytkownika do uruchomienia droppera/backdoora/stealera.
  • VT opisuje też bardziej zaawansowane techniki: m.in. Execution Hijacking (uruchomienie payloadu jeszcze zanim użytkownik wykona właściwe polecenie), „semantic worms”, trwałość przez modyfikację plików kontekstu agenta (SOUL.md/AGENTS.md) i inne.
  • Niezależny audyt Koi Security wskazał 341 złośliwych skillów na ClawHub (większość z jednej kampanii nazwanej ClawHavoc).

Kontekst / historia / powiązania

OpenClaw zdobył popularność jako „agent, który naprawdę coś robi” — działa lokalnie i może wykonywać akcje na urządzeniu użytkownika. W takich modelach prawdziwe ryzyko nie wynika wyłącznie z LLM i promptów, ale z faktu, że agent ma dostęp do powłoki systemowej, plików i sieci — a skille są w praktyce niezależnym oprogramowaniem stron trzecich, instalowanym często „na wiarę”.

Analogicznie do tego, co obserwowaliśmy w ekosystemach npm/PyPI czy w marketplace’ach rozszerzeń, ClawHub stał się atrakcyjny dla atakujących, bo:

  • jest szybki „time-to-victim” (użytkownicy instalują dodatki, by od razu działało),
  • jest duża tolerancja na „krok instalacyjny w terminalu”,
  • wiele skillów ma minimalną zawartość kodu, a najgroźniejsza część jest w instrukcjach.

Analiza techniczna / szczegóły luki

1) „Skille” jako opakowanie socjotechniczne (SKILL.md → uruchom to w terminalu)

VirusTotal opisuje skille jako pakiety oparte o SKILL.md (metadane i instrukcje), często z dodatkowymi skryptami/zasobami. Najczęstszy wzorzec nadużycia: pozornie legalny skill (np. „Yahoo Finance”) zawiera niewiele kodu i nie jest wykrywany jako malware przez klasyczne silniki, ale wymusza na użytkowniku pobranie i uruchomienie binarki/skryptu z zewnątrz.

W jednym z opisanych przypadków (konto „hightower6eu”) VT wskazał, że przeanalizował 314 skillów powiązanych z jednym wydawcą i wszystkie miały charakter złośliwy; instrukcje prowadziły do uruchamiania zewnętrznych payloadów na Windows i macOS.

2) Zmiana gry po stronie obrony: analiza „zachowania” skilla (Code Insight)

VirusTotal dodał natywne wsparcie w VT Code Insight dla paczek OpenClaw (również ZIP). Analiza ma być „security-first”: nie tyle „co skill obiecuje”, ale co faktycznie robi/wywołuje, np. pobieranie i uruchamianie kodu, dostęp do danych wrażliwych, operacje sieciowe, wymuszanie niebezpiecznych zachowań.

3) Execution Hijacking i reverse shell „przy podglądzie helpa”

W części II VirusTotal pokazuje technikę Execution Hijacking: trigger ukryty w funkcji (np. warmup()), która uruchamia się zanim parser argumentów przetworzy polecenie. Efekt: payload może wykonać się już wtedy, gdy agent tylko „ładuje skrypt”, np. żeby sprawdzić --help.

W opisanym przykładzie VT omawia przepływ prowadzący do komendy uruchamiającej reverse shell (mechanizm bash + /dev/tcp + nohup), czyli realne zdalne przejęcie interaktywnej powłoki.

4) „Semantic worm”: agent jako kanał propagacji

VT nazywa „semantic worms” klasą nadużyć, gdzie skill nie tylko wykonuje kod, ale zawiera instrukcje mające skłonić agenta do rozprzestrzeniania (np. polecania/instalowania) dalej — wykorzystując mechanikę działania LLM i automatyzacji.

5) „Cognitive rootkit”: trwała modyfikacja warstwy instrukcji (SOUL.md / AGENTS.md)

Jedna z najbardziej niepokojących technik z części II to trwałość przez dopisanie treści do plików kontekstu agenta, które są automatycznie ładowane przy starcie. VT opisuje scenariusz, w którym instalator skilla dopisuje „implant” do SOUL.md i AGENTS.md, zmieniając zachowanie agenta w przyszłości nawet po usunięciu samego skilla.


Praktyczne konsekwencje / ryzyko

Dlaczego to jest groźniejsze niż „zwykłe” złośliwe repozytorium?

  1. Klasyczne AV/EDR może nie zareagować na etap 0
    Jeśli skill to „tylko markdown + mało kodu”, plik sam w sobie bywa „czysty”. Złośliwy jest dopiero etap pobrania i uruchomienia payloadu, często wykonywany ręcznie przez użytkownika zgodnie z instrukcją.
  2. Blast radius = cały komputer (a czasem sieć)
    Agent ma realne uprawnienia: pliki, powłoka, sieć. To sprawia, że drobny błąd w procesie instalacji skilla może skończyć się pełnym przejęciem hosta lub pivotem.
  3. Ryzyko kradzieży danych i kont
    W kampaniach opisywanych w ekosystemie OpenClaw pojawia się m.in. Atomic Stealer (AMOS). Unit 42 opisuje AMOS jako jednego z istotnych macOS infostealerów, kradnącego m.in. dane przeglądarek (hasła/cookies), artefakty kryptowalutowe i dane z komunikatorów.
  4. Skala i tempo
    Koi Security raportuje, że po audycie całego ClawHub wykryto 341 złośliwych skillów, z czego 335 wyglądało na jedną dominującą kampanię (ClawHavoc).

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników / zespołów (blue team)

  • Traktuj foldery skill jako granicę zaufanego kodu: kontroluj, kto może je modyfikować i skąd pochodzą.
  • Sandboxuj uruchomienia agenta (izolacja, oddzielny użytkownik/system, ograniczenia sieci, brak dostępu do kluczy/sekretów).
  • Zasada „zero one-linerów”: nie uruchamiaj poleceń typu curl ... | bash, nie wklejaj obfuskowanych komend, nie uruchamiaj binarek „z instrukcji”.
  • Weryfikuj, co skill robi naprawdę: przegląd SKILL.md, skryptów, odwołań do zewnętrznych domen, base64/obfuskacji; skanuj paczki przed instalacją.

Dla operatorów marketplace / maintainerów platformy

  • Skanowanie przy publikacji: flagowanie zdalnego pobierania i wykonywania kodu, obfuskacji, instrukcji omijających nadzór użytkownika.
  • Mechanizmy reputacyjne i antyabuse: wymagania dot. kont, zgłaszanie/automatyczne wycofanie, widoczne ostrzeżenia „ten skill uruchamia zewnętrzny kod”. (To także kierunek dyskutowany publicznie wokół ClawHub).

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

  • npm/PyPI vs ClawHub: w klasycznych menedżerach paczek złośliwy kod zwykle „jest w paczce”. W ekosystemie skillów agentowych często nie musi być — wystarczy, że paczka skutecznie nakłoni do uruchomienia payloadu lub „wstrzyknie” trwałe instrukcje do kontekstu agenta.
  • Infostealery jako payload: AMOS i podobne rodziny wpisują się w trend kradzieży danych/kluczy/sesji, ale nowością jest kanał dystrybucji (skille + agent z uprawnieniami).

Podsumowanie / kluczowe wnioski

OpenClaw i podobne „agentic AI” tworzą nową klasę ryzyka: automatyzacja z uprawnieniami systemowymi + marketplace dodatków = idealny cel dla supply chain. Najgroźniejsze przypadki nie polegają na „złośliwym ZIP-ie”, tylko na tym, że skill staje się wiarygodnym, powtarzalnym mechanizmem doprowadzania do RCE, kradzieży sekretów, backdoorów, a nawet trwałego przeprogramowania zachowania agenta („cognitive rootkit”).

Jeśli organizacja testuje agentów AI lokalnie: traktuj to jak wdrożenie narzędzia uprzywilejowanego. W takim świecie „supply chain” nie jest detalem — to jest produkt.


Źródła / bibliografia

  1. VirusTotal Blog — From Automation to Infection: How OpenClaw AI Agent Skills Are Being Weaponized (02.02.2026). (VirusTotal Blog)
  2. VirusTotal Blog — From Automation to Infection (Part II): Reverse Shells, Semantic Worms, and Cognitive Rootkits in OpenClaw Skills (05.02.2026). (VirusTotal Blog)
  3. Koi Security — ClawHavoc: 341 Malicious Clawed Skills Found by the Bot They Were Targeting (01.02.2026). (koi.ai)
  4. The Verge — OpenClaw’s AI ‘skill’ extensions are a security nightmare (ok. 05.02.2026). (The Verge)
  5. Palo Alto Networks Unit 42 — Stealers on the Rise: A Closer Look at a Growing macOS Threat (04.02.2025). (Unit 42)

Docker łata krytyczną lukę „DockerDash” w Ask Gordon AI: od metadanych obrazu do wykonania narzędzi i wycieku danych

Wprowadzenie do problemu / definicja luki

Docker załatał krytyczną podatność dotyczącą Ask Gordon (wbudowanego asystenta AI w Docker Desktop i Docker CLI), która pozwalała atakującemu „przemycić” złośliwe instrukcje w metadanych obrazu kontenera (np. w polach LABEL Dockerfile). Gdy użytkownik pytał Ask Gordon o taki obraz, agent mógł potraktować metadane jak polecenia, przekazać je dalej do warstwy pośredniej (MCP Gateway) i doprowadzić do uruchomienia narzędzi lub wycieku danych.


W skrócie

  • Nazwa/codename: DockerDash
  • Wektor: złośliwe instrukcje zaszyte w metadanych obrazu (np. LABEL) lub metadanych repozytorium w ekosystemie Docker (wariant prompt injection).
  • Skutek: ryzyko wykonania operacji przez narzędzia powiązane z agentem (w praktyce „RCE przez łańcuch agentowy”) i/lub eksfiltracji wrażliwych informacji.
  • Status: naprawione w Docker Desktop 4.50.0 (łatki obejmują oba opisane scenariusze).

Kontekst / historia / powiązania

Ask Gordon to asystent AI dostępny w Docker Desktop i Docker CLI (funkcja wciąż opisywana jako beta w dokumentacji), mający ułatwiać pracę z Dockerem i ekosystemem narzędzi.

W praktyce jest to klasyczny przykład nowej klasy ryzyk: agent + narzędzia + kontekst z zewnątrz. Jeśli agent bezkrytycznie ufa danym wejściowym (tu: metadanym obrazu/repozytorium), a następnie ma możliwość uruchamiania narzędzi, powstaje „most” przez granice zaufania.

Wątek prompt injection w Ask Gordon pojawiał się już wcześniej: Pillar Security opisało scenariusz „zatruwania” metadanych repozytorium (Docker Hub), który mógł prowadzić do przejęcia zachowania asystenta i wycieku danych.


Analiza techniczna / szczegóły luki

Mechanika ataku (wariant „metadane obrazu → MCP Gateway → narzędzie”)

W opisywanym łańcuchu ataku kluczowe są trzy elementy:

  1. Nośnik instrukcji – atakujący publikuje obraz Dockera zawierający „uzbrojone” metadane, np. w polach LABEL w Dockerfile.
  2. Interpretacja przez agenta – użytkownik prosi Ask Gordon o analizę/wyjaśnienie obrazu; agent pobiera metadane i nie odróżnia zwykłego opisu od wstrzykniętych poleceń.
  3. Egzekucja przez narzędzia – zinterpretowane instrukcje trafiają do MCP Gateway (warstwa pośrednia między agentem a serwerami/narzędziami MCP). Błąd polega na tym, że polecenia przechodzą „po linii zaufania” i mogą skutkować uruchomieniem narzędzi z uprawnieniami użytkownika (lub przynajmniej wyciekiem danych dostępnym w kontekście środowiska).

Co zostało zmienione w poprawkach

Według opisu poprawek i omówień, Docker wdrożył mechanizmy ograniczające nadużycia: m.in. wymaganie potwierdzenia przed uruchomieniem narzędzi (MCP tools) oraz blokady pewnych ścieżek eksfiltracji.


Praktyczne konsekwencje / ryzyko

Najważniejszy wniosek: to nie jest „tylko prompt injection w czacie”. To podatność łańcuchowa, w której:

  • zaufana czynność (pytanie o obraz/komendę) uruchamia analizę,
  • analiza konsumuje niezaufany kontekst (metadane z obrazu/repozytorium),
  • a agent ma „ręce i nogi” w postaci narzędzi (MCP), które mogą wykonać działania w systemie lub pobrać i wynieść dane.

W środowiskach firmowych ryzyko rośnie, bo Docker Desktop/CLI często mają dostęp do:

  • rejestrów i tokenów (PAT), zmiennych środowiskowych, konfiguracji,
  • prywatnych obrazów i logów (np. build, debug),
  • artefaktów w repozytoriach oraz sieci firmowej (ruch wychodzący).

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj Docker Desktop i Docker CLI do wersji zawierającej poprawki (co najmniej 4.50.0) – to najszybsza redukcja ryzyka.
  2. Jeśli AI-asystent nie jest wymagany: wyłącz Ask Gordon lub ogranicz jego użycie do środowisk testowych (szczególnie na stacjach z dostępem do sekretów).
  3. Ogranicz narzędzia MCP:
    • usuń/wyłącz zbędne integracje,
    • wymagaj potwierdzeń dla uruchomień narzędzi (po aktualizacji sprawdź polityki/ustawienia).
  4. Higiena supply chain:
    • nie analizuj „cudzych” obrazów bez sandboxa,
    • pinuj obrazy po digest, stosuj polityki dopuszczania rejestrów,
    • skanuj obrazy (SCA/SBOM) i stosuj zasady provenance, gdzie to możliwe.
  5. Ogranicz eksfiltrację: kontrola egress (proxy, firewall), DLP dla kluczowych stacji, minimalizacja sekretów w zmiennych środowiskowych.

Różnice / porównania z innymi przypadkami

  • Klasyczne podatności w kontenerach (np. ucieczka z kontenera) zwykle wynikają z błędów w runtime/daemonie. Tu problem jest inny: AI agent staje się „parserem poleceń” dla danych, które miały być opisem.
  • To także krok dalej niż typowy prompt injection: stawką nie jest odpowiedź modelu, tylko uruchomienie narzędzia (agentic/tool-enabled LLM).

Podsumowanie / kluczowe wnioski

DockerDash pokazuje, że wbudowane asystenty AI w narzędziach deweloperskich realnie poszerzają powierzchnię ataku supply chain: metadane i opisy, dotąd „pasywne”, mogą stać się aktywnym wektorem wpływu na zachowanie agenta.

Najważniejsze działania to aktualizacja do wersji z poprawkami, ograniczenie automatyzacji uruchamiania narzędzi oraz twarde zasady pracy z obrazami z zewnętrznych źródeł.


Źródła / bibliografia

  1. The Hacker News – opis podatności i wektora przez metadane (LABEL), informacja o poprawkach w 4.50.0 (The Hacker News)
  2. Noma Security / Noma Labs – analiza DockerDash i łańcuchów ataku (noma.security)
  3. SecurityWeek – omówienie roli MCP Gateway i efektów (RCE/wyciek), kontekst poprawek (SecurityWeek)
  4. Pillar Security – prompt injection przez metadane repozytorium (Docker Hub) (pillar.security)
  5. Docker Docs – dokumentacja Ask Gordon (kontekst funkcji i dostępności) (Docker Documentation)

RedKitten: irańska kampania szpiegowska z „akceleracją AI” celuje w NGO i aktywistów

Wprowadzenie do problemu / definicja luki

Kampania RedKitten to świeżo zidentyfikowany łańcuch ataku, który wykorzystuje klasyczny wektor „dokument z makrem”, ale dokłada do niego dwie nowoczesne cechy: komodytyzację infrastruktury (usługi chmurowe i komunikatory zamiast własnych serwerów) oraz oznaki LLM-wspomaganego developmentu (styl kodu, komentarze, szybka iteracja). W praktyce to nie „jedna luka CVE”, tylko zestaw technik prowadzących do zdalnej kontroli i eksfiltracji danych.

Badacze HarfangLab opisują tę aktywność jako kampanię obserwowaną na początku stycznia 2026 r., wymierzoną w osoby i organizacje dokumentujące nadużycia praw człowieka.


W skrócie

  • Punkt startu: archiwum (m.in. 7z) z arkuszami XLSM zawierającymi złośliwe makra.
  • Dropper z makra uruchamia implant C# (w raporcie nazwany SloppyMIO) i wykorzystuje AppDomainManager injection jako technikę uruchomienia w kontekście .NET.
  • Konfiguracja i moduły są pobierane z legalnych usług: GitHub oraz Google Drive, a kanał C2 realizowany jest przez Telegram.
  • W infrastrukturze widoczne są elementy steganografii (konfiguracja osadzana w obrazach) oraz iteracyjny rozwój (zmiany w gistach, wersjonowanie).
  • Atrybucja: silne przesłanki na aktora farsi-języcznego powiązanego z interesami państwowymi Iranu, ale bez jednoznacznego przypisania do znanej grupy.

Kontekst / historia / powiązania

Wątek „kittens” to nie przypadek: w ekosystemie threat intel nazewnictwo wielu irańskich klastrów i grup często zawiera „Kitten”. Opisuje to m.in. Middle East Institute w przeglądzie irańskich APT i konwencji nazewniczych.

W tle warto też pamiętać o długiej historii irańskich działań ofensywnych, w tym operacji określanych jako Fox Kitten w bazie MITRE ATT&CK.
Z kolei raport ClearSky Cyber Security (2020) pokazuje, że część irańskich kampanii łączyła rozpoznanie i utrzymanie dostępu z gotowością do eskalacji (np. do działań destrukcyjnych) oraz wykorzystywała szeroką infrastrukturę i dostęp przez zewnętrzne usługi zdalne.


Analiza techniczna / szczegóły luki

1) Initial access: XLSM + makra + socjotechnika

Atak startuje od dokumentów XLSM podszywających się pod materiały związane z ofiarami protestów (tematyka „shock lures”).
W opisie The Hacker News podkreślono oznaki generowania lub wspomagania kodu VBA przez LLM (styl, nazewnictwo, komentarze typu „PART …”).

2) Execution: AppDomainManager injection (w praktyce: .NET-owe „hijackowanie” ładowania)

Makro działa jako dropper dla implantu C# i wykorzystuje technikę AppDomainManager injection.
Z perspektywy obrony to istotne, bo AppDomainManager może umożliwiać wykonanie arbitralnego kodu w procesie .NET poprzez kontrolę sposobu ładowania domen aplikacji i assembly. Dobre omówienie mechaniki i tropów detekcyjnych opisuje Pentest Laboratories.

3) Implant i moduły: SloppyMIO jako „mini-framework” z pobieraniem funkcji na żądanie

W raporcie HarfangLab implant SloppyMIO:

  • cyklicznie odświeża konfigurację,
  • pobiera moduły (źródła .cs lub gotowe DLL),
  • buforuje je (cache) i uruchamia funkcje typu Run().

Wprost opisano też funkcje modułowe, m.in. wykonywanie poleceń, zbieranie plików i wysyłkę danych kanałem C2, z uwzględnieniem limitów rozmiaru wiadomości/dokumentów.

4) C2 i infrastruktura: „legit services only” + steganografia

Najbardziej charakterystyczny fragment tej kampanii to przeniesienie kluczowych elementów w legalne platformy:

  • dead drop/resolver na GitHub (gisty),
  • hostowanie modułów i obrazów na Google Drive,
  • sterowanie przez Telegram (bot token + chat ID w konfiguracji).

HarfangLab opisuje również wersjonowanie „steganographic configuration image” oraz timeline commitów gistów od października 2025 do 23 stycznia 2026 r., co sugeruje iteracyjne dopracowywanie narzędzia i (paradoksalnie) zostawia sporo metadanych.


Praktyczne konsekwencje / ryzyko

  1. Ryzyko dla NGO / OSINT / aktywistów: kradzież dokumentacji, list kontaktów, materiałów dowodowych, metadanych (kto, kiedy, z kim).
  2. Ryzyko organizacyjne: kompromitacja skrzynek, komunikatorów i repozytoriów danych może prowadzić do deanonimizacji źródeł i działań odwetowych.
  3. Utrudnione blokowanie po IP/domenie: jeśli ruch idzie do usług powszechnie używanych (Drive/Telegram), polityka „po prostu zablokuj domenę” bywa nierealna.
  4. Próg wejścia spada: jeśli LLM realnie przyspiesza pisanie makr/loaderów i modułów, to tempo iteracji w kampaniach phishingowych może rosnąć (więcej wariantów, krótsze cykle).

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (0–72h)

  • Zablokuj makra z Internetu w środowisku M365 (Attack Surface Reduction / Office policy) i ogranicz uruchamianie XLSM do zaufanych lokalizacji.
  • Hunting po artefaktach: w raporcie HarfangLab są IOC (hash’e), ścieżki oraz nazwy zaplanowanych zadań (scheduled tasks) i reguły YARA — warto je wciągnąć do procesu detekcji w EDR/SIEM.
  • Telemetria dla .NET: poluj na anomalie wokół AppDomainManager (np. nietypowe pliki konfiguracyjne, podejrzane assembly ładowane przez legalne binarki .NET) – technika bywa używana dla „cichego” wykonania.

Twardnienie i prewencja (1–4 tygodnie)

  • Segmentacja i kontrola egress: jeśli nie możesz zablokować Telegram/Drive globalnie, rozważ:
    • allowlistę procesów/hostów, które mogą rozmawiać z tymi usługami,
    • inspekcję DNS/HTTP(S) pod kątem nietypowych wzorców pobrań modułów.
  • Detekcja „living on popular services”: buduj reguły korelacyjne typu: uruchomienie Office → tworzenie DLL/artefaktów w profilu użytkownika → scheduled task → ruch do Drive/Telegram.
  • Szkolenia anty-phishingowe ukierunkowane na „dokumenty-pułapki” i scenariusze kryzysowe (lures o silnym ładunku emocjonalnym).

Różnice / porównania z innymi przypadkami

  • „Kitteny” różnią się tradecraftem: część historycznych kampanii skupiała się na utrzymaniu dostępu i eksploatacji usług zdalnych (VPN/RDP), co opisywał ClearSky w kontekście Fox Kitten.
  • RedKitten idzie mocno w „legit infra” i automatyzację: zamiast klasycznej infrastruktury C2 – Telegram + Drive + GitHub, do tego steganografia i modułowość.
  • Podobieństwa w „protest lures”: Kaspersky opisywał w 2021 r. kampanię Ferocious Kitten, która także wykorzystywała dokumenty-wabiki z makrami i tematy protestów, a nawet celowała w ekosystem komunikatorów.

Podsumowanie / kluczowe wnioski

  • RedKitten to kampania szpiegowska, która łączy stare dobre makra z nowoczesnym podejściem do infrastruktury (popularne usługi) i prawdopodobnym wsparciem LLM przy wytwarzaniu kodu.
  • Największym wyzwaniem obronnym jest nie sam dropper, tylko detekcja i blokowanie modularnego implantu korzystającego z Drive/Telegram bez wyraźnych „złych domen”.
  • Najbardziej praktyczny krok: twarda polityka dla makr + hunting po IOC/YARA + telemetria .NET pod kątem AppDomainManager.

Źródła / bibliografia

  1. HarfangLab – RedKitten: AI-accelerated campaign targeting Iranian protests (29 stycznia 2026). (HarfangLab)
  2. The Hacker News – opis kampanii i wskazówki dot. LLM-generowanych makr (31 stycznia 2026). (The Hacker News)
  3. MITRE ATT&CK – wpis o Fox Kitten (G0117) i kontekst grup powiązanych (aktualizacje do 2024). (attack.mitre.org)
  4. ClearSky – Fox Kitten – Widespread Iranian Espionage-Offensive Campaign (2020). (clearskysec.com)
  5. Kaspersky – A 6-year cyberespionage campaign… (Ferocious Kitten, 2021). (Kaspersky)

Operacja „Bizarre Bazaar”: jak cyberprzestępcy przejmują wystawione endpointy LLM i monetyzują dostęp do AI

Wprowadzenie do problemu / definicja luki

„LLMjacking” to nadużycie infrastruktury dużych modeli językowych (LLM) przez osoby nieuprawnione — analogicznie do cryptojackingu, ale zamiast kopania kryptowalut na cudzym CPU/GPU, celem jest wykonywanie kosztownej inferencji, kradzież danych z kontekstu rozmów, a nawet próby wejścia głębiej w sieć przez integracje typu MCP.

W styczniu 2026 nagłośniono kampanię nazwaną Operation Bizarre Bazaar, w której atakujący polują na wystawione do internetu lub słabo uwierzytelnione endpointy LLM (np. self-hosted) i budują wokół tego cały „łańcuch dostaw” — od skanowania, przez walidację, po odsprzedaż dostępu w formie quasi-komercyjnej usługi.


W skrócie

  • Badacze Pillar Security zarejestrowali ~35 000 sesji ataków na honeypotach w oknie ok. 40 dni (grudzień 2025 – styczeń 2026).
  • Najczęściej wykorzystywane „wejścia” to domyślne/odsłonięte porty i brak kontroli dostępu, m.in. Ollama na 11434 oraz OpenAI-compatible API na 8000.
  • Model działania obejmuje: Scanner → Validator → Marketplace, gdzie rynek miał funkcjonować pod domeną silver[.]inc, promując „unified gateway” do wielu modeli.
  • Poza kradzieżą zasobów i odsprzedażą API, ryzyko dotyczy wycieku danych z promptów/konwersacji oraz pivotu przez serwery MCP (łączenie LLM z plikami, DB, API).

Kontekst / historia / powiązania

Zainteresowanie atakujących powierzchnią AI rośnie, bo:

  1. inferencja bywa droga (szczególnie przy GPU),
  2. endpointy LLM często są wdrażane „startupowo” — szybko, w środowiskach dev/stage, z publicznym IP,
  3. integracje narzędziowe (np. MCP) łączą LLM z zasobami o realnej wartości.

Niezależnie od Bizarre Bazaar, GreyNoise opisało w styczniu 2026 metodyczne mapowanie i sondowanie dziesiątek endpointów modeli oraz szukanie błędnych konfiguracji mogących ujawniać dostęp do komercyjnych API.


Analiza techniczna / szczegóły luki

1) Jak wybierane są cele

Według Pillar Security, przestępcy korzystają z narzędzi typu Shodan/Censys i reagują szybko — próby nadużyć pojawiają się w ciągu godzin od tego, gdy źle skonfigurowany endpoint zacznie być widoczny w wynikach skanów.

Typowe „higieniczne” błędy:

  • brak uwierzytelniania i autoryzacji,
  • wystawienie dev/stage na publiczny adres,
  • brak limitów (rate limiting / quota),
  • brak segmentacji sieciowej i egress control,
  • publicznie dostępne integracje MCP.

2) Najczęstsze wektory wejścia (konkretne przykłady)

Wskazane w raportach przykłady misconfigów:

  • Ollama bez auth na porcie 11434,
  • OpenAI-compatible endpoints na 8000 dostępne z internetu,
  • wystawione serwery MCP bez kontroli dostępu.

3) Łańcuch dostaw cyberprzestępców: Scanner → Validator → Marketplace

Pillar opisuje trójfazowy model:

  • Scanner: rozproszona infrastruktura botów kataloguje odsłonięte endpointy LLM/MCP,
  • Validator: waliduje działanie API (testy, enumeracja możliwości/modeli),
  • Marketplace: monetyzuje dostęp — w raporcie wskazano silver[.]inc jako „bramę” odsprzedającą dostęp do wielu dostawców i promującą projekt „NeXeonAI”.

4) Oddzielna aktywność wokół MCP

W raporcie Pillar pojawia się też wątek osobnej kampanii rozpoznawczej ukierunkowanej na endpointy MCP, gdzie stawką bywa nie tylko koszt inferencji, ale potencjalny dostęp do zasobów (np. interakcje z Kubernetes, dostęp do usług chmurowych, wykonanie poleceń) — co w praktyce może być bardziej wartościowe niż samo „podkradanie” tokenów.


Praktyczne konsekwencje / ryzyko

  1. Koszty i nadużycia zasobów
    Nieautoryzowane użycie inferencji może wygenerować duże rachunki lub zajechać GPU/CPU (DoS kosztowy). Pillar opisuje odsprzedaż dostępu z „rabatem” w modelu przestępczym.
  2. Wyciek danych z promptów i historii konwersacji
    Jeśli endpoint umożliwia wgląd w kontekst, logi, historię rozmów lub jeśli aplikacja nie izoluje tenantów/sesji, atakujący może wyciągnąć dane wrażliwe (PII, fragmenty kodu, treści biznesowe).
  3. Pivot do sieci wewnętrznej przez integracje (MCP / narzędzia)
    Jeżeli MCP/agent ma uprawnienia do plików, baz danych czy wewnętrznych API, „tylko” odsłonięty endpoint AI staje się punktem wejścia do klasycznych ataków na środowisko.
  4. Ryzyko reputacyjne i prawne
    Wycieki danych klientów, utrata poufności, potencjalne naruszenia RODO/umów, a do tego przerwy w działaniu usług (chatboty, support, sprzedaż).

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań „od razu” (praktyka z SOC/CloudSec):

1) Odcięcie ekspozycji i twarde uwierzytelnienie

  • Nie wystawiaj endpointów LLM/MCP bezpośrednio do internetu; schowaj je za VPN/ZTNA lub reverse proxy.
  • Wymuś mTLS / OAuth2 / signed JWT / silne API keys + rotacja sekretów.
  • Zastosuj IP allowlist (tam, gdzie to realne).

2) Kontrole kosztowe i anty-abuse

  • Rate limiting / quotas per client, limity tokenów, limity równoległości.
  • Alerty na anomalia: skoki requestów, nietypowe modele, nietypowe godziny, długie konteksty.

3) Telemetria i detekcja

  • Loguj: źródłowe IP, user agent, klucze, endpointy, liczbę tokenów, czasy odpowiedzi, błędy 401/403.
  • Koreluj z widocznością w Shodan/Censys (monitoring zewnętrzny własnych adresów).

4) Twarde zasady dla MCP / agentów i integracji narzędziowych

  • Least privilege dla narzędzi (filesystem/DB/API), osobne konta serwisowe, minimalne scope.
  • Rozdziel sieciowo warstwę LLM od zasobów krytycznych (segmentacja).
  • Wprowadź polityki „tool allowlist” i ograniczenia komend/operacji (szczególnie tam, gdzie możliwe jest wykonywanie poleceń).

5) Higiena wdrożeń self-hosted (Ollama/vLLM i podobne)

  • Zmień domyślne ustawienia, wyłącz publiczne bindy, nie zostawiaj portów typu 11434/8000 na WAN.
  • Traktuj dev/stage jak produkcję: brak publicznych IP, brak „tymczasowo otwartego” API.

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

  • Cryptojacking vs LLMjacking: w obu przypadkach kradniesz moc obliczeniową, ale przy LLM dochodzi wyższa wrażliwość danych (kontekst rozmów) i częściej ścieżka do systemów wewnętrznych przez integracje (MCP/agent tools).
  • Skanowanie/rekonesans vs monetyzacja: GreyNoise opisywało kampanie silnie rekonesansowe, budujące listy celów i testujące formaty API. Z kolei Bizarre Bazaar (wg Pillar) idzie krok dalej — domyka pętlę „biznesową” przez walidację i odsprzedaż dostępu.

Podsumowanie / kluczowe wnioski

  • Wystawione endpointy LLM/MCP przestały być „niszowym problemem” — pojawił się powtarzalny model przestępczy z monetyzacją.
  • Największe ryzyko to nie tylko rachunki za GPU, ale też wyciek danych i pivot do wnętrza organizacji przez integracje narzędziowe.
  • Najskuteczniejsza obrona jest nudna, ale działa: brak ekspozycji do internetu + silne auth + limity + monitoring + least privilege dla MCP.

Źródła / bibliografia

  1. Pillar Security — Operation Bizarre Bazaar: First Attributed LLMjacking Campaign… (28 stycznia 2026). (pillar.security)
  2. BleepingComputer — Hackers hijack exposed LLM endpoints in Bizarre Bazaar operation (28 stycznia 2026). (BleepingComputer)
  3. CSO Online — Crooks are hijacking and reselling AI infrastructure: Report (28 stycznia 2026). (CSO Online)
  4. GreyNoise — Threat Actors Actively Targeting LLMs (8 stycznia 2026). (greynoise.io)
  5. SecurityWeek — LLMs in Attacker Crosshairs, Warns Threat Intel Firm (12 stycznia 2026). (SecurityWeek)

Nowe „sandbox escape” w n8n: CVE-2026-1470 i CVE-2026-0863 otwierają drogę do RCE na self-hosted instancjach

Wprowadzenie do problemu / definicja luki

n8n to popularna platforma do automatyzacji workflow (często także dla integracji z narzędziami AI/LLM), którą organizacje uruchamiają zarówno w chmurze, jak i w modelu self-hosted. Problem zaczyna się wtedy, gdy „niezaufana” logika użytkownika (wyrażenia JavaScript i fragmenty kodu Python w węzłach workflow) jest wykonywana w środowisku, które ma być odseparowane od hosta – ale w praktyce da się z tej piaskownicy uciec.

W dniach 27–28 stycznia 2026 opisano dwa takie przypadki: CVE-2026-1470 (krytyczna, CVSS 9.9) oraz CVE-2026-0863 (wysoka, CVSS 8.5). Obie luki pozwalają uwierzytelnionemu użytkownikowi z uprawnieniami do tworzenia/edycji workflow doprowadzić do zdalnego wykonania kodu (RCE) i przejęcia instancji – a w pewnych konfiguracjach nawet hosta.


W skrócie

  • CVE-2026-1470 (CVSS 9.9, Critical): ucieczka z sandboxa w silniku wyrażeń (Expression Engine) poprzez obejście walidacji AST w JavaScript; finalnie prowadzi do RCE w głównym procesie n8n.
  • CVE-2026-0863 (CVSS 8.5, High): ucieczka z sandboxa dla Python Code node (zwłaszcza w trybie Internal) z wykorzystaniem zachowania wyjątków w Python 3.10+; w „Internal” może skutkować przejęciem całej instancji na hoście.
  • Dotyczy głównie self-hosted (n8n cloud ma mieć poprawki wdrożone), a kluczowe jest szybkie przejście na wersje naprawione.

Kontekst / historia / powiązania

W praktyce n8n działa jak „centralny węzeł automatyzacji” – ma dostęp do webhooków, sekretów, tokenów API, systemów IAM, narzędzi DevOps i danych biznesowych. To sprawia, że nawet „tylko” post-auth RCE jest bardzo groźne: użytkownik o pozornie ograniczonych prawach (np. edycja workflow) może stać się punktem wejścia do przejęcia infrastruktury.

Badacze JFrog podkreślają, że mimo wzmacniania mechanizmów ochronnych w n8n, złożone cechy języków dynamicznych (JS/Python) i zmiany zachowań runtime potrafią rozbić założenia sandboxa.


Analiza techniczna / szczegóły luki

CVE-2026-1470: JavaScript „Expression Engine” i pominięty edge-case with

Mechanizm wyrażeń n8n opiera się na wykonywaniu treści {{ ... }} poprzez konstruktor JavaScript Function, co z natury jest ryzykowne. Dlatego n8n stosuje AST-based sandbox (m.in. walidacje i neutralizację niebezpiecznych konstrukcji). JFrog opisuje jednak, że jeden problematyczny element został przeoczony: instrukcja with (przestarzała, ale wciąż wspierana), która zmienia sposób rozwiązywania identyfikatorów w zakresie. Skutkiem jest możliwość „oszukania” walidacji AST tak, by obejść blokady i doprowadzić do uruchomienia dowolnego kodu w kontekście głównego procesu n8n.

Dlaczego CVSS aż 9.9 mimo wymogu logowania? Bo wykonanie następuje na głównym node n8n, co daje realnie pełne przejęcie instancji (a często i hosta) przy niskim progu uprawnień (wystarczy możliwość edycji workflow).

CVE-2026-0863: Python Code node, AST sandbox i „ucieczka przez wyjątki” (Python 3.10+)

Druga luka dotyczy wykonywania Pythona w Code node i obejścia restrykcji sandboxa (opartego o analizę AST, denylisty builtins/importów itp.). Kluczowy element to fakt, że od Python 3.10 obiekty wyjątków typu AttributeError zyskały dodatkowe pola (m.in. obj), co może zostać wykorzystane do odzyskania referencji do obiektów, które sandbox próbował ukryć. W efekcie, przy sprytnym łańcuchu działań (bez potrzeby klasycznych, wprost zakazanych wywołań), możliwe staje się obejście ograniczeń i dojście do wykonania poleceń systemowych.

Bardzo ważne jest tu rozróżnienie trybów uruchomienia:

  • Internal mode: task runner jest procesem potomnym n8n (ta sama tożsamość/UID/GID), co zwiększa skutki kompromitacji.
  • External mode: kod wykonuje się w sidecarze (oddzielny kontener/runner), co zwykle ogranicza wpływ na hosta (choć nadal jest to poważny incydent).

Praktyczne konsekwencje / ryzyko

Jeśli atakujący ma konto (lub przejmie konto) z uprawnieniami do tworzenia/edycji workflow, może:

  • uzyskać RCE i przejąć instancję n8n (a przez to dostęp do sekretów, tokenów, połączeń z systemami firmy),
  • modyfikować workflow w celu trwałej persystencji (np. „ciche” eksfiltracje lub dalsze skrypty),
  • wykonać ruch boczny (lateral movement) do narzędzi, które n8n integruje (CI/CD, chmura, SaaS, IAM).

W konfiguracjach Internal mode ryzyko jest szczególnie wysokie, bo udana ucieczka z sandboxa oznacza wykonywanie komend w kontekście głównego środowiska n8n. Sama dokumentacja n8n ostrzega, że internal w produkcji to ryzyko bezpieczeństwa i zaleca external.


Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj n8n do wersji z poprawkami:
    • dla CVE-2026-1470: 1.123.17 / 2.4.5 / 2.5.1 (lub nowsze)
    • dla CVE-2026-0863: 1.123.14 / 2.3.5 / 2.4.2 (lub nowsze)
  2. Wymuś „External mode” dla task runners (szczególnie jeśli korzystasz z Code node) – to domyślna rekomendacja do produkcji, bo zapewnia izolację przez sidecar/runner.
  3. Ogranicz uprawnienia do tworzenia/edycji workflow (RBAC/least privilege): traktuj je jak uprawnienia „prawie administracyjne”, bo w razie luki sandboxowej to realny wektor przejęcia.
  4. Segmentacja i ograniczenia sieciowe: jeśli n8n musi mieć dostęp do systemów wewnętrznych, ogranicz to listami dozwolonych adresów/usług; rozważ osobne środowiska dla automatyzacji „wysokiego zaufania”.
  5. Rotacja sekretów po aktualizacji, jeśli istnieje podejrzenie nadużycia (tokeny API, hasła integracji, klucze chmurowe). W przypadku RCE zakładaj kompromitację poufności.
  6. Monitoring: wykrywaj nietypowe modyfikacje workflow (nowe węzły Code/Expression, zmiany w webhookach, nowe integracje), skoki w uruchomieniach i nieoczekiwane połączenia wychodzące.

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

  • JavaScript vs Python: w obu przypadkach problemem jest zaufanie do AST-based sandbox i to, że drobne szczegóły języka/runtime mogą stworzyć „furtkę” poza założony model bezpieczeństwa.
  • Wpływ konfiguracji: CVE-2026-0863 wyraźnie eskaluje w Internal mode, podczas gdy external (sidecar) może ograniczać zasięg skutków.
  • Wspólny mianownik: atak wymaga co prawda uwierzytelnienia, ale w realnych środowiskach „edytor workflow” to częsta rola operacyjna – a n8n bywa wystawiane w sieci firmowej (czasem też publicznie), co podnosi ryzyko.

Podsumowanie / kluczowe wnioski

CVE-2026-1470 i CVE-2026-0863 to kolejny sygnał, że sandboxowanie JavaScript i Pythona w produktach automatyzacji jest wyjątkowo trudne do „domknięcia” na stałe. W praktyce bezpieczeństwo n8n zależy nie tylko od patchy, ale też od modelu uruchomienia (external vs internal) oraz od tego, komu dajemy możliwość edycji workflow.

Jeśli masz self-hosted n8n: patchuj pilnie, przełącz na external mode dla task runners i potraktuj uprawnienia do workflow jako zasób krytyczny.


Źródła / bibliografia

  • BleepingComputer – opis CVE-2026-1470 i CVE-2026-0863, wersje naprawione, kontekst zagrożenia (28 stycznia 2026). (BleepingComputer)
  • JFrog Security Research – szczegóły techniczne obejść sandboxa (27 stycznia 2026). (research.jfrog.com)
  • National Vulnerability Database (NVD) – karty CVE-2026-1470 i CVE-2026-0863 (metryki, opis, wektory). (NVD)
  • Dokumentacja n8n – task runners, tryby internal/external i ostrzeżenie dot. produkcji. (docs.n8n.io)
  • The Hacker News – podsumowanie, zalecane wersje aktualizacji i akcent na ryzyko w trybie internal. (The Hacker News)

KONNI wykorzystuje AI do budowy backdoora w PowerShell i celuje w deweloperów (blockchain/crypto)


Wprowadzenie do problemu / definicja luki

W styczniu 2026 Check Point Research opisał aktywną kampanię phishingową przypisywaną do KONNI – północnokoreańskiego aktora działającego co najmniej od 2014 roku. Tym razem kluczową zmianą jest dobór ofiar (software development/engineering) oraz narzędzie egzekucji: backdoor w PowerShell, którego cechy wskazują na AI-assist/AI-generated development (nie tyle nowe TTP, co szybsze i „czyściejsze” wytwarzanie kodu z typowymi artefaktami LLM).

W praktyce nie jest to „pojedyncza luka CVE”, ale łańcuch infekcji oparty o socjotechnikę, pliki skrótów Windows (LNK) i wieloetapowe uruchomienie komponentów, którego efektem jest trwały dostęp do hosta oraz możliwość dalszej eskalacji do narzędzi zdalnego zarządzania.


W skrócie

  • Kampania celuje w deweloperów i zespoły inżynieryjne z dostępem do zasobów blockchain/crypto (repozytoria, API, portfele, infrastruktura).
  • Start łańcucha: link hostowany na Discord → pobranie ZIP z przynętą (PDF) i LNK, który uruchamia loader PowerShell i rozpakowuje kolejne elementy (DOCX + CAB).
  • Utrwalenie: Scheduled Task podszywający się pod OneDrive, uruchamiany cyklicznie, deszyfrujący (XOR) i wykonujący backdoor „in-memory”.
  • Backdoor zawiera rozbudowane anti-analysis (progi sprzętowe, blacklist narzędzi, wymaganie aktywności myszą), fingerprinting przez WMI oraz mechanizmy eskalacji UAC (fodhelper).
  • C2: obejście „bramki” po stronie serwera przez emulację JavaScript challenge i pozyskanie cookie __test, a potem cykliczne wysyłanie metadanych hosta do endpointu PHP.

Kontekst / historia / powiązania

KONNI historycznie kojarzono głównie z celami w Korei Południowej (dyplomacja, rząd, NGO, akademia) oraz klasycznym spear-phishingiem opartym o tematy geopolityczne. W opisywanej kampanii widać przesunięcie na ekosystemy techniczne: development i obszary, gdzie pojedynczy kompromitowany endpoint może otworzyć drogę do kontenerów, CI/CD, sekretów w repozytoriach czy kluczy do usług.

Z szerszej perspektywy to pasuje do obserwacji, że północnokoreański program cyber jest wykorzystywany nie tylko do szpiegostwa, ale również do operacji generujących środki finansowe, m.in. przez kradzieże kryptowalut i naruszenia sankcji.


Analiza techniczna / szczegóły luki

1) Przynęty i initial access

Przynęty wyglądają jak materiały projektowe (architektura, stack, harmonogramy, budżety/milestones) powiązane z blockchain/crypto. Wektor początkowy wprost nie jest ujawniony, ale łańcuch startuje od linku hostowanego na Discord, prowadzącego do archiwum ZIP.

Z perspektywy MITRE ATT&CK to klasyczny przypadek User Execution: Malicious File (T1204.002) – ofiara musi otworzyć/uruchomić spreparowany plik (tu: LNK).

2) Łańcuch infekcji (ZIP → LNK → CAB → BAT/PS1)

W ZIP znajdują się PDF (lure) oraz LNK. LNK uruchamia osadzony loader PowerShell, który:

  • zapisuje na dysk przynętę DOCX i archiwum CAB (oba osadzone w LNK i XOR-owane jednobajtowym kluczem),
  • otwiera DOCX, żeby odciągnąć uwagę,
  • rozpakowuje CAB, gdzie znajdują się: PowerShell backdoor, dwa batch file oraz exe do UAC bypass,
  • uruchamia pierwszy batch.

3) Persistence i „living off the land”

Pierwszy batch tworzy staging w C:\ProgramData, przenosi komponenty i zakłada Scheduled Task podszywający się pod zadanie OneDrive uruchamiane co godzinę. Zadanie czyta zaszyfrowany backdoor, wykonuje XOR-decrypt (klucz ‘Q’) i uruchamia kod w pamięci. Następnie batch usuwa się z dysku (redukcja śladów).

4) Cechy sugerujące AI-generated backdoor

CPR wskazuje na nietypowo „produktowy” charakter skryptu: czytelna struktura, komentarze/dokumentacja oraz artefakt wprost przypominający placeholder z generatorów LLM: komentarz w rodzaju „your permanent project UUID” (instrukcja dla człowieka jak uzupełnić wartość). To zestaw sygnałów, który ma wspierać tezę o AI-assist/AI-generated development.

5) Funkcje backdoora: anti-analysis, identyfikacja hosta, eskalacja

Backdoor wykonuje:

  • anti-analysis/sandbox evasion: progi sprzętowe, wykrywanie narzędzi (IDA, Wireshark, Procmon itd.), wymaganie interakcji użytkownika (ruch/kliknięcia myszy),
  • single-instance przez mutex Global\SysInfoProject_<projectUUID> (UUID stały dla próbek wskazanych w raporcie),
  • fingerprinting przez WMI (m.in. serial płyty głównej + UUID systemu), SHA-256 i skrócenie do 16 znaków,
  • rozgałęzienie działań wg uprawnień: dla „User” – fodhelper UAC bypass przez manipulacje w HKCU\Software\Classes i przekierowanie protokołu ms-settings, a następnie modyfikację ConsentPromptBehaviorAdmin (de facto ograniczenie promptów UAC dla adminów).

Dodatkowo, w scenariuszu „Admin” raport opisuje m.in. dodanie wykluczenia Windows Defender dla C:\ProgramData i podmianę zadania harmonogramu na wersję z wyższym kontekstem uprawnień.

6) C2 i obejście „bramki” anty-bot

C2 jest zabezpieczone client-side’ową „bramką” (AES/JS) i cookie __test. Backdoor emuluje JavaScript challenge: pobiera implementację AES używaną przez stronę, odtwarza logikę JS, odszyfrowuje ciphertext z serwera i wyciąga token, a następnie używa go jako cookie do kolejnych żądań. Potem okresowo wysyła metadane hosta (ID, poziom uprawnień, IPv4, username) do endpointu PHP, a odpowiedzi traktuje jako tasking (PowerShell wykonywany w tle).

7) Warianty i IoC

CPR wspomina też o wariancie z października 2025, gdzie początkowy payload był wprost obfuskowanym skryptem PowerShell pobierającym kolejne komponenty, a OneDriveUpdater.exe służył głównie do pobrania i uruchomienia klienta SimpleHelp (legit RMM) dla interaktywnego dostępu.

W raporcie podano też przykładowe domeny/IP C2 oraz listy hashy (IoC).


Praktyczne konsekwencje / ryzyko

Dla organizacji software’owych i zespołów blockchain/crypto ryzyko jest szczególne, bo kompromitacja jednego stanowiska developerskiego może przełożyć się na:

  • wyciek sekretów z repozytoriów (tokeny do Git, klucze API, SSH),
  • przejęcie CI/CD (wstrzyknięcia w pipeline, supply-chain),
  • dostęp do środowisk chmurowych i walletów/kluczy podpisujących,
  • lateral movement do zasobów produkcyjnych.

Kontekst finansowy jest istotny: w oficjalnych opracowaniach dot. aktywności DPRK podkreśla się skalę cyber-kradzieży i ich rolę w finansowaniu działań państwa, w tym obchodzeniu sankcji.


Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (24–72h)

  1. Zablokuj/ogranicz uruchamianie LNK z pobranych archiwów i katalogów typu Downloads/Temp (tam, gdzie to możliwe politykami). To bezpośrednio tnie klasę ataków „malicious file + user execution”.
  2. Polowanie na Scheduled Tasks podszywające się pod OneDrive i uruchamiające inline PowerShell (szczególnie z odczytem bajtów z C:\ProgramData\… i natychmiastowym IEX).
  3. Telemetria EDR: alerty na PowerShell obfuskowany arytmetyką, nietypowe tworzenie słowników stringów + Invoke-Expression.
  4. Wykrywanie zmian w rejestrze pod fodhelper UAC bypass (ścieżki pod HKCU\Software\Classes i ms-settings) oraz modyfikacji ConsentPromptBehaviorAdmin.
  5. Network: blokady/alerty na wskazane w raporcie domeny/IP oraz na nietypowe żądania do endpointów PHP po wcześniejszym „handshake” z cookie __test.

Średni termin (1–4 tygodnie)

  • Hardening stacji dev: separacja kont, MFA wszędzie, minimalizacja lokalnych uprawnień admin, izolacja sekretów (vault), rotacja tokenów.
  • Ograniczenie możliwości dodawania Defender exclusions i monitorowanie wykluczeń dla C:\ProgramData.
  • Kontrole supply-chain: podpisywanie artefaktów, wymuszenie code review dla zmian w pipeline, zasada „two-person rule” dla kluczy produkcyjnych.
  • Uświadamianie: „projektowe PDF/DOCX z Discorda” jako realna przynęta dla devów – to dziś równie typowe jak „faktura” w klasycznych kampaniach.

Różnice / porównania z innymi przypadkami

  • KONNI (AI-assist backdoor): raportowane elementy wskazują na wykorzystanie AI głównie do wytwarzania/formatowania kodu (komentarze-artefakty, modularność), przy zachowaniu znanych TTP (LNK, scheduled task, PowerShell).
  • Szerszy trend AI-generated malware: Check Point kilka dni wcześniej opisał „VoidLink” jako przykład bardziej „frameworkowego” podejścia, gdzie AI miało przyspieszać nie tylko pisanie kodu, ale też planowanie i iterację całego projektu. To sugeruje, że „AI w malware” szybko przesuwa się od ciekawostek do realnego przyspieszacza R&D po stronie atakujących.
  • LNK jako stały motyw: niezależnie od tej konkretnej kampanii, analizy TTP w regionie (w tym porównania aktorów państwowych) pokazują, że pliki LNK w archiwach ZIP są dojrzałym i powtarzalnym wzorcem initial access.

Podsumowanie / kluczowe wnioski

  1. KONNI rozszerza profil ofiar: deweloperzy + blockchain/crypto to atrakcyjny cel, bo daje dostęp do sekretów i infrastruktury o wysokiej wartości.
  2. Największa nowość nie leży w „magicznych” nowych technikach, tylko w tym, że AI może obniżać koszt i czas tworzenia użytecznych implantów (bardziej uporządkowany kod, szybkie wariantowanie).
  3. Obrona powinna iść dwutorowo: (a) twarde kontrole uruchamiania plików i PowerShell, (b) security hygiene w środowisku dev (sekrety, pipeline, uprawnienia).
  4. Warto traktować kanały typu Discord jako realny wektor dystrybucji „materiałów projektowych” – szczególnie w społecznościach dev/web3.

Źródła / bibliografia

  1. Check Point Research – KONNI Adopts AI to Generate PowerShell Backdoors (22 stycznia 2026). (Check Point Research)
  2. MITRE ATT&CK – User Execution: Malicious File (T1204.002). (attack.mitre.org)
  3. Genians – analiza spear-phishing i nadużyć LNK/ZIP w kampaniach APT (kontekst TTP). (genians.co.kr)
  4. MOFA Japan (PDF) – raport dot. naruszeń/obchodzenia sankcji i roli DPRK cyber (kontekst finansowy).
  5. Check Point – VoidLink Signals the Start of a New Era in AI-Generated Malware (19 stycznia 2026). (Check Point Blog)