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

Tag: AI

Security analysis Moltbook: bot-to-bot prompt injection, wycieki danych i „agentowe” kampanie socjotechniczne

Wprowadzenie do problemu / definicja luki

Moltbook to „sieć społecznościowa dla agentów AI” powiązana z ekosystemem OpenClaw (wcześniej Moltbot/Clawdbot): autonomiczne boty publikują, komentują i wchodzą w interakcje bez bezpośredniego udziału człowieka. W takim modelu bezpieczeństwo nie kończy się na typowych podatnościach aplikacji webowej – dochodzi warstwa interakcji agent-agent, gdzie atakujący manipuluje zachowaniem innych botów, wstrzykując im złośliwe instrukcje (prompt injection) i „socjotechnikę” w formie treści. SecurityWeek opisał analizę Wiz i Permiso, wskazując zarówno wyciek danych, jak i bot-to-bot prompt injection jako realne, już obserwowane wektory nadużyć.

W skrócie

  • Wiz wykrył ekspozycję, która dawała odczyt i zapis do produkcyjnej bazy Moltbook (wprost: klucz/API umożliwiający pełny dostęp do DB). Skutkiem było ujawnienie m.in. ~1,5 mln tokenów uwierzytelniających, ~35 tys. adresów e-mail oraz prywatnych wiadomości między agentami; problem miał zostać szybko załatany po zgłoszeniu.
  • Permiso opisał złośliwe agentowe zachowania: wpływowe operacje, próby manipulacji, prompt injection wymierzone w inne boty (np. instrukcje skłaniające do działań autodestrukcyjnych kont, budowania fałszywego autorytetu, rozpowszechniania jailbreaków, czy schematów finansowych).
  • Równolegle rośnie ryzyko „agentowego supply chain”: złośliwe „skills” (wtyczki/umiejętności) w marketplace ClawHub, które mogą prowadzić do infekcji i kradzieży danych, jeśli użytkownicy uruchamiają kod o nieznanym pochodzeniu.

Kontekst / historia / powiązania

Moltbook wyrósł na fali popularności OpenClaw – narzędzia pozwalającego agentowi wykonywać realne akcje (np. polecenia w terminalu, integracje, wysyłkę wiadomości). Wokół powstały:

  • ClawHub/MoltHub – rynek „skills”, czyli rozszerzeń funkcjonalnych,
  • Moltbook – miejsce, gdzie same boty „rozmawiają” i wymieniają się promptami/treściami.

Ten model dramatycznie zwiększa powierzchnię ataku: nawet jeśli infrastruktura jest zabezpieczona, to treść staje się ładunkiem. A jeśli infrastruktura nie jest zabezpieczona (np. błędna konfiguracja bazy), skutki są natychmiastowe i masowe.

Analiza techniczna / szczegóły luki

1) Ekspozycja dostępu do bazy (Wiz)

Wiz opisał przypadek, w którym ujawniony sekret/klucz dawał read/write do produkcyjnej bazy danych Moltbook. W konsekwencji możliwy był dostęp do danych wrażliwych, w tym tokenów i wiadomości agentów. SecurityWeek cytuje liczby: 1,5 mln tokenów, 35 tys. e-maili, oraz prywatne wiadomości między agentami.

To klasyczny przykład tego, jak „zwykła” usterka (sekret w złym miejscu / zbyt szerokie uprawnienia / brak właściwego modelu dostępu) w systemie agentowym eskaluje szybciej: tokeny stają się kluczami do przejmowania tożsamości i działań agentów.

2) Bot-to-bot prompt injection (Permiso)

Permiso zwraca uwagę na nadużycia, które nie wymagają łamania backendu: boty atakują boty, wykorzystując fakt, że agenci traktują treści jako instrukcje. W opisie pojawiają się m.in.:

  • prompt injection nakłaniające inne boty do działań typu „usuń konto”,
  • próby manipulacji finansowej (np. schematy pomp na krypto),
  • budowanie fałszywego autorytetu i socjotechnika „na zaufanie”,
  • dystrybucja treści jailbreakujących, zwiększających ryzyko nadużyć.

3) Złośliwe „skills” i agentowy supply chain (ClawHub)

Jeśli „skill” jest w praktyce kodem uruchamianym lokalnie lub z szerokimi uprawnieniami, to marketplace staje się łańcuchem dostaw. SC Media relacjonował ustalenia Koi Security o setkach złośliwych „skills” (m.in. malware, stealery, backdoory).

Praktyczne konsekwencje / ryzyko

Najważniejsze ryzyka w takim ekosystemie układają się w trzy warstwy:

  1. Ryzyko danych i tożsamości
    Wyciek tokenów i wiadomości to nie tylko naruszenie prywatności – to możliwość podszywania się pod agentów, przejmowania ich reputacji oraz „wstrzykiwania” działań w ich imieniu.
  2. Ryzyko behawioralne (manipulacja agentów)
    Prompt injection między botami przenosi socjotechnikę na poziom maszynowy: atakujący nie musi przekonywać człowieka – przekonuje system decyzyjny agenta, który ma skłonność do wykonywania poleceń z treści.
  3. Ryzyko wykonawcze (agent z uprawnieniami + złośliwy kod)
    Połączenie autonomii, integracji i „skills” może prowadzić do realnych szkód: kradzieży danych lokalnych, tokenów, plików, a w skrajnym przypadku – wykonania złośliwych komend w środowisku użytkownika/organizacji.

Rekomendacje operacyjne / co zrobić teraz

Jeśli korzystasz z agentów (OpenClaw lub podobnych) lub budujesz platformę agentową:

  1. Zamknij „kran” z sekretami
  • rotuj tokeny/klucze, skróć TTL, wprowadź scoping (najmniejsze możliwe uprawnienia),
  • traktuj token agenta jak konto uprzywilejowane: monitoring, anomaly detection, revocation.
  1. Wprowadź twardą izolację wykonawczą
  • sandbox/VM/kontenery dla każdego „skilla” i dla akcji wysokiego ryzyka,
  • kontrola egress (DNS/HTTP), allowlist domen i blokowanie exfiltracji,
  • blokada dostępu do katalogów z sekretami (np. ~/.ssh, przeglądarki, menedżery haseł).
  1. Uodpornij agentów na prompt injection (treść jako nieufne wejście)
  • separuj „instrukcje systemowe” od treści zewnętrznych (postów/komentarzy),
  • stosuj klasyfikację treści (np. wykrywanie próśb o sekrety, poleceń autodestrukcyjnych, jailbreaków),
  • wprowadź „policy gate”: agent nie wykonuje działań bez jawnego spełnienia reguł (np. podpis, zgoda, dodatkowa weryfikacja).
  1. Zabezpiecz łańcuch dostaw „skills”
  • podpisywanie rozszerzeń, weryfikacja wydawcy, reputacja/telemetria,
  • automatyczny skaner (SAST/antymalware) + blokady na obfuskację i zdalne pobieranie kodu,
  • domyślnie „deny”, dopiero potem allowlist.
  1. Dla organizacji: polityka „agentów uprzywilejowanych”
  • osobne konta/sekrety dla agentów, brak dostępu do krytycznych zasobów,
  • logowanie działań, ścieżka audytu, mechanizmy break-glass.

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

  • Klasyczne prompt injection zwykle dotyczy aplikacji, gdzie człowiek „pyta” model. W Moltbook/agentach mamy prompt injection kaskadowe: boty generują treści, które stają się wejściem dla kolejnych botów – skala i szybkość propagacji rośnie nieliniowo.
  • W typowych incydentach wycieku API klucz jest „tylko” furtką do danych. W modelu agentowym token może być furtką do tożsamości i akcji (agent działa dalej, w twoim imieniu).
  • Marketplace „skills” przypomina rozszerzenia przeglądarkowe lub pakiety OSS – ale ryzyko jest większe, bo agent ma często „palec na spuście” (terminal, pliki, integracje).

Podsumowanie / kluczowe wnioski

Moltbook jest dobrym studium przypadku: w świecie agentów AI bezpieczeństwo to jednocześnie backend (sekrety i uprawnienia) oraz warstwa behawioralna (treść jako atak). Analizy Wiz i Permiso pokazują, że zagrożenia są „tu i teraz”: od wycieków tokenów i wiadomości po bot-to-bot prompt injection i manipulacje finansowe.

Najważniejsza praktyka: traktuj każdego agenta jak uprzywilejowaną usługę i każdą treść jak potencjalnie złośliwe wejście. Bez tego „autonomia” bardzo szybko staje się wektorem eskalacji.

Źródła / bibliografia

  1. SecurityWeek – Security Analysis of Moltbook Agent Network: Bot-to-Bot Prompt Injection and Data Leaks (SecurityWeek)
  2. Wiz – Exposed Moltbook database reveals millions of API keys (wiz.io)
  3. Permiso – Inside the OpenClaw Ecosystem: AI agents with privileged credentials (permiso.io)
  4. SC Media – OpenClaw agents targeted with 341 malicious ClawHub skills (Koi Security findings) (SC Media)

Krytyczne luki w n8n: CVE-2026-25049 z publicznymi exploitami umożliwia przejęcie serwera (RCE)

Wprowadzenie do problemu / definicja luki

n8n to popularna platforma do automatyzacji workflow (często również jako „AI workflow automation”), w której użytkownicy konfigurują przepływy danych, integracje i logikę (m.in. poprzez wyrażenia JavaScript w parametrach węzłów). Ta elastyczność jest jednocześnie największym ryzykiem: jeżeli mechanizm „sandboxowania” i sanityzacji wyrażeń jest niekompletny, użytkownik z uprawnieniami do tworzenia/edycji workflow może doprowadzić do wyjścia z sandboxa (sandbox escape) i uruchomienia kodu na hoście.

Właśnie to dotyczy CVE-2026-25049 – krytycznej podatności prowadzącej do zdalnego wykonania kodu (RCE), dla której opisano publiczne PoC/exploity.

W skrócie

  • CVE-2026-25049: krytyczna podatność n8n umożliwiająca RCE poprzez obejście mechanizmu sanityzacji/sandboxa wyrażeń używanych w workflow.
  • Wektor ataku: typowo wymaga konta z możliwością tworzenia lub edycji workflow (PR:L), ale skutki to pełne przejęcie instancji/serwera.
  • Skutki: kradzież sekretów (API keys, OAuth), danych konfiguracyjnych, pivot do systemów wewnętrznych i kont chmurowych; w środowiskach multi-tenant potencjalne ryzyko „przeskoku” w obrębie klastra/usług wewnętrznych.
  • Poprawki: zalecane aktualizacje do najnowszych wydań (w praktyce w obiegu komunikatów pojawiają się linie 1.x oraz 2.x; przykładowo wskazywane są 1.123.17 i 2.5.2 jako wersje docelowe).

Kontekst / historia / powiązania

To nie jest pierwszy raz, gdy n8n trafia na radar z krytycznymi podatnościami w krótkim oknie czasu:

  • CVE-2026-25049 została opisana jako obejście wcześniejszej poprawki na inną krytyczną podatność (w doniesieniach pojawia się CVE-2025-68613), co sugeruje problem klasy „patch bypass” i trudność w domknięciu całej klasy błędów w mechanizmie izolacji wyrażeń.
  • W styczniu 2026 r. n8n publikowało także advisory dotyczące podatności w określonych typach workflow (form-based), naprawionej w wersji 1.121.0 – to pokazuje, że powierzchnia ataku bywa szeroka i zależna od konfiguracji przepływów.

W praktyce: jeśli n8n jest „centralnym kręgosłupem automatyzacji” (a często jest), to skuteczny exploit nie kończy się na samym serwerze n8n — kończy się na tym, do czego n8n ma dostęp.

Analiza techniczna / szczegóły luki

1) Gdzie leży problem

Kluczowy element to sposób, w jaki n8n interpretuje i „oczyszcza” wyrażenia (Expressions) w workflow. Raporty badaczy wskazują na niekompletną izolację kontekstu wykonania oraz luki w sanityzacji, które dają się ominąć równoważnymi konstrukcjami językowymi (typowy „denylist bypass”).

2) Dlaczego to kończy się RCE

Wyrażenia, które miały być „bezpieczne”, mogą uzyskać dostęp do obiektów środowiska uruchomieniowego (np. kontekstu Node.js), co prowadzi do:

  • wykonania poleceń systemowych,
  • dostępu do systemu plików,
  • odczytu sekretów i konfiguracji,
  • uruchomienia kolejnych etapów łańcucha ataku.

3) Wersje i poprawki

W publicznych opisach podatności (rekord CVE oraz komunikaty branżowe) pojawia się zakres „przed” określonymi wersjami w liniach 1.x i 2.x (np. przed 1.123.17 i 2.5.2).

Praktyczne konsekwencje / ryzyko

Jeśli atakujący uzyska możliwość edycji workflow (np. przez:

  • przejęcie konta operatora,
  • błędnie skonfigurowane role,
  • dostęp współdzielony w organizacji/kliencie),
    to CVE-2026-25049 może pozwolić na:
  • Kradzież wszystkich credentiali przechowywanych w n8n (API keys, OAuth tokens, sekrety integracji).
  • Ruch lateralny: pivot do systemów, z którymi n8n się łączy (bazy danych, CI/CD, chmura, SaaS).
  • Sabotaż procesów i „ciche” manipulacje: podmiana logiki workflow, modyfikowanie danych, przekierowania, w kontekście AI również możliwość ingerencji w przepływy promptów/odpowiedzi.
  • W środowiskach multi-tenant: ryzyko dotknięcia innych danych/tenantów poprzez dostęp do usług wewnętrznych klastra.

Warto podkreślić: „tylko uwierzytelniony użytkownik” w praktyce często oznacza każdy, kto dostanie najniższe uprawnienia edycyjne w narzędziu automatyzacji — a to bywa łatwiejsze niż klasyczny RCE z internetu.

Rekomendacje operacyjne / co zrobić teraz

  1. Aktualizacja n8n natychmiast
  • Zaktualizuj do wersji naprawiających CVE-2026-25049 wskazywanych w komunikatach (w obiegu: np. 1.123.17 i 2.5.2 jako bezpieczne punkty dla odpowiednich linii).
  1. Ogranicz uprawnienia do tworzenia/edycji workflow
  • Traktuj workflow-edit jako uprawnienie uprzywilejowane (admin-like).
  • Zastosuj zasadę najmniejszych uprawnień, osobne konta serwisowe, MFA/SSO jeśli dostępne.
  • GitHub advisory wprost podaje: ograniczyć tworzenie/edycję workflow do w pełni zaufanych użytkowników jako doraźne ograniczenie ryzyka.
  1. Rotacja sekretów
  • Po aktualizacji rozważ rotację N8N_ENCRYPTION_KEY oraz wszystkich credentiali i tokenów przechowywanych/obsługiwanych przez n8n (zwłaszcza chmura/CI/CD). To zalecenie pojawia się w rekomendacjach operacyjnych po publikacji podatności.
  1. Przegląd workflow pod kątem wskaźników nadużyć
  • Szukaj podejrzanych wyrażeń w parametrach węzłów, nieoczekiwanych zmian, nowych workflow, nietypowych integracji/endpointów.
  • Zweryfikuj logi uruchomień workflow oraz zmiany konfiguracji.
  1. Hardening środowiska uruchomieniowego
  • Uruchamiaj n8n w środowisku o ograniczonych uprawnieniach OS (non-root), z restrykcyjnym AppArmor/SELinux (gdzie możliwe), ograniczeniami syscalls/kapabilitami.
  • Segmentacja sieci + ograniczenie egress: n8n nie powinien „móc wszędzie”.
  • GitHub advisory podkreśla, że hardening i ograniczenia sieciowe zmniejszają wpływ ewentualnej eksploatacji, choć nie usuwają przyczyny.

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

  • CVE-2026-25049 to klasyczny przypadek „sandbox escape → RCE” w mechanizmie interpretacji logiki użytkownika (Expressions). Gdy bezpieczeństwo opiera się o sanityzację/denylisty, często kończy się to obejściami, bo język (JS) ma wiele równoważnych konstrukcji.
  • W przeciwieństwie do podatności zależnych od specyficznych typów workflow (np. form-based scenariusze w advisory n8n), tutaj ryzyko jest „bardziej systemowe”: dotyka samego mechanizmu wyrażeń używanego bardzo szeroko w automatyzacjach.

Podsumowanie / kluczowe wnioski

  • CVE-2026-25049 to krytyczna podatność n8n umożliwiająca przejęcie serwera poprzez mechanizm wyrażeń w workflow — a PoC/exploity są publicznie opisywane.
  • Realne ryzyko jest szczególnie wysokie tam, gdzie n8n ma szerokie integracje i dostęp do sekretów: udany atak często oznacza przejęcie całego łańcucha automatyzacji.
  • Najważniejsze działania: patch now, ograniczenie uprawnień edycyjnych workflow, rotacja sekretów i hardening środowiska.

Źródła / bibliografia

  1. BleepingComputer — „Critical n8n flaws disclosed along with public exploits” (BleepingComputer)
  2. GitHub Advisory Database — GHSA-6cqr-8cfr-67f8 / CVE-2026-25049 (GitHub)
  3. Pillar Security — opis podatności „sandbox escape” w n8n (pillar.security)
  4. Endor Labs — analiza i kontekst obejścia sanityzacji (CVE-2026-25049) (endorlabs.com)
  5. Oficjalny rekord CVE (cve.org) — CVE-2026-25049 (cve.org)

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)

OpenClaw: luka CVE-2026-25253 umożliwia 1-klikowe RCE przez złośliwy link

Wprowadzenie do problemu / definicja luki

W OpenClaw ujawniono podatność o wysokiej istotności, która pozwala na zdalne wykonanie kodu (RCE) po jednym kliknięciu w link. Błąd otrzymał identyfikator CVE-2026-25253 i ocenę CVSS 8.8 (HIGH).

Łańcuch ataku jest szczególnie niebezpieczny, bo wykorzystuje typowy przepływ w przeglądarce (wejście na stronę) do wykradzenia tokenu uwierzytelniającego, a następnie przejęcia „gateway” narzędzia – co w praktyce może skończyć się pełną kontrolą nad hostem, na którym działa agent.

W skrócie

  • Co jest podatne: wersje OpenClaw przed 2026.1.29.
  • Wektor: użytkownik musi odwiedzić złośliwą stronę / kliknąć link (UI:R w CVSS).
  • Sedno problemu: UI kontrolne ufa parametrowi gatewayUrl z query string i automatycznie łączy się po WebSocket, wysyłając zapisany token.
  • Skutek: kradzież tokenu → operator-level dostęp do gateway API → zmiany konfiguracji i wykonanie kodu na hoście.
  • Naprawa: aktualizacja do 2026.1.29 (wydana 30 stycznia 2026) lub nowszej.

Kontekst / historia / powiązania

OpenClaw to self-hosted agent AI, który potrafi automatyzować działania w systemie (uruchamianie poleceń, praca na plikach, orkiestracja workflow). Taka klasa narzędzi ma „naturalnie” wysoki blast radius — przejęcie sesji operatora zwykle oznacza dostęp do wszystkiego, do czego agent ma uprawnienia.

W tym incydencie kluczowe jest to, że atak nie wymaga bezpośredniego dostępu do hosta ofiary na start — wystarcza przejęcie tokenu z warstwy przeglądarkowej, a resztę „dowozi” API/agent po stronie gateway.

Analiza techniczna / szczegóły luki

1) Zaufanie do gatewayUrl z query string

Opis podatności wskazuje, że aplikacja (Control UI) pobiera gatewayUrl z parametrów URL i używa go do zestawienia połączenia. W wersjach podatnych brakuje walidacji/ograniczeń, przez co atakujący może podstawić własny adres.

2) Automatyczne połączenie WebSocket i „wyciek” tokenu

Najbardziej krytyczny element: UI auto-connectuje po załadowaniu, a w payloadzie połączenia WebSocket wysyła zapisany token gateway. Jeśli gatewayUrl wskazuje na serwer atakującego, token trafia wprost do niego.

3) Co daje token: przejęcie gateway i droga do RCE

Po przechwyceniu tokenu atakujący może połączyć się z instancją OpenClaw ofiary i uzyskać dostęp o poziomie operatora do gateway API, co umożliwia arbitralne zmiany konfiguracji i wykonanie kodu na hoście gateway. W praktyce oznacza to klasyczne „account/session takeover”, ale dla komponentu, który ma bardzo szerokie uprawnienia systemowe.

4) Warunek wstępny (ważne w ocenie ryzyka)

Podatność dotyczy wdrożeń, w których użytkownik zalogował się do Control UI (token istnieje i jest możliwy do wysłania). To typowy warunek dla ataków opartych o kradzież sesji.

Praktyczne konsekwencje / ryzyko

Skutki dla organizacji i użytkowników technicznych są ciężkie:

  • kompromitacja hosta (RCE) i przejęcie środowiska automatyzacji,
  • dostęp do lokalnie przechowywanych danych i poświadczeń, jeśli agent ma do nich uprawnienia,
  • szybka eskalacja do incydentu klasy „full takeover”, bo agent bywa „mostem” do systemów, przeglądarek, plików i integracji.

Warto też podkreślić „operacyjny” aspekt 1-kliku: takie wektory świetnie sklejają się z phishingiem, drive-by oraz kampaniami w mediach społecznościowych, bo kliknięcie linku jest zachowaniem powszechnym i trudnym do wyeliminowania politykami.

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj do OpenClaw 2026.1.29 lub nowszej wszędzie, gdzie narzędzie jest używane (dev/staging/prod).
  2. Rotacja/rewokacja tokenów i kluczy
    Jeśli w Twoim modelu wdrożenia tokeny są długowieczne, rozważ ich wymuszoną rotację po aktualizacji (aby „stare” wykradzione tokeny przestały działać).
  3. Ogranicz ekspozycję Control UI
  • wystawiaj panel administracyjny tylko za VPN / w sieci wewnętrznej,
  • rozważ dodatkową warstwę uwierzytelnienia (np. reverse proxy z SSO/MFA),
  • stosuj twarde reguły origin/host (allowlist) dla połączeń do gateway.
  1. Hardening po stronie aplikacji (jeśli utrzymujesz fork / wkład w projekt)
  • walidacja gatewayUrl (allowlist domen, schematów, portów),
  • usunięcie auto-connect lub wymuszenie świadomej zgody użytkownika,
  • ograniczenie sposobu przechowywania i wysyłania tokenów (minimalizacja ekspozycji w kontekście przeglądarki).
    To są dokładnie te elementy, które według opisu doprowadziły do eksfiltracji tokenu.
  1. Monitoring i detekcja nadużyć
  • szukaj nietypowych połączeń WebSocket i nieoczekiwanych zmian konfiguracji gateway,
  • koreluj logowania/wykorzystanie tokenów z anomaliami w zadaniach agenta (uruchamianie poleceń, modyfikacje plików),
  • dodaj alerty na „operator-level actions”, jeśli Twoja telemetria to rozróżnia.

Różnice / porównania z innymi przypadkami

CVE-2026-25253 to dobry przykład, że w agentach AI „prawdziwym wrogiem” bywa nie tyle model, co warstwa sterowania i zaufania między komponentami (UI → gateway). Klasyczne błędy webowe (zaufanie do danych wejściowych z URL, automatyczne połączenia, tokeny w nieodpowiednim kontekście) stają się krytyczne, gdy backend ma możliwość wykonywania działań systemowych.

W praktyce to wzorzec: session/token theft w narzędziu o wysokich uprawnieniach daje efekt porównywalny do RCE — bo „legalne” API umożliwia wykonanie tych samych destrukcyjnych czynności, tylko „w białych rękawiczkach”.

Podsumowanie / kluczowe wnioski

  • CVE-2026-25253 to 1-klikowe przejęcie OpenClaw prowadzące do RCE przez eksfiltrację tokenu WebSocket.
  • Problem wynika z połączenia: zaufanie do gatewayUrl + auto-connect + wysyłka tokenu.
  • Aktualizacja do 2026.1.29 jest podstawową mitigacją, a dodatkowo warto utwardzić ekspozycję Control UI i rotować tokeny.

Źródła / bibliografia

  • The Hacker News — opis podatności i informacja o wersji naprawczej. (The Hacker News)
  • CCB Safeonweb — ostrzeżenie i zakres wersji podatnych. (ccb.belgium.be)
  • National Vulnerability Database (NIST) — rekord CVE i metryki. (NVD)
  • runZero — podsumowanie wpływu i zakresu wersji. (runZero)
  • SecurityWeek — opis scenariusza ataku i konsekwencji „gateway takeover”. (SecurityWeek)

Złośliwe „skills” dla OpenClaw/MoltBot: nowy wektor ataku łańcucha dostaw i kradzieży haseł

Wprowadzenie do problemu / definicja luki

W ekosystemie self-hosted agentów AI pojawił się klasyczny problem supply chain — tyle że zamiast paczek npm/PyPI, celem stały się „skills” (wtyczki/pakiety funkcjonalności) dla osobistego asystenta AI OpenClaw (wcześniej: Moltbot/ClawdBot). Atakujący masowo publikują „skills” udające narzędzia (np. do krypto, finansów, social mediów), a w praktyce służące do instalacji infostealerów i kradzieży danych uwierzytelniających.

W skrócie

  • W krótkim oknie czasu (ok. 27 stycznia – 1 lutego 2026) opublikowano setki podejrzanych/złośliwych „skills” w rejestrze ClawHub i na GitHub.
  • Infekcja zwykle wymaga, by ofiara ręcznie wykonała instrukcje z dokumentacji („Prerequisites”), co przypomina schemat ClickFix: użytkownik sam uruchamia polecenie/pobiera narzędzie, bo „jest potrzebne do działania”.
  • Na macOS w łańcuchu pojawia się m.in. zdejmowanie atrybutu kwarantanny (xattr -c) w celu obejścia mechanizmów typu Gatekeeper oraz kradzież danych z pęku kluczy i profili przeglądarek.
  • Niezależnie od szczegółów payloadu, kluczowy problem jest systemowy: agent AI działa lokalnie i ma „głębokie” uprawnienia, a „skills” są w praktyce kodem wykonywalnym.

Kontekst / historia / powiązania

OpenClaw/MoltBot stał się wiralowy jako „personal AI agent” uruchamiany lokalnie, z pamięcią długoterminową i integracjami z usługami (komunikatory, e-mail, pliki, automatyzacje). Taka architektura jest atrakcyjna, ale z perspektywy bezpieczeństwa oznacza, że kompromitacja ekosystemu rozszerzeń jest kompromitacją hosta i danych użytkownika. Cisco zwraca uwagę, że narzędzia tego typu potrafią automatyzować działania, uruchamiać skrypty i operować na zasobach, co znacząco podnosi stawkę przy błędach w modelu uprawnień i dystrybucji rozszerzeń.

Równolegle pojawia się drugi wątek: poza zatruciem marketplace’u „skills”, badacze i źródła threat-intel wskazują też na błędnie wystawione interfejsy administracyjne oraz ryzyka wynikające z przechowywania sekretów w plikach i zdalnej ekspozycji usług.

Analiza techniczna / szczegóły luki

1) Mechanizm dystrybucji: „skills” jako nośnik zaufanego kodu

„Skills” są opisywane jako łatwo wdrażalne wtyczki/rozszerzenia. W praktyce atak polega na tym, że publikowane paczki:

  • klonują się masowo (bliźniacze repozytoria, losowe nazwy),
  • mają dopracowaną dokumentację,
  • podszywają się pod narzędzia o wysokiej „wartości” dla ofiar (krypto, finanse, narzędzia produktywności).

2) Socjotechnika „Prerequisites” i fałszywe narzędzia („AuthTool” / „openclaw-agent”)

W opisywanych kampaniach kluczowy jest punkt „Prerequisites”. To tam użytkownik dostaje instrukcję:

  • na macOS: wkleić do terminala polecenie (często base64 → bash, z pobraniem skryptu/payloadu z zewnętrznego hosta),
  • na Windows: pobrać i uruchomić archiwum ZIP (często zaszyfrowane hasłem, co utrudnia automatyczne skanowanie).

Koi Security opisuje też, że ZIP z hasłem jest używany nie „dla bezpieczeństwa”, ale jako taktyka przeciwko automatycznym analizatorom i AV w pipeline’ach.

3) Payload i kradzież danych: macOS i Windows

Z perspektywy skutków, celem jest klasyczny infostealer:

  • BleepingComputer wskazuje na wariant NovaStealer na macOS, który potrafi m.in. zdejmować kwarantannę (xattr -c), żądać szerokiego dostępu do plików i wyciągać dane takie jak: klucze API giełd krypto, seed phrases, dane z rozszerzeń walletów, dane z Keychain, hasła przeglądarki, klucze SSH, poświadczenia chmurowe, Git credentials i pliki .env.
  • Koi Security w swojej analizie przypisuje główną falę do kampanii (nazwanej ClawHavoc) i identyfikuje macOS-owy stealer jako Atomic Stealer (AMOS), opisując charakterystyczny łańcuch (pobranie skryptu → dropper → uruchomienie binarki) oraz szeroki zakres kradzionych artefaktów (przeglądarki, portfele, SSH, komunikatory).

W praktyce możliwe są rozbieżności w klasyfikacji rodziny malware (NovaStealer vs AMOS), bo część zachowań/artefaktów może być współdzielona lub zmieniana w kolejnych wariantach — dla obrony ważniejsze jest rozpoznanie TTP: ręczne uruchamianie „prerekwizytów”, download z zewnętrznych domen/IP, zdejmowanie kwarantanny i masowa eksfiltracja sekretów.

4) Skala i dodatkowe techniki (typosquatting, outliery)

  • Audyt cytowany przez The Hacker News mówi o 341 złośliwych „skills” na ClawHub (na tle ~2,857 sprawdzonych), z dominującą kampanią i dodatkowymi odchyleniami.
  • Wskazano też typosquatting (warianty nazw związanych z ClawHub), co zwiększa skuteczność infekcji przy literówkach i instalacjach „na skróty”.

Praktyczne konsekwencje / ryzyko

Ten incydent jest groźny nie tylko przez samą liczbę złośliwych paczek, ale przez kontekst użycia:

  • Agent AI ma dostęp do plików, przeglądarki, tokenów, integracji z usługami i często działa „jak użytkownik” — z naturalną zdolnością do eskalacji skutków kompromitacji (np. dostęp do repozytoriów, CI/CD, e-maila).
  • Kradzież .env, kluczy API, SSH i poświadczeń chmurowych oznacza ryzyko przejęcia kont i infrastruktury, a nie tylko „wycieku haseł z przeglądarki”.
  • Jeśli instancje administracyjne są wystawione do internetu lub słabo zabezpieczone, dochodzi dodatkowa powierzchnia ataku: przejęcie zarządzania agentem lub wykorzystanie go jako backdoora.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań „tu i teraz” — w kolejności od najszybszych do bardziej systemowych:

1) Natychmiastowe ograniczenie ryzyka

  • Wstrzymaj instalację nowych „skills” z publicznych rejestrów w zespołach/firmie do czasu wdrożenia zasad weryfikacji.
  • Potraktuj „skill” jak binarkę: jeśli ktoś każe wkleić komendę do terminala albo pobrać „narzędzie wymagane do działania” — to czerwony alarm.
  • Jeżeli instalowano „skills” w ostatnich dniach: rotuj sekrety (API keys, tokeny, SSH, klucze do giełd), sprawdź logi dostępu i nietypowe logowania.

2) Walidacja i skanowanie

  • Weryfikuj publishera, historię repo, podobieństwa nazw, a także czy nie ma „Prerequisites” z obfuskacją (base64, curl|bash).
  • Skorzystaj z narzędzi do oceny „skills” publikowanych przez badaczy (np. skaner URL od Koi Security) jako dodatkowego sygnału, nie jedynego kontrolera.

3) Izolacja środowiska (najważniejsze przy agentach AI)

  • Uruchamiaj OpenClaw w VM/kontenerze z minimalnymi uprawnieniami i separacją od głównego profilu przeglądarki, kluczy SSH i repozytoriów (zasada najmniejszych uprawnień).
  • Ogranicz egress (firewall, allowlist domen), bo większość łańcuchów infekcji i eksfiltracji wymaga połączeń wychodzących.

4) Governance „skills” w organizacji

  • Wprowadź allowlist zatwierdzonych „skills”, wersjonowanie i pinning (konkretne commity/release), a docelowo podpisywanie/artefakty z kontrolą integralności.
  • Rozważ całkowite wyłączenie mechanizmu „skills”, jeśli nie potrafisz go kontrolować (SOC Prime wprost sugeruje rozważenie ograniczenia tej funkcji bez odpowiedniego nadzoru).

5) Detekcja i IR

  • Monitoruj: nietypowe procesy powłoki, curl/bash w kontekście instalacji, zdejmowanie kwarantanny (xattr -c), nowe binarki w katalogach tymczasowych, nietypowy ruch do nieznanych hostów.
  • Jeśli podejrzewasz kompromitację: izoluj host, zbierz artefakty, zresetuj poświadczenia, przeprowadź przegląd integracji agenta z usługami (mail, repo, kalendarze) i rozważ reinstalację w utwardzonym środowisku.

Różnice / porównania z innymi przypadkami

To zdarzenie wpisuje się w dobrze znany schemat:

  • marketplace/registry → masowe paczki → socjotechnika → payload (jak w atakach na npm/PyPI/VS Code). Koi Security wprost porównuje ClawHub do popularnych ekosystemów paczek, wskazując, że „tam gdzie deweloperzy dzielą się kodem, tam pojawiają się atakujący”.
  • Różnica jest taka, że tutaj ofiary instalują rozszerzenia dla narzędzia, które z założenia ma szeroki dostęp i automatyzuje działania, więc „blast radius” może być większy niż przy typowej wtyczce do IDE.

Podsumowanie / kluczowe wnioski

  • Publiczny ekosystem „skills” dla OpenClaw/MoltBot stał się celem masowego zatrucia łańcucha dostaw, a skutkiem jest dystrybucja infostealerów i kradzież sekretów.
  • Najczęstszy wektor to „Prerequisites” i ręczne uruchamianie poleceń/instalatorów (ClickFix-like), co omija część automatycznych kontroli.
  • Najskuteczniejsza obrona to połączenie: izolacji środowiska agenta, twardego governance rozszerzeń oraz szybkiej rotacji sekretów, jeśli instalacje już miały miejsce.

Źródła / bibliografia

  1. (BleepingComputer) – BleepingComputer: skala kampanii, „AuthTool”, ClickFix-like, NovaStealer i zakres kradzieży
  2. (koi.ai) – Koi Security: audyt 2,857 „skills”, 341 złośliwych, ClawHavoc, techniki i łańcuch macOS
  3. (The Hacker News) – The Hacker News: podsumowanie ustaleń Koi i kategorie kampanii na ClawHub
  4. (Cisco Blogs) – Cisco Blogs: ryzyka architektoniczne „personal AI agents” i konsekwencje braku sandboxingu/governance
  5. (SOC Prime) – SOC Prime: perspektywa threat-intel (ekspozycja admin portów, sekrety w plikach, mitigacje)

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)

Hugging Face wykorzystany do dystrybucji tysięcy wariantów malware na Androida: kampania TrustBastion i „Premium Club”

Wprowadzenie do problemu / definicja luki

W końcówce stycznia 2026 r. badacze opisali kampanię Android RAT, w której przestępcy wykorzystali Hugging Face jako „zaufaną” infrastrukturę do hostowania i pobierania złośliwych plików APK. To nie jest klasyczna „luka” w sensie CVE, lecz nadużycie platformy (abuse): atakujący składowali payload w repozytoriach/datasetach, a ofiara pobierała go z domen i CDN, które rzadziej wzbudzają podejrzenia lub blokady.

W skrócie

  • Infekcja startowała od droppera „TrustBastion” podszywającego się pod narzędzie bezpieczeństwa i straszącego „zainfekowanym telefonem”.
  • Dropper nie serwował malware bezpośrednio – pobierał link przekierowujący do datasetu na Hugging Face, skąd ściągany był docelowy APK (również przez CDN Hugging Face).
  • Kampania używała polimorfizmu po stronie serwera: nowe warianty payloadu pojawiały się ~co 15 minut; repozytorium miało >6 tys. commitów w ~29 dni.
  • Payload nadużywał Accessibility Services oraz żądał uprawnień do overlay, przechwytywania ekranu itp., by kraść dane logowania (m.in. podszycia pod Alipay i WeChat) i utrzymać kontrolę.

Kontekst / historia / powiązania

To zdarzenie wpisuje się w szerszy trend: platformy współdzielenia artefaktów (repozytoria kodu, paczek, modeli, datasetów) są atrakcyjne dla atakujących, bo zapewniają:

  • renomę domeny (mniejsza podejrzaność),
  • wygodny hosting i dystrybucję,
  • szybkie iteracje (automatyzacja publikacji nowych wariantów).

W przypadku Hugging Face problem nie jest nowy: społeczność i firmy bezpieczeństwa od co najmniej 2024 r. ostrzegają przed możliwością dostarczania złośliwych treści (np. modeli prowadzących do wykonania kodu przy ładowaniu).
Jednocześnie Hugging Face rozwija mechanizmy bezpieczeństwa dla zasobów AI (np. skanowanie i alerty realizowane we współpracy z Protect AI), ale omawiana kampania pokazuje, że przestępcy potrafią „zmieścić się” w lukach kontroli treści – szczególnie gdy w grę wchodzą pliki binarne/instalatory i agresywny polimorfizm.

Analiza techniczna / szczegóły luki

1) Łańcuch infekcji (dropper → payload)

  1. Ofiara trafia na reklamę/scareware sugerującą infekcję i instalację „ochrony”. Instaluje aplikację TrustBastion (sideload).
  2. Po uruchomieniu dropper wyświetla obowiązkowy „update” z elementami łudząco podobnymi do Google Play/systemu.
  3. Dropper łączy się z trustbastion[.]com, ale zamiast pobierać APK, dostaje odpowiedź zawierającą URL do Hugging Face (dataset/repo), skąd pobiera finalny payload (APK) – finalnie po redirect do CDN Hugging Face.

2) Skala i polimorfizm

Bitdefender odnotował masowe tempo zmian: nowe buildy wrzucane ok. co 15 minut, a repozytorium miało ponad 6000 commitów przy wieku ok. 29 dni (w momencie analizy). Cel: omijanie detekcji opartej o hashe.

3) Zachowanie payloadu (RAT/spyware)

Po instalacji payload:

  • nakłania do włączenia Accessibility Services, podszywając prośbę pod „funkcję bezpieczeństwa/verification”; po uzyskaniu dostępu RAT zyskuje szeroką obserwowalność i kontrolę interakcji użytkownika,
  • dodatkowo prosi o uprawnienia umożliwiające nagrywanie/udostępnianie ekranu oraz overlay, co pozwala przechwytywać i manipulować treścią na ekranie w czasie rzeczywistym,
  • pokazuje fałszywe ekrany logowania (m.in. podszycia pod Alipay i WeChat) w celu kradzieży danych uwierzytelniających oraz przechwytuje informacje dot. blokady ekranu.

4) C2 i wskaźniki (IOCs) z publikacji badaczy

W raporcie wskazano m.in.:

  • C2: IP 154.198.48.57 (port 5000) i domenę trustbastion[.]com, a także w „drugiej fali” au-club[.]top oraz IP 108.187.7.133.
  • przykładowe nazwy pakietów: m.in. rgp.lergld.vhrthg oraz com.nrb.phayrucq.

Uwaga operacyjna: IoC szybko się „starzeją” w kampaniach polimorficznych. Traktuj je jako punkt startowy do polowań (threat hunting), nie jako jedyny warunek blokady.

Praktyczne konsekwencje / ryzyko

  • Dla użytkowników: przejęcie kont finansowych/płatniczych (phishing overlay + przechwytywanie ekranu), utrata kontroli nad urządzeniem (nadużycia Accessibility), potencjalne blokowanie prób usunięcia.
  • Dla organizacji: ryzyko kompromitacji telefonów służbowych (BYOD/COPE), eskalacja do wycieku danych (np. kody jednorazowe, dane logowania, treści ekranów), a także trudniejsze blokowanie ze względu na „zaufany” kanał pobierania (Hugging Face/CDN).
  • Dla platform: presja na rozszerzanie skanowania treści (nie tylko typowe pliki ML), lepsze reagowanie na abuse i wykrywanie anomalii (np. tysiące commitów w krótkim czasie w datasetach z binariami).

Rekomendacje operacyjne / co zrobić teraz

Jeśli bronisz środowiska firmowego (SOC/IT/MDM)

  1. Zablokuj sideloading (instalacje spoza sklepów) politykami MDM – to kluczowy punkt wejścia w tej kampanii.
  2. Wymuś polityki dla Accessibility Services: blokada/whitelist, alerty na nowe usługi dostępności, korelacja z overlay/screen capture.
  3. Dodaj detekcje sieciowe:
    • połączenia do wskazanych domen/IP (z zastrzeżeniem rotacji infrastruktury),
    • nietypowe pobrania plików APK z endpointów typu huggingface.co/.../resolve/.../*.apk.
  4. Threat hunting na urządzeniach: szukaj nazw pakietów wskazanych w IoC i anomalii uprawnień (Accessibility + overlay + screen capture).

Jeśli jesteś użytkownikiem Androida

  • Instaluj aplikacje wyłącznie z oficjalnych sklepów, unikaj „antywirusów” z reklam straszących infekcją.
  • Gdy aplikacja prosi o Ułatwienia dostępu, overlay lub przechwytywanie ekranu „bo inaczej nie zadziała” — potraktuj to jako czerwony alarm.

Jeśli utrzymujesz repozytoria/artefakty (DevSecOps / platform security)

  • Monitoruj i automatycznie flaguj:
    • nietypowe typy plików (np. APK w datasetach),
    • wysoką dynamikę commitów,
    • repozytoria służące wyłącznie jako „magazyn binarek”.
  • Rozważ skanowanie wielowarstwowe (signatures + heurystyka + reputacja) oraz szybki proces takedown po zgłoszeniach — w tej kampanii zgłoszenie doprowadziło do usunięcia złośliwych datasetów.

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

  • Tu Hugging Face był użyty głównie jako hosting payloadu APK i kanał dystrybucji (zaufana domena + CDN) w kampanii mobilnej.
  • W innych incydentach związanych z Hugging Face ryzyko częściej dotyczyło złośliwych modeli/plików typu pickle i wykonania kodu po stronie środowisk ML (supply chain dla data science). To inna powierzchnia ataku, ale wspólny mianownik jest ten sam: nadużycie otwartego ekosystemu dystrybucji artefaktów.

Podsumowanie / kluczowe wnioski

  1. Kampania TrustBastion pokazuje, że atakujący potrafią skutecznie wykorzystywać zaufane platformy (tu: Hugging Face) jako etap dystrybucji malware.
  2. Polimorfizm co ~15 minut i tysiące commitów w krótkim czasie to sygnał, że obrona „po hashach” nie wystarcza – potrzebne są detekcje behawioralne i kontrola uprawnień.
  3. W Androidzie krytycznym wektorem jest Accessibility + overlay/screen capture: to duet, który umożliwia realne przejęcie sesji i kradzież danych finansowych.

Źródła / bibliografia

  1. BleepingComputer – opis kampanii i kontekst nadużycia Hugging Face (29 stycznia 2026). (BleepingComputer)
  2. Bitdefender Labs – analiza techniczna TrustBastion/Premium Club, polimorfizm, uprawnienia, C2, IoC (29 stycznia 2026). (Bitdefender)
  3. Hugging Face Docs – mechanizm Malware Scanning (ClamAV) dla repozytoriów. (Hugging Face)
  4. Hugging Face Blog – współpraca z Protect AI i skanowanie modeli/alerty bezpieczeństwa (kwiecień 2025). (Hugging Face)
  5. JFrog Security Research – kontekst złośliwych modeli na Hugging Face i ryzyk supply chain (luty 2024). (JFrog)