Archiwa: LLM - Security Bez Tabu

OWASP powołuje Agentic Research Council, by wzmocnić bezpieczeństwo agentów AI

Wprowadzenie do problemu / definicja

OWASP rozszerza swoje działania w obszarze bezpieczeństwa sztucznej inteligencji, uruchamiając Agentic Research Council. Inicjatywa koncentruje się na zagrożeniach charakterystycznych dla systemów agentowych AI, czyli rozwiązań zdolnych do samodzielnego planowania, korzystania z narzędzi, wykonywania akcji i podejmowania decyzji w oparciu o kontekst operacyjny.

To istotna zmiana perspektywy, ponieważ w systemach agentowych ryzyko nie wynika wyłącznie z działania modelu językowego. Kluczowe znaczenie mają także pamięć, integracje, uprawnienia, narzędzia wykonawcze oraz poziom autonomii przyznany agentowi.

W skrócie

OWASP powołał Agentic Research Council, aby przyspieszyć badania nad bezpieczeństwem agentów AI.
Nowa rada ma łączyć środowisko akademickie, przemysł, administrację i praktyków cyberbezpieczeństwa.
Celem jest szybsze przekładanie wyników badań na praktyczne mechanizmy ochronne.
Inicjatywa rozwija wcześniejsze działania w ramach GenAI Security Project oraz Agentic Security Initiative.

Kontekst / historia

Powstanie nowej rady badawczej wpisuje się w szerszy trend przechodzenia organizacji od prostych chatbotów do bardziej autonomicznych systemów agentowych. Takie rozwiązania nie tylko odpowiadają na pytania, ale również wykonują operacje w systemach zewnętrznych, korzystają z API, zarządzają zadaniami i przetwarzają dane biznesowe.

OWASP od dłuższego czasu rozwija praktyczne wytyczne dotyczące bezpieczeństwa generatywnej AI. Wcześniejsze inicjatywy skupiały się na katalogowaniu ryzyk związanych z aplikacjami LLM i środowiskami agentowymi. Agentic Research Council stanowi kolejny etap dojrzewania tego obszaru: od identyfikacji zagrożeń do skoordynowanego rozwoju metod ochrony możliwych do wdrożenia w środowiskach produkcyjnych.

Analiza techniczna

Bezpieczeństwo agentów AI różni się od klasycznego bezpieczeństwa aplikacji webowych oraz standardowych wdrożeń LLM. Agent interpretuje cele, podejmuje decyzje pośrednie, planuje kolejne kroki i uruchamia narzędzia, co znacząco poszerza powierzchnię ataku.

Pierwszym problemem jest warstwa instrukcji i sterowania, w której agent może paść ofiarą prompt injection, także pośredniego, ukrytego w danych pobieranych z zewnętrznych źródeł. Drugim obszarem ryzyka jest warstwa narzędzi, gdzie znaczenia nabierają nadmierne uprawnienia, brak separacji dostępu, niewystarczająca walidacja wejścia oraz niekontrolowane skutki wywołań API.

Kolejna warstwa to pamięć i kontekst. Jeśli agent zapisuje informacje długoterminowo, możliwe staje się zatrucie pamięci lub utrwalenie złośliwych instrukcji wpływających na późniejsze decyzje. Istotna pozostaje również warstwa orkiestracji i integracji, w której agent staje się pośrednikiem między wieloma systemami, zwiększając ryzyko eskalacji uprawnień, eksfiltracji danych i niezamierzonych działań operacyjnych.

Z punktu widzenia obrony oznacza to konieczność wdrażania polityk dostępu do narzędzi, kontroli autonomii, rejestrowania przebiegu działań oraz walidacji decyzji podejmowanych przez agenta. Właśnie takie zagadnienia mają być rozwijane i porządkowane w ramach nowej rady badawczej OWASP.

Konsekwencje / ryzyko

Znaczenie inicjatywy rośnie wraz z tempem wdrażania agentów AI do środowisk produkcyjnych. W modelu agentowym skutki błędu lub nadużycia mogą wykraczać daleko poza wygenerowanie nieprawidłowej odpowiedzi. Agent może wykonać realne działanie w systemie biznesowym, takie jak przesłanie danych do nieuprawnionego odbiorcy, zmiana konfiguracji, uruchomienie procesu lub modyfikacja zasobów.

Dodatkowym wyzwaniem jest audyt i analiza incydentów. Zachowanie agentów bywa kontekstowe i częściowo probabilistyczne, przez co trudniej odtworzyć pełny przebieg decyzyjny niż w tradycyjnych aplikacjach. To komplikuje testowanie, modelowanie zagrożeń oraz dochodzenia powłamaniowe.

Rekomendacje

Organizacje wdrażające agentów AI powinny traktować je jak komponenty wykonawcze o podwyższonym poziomie ryzyka, a nie wyłącznie jako interfejsy konwersacyjne. W praktyce oznacza to konieczność ograniczania uprawnień i ścisłego nadzoru nad ich działaniem.

Stosować zasadę minimalnej autonomii i udostępniać agentowi wyłącznie niezbędne narzędzia oraz dane.
Wprowadzać niezależną autoryzację i walidację parametrów dla każdego narzędzia wywoływanego przez agenta.
Wymagać dodatkowego zatwierdzania działań o wysokim wpływie biznesowym lub operacyjnym.
Zapewnić pełną obserwowalność obejmującą kontekst, przebieg planowania, wywołania narzędzi i skutki operacji.
Regularnie prowadzić testy bezpieczeństwa pod kątem prompt injection, zatruwania pamięci, eskalacji uprawnień i eksfiltracji danych.
Śledzić rozwój otwartych wytycznych bezpieczeństwa dla systemów agentowych, ponieważ krajobraz zagrożeń szybko się zmienia.

Podsumowanie

Powołanie Agentic Research Council przez OWASP pokazuje, że bezpieczeństwo agentów AI staje się odrębnym i dojrzałym obszarem cyberbezpieczeństwa. Najważniejsza zmiana polega na odejściu od oceny samego modelu na rzecz analizy całego ekosystemu działania agenta: jego pamięci, integracji, narzędzi, polityk i poziomu autonomii.

Dla branży oznacza to potrzebę budowy nowych standardów testowania, nadzoru i ograniczania ryzyka. Jeśli inicjatywa OWASP spełni swoją rolę, może znacząco przyspieszyć przekładanie badań nad agentami AI na praktyczne zabezpieczenia stosowane w organizacjach.

Źródła

Krytyczna luka RCE w Flowise zwiększa ryzyko dla środowisk self-hosted po publikacji kodu exploitacji

Wprowadzenie do problemu / definicja

W świecie narzędzi opartych na sztucznej inteligencji rośnie liczba incydentów wynikających nie tylko z klasycznych błędów programistycznych, ale również z niebezpiecznych założeń projektowych. Taki charakter ma podatność CVE-2026-40933 w platformie Flowise, popularnym rozwiązaniu open source do budowy przepływów LLM i agentów AI.

Problem dotyczy zdalnego wykonania kodu (RCE) i może zostać wykorzystany poprzez import spreparowanego pliku chatflow. Publiczne udostępnienie kodu proof-of-concept dodatkowo zwiększa ryzyko, ponieważ ułatwia odtworzenie scenariusza ataku także mniej zaawansowanym technicznie napastnikom.

W skrócie

Podatność oznaczona jako CVE-2026-40933 otrzymała ocenę krytyczną i dotyczy mechanizmu integracji MCP w Flowise. Luka pozwala na uruchomienie dowolnych poleceń systemowych na serwerze po zaimportowaniu złośliwego chatflow zawierającego odpowiednio przygotowaną konfigurację.

Zagrożone są przede wszystkim instancje self-hosted.
Atak może zostać uruchomiony poprzez import złośliwego pliku JSON.
Wektor wykorzystuje obsługę MCP w trybie stdio.
Publiczny kod exploitacji zwiększa prawdopodobieństwo masowych prób nadużyć.
Według dostępnych informacji Flowise Cloud nie jest objęte tym samym scenariuszem ataku.

Kontekst / historia

Luka została ujawniona w szerszym kontekście problemów bezpieczeństwa związanych z ekosystemami AI korzystającymi z protokołu MCP. Flowise znalazł się w grupie produktów narażonych na tę klasę błędów ze względu na sposób obsługi niestandardowych narzędzi oraz serializacji poleceń wykonywanych przez adapter stdio.

Rosnąca popularność Flowise jako platformy do wizualnego budowania przepływów dla modeli językowych sprawia, że produkt staje się atrakcyjnym celem dla cyberprzestępców. Dodatkowym czynnikiem ryzyka jest publiczna dostępność technicznych szczegółów oraz kodu PoC, co skraca czas potrzebny na przygotowanie skutecznej kampanii ofensywnej.

Analiza techniczna

Istota podatności sprowadza się do niebezpiecznej obsługi konfiguracji MCP w trybie stdio. W podatnych wersjach Flowise wcześniejszych niż 3.1.0 możliwe było dodanie komponentu MCP i zdefiniowanie polecenia systemowego, które następnie mogło zostać wykonane przez host obsługujący aplikację.

Scenariusz ataku wykorzystuje legalną funkcjonalność programu. Napastnik przygotowuje złośliwy chatflow z osadzonym niestandardowym narzędziem MCP, eksportuje go do formatu JSON i przekazuje ofierze. Po imporcie backend podejmuje próbę enumeracji dostępnych akcji narzędzia. Jeżeli wykorzystywany jest transport stdio, ten etap może doprowadzić do uruchomienia wcześniej zdefiniowanej komendy systemowej.

To oznacza, że wykonanie złośliwego kodu nie musi następować dopiero po ręcznym uruchomieniu przepływu. W praktyce zagrożenie może materializować się już podczas importu lub otwarcia konfiguracji, co znacząco zwiększa skuteczność ataku i utrudnia użytkownikowi rozpoznanie momentu kompromitacji.

Publicznie dostępny kod PoC pokazuje możliwość uzyskania powłoki systemowej. W środowiskach kontenerowych skutki mogą być szczególnie dotkliwe, zwłaszcza gdy proces Flowise działa z szerokimi uprawnieniami lub jako root wewnątrz kontenera.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją jest możliwość wykonania dowolnego kodu z uprawnieniami procesu Flowise. To z kolei może prowadzić do pełnego przejęcia aplikacji, odczytu sekretów, kradzieży tokenów API, dostępu do baz danych oraz wykorzystania integracji z usługami chmurowymi i systemami biznesowymi.

Skala ryzyka jest wysoka, ponieważ atak może zostać ukryty w pozornie legalnym pliku importu i wykorzystuje natywne funkcje aplikacji. Dla zespołów bezpieczeństwa oznacza to większą trudność w detekcji oraz konieczność analizy zdarzeń, które na pierwszy rzut oka mogą wyglądać jak normalna aktywność administracyjna.

możliwość przejęcia serwera aplikacyjnego,
ekspozycja kluczy API i danych uwierzytelniających,
dostęp do połączonych baz danych i usług zewnętrznych,
ryzyko ruchu bocznego w infrastrukturze organizacji,
zwiększone prawdopodobieństwo automatyzacji ataków po publikacji PoC.

W wielu środowiskach produkcyjnych Flowise pełni rolę warstwy orkiestracyjnej pomiędzy modelami AI, źródłami danych, API i zasobami chmurowymi. Z tego względu skuteczna eksploatacja może wywołać konsekwencje wykraczające daleko poza samą aplikację.

Rekomendacje

Organizacje korzystające z Flowise w modelu self-hosted powinny potraktować tę podatność jako priorytet krytyczny. Najważniejszym krokiem jest niezwłoczne usunięcie podatnych wersji oraz ograniczenie powierzchni ataku związanej z mechanizmem MCP.

zaktualizować Flowise do wersji 3.1.0 lub nowszej,
wyłączyć albo ograniczyć obsługę stdio MCP tam, gdzie nie jest niezbędna,
zablokować import chatflow z niezweryfikowanych źródeł,
ograniczyć liczbę użytkowników mogących tworzyć i edytować przepływy,
stosować zasadę najmniejszych uprawnień dla procesu Flowise,
unikać uruchamiania aplikacji z uprawnieniami root,
odseparować aplikację od wrażliwych zasobów poprzez segmentację sieci,
monitorować logi pod kątem nietypowych importów i uruchomień procesów potomnych,
przeprowadzić rotację sekretów i poświadczeń w razie podejrzenia kompromitacji,
wdrożyć dodatkowe zabezpieczenia kontenerowe, takie jak seccomp, AppArmor, SELinux oraz ograniczenia capabilities.

Z perspektywy detekcji warto korelować zdarzenia importu konfiguracji z pojawieniem się nowych procesów systemowych, nietypowymi połączeniami sieciowymi oraz zmianami w konfiguracji narzędzi MCP. W zespołach SOC zasadna jest również budowa reguł wykrywających procesy uruchamiane z kontekstu Flowise.

Podsumowanie

CVE-2026-40933 pokazuje, że w narzędziach AI szczególnie niebezpieczne mogą być błędy wynikające z połączenia legalnej funkcjonalności z niekontrolowanym wykonaniem komend systemowych. Publikacja kodu exploitacji znacząco zwiększa prawdopodobieństwo realnych ataków na instancje self-hosted.

Dla organizacji korzystających z Flowise oznacza to konieczność natychmiastowej weryfikacji wersji oprogramowania, ograniczenia funkcji MCP, przeglądu uprawnień oraz analizy ewentualnych śladów wcześniejszej kompromitacji. Im większy dostęp aplikacji do danych, modeli i usług produkcyjnych, tym poważniejsze mogą być skutki udanego ataku.

Źródła

SecurityWeek – Exploit Code Published for Critical Flowise RCE Vulnerability — https://www.securityweek.com/exploit-code-published-for-critical-flowise-rce-vulnerability/
NVD – CVE-2026-40933 — https://nvd.nist.gov/vuln/detail/CVE-2026-40933
Flowise – GitHub Repository — https://github.com/FlowiseAI/Flowise
Obsidian Security – Technical analysis of Flowise MCP exploitation — https://www.obsidiansecurity.com/

Ataki z agentem LLM po luce Marimo CVE-2026-39987: nowy etap post-exploitation

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa opisali incydent, w którym po wykorzystaniu krytycznej luki w Marimo napastnik nie poprzestał na prostym uzyskaniu dostępu do systemu. Zamiast klasycznego zestawu sztywnych skryptów użyto agenta opartego na dużym modelu językowym, który wykonywał kolejne działania po kompromitacji w sposób adaptacyjny, reagując na wyniki komend i charakterystykę środowiska.

To istotna zmiana w krajobrazie zagrożeń. Agent LLM może działać jak półautonomiczny operator: rozpoznawać host, wyszukiwać sekrety, planować następne kroki i modyfikować przebieg ataku bez konieczności ręcznej interwencji na każdym etapie.

W skrócie

CVE-2026-39987 dotyczy nieuwierzytelnionego zdalnego wykonywania kodu w Marimo przez endpoint WebSocket /terminal/ws.
Podatność umożliwiała uzyskanie pełnej interaktywnej powłoki PTY bez logowania na wersjach wcześniejszych niż 0.23.0.
W zaobserwowanym ataku napastnik wydobył poświadczenia chmurowe, pobrał klucz SSH z AWS Secrets Manager, wykonał ruch lateralny i uzyskał dostęp do wewnętrznej bazy PostgreSQL.
Charakter poleceń wskazywał, że działania po kompromitacji mogły być realizowane przez agenta LLM.

Kontekst / historia

Marimo to reaktywny notebook Pythona wykorzystywany przez zespoły analityczne, inżynieryjne i deweloperskie. Tego typu narzędzia często działają blisko danych, środowisk testowych, sekretów aplikacyjnych oraz usług chmurowych, dlatego ich ekspozycja do internetu znacząco zwiększa powierzchnię ataku.

Po ujawnieniu CVE-2026-39987 okazało się, że problem wynikał z niewłaściwej kontroli autoryzacji dla terminalowego endpointu WebSocket. Luka została usunięta w wersji 0.23.0, ale publicznie dostępne, niezałatane instancje szybko stały się atrakcyjnym celem. Z perspektywy obrońców to kolejny przykład, że narzędzia AI i data science nie mogą być traktowane jako zasoby o niskim ryzyku tylko dlatego, że nie są systemami produkcyjnymi w klasycznym rozumieniu.

Analiza techniczna

Istota podatności sprowadzała się do tego, że endpoint /terminal/ws akceptował połączenia bez prawidłowej weryfikacji uwierzytelnienia. W praktyce umożliwiało to nieautoryzowanemu użytkownikowi uzyskanie interaktywnej powłoki systemowej, czyli bardzo silnego punktu wejścia do dalszej kompromitacji.

W opisanym scenariuszu atak rozpoczął się od przejęcia publicznie wystawionej instancji Marimo. Następnie napastnik przeszukał środowisko pod kątem poświadczeń, odnalazł dane dostępowe do usług chmurowych i użył ich do odczytu sekretu z AWS Secrets Manager. W kolejnym kroku pobrano prywatny klucz SSH, zestawiono krótkie sesje do kolejnych systemów i dotarto do segmentu infrastruktury zawierającego bazę PostgreSQL, z której wyeksfiltrowano dane.

Najbardziej niepokojące było jednak nie samo przejście przez kolejne etapy, ale sposób realizacji działań. Badacze zwrócili uwagę na kilka elementów sugerujących użycie agenta LLM: improwizowaną sekwencję poleceń zależną od bieżących wyników, obecność komentarza planistycznego, formułowanie komend w sposób uporządkowany i przyjazny przetwarzaniu maszynowemu oraz przekazywanie wyników poprzednich komend do kolejnych decyzji operacyjnych.

Taki model działania oznacza, że atakujący nie musi wcześniej znać dokładnej architektury środowiska ofiary. Wystarczy ogólna wiedza o systemach Linux, sposobach przechowywania sekretów, konwencjach administracyjnych i typowych narzędziach, aby agent po uzyskaniu powłoki samodzielnie eksplorował host i budował kolejne etapy łańcucha ataku.

Konsekwencje / ryzyko

Ryzyko związane z tym incydentem wykracza daleko poza pojedyncze RCE. Najpoważniejszym problemem jest skrócenie czasu od uzyskania dostępu do osiągnięcia realnego wpływu biznesowego. Jeżeli agent potrafi samodzielnie odnajdywać poświadczenia, pobierać sekrety, wykonywać ruch boczny i identyfikować wartościowe zasoby, okno czasowe na detekcję i reakcję staje się znacznie krótsze.

Dodatkowo agentyczne post-exploitation zwiększa odporność napastnika na błędy i nietypowe warunki środowiskowe. Klasyczny skrypt często zawodzi przy niestandardowych ścieżkach, innym układzie katalogów czy odmiennym schemacie systemu. Agent może natomiast analizować wyniki, korygować plan i próbować alternatywnych metod, co podnosi skuteczność operacji w zróżnicowanych środowiskach.

Dla organizacji oznacza to ryzyko przejęcia kont chmurowych, utraty kluczy SSH, kompromitacji baz danych, wycieku danych wrażliwych oraz dalszego rozprzestrzenienia się ataku na środowiska deweloperskie i produkcyjne. Szczególnie narażone są firmy, które dopuszczają bezpośrednią ekspozycję notebooków i pomocniczych usług inżynieryjnych do internetu.

Rekomendacje

Najważniejszym działaniem jest natychmiastowa aktualizacja Marimo do wersji 0.23.0 lub nowszej oraz pełna inwentaryzacja wszystkich instancji dostępnych z sieci publicznej. Dotyczy to także środowisk testowych, tymczasowych i tworzonych ad hoc przez zespoły analityczne.

Należy również założyć możliwość wcześniejszej kompromitacji każdego hosta działającego na podatnej wersji. W praktyce oznacza to konieczność rotacji kluczy API, poświadczeń AWS, kluczy SSH, haseł do baz danych oraz wszystkich tokenów zapisanych lokalnie lub dostępnych przez zmienne środowiskowe. Sama poprawka nie eliminuje skutków potencjalnego włamania.

Ograniczyć ekspozycję notebooków i narzędzi AI do internetu.
Wymusić silne uwierzytelnianie przez reverse proxy lub warstwę pośrednią.
Zminimalizować uprawnienia IAM i dostęp do menedżerów sekretów.
Wdrożyć segmentację sieci, aby hosty deweloperskie nie miały bezpośredniej ścieżki do bastionów, baz danych i paneli administracyjnych.
Monitorować nietypowe połączenia do terminalowych endpointów WebSocket oraz seryjne, krótkie sekwencje komend systemowych.
Analizować użycie AWS Secrets Manager i sesji SSH inicjowanych z nieoczekiwanych hostów.

Podsumowanie

Incydent związany z CVE-2026-39987 pokazuje, że nowoczesny post-exploitation coraz częściej przybiera formę agentyczną. Krytyczna luka w Marimo umożliwiła uzyskanie dostępu, ale prawdziwym sygnałem ostrzegawczym jest to, że po wejściu na host napastnik mógł szybko przejść do kradzieży sekretów, ruchu lateralnego i eksfiltracji danych przy wsparciu mechanizmu przypominającego autonomicznego operatora.

Dla zespołów bezpieczeństwa oznacza to potrzebę szybszego patchowania, mocniejszej segmentacji, ograniczania uprawnień oraz budowania detekcji ukierunkowanej nie tylko na sam exploit, lecz także na wzorce elastycznego, zautomatyzowanego działania po kompromitacji.

Źródła

GREYVIBE: rosyjskojęzyczna grupa wykorzystuje AI do cyberataków wymierzonych w Ukrainę

Wprowadzenie do problemu / definicja

GREYVIBE to nowo opisana grupa zagrożeń prowadząca operacje wymierzone w Ukrainę oraz podmioty powiązane z sektorem wojskowym, publicznym, cywilnym i biznesowym. Jej działalność wyróżnia łączenie klasycznych technik cyberwywiadowczych z wykorzystaniem narzędzi opartych na generatywnej sztucznej inteligencji, co pozwala szybciej przygotowywać infrastrukturę, przynęty socjotechniczne i komponenty złośliwego oprogramowania.

Z perspektywy obrońców jest to istotny sygnał zmiany w krajobrazie zagrożeń. Automatyzacja części procesu operacyjnego przez modele AI skraca czas potrzebny na tworzenie nowych wariantów malware i utrudnia wykrywanie kampanii wyłącznie na podstawie znanych sygnatur.

W skrócie

GREYVIBE prowadzi aktywne operacje co najmniej od sierpnia 2025 roku.
Grupa wykorzystuje spear phishing, fałszywe strony CAPTCHA, strony podszywające się pod ukraińskie podmioty oraz malware na Windows i Androida.
W arsenale aktora znalazły się m.in. PhantomRelay, LegionRelay i FallSpy.
Badacze wskazują, że modele AI i LLM wspierają rozwój elementów operacyjnych, obfuskację i przygotowanie infrastruktury.
Celem działań wydaje się przede wszystkim pozyskiwanie informacji wywiadowczych oraz utrzymywanie dostępu do środowisk ofiar.

Kontekst / historia

GREYVIBE wpisuje się w szerszy krajobraz operacji prowadzonych w interesie Federacji Rosyjskiej w kontekście wojny rosyjsko-ukraińskiej. Profil ofiar sugeruje ukierunkowanie na długotrwałe rozpoznanie i pozyskiwanie danych, a nie wyłącznie na destrukcję systemów czy szybki zysk finansowy.

Jednocześnie grupa nie sprawia wrażenia w pełni dojrzałego, jednolitego zespołu państwowego. Analitycy zwracają uwagę na błędy operacyjne, ślady testowych wersji malware oraz relacje z szerszym ekosystemem cyberprzestępczym. Taki model hybrydowy utrudnia jednoznaczną atrybucję i pokazuje, że granica między klasycznym APT a grupą przestępczą staje się coraz mniej wyraźna.

Analiza techniczna

GREYVIBE korzysta z kilku łańcuchów infekcji dostosowanych do rodzaju ofiary i wykorzystywanej platformy. W kampanii określanej jako PhantomMail stosowano wiadomości spear phishingowe zawierające odnośniki do archiwów ZIP lub RAR. Wewnątrz znajdował się loader JavaScript, który uruchamiał dokument-wabik i wdrażał komponent PhantomRelay. Ten pełnił rolę zdalnego trojana dostępowego opartego na PowerShell, umożliwiającego profilowanie hosta oraz wykonywanie poleceń systemowych.

Wariant PhantomClick bazował na stronach podszywających się pod legalne usługi i wykorzystywał mechanikę fałszywego CAPTCHA w stylu ClickFix. Ofiara była nakłaniana do samodzielnego uruchomienia poleceń, co prowadziło do wdrożenia kolejnego etapu infekcji. To przykład skutecznego połączenia socjotechniki z techniką living-off-the-land, ponieważ część działań wykonywano przy użyciu natywnych mechanizmów Windows.

Kampania PrincessClub wykorzystywała fałszywe strony ukraińskich klubów dla dorosłych. W zależności od urządzenia ofiara otrzymywała spyware FallSpy dla Androida albo malware PhantomRelayV1 i LegionRelay dla Windows. Późniejsze wersje stron zawierały też funkcję połączenia na żywo opartą na WebRTC, co mogło zwiększać wiarygodność przynęty i wspierać przechwytywanie audio lub wideo.

FallSpy został opisany jako spyware dla Androida nastawiony na pozyskiwanie wrażliwych danych z urządzenia. LegionRelay to z kolei lekki RAT oparty na PowerShell, obsługujący enumerację plików, eksfiltrację danych, wykonywanie zrzutów ekranu, kradzież danych z przeglądarek, pozyskiwanie informacji z komunikatorów oraz konfigurację dostępu RDP. PhantomRelayV1 rozwija te możliwości o mechanizmy trwałości, w tym niestandardowy watchdog.

W łańcuchu DroneLink atakujący wykorzystywali strony podszywające się pod fundacje charytatywne wspierające ukraińskie siły zbrojne. Celem było dostarczenie komponentów takich jak WireGuard i LegionRelay, co może wskazywać na próbę zestawienia trwałego kanału komunikacyjnego lub tunelowania ruchu po skutecznej kompromitacji.

Opisano również kampanię Nebo, w której próbka FallSpy imitowała rosyjskojęzyczny ekran logowania. Taki zabieg mógł służyć dezorientacji ofiar i budowaniu wrażenia pracy w wiarygodnym środowisku.

Najciekawszym aspektem technicznym pozostaje wykorzystanie AI do wspierania rozwoju operacji. Badacze wskazali, że generatywna sztuczna inteligencja mogła być używana do tworzenia grafik, rozwijania komponentów LegionRelay, przygotowywania loaderów i skryptów obfuskacyjnych, budowy zaplecza infrastrukturalnego oraz opracowywania komend wykorzystywanych po uzyskaniu dostępu. Jednocześnie analiza próbek ujawniła błędy projektowe i ślady niedojrzałości, co pokazuje, że przyspieszenie developmentu nie zawsze oznacza wysoką jakość operacyjną.

Konsekwencje / ryzyko

Działania GREYVIBE zwiększają presję na organizacje funkcjonujące w regionach objętych konfliktem oraz na podmioty współpracujące z administracją, wojskiem i sektorem pomocowym. Zagrożenie nie ogranicza się do utraty poufności danych. Obejmuje także długotrwałe rozpoznanie środowiska, kradzież danych uwierzytelniających, przejęcie komunikacji oraz wykorzystanie legalnych kanałów zdalnego dostępu do dalszej penetracji infrastruktury.

Szczególnie niebezpieczne jest łączenie wielu wektorów dostępu: phishingu, stron-wabików, infekcji mobilnych oraz komponentów PowerShell wdrażanych na stacjach roboczych. Taka wielowarstwowość zwiększa odporność kampanii na punktowe działania obronne i utrudnia pełne odtworzenie przebiegu incydentu.

Dodatkowym wyzwaniem jest rozwój malware wspomagany przez AI. Jeżeli aktor potrafi szybko przebudowywać loadery, skrypty i infrastrukturę, tradycyjne metody detekcji oparte na stałych sygnaturach mogą okazać się niewystarczające. Dla zespołów SOC oznacza to konieczność większego oparcia się na analizie zachowań, korelacji telemetrii i wykrywaniu anomalii.

Rekomendacje

Organizacje narażone na podobne kampanie powinny w pierwszej kolejności wzmocnić ochronę poczty i komunikacji użytkowników. W praktyce oznacza to rygorystyczne filtrowanie załączników i archiwów, sandboxing wiadomości oraz wdrożenie mechanizmów wykrywania phishingu ukierunkowanego.

W środowiskach Windows warto ograniczyć wykonywanie nieautoryzowanych skryptów PowerShell, monitorować uruchamianie interpreterów skryptowych oraz wykrywać nietypowe sekwencje poleceń kopiowanych przez użytkownika do okien dialogowych i terminali. Szkolenia z zakresu awareness powinny obejmować nie tylko klasyczne wiadomości phishingowe, ale także scenariusze fałszywych stron CAPTCHA i technik ClickFix.

Niezbędne jest również monitorowanie anomalii związanych z RDP, tworzeniem tuneli sieciowych, wykorzystaniem narzędzi zdalnego dostępu oraz próbami eksfiltracji danych z przeglądarek i komunikatorów. W przypadku urządzeń mobilnych należy egzekwować polityki MDM, ograniczać instalację aplikacji spoza zaufanych źródeł i analizować uprawnienia aplikacji pod kątem dostępu do wiadomości, mikrofonu, aparatu i pamięci urządzenia.

Budować reguły behawioralne dla uruchomień JavaScript z archiwów pobranych z internetu.
Monitorować nietypową aktywność PowerShell po otwarciu dokumentów lub stron phishingowych.
Wykrywać połączenia WebRTC inicjowane przez mało znane domeny.
Analizować nagłe tworzenie zdalnych kanałów administracyjnych i tuneli.
Łączyć telemetrię z hostów, poczty, proxy, EDR i urządzeń mobilnych.

Podsumowanie

GREYVIBE pokazuje, że współczesne operacje cyberwywiadowcze coraz częściej łączą klasyczne techniki infekcji z szybkim rozwojem komponentów wspomaganym przez sztuczną inteligencję. Grupa atakuje cele związane z Ukrainą, wykorzystuje zróżnicowane łańcuchy dostępu i działa na styku cyberprzestępczości oraz aktywności powiązanej z interesami państwowymi.

Dla obrońców najważniejszy wniosek jest praktyczny: sama znajomość nazw malware nie wystarcza. Skuteczna obrona wymaga monitorowania zachowań, ograniczania możliwości wykonywania skryptów, wzmacniania bezpieczeństwa urządzeń mobilnych oraz ciągłego dostosowywania detekcji do kampanii, które mogą dynamicznie zmieniać swoje artefakty techniczne dzięki użyciu AI.

Źródła

CERT-In zaleca łatanie krytycznych luk w systemach internetowych w 12 godzin

Wprowadzenie do problemu / definicja

Indyjski zespół reagowania na incydenty komputerowe CERT-In opublikował nowe wytyczne dotyczące ograniczania ekspozycji na podatności, które mogą być wykorzystywane w atakach wspieranych przez sztuczną inteligencję. Najważniejszym elementem dokumentu jest rekomendacja, aby krytyczne luki w systemach dostępnych z internetu były usuwane w ciągu 12 godzin od ich identyfikacji, o ile jest to operacyjnie możliwe.

To wyraźny sygnał, że tradycyjne modele zarządzania podatnościami przestają nadążać za tempem współczesnych kampanii ofensywnych. Rozwój modeli AI i LLM skraca czas potrzebny atakującym na analizę nowych błędów, przygotowanie exploitów i rozpoczęcie prób kompromitacji.

W skrócie

CERT-In chce skrócenia czasu reakcji na krytyczne podatności w systemach wystawionych do internetu do 12 godzin.
Powodem jest rosnące wykorzystanie AI do rekonesansu, analizy powierzchni ataku, phishingu i automatyzacji exploitacji.
Wytyczne promują ciągłą ocenę ryzyka, szybkie łatanie, architekturę Zero Trust i stosowanie środków kompensacyjnych.
Nowe podejście dotyczy nie tylko klasycznych systemów IT, ale również środowisk i komponentów AI.

Kontekst / historia

Presja na skracanie czasu reakcji na podatności nie jest nowym zjawiskiem, jednak w 2026 roku nabrała nowego znaczenia. CERT-In już wcześniej ostrzegał, że technologie AI o charakterze dual-use mogą zarówno obniżać próg wejścia dla mniej zaawansowanych napastników, jak i zwiększać skuteczność bardziej doświadczonych grup.

W praktyce nie chodzi już wyłącznie o szybsze wyszukiwanie błędów w kodzie czy analizę nowych wpisów CVE. Coraz większym problemem staje się automatyzacja całych łańcuchów ataku: od rozpoznania infrastruktury, przez identyfikację słabych punktów, po przygotowanie wiarygodnych wiadomości phishingowych i złośliwych komponentów.

Na tym tle klasyczny, tygodniowy cykl patch managementu może okazać się niewystarczający, szczególnie dla usług publicznie dostępnych, interfejsów API, środowisk chmurowych i systemów o wysokiej wartości biznesowej.

Analiza techniczna

Techniczny sens nowych wytycznych opiera się na założeniu, że cykl życia exploita ulega dalszej kompresji. Atakujący mogą dziś wykorzystywać AI do mapowania zasobów wystawionych do internetu, identyfikacji błędnych konfiguracji, analizy nowych podatności oraz szybkiego budowania proof-of-concept.

Do najważniejszych obszarów zastosowania AI po stronie ofensywnej należą:

rekonesans i analiza powierzchni ataku,
identyfikacja słabych tożsamości i niezabezpieczonych API,
automatyzacja przetwarzania informacji o podatnościach,
tworzenie treści phishingowych o wysokiej wiarygodności,
modyfikacja lub wspomaganie rozwoju złośliwego oprogramowania.

CERT-In zwraca też uwagę, że same systemy AI stają się atrakcyjnym celem. Wśród kluczowych zagrożeń wymieniane są prompt injection, wyciek danych, jailbreaking modeli, zatruwanie danych treningowych, kradzież modeli oraz kompromitacja pipeline’ów orkiestracji. Oznacza to, że bezpieczeństwo organizacji musi obejmować nie tylko serwery, stacje robocze i aplikacje, ale także modele, dane oraz warstwę integracyjną wykorzystywaną w procesach biznesowych.

Wytyczne różnicują również czasy remediacji. Najwyższy priorytet mają znane i aktywnie wykorzystywane podatności wpływające na systemy dostępne z internetu i infrastrukturę krytyczną. To właśnie dla nich rekomendowano 12-godzinne okno naprawcze, jeśli wdrożenie poprawki jest wykonalne.

Jeśli poprawka nie jest jeszcze dostępna, organizacja powinna wdrożyć środki kompensacyjne. Mogą one obejmować izolację systemu, ograniczenie dostępu, ochronę za pomocą WAF lub mechanizmów bezpieczeństwa API, wyłączenie podatnej funkcji oraz podniesienie poziomu monitoringu telemetrycznego i detekcyjnego.

Konsekwencje / ryzyko

Dla zespołów bezpieczeństwa i operacji IT nowe wytyczne oznaczają konieczność przebudowy procesu zarządzania podatnościami. Największym wyzwaniem będzie pogodzenie szybkości wdrożeń z zachowaniem kontroli zmian, zwłaszcza w złożonych środowiskach produkcyjnych i hybrydowych.

Spełnienie 12-godzinnego celu może wymagać:

pełnej widoczności aktywów i ich ekspozycji,
automatycznej priorytetyzacji podatności według ryzyka,
gotowych procedur emergency change,
stałej współpracy między SOC, IT, DevOps, zespołami chmurowymi i właścicielami aplikacji,
sprawnych testów regresji oraz procedur rollbacku.

Największe ryzyko dotyczy organizacji, które nadal utrzymują długie okna patchowania dla systemów internet-facing. To właśnie takie zasoby często stają się pierwszym punktem wejścia do środowiska poprzez zdalne wykonanie kodu, nadużycia API, przejęcie kont uprzywilejowanych, eskalację uprawnień lub ruch boczny po uzyskaniu dostępu.

Opóźnione łatanie może prowadzić do incydentów ransomware, kradzieży danych, zakłóceń ciągłości działania i problemów w łańcuchu dostaw. Dodatkowo AI zwiększa nie tylko skuteczność, ale również skalę ataków, co przekłada się na większą liczbę prób kompromitacji i szybszą adaptację kampanii do środowiska ofiary.

Rekomendacje

Organizacje powinny potraktować nowe wytyczne jako impuls do przejścia na model risk-based vulnerability management wspierany automatyzacją. W praktyce warto skupić się na kilku kluczowych działaniach.

Zidentyfikować wszystkie zasoby dostępne z internetu, w tym usługi chmurowe, API, panele administracyjne, VPN i komponenty zewnętrzne.
Wyodrębnić aktywa krytyczne biznesowo i przypisać im krótsze SLA naprawcze.
Zautomatyzować korelację danych z asset inventory, skanerów podatności, telemetryki SOC oraz informacji o aktywnej eksploatacji.
Wdrożyć procedury szybkiego patchingu dla zmian awaryjnych wraz z gotowymi scenariuszami testów i cofnięcia zmian.
Rozwijać architekturę Zero Trust oraz zasadę least privilege dla kont uprzywilejowanych i integracji API.
Wzmacniać zabezpieczenia warstwowe, takie jak segmentacja, EDR/XDR, WAF, ochrona API i monitoring tożsamości.
Rozszerzyć program bezpieczeństwa na komponenty AI, obejmując modele, dane, integracje i polityki dostępu.
W przypadku braku łatki natychmiast stosować compensating controls i formalnie dokumentować decyzje dotyczące ryzyka.

Dla dużych organizacji kluczowe będzie także silniejsze powiązanie patch managementu z cyber threat intelligence. Sama ocena CVSS może nie wystarczyć, jeśli dana podatność dotyczy systemu publicznie dostępnego i pojawiają się sygnały o jej aktywnym wykorzystywaniu.

Podsumowanie

Nowe wytyczne CERT-In dobrze pokazują, że w realiach ataków wspieranych przez AI czas reakcji staje się równie istotny jak jakość samych zabezpieczeń. Zalecenie 12-godzinnego łatania krytycznych luk w systemach dostępnych z internetu nie jest wyłącznie ambitnym celem operacyjnym, ale odpowiedzią na skracający się czas uzbrajania podatności przez napastników.

Dla organizacji oznacza to konieczność większej automatyzacji, lepszej widoczności aktywów i ściślejszej integracji bezpieczeństwa z operacjami IT. W środowisku, w którym przeciwnik działa szybciej dzięki AI, opóźnienia liczone w dniach mogą stać się realnym ryzykiem biznesowym.

Źródła

Mythos Nie Wystarczy. Lekcja Z Cloudflare.

Mythos jednak nie taki wspaniały?

Mythos Preview to jeden z tych tematów, przy których łatwo popaść w skrajności. Jedni widzą początek końca klasycznego pentestingu. Drudzy widzą głównie marketing, PR i kolejną falę zachwytu nad AI. Prawda jest mniej wygodna: Mythos jest wystarczająco mocny, żeby potraktować go bardzo poważnie, ale nie jest magicznym inżynierem bezpieczeństwa, którego można podpiąć do repozytorium i powiedzieć: „znajdź wszystko, co groźne”.

Czytaj dalej

AI zwiększa świadomość podatności, ale nie przełamuje problemu ich wykrywania

Wprowadzenie do problemu / definicja

Sztuczna inteligencja coraz mocniej wchodzi do obszaru cyberbezpieczeństwa, szczególnie tam, gdzie organizacje próbują szybciej identyfikować podatności, porządkować alerty i ustalać priorytety działań naprawczych. W praktyce oznacza to rosnące zainteresowanie narzędziami opartymi na modelach AI i LLM, które mają wspierać zespoły bezpieczeństwa w analizie ekspozycji i ocenie ryzyka.

Jednak mimo wysokich oczekiwań rynkowych obecny stan technologii pokazuje, że AI przede wszystkim poprawia widoczność problemu podatności i ułatwia pracę analityków, a nie stanowi jeszcze przełomu w samodzielnym wykrywaniu luk. To rozróżnienie ma kluczowe znaczenie dla organizacji planujących inwestycje w defensive AI.

W skrócie

AI pomaga lepiej rozumieć powierzchnię ataku i porządkować dane o podatnościach.
Wpływ obecnych narzędzi AI na samo wykrywanie podatności pozostaje ograniczony.
Największą wartość AI daje dziś w triage, korelacji danych i priorytetyzacji działań.
Organizacje nadal muszą opierać się na klasycznych metodach bezpieczeństwa i nadzorze ekspertów.
Wdrożenia AI hamują m.in. koszty, braki kompetencyjne i ograniczone zaufanie do autonomicznych decyzji modeli.

Kontekst / historia

W ciągu ostatnich kilkunastu miesięcy AI stała się jednym z najczęściej dyskutowanych tematów w branży bezpieczeństwa. Firmy i instytucje zaczęły testować modele generatywne nie tylko w centrach operacji bezpieczeństwa, lecz także w analizie kodu, klasyfikacji podatności, skanowaniu zasobów i korelacji telemetrii.

Równolegle pojawiła się silna narracja marketingowa sugerująca, że AI może znacząco zwiększyć skuteczność wykrywania luk i odciążyć przeciążone zespoły bezpieczeństwa. Bardziej ostrożne oceny przyniosły jednak analizy rynku oraz pilotaże prowadzone przez instytucje publiczne. Wnioski z takich działań wskazują, że wpływ AI na operacyjne wykrywanie podatności jest zauważalny głównie w obszarze analityki wspomagającej, ale nie daje jeszcze wyraźnej przewagi nad rozwiązaniami niewykorzystującymi AI.

W praktyce komercyjnej obraz wygląda podobnie. Organizacje są zainteresowane defensive AI, zwłaszcza tam, gdzie chodzi o detekcję, threat intelligence i priorytetyzację ryzyka, ale większość wdrożeń pozostaje na wczesnym etapie dojrzałości. AI częściej działa dziś jako warstwa wspierająca proces decyzyjny niż jako autonomiczny mechanizm odkrywania krytycznych błędów.

Analiza techniczna

Z technicznego punktu widzenia AI może wnosić realną wartość do zarządzania podatnościami na kilku poziomach. Przede wszystkim pomaga agregować i normalizować dane pochodzące z wielu źródeł, takich jak skanery bezpieczeństwa, systemy EDR, repozytoria kodu, bazy zasobów czy informacje o aktywnie wykorzystywanych lukach. Dzięki temu analitycy szybciej uzyskują spójny obraz sytuacji.

Drugim obszarem jest wzbogacanie kontekstu. Modele AI mogą wspierać klasyfikację zgłoszeń, uwzględniając krytyczność zasobu, ekspozycję internetową, znaczenie biznesowe systemu, zależności usługowe czy potencjalne ścieżki ruchu atakującego. W efekcie łatwiej ustalić, które podatności wymagają natychmiastowej reakcji, a które mogą zostać obsłużone w późniejszym terminie.

Trzeci poziom to interfejs i użyteczność. Modele językowe upraszczają wyszukiwanie informacji, generowanie podsumowań oraz przygotowywanie rekomendacji naprawczych w języku naturalnym. To szczególnie cenne w środowiskach, gdzie zespoły bezpieczeństwa pracują pod presją czasu i muszą analizować dużą liczbę sygnałów.

Problem zaczyna się wtedy, gdy od AI oczekuje się samodzielnego i niezawodnego wykrywania nowych lub trudnych do uchwycenia podatności. Takie zadanie wymaga nie tylko rozpoznawania wzorców, ale również rozumienia semantyki kodu, architektury aplikacji, stanów wykonania, konfiguracji środowiska i relacji między komponentami. Obecne modele dobrze radzą sobie z analizą opisową i wspieraniem interpretacji danych, ale gorzej z deterministycznym wskazywaniem realnie wykorzystywalnych błędów.

Dodatkowym ograniczeniem są znane problemy systemów AI, takie jak halucynacje, niestabilność odpowiedzi, zależność od jakości danych wejściowych oraz trudności z walidacją wyników. W programach zarządzania podatnościami może to prowadzić do błędnej priorytetyzacji, pomijania istotnych luk albo generowania nadmiarowych alertów o niskiej wartości operacyjnej.

Konsekwencje / ryzyko

Największym ryzykiem związanym z obecną falą wdrożeń AI są błędne oczekiwania. Jeśli organizacja uzna, że sztuczna inteligencja samodzielnie rozwiąże problem zarządzania podatnościami, może zaniedbać podstawy bezpieczeństwa, takie jak inwentaryzacja aktywów, skuteczny patch management, segmentacja sieci, ograniczanie ekspozycji internetowej czy właściwe mapowanie krytyczności systemów.

Istotnym problemem jest również nadmierne zaufanie do rekomendacji modelu. W środowisku złożonym biznesowo nieprawidłowa ocena priorytetów może spowodować, że naprawdę krytyczna luka pozostanie niezałatana, podczas gdy zespół skupi się na mniej istotnych zdarzeniach. Z kolei zbyt duża liczba fałszywych alarmów zwiększa koszty operacyjne i prowadzi do zmęczenia alertami.

Nie można też pomijać ryzyk wynikających z samego wdrażania AI. Obejmują one bezpieczeństwo danych przekazywanych do modelu, kontrolę uprawnień, odporność integracji, ryzyko ujawnienia informacji wrażliwych oraz zależność od zewnętrznych dostawców. W efekcie AI w cyberbezpieczeństwie tworzy jednocześnie nową wartość i nową powierzchnię ataku.

Rekomendacje

Najbardziej racjonalnym podejściem jest traktowanie AI jako elementu wspierającego program zarządzania podatnościami, a nie jako jego podstawowego filaru. Organizacje powinny wdrażać takie rozwiązania w jasno zdefiniowanych przypadkach użycia, gdzie łatwo zmierzyć korzyści operacyjne i utrzymać nadzór nad wynikami.

Wykorzystywać AI do triage alertów, korelacji danych i wzbogacania kontekstu podatności.
Weryfikować rekomendacje modelu przez analityków, szczególnie przy lukach krytycznych i systemach produkcyjnych.
Mierzyć skuteczność AI za pomocą tych samych wskaźników co inne technologie bezpieczeństwa, np. MTTR, udział false positives i pokrycie aktywów.
Utrzymywać klasyczne fundamenty bezpieczeństwa: patching, segmentację, hardening, testy aplikacyjne i kontrolę zależności w łańcuchu dostaw.
Objąć wdrożenia AI odpowiednim governance, w tym kontrolą danych wejściowych, audytem decyzji modelu i oceną ryzyka dostawców.

Dopiero takie połączenie pozwala wykorzystać zalety AI bez tworzenia fałszywego poczucia bezpieczeństwa. W obecnej fazie rozwoju technologii kluczowe pozostaje połączenie automatyzacji z eksperckim nadzorem człowieka.

Podsumowanie

AI realnie zwiększa świadomość podatności i pomaga zespołom bezpieczeństwa szybciej zrozumieć, co dzieje się w ich środowisku. To ważny postęp, zwłaszcza w dużych organizacjach, które muszą obsługiwać rozproszoną infrastrukturę oraz stale rosnącą liczbę sygnałów bezpieczeństwa.

Jednocześnie obecne narzędzia nie potwierdzają jeszcze, że sztuczna inteligencja jest w stanie autonomicznie i niezawodnie przełamać problem wykrywania podatności. Najbardziej dojrzałe podejście polega dziś na łączeniu AI z tradycyjnymi metodami bezpieczeństwa, kontrolą procesów i stałą walidacją wyników przez ekspertów.

Źródła

AI Raises Vulnerability Awareness, But Detection Impact Remains Limited — https://www.infosecurity-magazine.com/news/ai-raises-vulnerability-awareness/
Pilot for Artificial Intelligence Enabled Vulnerability Detection — https://www.cisa.gov/resources-tools/resources/pilot-artificial-intelligence-enabled-vulnerability-detection
Joint Guidance on Deploying AI Systems Securely — https://www.cisa.gov/news-events/alerts/2024/04/15/joint-guidance-deploying-ai-systems-securely
NSA Publishes Guidance for Strengthening AI System Security — https://www.nsa.gov/serve-from-netstorage/Press-Room/Press-Releases-Statements/Press-Release-View/Article/3741371/nsa-publishes-guidance-for-strengthening-ai-system-security/index.html
AI adoption in security taking off amid budget, trust, and skill-based issues — https://www.csoonline.com/article/1307294/ai-adoption-in-security-taking-off-amid-budget-trust-and-skill-based-issues.html