Archiwa: AI - Strona 2 z 49 - Security Bez Tabu

Bezpieczeństwo „Mythos-ready”: CSA ostrzega CISO przed przyspieszeniem zagrożeń AI

Wprowadzenie do problemu / definicja

Dynamiczny rozwój modeli sztucznej inteligencji zdolnych do automatycznego wykrywania luk, analizowania kodu i przygotowywania ścieżek ataku zmienia sposób myślenia o cyberobronie. Cloud Security Alliance zwraca uwagę, że organizacje powinny przygotować się na erę, w której czas między odkryciem podatności a jej aktywną eksploatacją będzie znacznie krótszy niż dotychczas.

Pojęcie programu bezpieczeństwa „Mythos-ready” opisuje podejście dostosowane do środowiska, w którym ataki wspierane przez AI są szybsze, bardziej zautomatyzowane i prowadzone równolegle na wielu frontach. Dla działów bezpieczeństwa oznacza to konieczność przeglądu procedur, narzędzi i zdolności operacyjnych.

W skrócie

CSA ostrzega, że ofensywne modele AI mogą znacząco skrócić czas potrzebny do identyfikacji i wykorzystania podatności.
Największym problemem nie jest nowy typ zagrożeń, lecz skokowy wzrost tempa i skali działań przeciwnika.
Organizacje powinny przyspieszyć patch management, rozbudować automatyzację i wzmocnić podstawowe kontrole bezpieczeństwa.
Szczególnego znaczenia nabierają segmentacja, filtrowanie ruchu wychodzącego, MFA odporne na phishing oraz ćwiczenia na scenariusze wielu incydentów jednocześnie.

Kontekst / historia

Znaczenie tematu wzrosło po ujawnieniu inicjatywy Project Glasswing, w ramach której Anthropic ograniczyło dostęp do modelu Claude Mythos Preview i skierowało go do kontrolowanego zastosowania defensywnego. Celem programu jest pomoc wybranym partnerom w identyfikowaniu oraz usuwaniu słabości w krytycznym oprogramowaniu, zanim podobne możliwości zostaną szerzej wykorzystane przez napastników.

Na tym tle Cloud Security Alliance opublikowała analizę poświęconą budowie programu bezpieczeństwa odpornego na przyspieszony krajobraz podatności. Przekaz jest jednoznaczny: organizacje nie powinny zakładać, że klasyczne okna serwisowe, standardowe cykle łatania i tradycyjne procedury reagowania będą wystarczające w świecie, w którym AI obniża koszt wyszukiwania błędów i przygotowywania exploitów.

Istotne jest również to, że zagrożenie nie dotyczy wyłącznie spektakularnych luk typu zero-day. Równie ważny staje się wzrost liczby błędów średniej i wysokiej wagi, które dzięki automatyzacji mogą być wykorzystywane niemal natychmiast po ujawnieniu.

Analiza techniczna

Techniczny problem polega na kompresji całego łańcucha ataku. Zaawansowany model AI może jednocześnie wspierać analizę kodu źródłowego, rozpoznanie logiki aplikacji, fuzzing, triage podatności, generowanie proof-of-concept oraz dobór technik post-exploitation. Gdy te etapy zostają połączone w jeden proces, przewaga czasowa obrońcy gwałtownie maleje.

W tradycyjnym modelu bezpieczeństwa odkrycie podatności, opracowanie eksploitu, walidacja warunków ataku i wdrożenie kampanii były osobnymi działaniami. W scenariuszu wspieranym przez AI granice między tymi fazami zacierają się, co oznacza, że moment znalezienia błędu może niemal pokrywać się z gotowością do jego wykorzystania.

Szczególnie narażone pozostają środowiska o dużej złożoności operacyjnej i technologicznej:

rozbudowane ekosystemy chmurowe i hybrydowe,
złożone łańcuchy CI/CD,
infrastruktura obciążona długiem technicznym,
aplikacje z bardzo częstymi wdrożeniami,
środowiska zależne od szerokiego łańcucha dostaw oprogramowania.

CSA podkreśla jednak, że fundamenty bezpieczeństwa pozostają aktualne. Segmentacja sieci ogranicza ruch boczny, filtrowanie ruchu wychodzącego utrudnia komunikację z infrastrukturą dowodzenia i eksfiltrację danych, a architektura defense-in-depth zmniejsza skutki pojedynczego przełamania. Duże znaczenie mają też phishing-resistant MFA, zasada najmniejszych uprawnień oraz rotacja sekretów.

Równolegle rośnie znaczenie automatyzacji po stronie obrony. Narzędzia AI i agentowe mechanizmy analityczne mogą wspierać przegląd kodu, priorytetyzację podatności, walidację konfiguracji, wykrywanie anomalii i częściowo także remediację. Nie usuwa to ryzyka, ale pozwala skrócić czas reakcji i częściowo zrównoważyć przewagę tempa po stronie atakującego.

Konsekwencje / ryzyko

Najważniejszą konsekwencją jest skrócenie okna reakcji. Organizacje, które wcześniej zakładały, że od publikacji informacji o luce do prób masowej eksploatacji miną dni lub tygodnie, mogą szybko przekonać się, że taki model przestaje działać. Opóźnienie we wdrożeniu poprawki może oznaczać natychmiastową ekspozycję na atak.

Drugim istotnym skutkiem jest wzrost obciążenia zespołów bezpieczeństwa i operacji IT. Więcej alertów, więcej aktualizacji, więcej analiz i więcej krytycznych decyzji podejmowanych w krótkim czasie prowadzi do zmęczenia operacyjnego, wzrostu liczby błędów i ryzyka wypalenia specjalistów.

Trzecie ryzyko dotyczy incydentów wielowątkowych. W środowisku napędzanym przez AI organizacja może równocześnie mierzyć się z próbą przejęcia tożsamości uprzywilejowanej, atakiem na usługi zewnętrzne, eksfiltracją danych i wykorzystaniem podatności w łańcuchu dostaw. Tradycyjne playbooki, projektowane pod pojedynczy i liniowy incydent, mogą okazać się niewystarczające.

Nie można też ignorować ryzyka destrukcyjnego. Przyspieszenie ofensywnych zdolności AI może zwiększyć skalę kampanii ransomware, ale także użycie narzędzi powodujących trwałe uszkodzenie danych lub destabilizację środowiska. Dlatego odporność operacyjna i zdolność odtworzeniowa powinny być analizowane równie poważnie jak prewencja i detekcja.

Rekomendacje

W ocenie ekspertów temat należy traktować jednocześnie jako priorytet strategiczny i operacyjny. Kluczowe działania obejmują:

przyspieszenie zarządzania podatnościami i skrócenie czasu od wykrycia do remediacji,
wzmocnienie podstawowych kontroli bezpieczeństwa, takich jak segmentacja, egress filtering, Zero Trust i MFA odporne na phishing,
automatyzację bezpieczeństwa w SDLC oraz SecOps, w tym skanowanie kodu i testy bezpieczeństwa w pipeline’ach CI/CD,
prowadzenie ćwiczeń obejmujących wiele jednoczesnych incydentów wysokiej wagi,
przegląd możliwości patch management pod kątem okien serwisowych, zasobów i procesów akceptacji zmian,
zwiększenie odporności operacyjnej, w tym gotowości do odtwarzania usług i weryfikacji integralności kopii zapasowych,
ostrzejszą ocenę ryzyka w łańcuchu dostaw, zwłaszcza w obszarze zależności open source i komponentów zewnętrznych,
lepsze wsparcie dla zespołów bezpieczeństwa poprzez dodatkowe zasoby, realistyczne priorytety i automatyzację pracy.

Podsumowanie

Koncepcja bezpieczeństwa „Mythos-ready” nie oznacza rewolucji w podstawach cyberbezpieczeństwa, lecz konieczność dostosowania ich do znacznie szybszego tempa działań przeciwnika. Największe zagrożenie wynika nie z pojedynczej nowej techniki ataku, ale z gwałtownego skrócenia czasu między wykryciem słabości a jej wykorzystaniem.

Dla CISO to wyraźny sygnał, że należy pilnie zrewidować procesy łatania, automatyzacji, segmentacji, gotowości operacyjnej i wsparcia dla zespołów. Organizacje, które wykorzystają obecne okno przygotowawcze, będą lepiej przygotowane na rzeczywistość, w której AI stanie się standardowym akceleratorem cyberataków.

Źródła

SecurityWeek — „Mythos-Ready” Security: CSA Urges CISOs to Prepare for Accelerated AI Threats — https://www.securityweek.com/mythos-ready-security-csa-urges-cisos-to-prepare-for-accelerated-ai-threats/
Cloud Security Alliance Labs — The “AI Vulnerability Storm”: Building a “Mythos-ready” Security Program — https://labs.cloudsecurityalliance.org/mythos-ciso/
Anthropic — Project Glasswing — https://www.anthropic.com/project/glasswing
Anthropic — Project Glasswing: Securing critical software for the AI era — https://www.anthropic.com/glasswing

Raport AppSec 2026: 4-krotny wzrost krytycznego ryzyka przy 216 mln ustaleń bezpieczeństwa

Wprowadzenie do problemu / definicja

Bezpieczeństwo aplikacji przestaje być dziś zagadnieniem sprowadzanym wyłącznie do liczby wykrytych podatności i alertów. Coraz większe znaczenie ma to, które problemy realnie przekładają się na ryzyko biznesowe, bezpieczeństwo danych oraz ciągłość działania usług. Najnowsza analiza obejmująca 216 milionów ustaleń bezpieczeństwa pokazuje, że organizacje nie mierzą się już tylko z nadmiarem sygnałów, ale z wyraźnym wzrostem liczby zdarzeń wymagających natychmiastowej reakcji.

To istotna zmiana dla zespołów AppSec, DevSecOps i SOC, ponieważ sama techniczna ocena podatności coraz częściej nie wystarcza do właściwego ustalenia priorytetów. O wyniku decyduje kontekst: znaczenie aplikacji dla biznesu, rodzaj przetwarzanych danych, ekspozycja usługi oraz możliwość wykorzystania luki w praktyce.

W skrócie

Analiza objęła 216 mln ustaleń bezpieczeństwa z 250 organizacji w okresie 90 dni.
Łączny wolumen alertów wzrósł rok do roku o 52%.
Liczba priorytetowych ryzyk krytycznych zwiększyła się niemal czterokrotnie.
Średnio na organizację przypadło 865 tys. alertów oraz 795 krytycznych problemów po uwzględnieniu kontekstu.
Udział krytycznych ustaleń względem całego strumienia sygnałów niemal się potroił.

Wniosek jest jednoznaczny: problemem nie jest już wyłącznie szum generowany przez narzędzia, ale rosnąca ekspozycja na realnie niebezpieczne scenariusze ataku.

Kontekst / historia

Przez lata bezpieczeństwo aplikacji opierało się głównie na klasycznych metrykach technicznych, takich jak poziomy CVSS czy wyniki pochodzące z narzędzi SAST, SCA, DAST oraz skanowania kontenerów i pipeline’ów CI/CD. Model ten był skuteczny w środowiskach, gdzie tempo zmian w kodzie było bardziej przewidywalne, a krajobraz aplikacyjny mniej dynamiczny.

Obecnie sytuację zmienia rosnąca skala automatyzacji developmentu oraz wykorzystanie narzędzi wspieranych przez AI. Przyspieszają one dostarczanie oprogramowania, ale jednocześnie zwiększają liczbę zależności, częstotliwość zmian i złożoność środowisk. W takim modelu sama surowa ocena techniczna podatności nie odzwierciedla już pełnego poziomu zagrożenia.

Coraz ważniejsze staje się więc podejście kontekstowe, w którym luka oceniana jest nie tylko przez pryzmat swojej natury technicznej, lecz także przez wpływ na procesy biznesowe, dane osobowe i systemy produkcyjne.

Analiza techniczna

Najważniejszym wnioskiem z raportu jest przesunięcie ciężaru oceny z samej podatności na jej osadzenie w konkretnym środowisku organizacji. Dwie luki o podobnym charakterze technicznym mogą mieć zupełnie inną wagę operacyjną, jeśli jedna występuje w systemie przetwarzającym dane wrażliwe, a druga w mniej istotnym komponencie o ograniczonej ekspozycji.

W analizie wskazano, że najczęstszymi czynnikami podnoszącymi priorytet były wysoka krytyczność biznesowa zasobu oraz obecność danych PII. To pokazuje, że skuteczny triage wymaga korelacji wyników skanowania z dodatkowymi metadanymi: właścicielem aplikacji, klasyfikacją danych, środowiskiem wdrożeniowym oraz rolą systemu w architekturze organizacji.

Z technicznego punktu widzenia widoczna jest rosnąca luka między tempem developmentu a zdolnością organizacji do remediacji. Narzędzia wspierające tworzenie kodu przyspieszają wdrożenia, ale nie gwarantują równie szybkiego wykrywania i usuwania błędów. W efekcie rośnie liczba problemów trudniejszych do wychwycenia przez proste reguły i tradycyjne skanery.

podatności zależne od konkretnej ścieżki wykonania,
błędy logiki biznesowej,
niebezpieczne integracje z bibliotekami i API,
problemy wynikające z niepełnego zrozumienia wpływu zmian na środowisko produkcyjne,
ryzyka w łańcuchu dostaw oprogramowania związane z zależnościami i automatyzacją.

Raport pokazuje także różnice między sektorami. Najwyższą gęstość krytycznych ustaleń odnotowano w branży ubezpieczeniowej, natomiast najwyższy surowy wolumen alertów pojawił się w sektorze motoryzacyjnym. To sygnał, że wraz z rozwojem złożonych platform cyfrowych problem bezpieczeństwa przesuwa się z poziomu pojedynczych aplikacji na poziom całych ekosystemów.

Konsekwencje / ryzyko

Operacyjnie oznacza to, że organizacje mogą błędnie uznać wzrost liczby alertów za zwykły problem przeciążenia narzędzi i zespołów. Tymczasem dane wskazują, że równolegle rośnie liczba przypadków o bezpośrednim wpływie biznesowym. Ignorowanie tego trendu zwiększa ryzyko kompromitacji aplikacji produkcyjnych, wycieku danych osobowych, zakłóceń usług i naruszeń regulacyjnych.

Kolejnym problemem jest niewłaściwa kolejność działań naprawczych. Gdy backlog remediacyjny opiera się wyłącznie na severity score, zespoły mogą poświęcać zasoby na mniej istotne technicznie problemy, podczas gdy rzeczywiście groźne luki pozostają otwarte w systemach kluczowych dla organizacji.

Wzrost liczby krytycznych ustaleń na organizację oznacza też większe obciążenie dla programistów, zespołów AppSec, platform engineering i właścicieli usług. Bez automatyzacji korelacji kontekstu oraz inteligentnej priorytetyzacji proces usuwania podatności staje się coraz mniej skalowalny.

Dodatkowo firmy wdrażające AI-assisted development bez równoległego wzmacniania kontroli bezpieczeństwa ryzykują, że wzrost produktywności zostanie zniwelowany przez większą liczbę błędów, bardziej złożone śledztwa i wyższe koszty napraw po wdrożeniu.

Rekomendacje

Najważniejszym krokiem powinno być odejście od zarządzania podatnościami wyłącznie przez pryzmat oceny technicznej. Priorytetyzacja musi obejmować kontekst biznesowy i operacyjny aplikacji, a także realne możliwości wykorzystania luki.

korelować wyniki SAST, SCA, DAST, skanowania kontenerów i CI/CD z inwentarzem aplikacji oraz klasyfikacją danych,
wdrożyć polityki risk-based remediation zamiast prostego sortowania po CVSS,
przekazywać do zespołów developerskich tylko te alerty, które zostały potwierdzone kontekstowo,
objąć narzędzia AI wykorzystywane przez programistów dodatkowymi kontrolami bezpieczeństwa,
zwiększyć automatyzację wykrywania problemów w pipeline’ach przy jednoczesnym rozwijaniu walidacji kontekstowej,
mierzyć czas do remediacji ryzyk krytycznych oraz udział podatności w systemach przetwarzających PII,
rozwijać współpracę między AppSec, zespołami platformowymi, właścicielami produktów i compliance.

Równie istotna jest redukcja szumu w architekturze narzędzi bezpieczeństwa. Samo zwiększanie liczby skanerów nie rozwiąże problemu, jeśli ich wyniki nie będą łączone w spójny obraz ryzyka. Potrzebna jest widoczność end-to-end: od kodu źródłowego i zależności, przez build pipeline, aż po środowisko uruchomieniowe i znaczenie konkretnego komponentu dla biznesu.

Podsumowanie

Analiza 216 milionów ustaleń bezpieczeństwa potwierdza wyraźną zmianę w krajobrazie AppSec. Kluczowym wyzwaniem nie jest już jedynie liczba alertów, ale szybki wzrost rzeczywiście krytycznych ryzyk, które po uwzględnieniu kontekstu wymagają natychmiastowej reakcji.

Wraz z przyspieszeniem developmentu i rosnącym wykorzystaniem AI zespoły bezpieczeństwa muszą przebudować sposób priorytetyzacji, triage i remediacji. Organizacje, które nie połączą danych technicznych z kontekstem biznesowym, będą coraz trudniej nadążać za tempem zmian i rosnącą powierzchnią ataku.

Źródła

The Hacker News — Analysis of 216M Security Findings Shows a 4x Increase In Critical Risk (2026 Report) — https://thehackernews.com/2026/04/analysis-of-216m-security-findings.html
OX Security — DERAILED | 2026 Application Security Benchmark Report — https://www.ox.security/resource-category/whitepapers-and-reports/derailed-2026-application-security-benchmark-report/

Pushpaganda: kampania wykorzystująca Google Discover, AI i powiadomienia push do scareware oraz fraudów reklamowych

Wprowadzenie do problemu / definicja

Pushpaganda to nazwa kampanii cyberoszustw i nadużyć reklamowych, w której przestępcy łączą spamerskie pozycjonowanie treści, materiały generowane przez sztuczną inteligencję oraz przeglądarkowe powiadomienia push. Celem operacji jest przejęcie ruchu z pozornie wiarygodnych źródeł, takich jak kanały rekomendacji treści, a następnie przekierowanie użytkownika do scareware, fałszywych ostrzeżeń i schematów wyłudzeń.

To zagrożenie pokazuje, że współczesne kampanie nie muszą opierać się wyłącznie na klasycznym phishingu czy malware. Coraz częściej wykorzystują legalne funkcje przeglądarek i platform internetowych, aby budować wiarygodność oraz utrzymywać długotrwały kontakt z ofiarą.

W skrócie

Badacze bezpieczeństwa opisali Pushpagandę jako operację ad fraud opartą na zmanipulowanym ruchu organicznym pochodzącym z prawdziwych urządzeń mobilnych. Atakujący publikowali pseudoartykuły stylizowane na wiadomości, zwiększali ich widoczność w ekosystemie Google, a następnie kierowali odbiorców na kontrolowane domeny.

Po wejściu na stronę użytkownik był nakłaniany do włączenia powiadomień push. Od tego momentu przeglądarka stawała się kanałem dalszej socjotechniki, służącym do dostarczania alarmistycznych komunikatów, przekierowań oraz treści monetyzowanych reklamowo.

kampania wykorzystywała treści generowane przez AI,
nadużywała widoczności w kanałach rekomendacji treści,
opierała się na zgodach na web push,
łączyła scareware z fraudem reklamowym i wyłudzeniami.

Kontekst / historia

Nadużycia związane z powiadomieniami push są znane od lat, ponieważ stanowią tani i skuteczny sposób utrzymywania kontaktu z ofiarą bez potrzeby instalowania klasycznego złośliwego oprogramowania. Wcześniejsze kampanie zwykle skupiały się jednak na prostym spamie lub pojedynczych przekierowaniach.

W przypadku Pushpagandy nowością jest połączenie kilku elementów w jeden spójny łańcuch: masowej produkcji treści z pomocą AI, zatruwania wyników widoczności oraz późniejszej monetyzacji ruchu poprzez reklamy i oszustwa. Kampania miała charakter skalowalny i transgraniczny, obejmując wiele regionów oraz różne wersje językowe.

Według ujawnionych informacji operacja była początkowo obserwowana głównie w Indiach, ale z czasem rozszerzyła zasięg na kolejne rynki, w tym Stany Zjednoczone, Australię, Kanadę, Republikę Południowej Afryki i Wielką Brytanię.

Analiza techniczna

Techniczny przebieg kampanii można opisać jako wieloetapowy model nadużycia, którego celem było przejęcie uwagi użytkownika i przekształcenie jej w trwały kanał monetyzacji.

Przygotowanie infrastruktury: operatorzy utrzymywali sieć domen publikujących fałszywe materiały przypominające artykuły informacyjne.
Generowanie treści przez AI: automatyzacja umożliwiała szybkie tworzenie dużej liczby pseudoartykułów dopasowanych do trendów i tematów lokalnych.
SEO poisoning: treści były optymalizowane pod widoczność w wyszukiwaniu i kanałach rekomendacji, co zwiększało szanse na pozyskanie organicznego ruchu.
Socjotechnika na stronie: użytkownik był zachęcany do kliknięcia przycisku zgody na powiadomienia, często pod presją pilności lub rzekomego zagrożenia.
Utrwalenie dostępu: po udzieleniu zgody przeglądarka mogła wyświetlać kolejne komunikaty bez potrzeby ponownego wejścia na stronę.
Monetyzacja: kliknięcia w notyfikacje prowadziły do kolejnych serwisów generujących przychód reklamowy lub realizujących schematy wyłudzeń.

Istotnym elementem kampanii było wykorzystanie ruchu z realnych urządzeń mobilnych. Taki model może być trudniejszy do odfiltrowania niż klasyczny ruch botów, ponieważ wygląda bardziej naturalnie z perspektywy systemów reklamowych i analitycznych.

W szczytowym okresie operacja miała generować około 240 milionów żądań bid request w ciągu siedmiu dni i obejmować 113 domen, co pokazuje przemysłową skalę tego typu nadużycia.

Konsekwencje / ryzyko

Dla użytkownika końcowego największym zagrożeniem jest zamiana zaufanego środowiska konsumpcji treści w kanał dostarczania oszustw. Ofiara może uznać komunikaty za wiarygodne tylko dlatego, że pierwszy kontakt nastąpił przez pozornie legalny artykuł lub mechanizm rekomendacji.

kontakt ze scareware i fałszywymi ostrzeżeniami bezpieczeństwa,
przekierowania do stron wyłudzających płatności lub dane,
zalewanie urządzenia spamem przez powiadomienia push,
większa podatność na kolejne etapy socjotechniki.

Ryzyko dotyczy także organizacji. Jeśli pracownik korzysta z urządzenia służbowego, może wejść w interakcję z fałszywymi komunikatami, zainicjować nieautoryzowane działania lub ujawnić dane. Dodatkowo ekosystem reklamowy ponosi straty wynikające ze sztucznego generowania ruchu i zafałszowania jakości odsłon.

Strategicznie szczególnie niepokojące jest wykorzystanie AI, która obniża koszt i próg wejścia dla podobnych operacji. Automatyzacja umożliwia szybsze testowanie wielu wariantów treści i dostosowywanie przynęt do konkretnych grup odbiorców.

Rekomendacje

Ograniczenie skuteczności kampanii takich jak Pushpaganda wymaga podejścia warstwowego, obejmującego zarówno konfigurację techniczną, jak i edukację użytkowników.

Ograniczanie uprawnień push: w środowiskach firmowych warto blokować lub ściśle kontrolować zgody na powiadomienia przeglądarkowe.
Szkolenia użytkowników: programy świadomości powinny obejmować nie tylko e-mail phishing, lecz także fałszywe alerty w przeglądarce i ryzyka związane z kliknięciem „Zezwól”.
Monitorowanie telemetrii: należy analizować nietypowe przekierowania, nagłe zgody na powiadomienia oraz ruch do mało znanych domen.
Filtrowanie DNS i ochrona webowa: blokowanie domen o niskiej reputacji może zatrzymać kampanię jeszcze przed interakcją użytkownika ze stroną.
Polityki MDM i przeglądarek: zarządzanie urządzeniami mobilnymi powinno obejmować konfigurację przeglądarek i ograniczenia dla ryzykownych uprawnień.
Współpraca zespołów: bezpieczeństwo, fraud prevention i ad operations powinny wspólnie analizować anomalię ruchu oraz sygnały sztucznej monetyzacji.
Reakcja po incydencie: w przypadku aktywacji podejrzanych notyfikacji należy usunąć zgodę, wyczyścić dane witryny, przeanalizować historię przekierowań i sprawdzić urządzenie.

Podsumowanie

Pushpaganda jest przykładem nowoczesnej kampanii cyberoszustw, w której legalne funkcje platform internetowych zostały połączone z automatyzacją AI, spamerskim SEO i socjotechniką. Przestępcy nie muszą od razu infekować urządzenia, jeśli potrafią przejąć uwagę użytkownika i skłonić go do udzielenia zgody na powiadomienia.

Dla obrońców oznacza to konieczność szerszego spojrzenia na zagrożenia. Ochrona nie może ograniczać się do wykrywania malware i phishingu, lecz powinna obejmować także nadużycia rekomendacji treści, mechanizmów reklamowych oraz uprawnień przeglądarkowych.

Źródła

The Hacker News — https://thehackernews.com/2026/04/ai-driven-pushpaganda-scam-exploits.html
Google Safety Center — Protection from Online Scams & Fraud — https://safety.google/intl/en_us/safety/scams-fraud/

Fałszywa witryna Claude rozprowadza PlugX RAT. Kampania łączy socjotechnikę, MSI i DLL sideloading

Wprowadzenie do problemu / definicja

Cyberprzestępcy coraz częściej wykorzystują rozpoznawalność narzędzi opartych na sztucznej inteligencji do prowadzenia kampanii malware. W opisywanym przypadku fałszywa witryna podszywająca się pod usługę związaną z Claude była używana do dystrybucji PlugX RAT — znanego trojana zdalnego dostępu, który umożliwia atakującym przejęcie kontroli nad systemem ofiary.

Incydent pokazuje, jak skuteczne staje się połączenie socjotechniki z technikami ukrywania złośliwego kodu. Użytkownik widzi pozornie wiarygodny instalator i działającą aplikację, podczas gdy w tle uruchamiany jest łańcuch infekcji zapewniający trwałość i komunikację z infrastrukturą command-and-control.

W skrócie

Fałszywa strona podszywała się pod popularne narzędzie AI i oferowała rzekomą wersję „pro”.
Ofiara pobierała archiwum ZIP zawierające instalator MSI imitujący legalne wdrożenie aplikacji.
Równolegle uruchamiany był skrypt VBScript, który instalował PlugX RAT.
Malware wykorzystywało technikę DLL sideloading z użyciem podpisanego pliku wykonywalnego.
Zagrożenie utrzymywało trwałość po restarcie i komunikowało się z serwerem C2.

Kontekst / historia

PlugX to rodzina złośliwego oprogramowania obecna w krajobrazie zagrożeń od wielu lat. Historycznie była obserwowana w kampaniach ukierunkowanych i operacjach szpiegowskich, jednak z czasem jej warianty zaczęły pojawiać się także szerzej, co utrudnia jednoznaczną atrybucję. Dziś PlugX pozostaje niebezpiecznym narzędziem zarówno w działaniach sponsorowanych, jak i w typowo cyberprzestępczych kampaniach nastawionych na trwały dostęp do systemu.

Nowa kampania wpisuje się w coraz wyraźniejszy trend nadużywania marek technologicznych oraz tematów związanych z AI. Popularność takich usług zwiększa skuteczność oszustw, ponieważ użytkownicy są bardziej skłonni zaufać instalatorowi, który wygląda profesjonalnie i obiecuje szybki dostęp do modnego narzędzia.

Analiza techniczna

Łańcuch infekcji został zaprojektowany tak, aby maksymalnie ograniczyć podejrzenia. Dostarczany plik zawierał instalator MSI, który naśladował legalny proces instalacji. To istotny element maskowania, ponieważ użytkownik faktycznie otrzymywał działającą aplikację, co zmniejszało szansę na szybkie wykrycie incydentu.

Kluczowy etap rozpoczynał się przy uruchomieniu programu ze skrótu na pulpicie. Zamiast prostego startu aplikacji wykonywany był skrypt VBScript pełniący funkcję droppera. Skrypt uruchamiał prawdziwy program na pierwszym planie, a jednocześnie w tle wdrażał komponenty malware.

Następnie złośliwy łańcuch umieszczał pliki w folderze autostartu. Jednym z nich był podpisany plik NOVUpdate.exe, legalny komponent aktualizatora oprogramowania zabezpieczającego, wykorzystany do DLL sideloading. Taka technika pozwala uruchomić złośliwą bibliotekę DLL w kontekście zaufanego procesu, co utrudnia wykrycie i może osłabić skuteczność mechanizmów opartych wyłącznie na reputacji plików.

Po uruchomieniu komponent inicjował połączenie TCP z infrastrukturą C2 hostowaną w chmurze. To umożliwiało zdalne sterowanie zainfekowaną stacją, pobieranie kolejnych modułów, wykonywanie poleceń oraz potencjalną eksfiltrację danych. Dodatkowo dropper tworzył plik wsadowy usuwający część artefaktów po infekcji, co ograniczało widoczność incydentu i utrudniało analizę śledczą.

W kampanii zastosowano także mechanizmy tłumienia błędów, aby zminimalizować ryzyko pojawienia się komunikatów ostrzegawczych. W praktyce oznacza to, że użytkownik mógł nie zauważyć żadnych oznak kompromitacji mimo aktywnej infekcji działającej w tle.

Konsekwencje / ryzyko

Ryzyko związane z PlugX RAT jest wysokie, ponieważ malware tego typu zapewnia szerokie możliwości zdalnej kontroli nad systemem. W zależności od wariantu atakujący może prowadzić rozpoznanie środowiska, kraść dane, przechwytywać informacje uwierzytelniające, instalować dodatkowe payloady oraz wykorzystywać zainfekowane urządzenie jako punkt wyjścia do dalszych działań w sieci organizacji.

Szczególnie groźny jest sam model dostarczenia zagrożenia. Ofiara otrzymuje bowiem działającą aplikację, więc nie ma oczywistych powodów, by podejrzewać naruszenie. W środowisku firmowym taki schemat może skutecznie ominąć czujność pracowników, zwłaszcza jeśli pobierają oni narzędzia AI poza oficjalnym procesem akceptacji oprogramowania.

Dodatkowym problemem pozostaje użycie podpisanego pliku wykonywalnego oraz techniki DLL sideloading. To połączenie utrudnia detekcję opartą na prostych regułach i zwiększa szansę, że zagrożenie pozostanie aktywne przez dłuższy czas.

Rekomendacje

Organizacje powinny ograniczyć możliwość instalowania oprogramowania z niezatwierdzonych źródeł, szczególnie narzędzi AI, komunikacyjnych i biurowych. Kluczowe znaczenie ma egzekwowanie zasady pobierania aplikacji wyłącznie z oficjalnych kanałów producenta lub z centralnie zarządzanych repozytoriów.

Wdrożyć allowlisting aplikacji oraz kontrolę uruchamiania skryptów z katalogów użytkownika.
Monitorować tworzenie plików w folderach Startup oraz nietypowe mechanizmy trwałości.
Analizować relacje parent-child process po instalacji oprogramowania.
Wykrywać przypadki DLL sideloading i ładowania niestandardowych bibliotek przez zaufane procesy.
Kontrolować połączenia wychodzące do nietypowej infrastruktury C2 bezpośrednio po instalacji aplikacji.
Prowadzić szkolenia użytkowników dotyczące fałszywych stron, reklam i nieoficjalnych wersji „premium”.

W przypadku podejrzenia infekcji należy natychmiast odizolować host, zabezpieczyć artefakty z folderów autostartu, przeanalizować aktywność procesów oraz zweryfikować, czy nie doszło do kradzieży poświadczeń lub ruchu bocznego.

Podsumowanie

Fałszywa witryna podszywająca się pod popularne narzędzie AI została wykorzystana do dystrybucji PlugX RAT w kampanii łączącej wiarygodny instalator, skryptowy dropper i DLL sideloading. To dojrzały technicznie scenariusz ataku, którego skuteczność wynika z dobrego maskowania oraz wykorzystania aktualnych trendów socjotechnicznych.

Dla organizacji jest to wyraźny sygnał ostrzegawczy: kontrola źródeł oprogramowania, monitoring mechanizmów trwałości oraz detekcja nietypowych procesów uruchamianych po instalacji aplikacji powinny pozostać priorytetem operacyjnym.

Źródła

SecurityWeek – Fake Claude Website Distributes PlugX RAT
https://www.securityweek.com/fake-claude-website-distributes-plugx-rat/
Malwarebytes – Fake Claude AI website installs malware instead of your AI assistant
https://www.malwarebytes.com/blog/news/2026/04/fake-claude-ai-website-installs-malware-instead-of-your-ai-assistant
MITRE ATT&CK – DLL Side-Loading
https://attack.mitre.org/techniques/T1574/002/
MITRE ATT&CK – PlugX
https://attack.mitre.org/software/S0013/
Lab52 – Analiza kampanii wykorzystującej PlugX
https://lab52.io/blog/

Operation Atlantic: zamrożenie 12 mln dolarów ujawnia skalę oszustw kryptowalutowych

Wprowadzenie do problemu / definicja

Międzynarodowa operacja organów ścigania wymierzona w oszustwa inwestycyjne i kryptowalutowe po raz kolejny pokazała, że przestępczość finansowa oparta na aktywach cyfrowych pozostaje jednym z najpoważniejszych zagrożeń dla użytkowników indywidualnych. W centrum sprawy znalazł się mechanizm określany jako approval phishing, czyli oszustwo nakłaniające ofiarę do nadania złośliwego uprawnienia portfelowi lub inteligentnemu kontraktowi, co umożliwia późniejsze przejęcie środków bez ponownej autoryzacji.

W skrócie

W ramach Operation Atlantic zamrożono ponad 12 mln dolarów i zidentyfikowano ponad 20 tys. ofiar. Śledczy powiązali sprawę z ponad 45 mln dolarów podejrzewanych strat na całym świecie. Działania były koordynowane przez brytyjską National Crime Agency przy współpracy partnerów z USA i Kanady.

Operacja koncentrowała się na identyfikacji osób, które utraciły środki lub były narażone na ich utratę w wyniku approval phishingu oraz powiązanych oszustw inwestycyjnych. Według najnowszych danych FBI oszustwa związane z kryptowalutami odpowiadają już za ponad 11,3 mld dolarów zgłoszonych strat, z czego około 7,2 mld dolarów dotyczy samych oszustw inwestycyjnych.

Kontekst / historia

Oszustwa kryptowalutowe od kilku lat przechodzą wyraźną ewolucję. Początkowo dominowały proste schematy podszywania się pod giełdy, fałszywe airdropy i klasyczne kampanie phishingowe. Z czasem przestępcy zaczęli wykorzystywać cechy charakterystyczne ekosystemu Web3: nieodwracalność transakcji, pseudonimowość adresów, łatwość tworzenia złośliwych aplikacji zdecentralizowanych oraz złożony model uprawnień tokenów.

Approval phishing stał się szczególnie skuteczny, ponieważ nie wymaga od napastnika przełamania zabezpieczeń portfela w tradycyjnym rozumieniu. Zamiast tego ofiara sama autoryzuje dostęp do zasobów, najczęściej pod wpływem fałszywej narracji inwestycyjnej, presji czasu albo podszycia się pod legalny projekt. W rezultacie granica między błędem użytkownika a technicznym przejęciem aktywów staje się trudna do wychwycenia, co utrudnia zarówno wykrywanie, jak i odzyskiwanie środków.

Analiza techniczna

Techniczny rdzeń approval phishingu opiera się na mechanizmach zatwierdzania uprawnień w standardach tokenów oraz na interakcjach z inteligentnymi kontraktami. Ofiara jest kierowana do strony, aplikacji lub interfejsu, który wygląda wiarygodnie i prosi o podpisanie operacji. W praktyce nie chodzi o zwykłe zalogowanie, lecz o autoryzację pozwalającą zewnętrznemu podmiotowi na dysponowanie określonymi aktywami z poziomu portfela.

W typowym scenariuszu użytkownik:

klika odsyłacz promujący inwestycję, odzyskanie środków, staking lub nagrodę,
podłącza portfel do fałszywej aplikacji,
podpisuje żądanie nadania uprawnień,
pozostawia aktywne zezwolenie umożliwiające transfer tokenów,
traci środki, gdy przestępcy uruchamiają mechanizm drenujący portfel.

Kluczowe jest to, że część takich operacji nie wymaga ujawnienia frazy seed ani prywatnego klucza. Z perspektywy użytkownika interakcja może wyglądać jak standardowa czynność biznesowa lub inwestycyjna. Z perspektywy bezpieczeństwa dochodzi jednak do ustanowienia trwałego zaufania wobec złośliwego kontraktu albo operatora kontrolującego adres odbiorczy.

Znaczenie Operation Atlantic polega nie tylko na zamrożeniu środków, ale również na skoordynowanym śledzeniu przepływów on-chain i korelowaniu ich z danymi operacyjnymi, zgłoszeniami ofiar oraz analizą podmiotów infrastrukturalnych. W tego typu sprawach skuteczność zależy od bardzo szybkiej identyfikacji adresów, współpracy z dostawcami usług blockchain intelligence oraz możliwości przerwania łańcucha transferów zanim środki zostaną rozproszone przez kolejne portfele, mosty międzyłańcuchowe lub usługi utrudniające śledzenie.

Konsekwencje / ryzyko

Skala incydentu potwierdza, że oszustwa inwestycyjne oparte na kryptowalutach mają dziś charakter masowy, transgraniczny i wysoce zautomatyzowany. Ryzyko obejmuje nie tylko straty finansowe użytkowników indywidualnych, ale również:

obciążenie zespołów reagowania i działów fraud detection,
utratę zaufania do platform wymiany aktywów cyfrowych,
wzrost kosztów zgodności i monitoringu transakcji,
zwiększoną presję regulacyjną na operatorów rynku,
możliwość wtórnego wykorzystania danych ofiar w kolejnych kampaniach socjotechnicznych.

Dodatkowym problemem jest trudność w odzyskaniu środków. Nawet jeśli część aktywów zostanie zamrożona, przestępcy często rozpraszają fundusze na wiele adresów i łączą je z innymi strumieniami transakcyjnymi. W praktyce skraca to okno czasowe na skuteczną reakcję do godzin, a niekiedy minut. Dla organizacji finansowych i podmiotów obsługujących kryptowaluty oznacza to konieczność prowadzenia monitoringu niemal w czasie rzeczywistym.

Rekomendacje

Użytkownicy indywidualni powinni każdorazowo weryfikować, jakie uprawnienia nadają portfelowi lub kontraktowi i unikać podpisywania operacji, których znaczenia nie rozumieją. Szczególnie ważne jest regularne przeglądanie aktywnych zezwoleń oraz ich cofanie, jeśli nie są już potrzebne.

Dla giełd, operatorów portfeli i dostawców usług Web3 rekomendowane są następujące działania:

wdrożenie ostrzeżeń kontekstowych przed nadaniem szerokich uprawnień tokenowych,
automatyczne wykrywanie znanych adresów drainerów i infrastruktur oszustw,
korelacja danych on-chain z modelami ryzyka i sygnałami oszustw inwestycyjnych,
integracja kanałów szybkiego zgłaszania i eskalacji incydentów,
rozwijanie playbooków do natychmiastowego zamrażania środków oraz współpracy międzynarodowej,
edukacja klientów w zakresie podpisywania transakcji i znaczenia zezwoleń smart contract.

Z perspektywy SOC i zespołów cyber fraud warto traktować approval phishing jako połączenie zagrożenia technicznego i socjotechnicznego. Skuteczna obrona nie może ograniczać się wyłącznie do analizy malware lub reputacji domen. Potrzebne są także mechanizmy wykrywania nietypowych wzorców autoryzacji, zmian behawioralnych użytkowników oraz nagłych transferów do adresów wysokiego ryzyka.

Podsumowanie

Operation Atlantic pokazuje, że walka z oszustwami kryptowalutowymi wymaga jednoczesnego zaangażowania organów ścigania, sektora prywatnego i dostawców analityki blockchain. Zamrożenie ponad 12 mln dolarów i identyfikacja ponad 20 tys. potencjalnych ofiar to ważny sukces operacyjny, ale jednocześnie sygnał ostrzegawczy dla całego rynku.

Approval phishing pozostaje jednym z najgroźniejszych modeli ataku na użytkowników aktywów cyfrowych, ponieważ wykorzystuje legalne mechanizmy autoryzacji do nielegalnego przejęcia środków. W praktyce najskuteczniejszą obroną pozostają szybkie wykrywanie, ograniczanie nadmiernych uprawnień i stała edukacja użytkowników.

Źródła

Help Net Security — https://www.helpnetsecurity.com/2026/04/13/crypto-scam-crackdown-12-million-frozen/
National Crime Agency: Fraudsters targeting cryptocurrency stopped and $12 million frozen in NCA-led Operation Atlantic — https://www.nationalcrimeagency.gov.uk/news/fraudsters-targeting-cryptocurrency-stopped-and-12-million-frozen-in-nca-led-operation-atlantic
FBI: Cryptocurrency and AI Scams Bilk Americans of Billions — https://www.fbi.gov/news/press-releases/cryptocurrency-and-ai-scams-bilk-americans-of-billions
BCSC InvestRight: Approval Phishing — https://www.investright.org/avoid-fraud/types-of-investment-scams/approval-phishing/

Krytyczna luka RCE w Marimo aktywnie wykorzystywana po ujawnieniu szczegółów

Wprowadzenie do problemu / definicja

W projekcie Marimo, otwartoźródłowym środowisku reaktywnych notatników Python, ujawniono krytyczną podatność typu pre-auth remote code execution. Oznacza to możliwość zdalnego wykonania poleceń bez wcześniejszego uwierzytelnienia, jeśli instancja została wystawiona w podatnej konfiguracji. Problem dotyczy szczególnie środowisk używanych do analiz danych, prac badawczych oraz budowy aplikacji i dashboardów opartych o Python.

W skrócie

Luka oznaczona jako CVE-2026-39987 dotyczy wersji Marimo 0.20.4 i starszych. Podatność wynika z niewłaściwej kontroli dostępu do endpointu WebSocket odpowiedzialnego za terminal. W praktyce atakujący może uzyskać interaktywną powłokę działającą z uprawnieniami procesu Marimo, a następnie wykonać rozpoznanie hosta, odczytać pliki konfiguracyjne oraz pozyskać sekrety, takie jak zmienne środowiskowe, poświadczenia chmurowe czy klucze SSH.

Podatność ma charakter pre-auth RCE.
Dotyczy środowisk Marimo wystawionych w podatnej konfiguracji.
Szczególnie narażone są instancje działające w trybie edycji i dostępne z sieci współdzielonej lub Internetu.
Po publicznym ujawnieniu szczegółów technicznych bardzo szybko pojawiły się próby wykorzystania luki.

Kontekst / historia

Marimo jest wykorzystywane przez data scientistów, inżynierów ML/AI, badaczy i programistów tworzących aplikacje analityczne. Takie środowiska często mają dostęp do wrażliwych danych, repozytoriów kodu, usług chmurowych oraz sekretów aplikacyjnych, co znacząco podnosi potencjalny wpływ skutecznego ataku.

Podatność została opublikowana 8 kwietnia 2026 roku jako krytyczny problem bezpieczeństwa związany z obejściem uwierzytelniania w terminalu WebSocket. Następnie przygotowano poprawkę w wydaniu 0.23.0. Ryzyko nie rozkłada się jednak równomiernie na wszystkie instalacje — najwyższe pozostaje tam, gdzie usługa działała w trybie edycji i była dostępna z zewnątrz, na przykład przez nasłuch na 0.0.0.0.

Analiza techniczna

Źródłem problemu jest endpoint /terminal/ws, który udostępnia interaktywny terminal przez WebSocket. W podatnych wersjach brakowało skutecznego mechanizmu autoryzacji połączeń przychodzących, co umożliwiało zestawienie sesji przez nieuwierzytelnionego klienta. W efekcie atakujący nie musiał przejmować sesji użytkownika ani omijać dodatkowych warstw logowania.

Po uzyskaniu dostępu do terminala napastnik działa z uprawnieniami procesu Marimo. To kluczowy aspekt techniczny, ponieważ skala skutków zależy od przywilejów samej usługi, dostępnych wolumenów, montowań, zmiennych środowiskowych oraz połączeń z usługami zewnętrznymi. W praktyce obserwowany łańcuch eksploatacji obejmuje potwierdzenie możliwości wykonywania poleceń, rozpoznanie systemu i przejście do pozyskiwania sekretów.

Szczególnie atrakcyjnym celem są pliki .env, które często zawierają tokeny API, dane dostępowe do baz danych, poświadczenia do usług chmurowych, klucze aplikacyjne oraz informacje używane przez pipeline’y CI/CD. Dodatkowym etapem może być sprawdzanie katalogów i plików związanych z SSH, co sugeruje próbę rozszerzenia dostępu poza pojedynczą instancję aplikacji.

Technicznie nie jest to więc wyłącznie lokalna wada komponentu terminalowego, ale podatność umożliwiająca bezpośredni pivot do warstwy sekretów i infrastruktury. Jeśli usługa została uruchomiona w kontenerze z nadmiernymi uprawnieniami, z zamontowanym katalogiem domowym użytkownika lub z szerokim dostępem sieciowym, skutki mogą szybko objąć kolejne systemy.

Konsekwencje / ryzyko

Najpoważniejszym ryzykiem jest kradzież poświadczeń i danych wrażliwych. W środowiskach data science i AI może to oznaczać przejęcie dostępu do zasobów obliczeniowych, magazynów danych, modeli, eksperymentów, rejestrów obrazów kontenerowych czy usług chmurowych. Nawet jednorazowe pozyskanie sekretów może umożliwić późniejszy, trudniejszy do wykrycia atak na inne elementy ekosystemu.

Drugą istotną konsekwencją jest możliwość wykonania dowolnych poleceń systemowych. Otwiera to drogę do odczytu lub modyfikacji danych, pobrania narzędzi post-exploitation, ruchu bocznego w sieci oraz zwiększenia wpływu operacyjnego. Szczególnie niebezpieczne są środowiska developerskie i badawcze, gdzie zwykle występuje słabsza segmentacja oraz większe nagromadzenie sekretów niż w klasycznych systemach produkcyjnych.

Poziom ryzyka należy ocenić jako wysoki także dlatego, że próby wykorzystania luki pojawiły się bardzo szybko po publicznym ujawnieniu szczegółów technicznych. To kolejny przykład, że okno czasowe między disclosure a aktywną eksploatacją jest zbyt krótkie, by polegać wyłącznie na standardowym cyklu aktualizacji.

Rekomendacje

Podstawowym działaniem powinno być niezwłoczne przejście do wersji Marimo 0.23.0 lub nowszej. Jeśli aktualizacja nie jest możliwa od razu, należy zablokować albo całkowicie wyłączyć dostęp do endpointu /terminal/ws oraz ograniczyć ekspozycję instancji na poziomie zapory sieciowej, reverse proxy i reguł dostępu.

Zweryfikować, które instancje Marimo działały w trybie edycji i nasłuchiwały na interfejsach dostępnych z zewnątrz.
Przeanalizować logi połączeń WebSocket pod kątem żądań do /terminal/ws.
Sprawdzić historię działań na hostach, w tym odczyty plików .env, katalogów domowych i lokalizacji związanych z SSH.
Zrotować wszystkie sekrety, które mogły znajdować się w zmiennych środowiskowych, plikach konfiguracyjnych lub katalogach roboczych.
Przeprowadzić przegląd uprawnień procesu aplikacji i ograniczyć je zgodnie z zasadą najmniejszych uprawnień.
Odseparować środowiska notebookowe od zasobów produkcyjnych oraz ograniczyć ich łączność wychodzącą i dostęp do metadanych chmurowych.
Upewnić się, że środowiska kontenerowe nie działają z nadmiernymi uprawnieniami roota, capability ani z szerokimi montowaniami wolumenów.

Podsumowanie

CVE-2026-39987 pokazuje, jak pozornie pomocnicza funkcja — terminal udostępniany przez WebSocket — może stać się bezpośrednim wektorem zdalnego wykonania kodu bez uwierzytelnienia. W praktyce zagrożenie nie kończy się na uruchomieniu komend na pojedynczym hoście, lecz obejmuje także możliwość szybkiego przejęcia sekretów i rozszerzenia kompromitacji na inne systemy. Dla zespołów bezpieczeństwa priorytetem powinny być aktualizacja, ograniczenie ekspozycji sieciowej, monitoring endpointu terminalowego oraz rotacja potencjalnie ujawnionych poświadczeń.

Źródła

Critical Marimo pre-auth RCE flaw now under active exploitation — https://www.bleepingcomputer.com/news/security/critical-marimo-pre-auth-rce-flaw-now-under-active-exploitation/
Pre-Auth Remote Code Execution via Terminal WebSocket Authentication Bypass — https://github.com/marimo-team/marimo/security/advisories
Release 0.23.0 · marimo-team/marimo — https://github.com/marimo-team/marimo/releases/tag/0.23.0

Anthropic prezentuje Mythos Preview: AI do wykrywania podatności i tworzenia exploitów otwiera nowy rozdział w cyberbezpieczeństwie

Wprowadzenie do problemu / definicja

Rozwój generatywnej sztucznej inteligencji coraz mocniej wpływa na praktykę cyberbezpieczeństwa. Modele językowe przestały pełnić wyłącznie rolę asystentów programistycznych i dziś są wykorzystywane do analizy kodu, identyfikacji błędów, wspierania triage podatności oraz przyspieszania prac zespołów bezpieczeństwa. Claude Mythos Preview, eksperymentalny model zaprezentowany przez Anthropic, przesuwa jednak granicę znacznie dalej: według deklaracji producenta system potrafi nie tylko wykrywać poważne luki, ale również przygotowywać działające łańcuchy exploitów.

To istotna zmiana w debacie o roli AI. Dotąd dominowało przekonanie, że sztuczna inteligencja będzie przede wszystkim wzmacniać obrońców. Tymczasem narzędzie zdolne do automatyzacji analizy podatności i opracowywania metod ich wykorzystania rodzi pytania o kontrolę dostępu, odpowiedzialność dostawców oraz ryzyko przeniesienia podobnych możliwości do ekosystemu przestępczego.

W skrócie

Anthropic zaprezentował Claude Mythos Preview jako model o bardzo wysokich kompetencjach w obszarze bezpieczeństwa aplikacji i analizie podatności.
Producent twierdzi, że system potrafi identyfikować krytyczne luki, odtwarzać warunki ich wykorzystania i generować exploit chainy.
Dostęp do rozwiązania jest ograniczony i powiązany z inicjatywą Project Glasswing, skierowaną do wybranych partnerów działających po stronie obrony.
Największe kontrowersje budzą ryzyko nadużyć, trudność niezależnej weryfikacji skuteczności oraz potencjalne skrócenie czasu między odkryciem luki a jej wykorzystaniem.

Kontekst / historia

W ostatnich latach AI stała się ważnym komponentem nowoczesnych narzędzi bezpieczeństwa. Algorytmy wspierają dziś analizę statyczną i dynamiczną kodu, detekcję anomalii, korelację zdarzeń, ocenę ryzyka oraz automatyzację reakcji na incydenty. Wraz z rozwojem zdolności reasoningowych dużych modeli językowych rozszerzył się również zakres ich zastosowań: od generowania poprawek po odtwarzanie możliwych ścieżek eksploatacji.

Anthropic przedstawia Mythos Preview jako efekt uboczny postępu w ogólnych zdolnościach modelu do kodowania i rozumowania, a nie jako projekt budowany wyłącznie do zastosowań ofensywnych. W praktyce firma argumentuje, że system, który potrafi lepiej wykrywać i naprawiać błędy, będzie także skuteczniejszy w ich wykorzystywaniu. W odpowiedzi na ten dylemat uruchomiono Project Glasswing — program mający umożliwić wykorzystanie takich możliwości przez podmioty odpowiedzialne za bezpieczeństwo krytycznego oprogramowania i infrastruktury.

Analiza techniczna

Najważniejszym elementem technicznym nie jest sama zdolność do „pisania exploitów”, lecz szeroki zakres zadań, które model ma realizować w jednym przepływie pracy. Według opisu producenta Claude Mythos Preview radzi sobie z analizą kodu źródłowego, identyfikacją błędów logicznych i pamięciowych, reprodukcją podatności, generowaniem proof-of-concept oraz proponowaniem remediacji.

Z perspektywy bezpieczeństwa szczególnie istotne są deklarowane kompetencje w bardziej złożonych scenariuszach. Chodzi o sytuacje obejmujące wiele połączonych podatności, obejścia mechanizmów izolacji, lokalną eskalację uprawnień, subtelne warunki wyścigu czy przygotowanie zdalnych exploitów prowadzących do wykonania kodu. Jeśli model rzeczywiście ogranicza potrzebę zaawansowanego promptingu, oznacza to obniżenie progu wejścia do prac, które wcześniej wymagały wysokospecjalistycznych kompetencji.

Jednocześnie rozwiązanie pozostaje zamkniętym preview. Dostęp jest kontrolowany, a testy mają odbywać się w środowiskach badawczych oraz w ramach programu partnerskiego. Taki model dystrybucji zmniejsza ryzyko natychmiastowego nadużycia, ale nie usuwa problemu metodologicznego. Bez szerokich, niezależnych testów trudno ocenić rzeczywistą skuteczność systemu, poziom false positives, powtarzalność wyników oraz odporność modelu na błędne wnioski.

Project Glasswing pełni tu rolę warstwy ochronnej między potencjałem ofensywnym a zastosowaniami defensywnymi. Partnerzy programu mają wykorzystywać model do skanowania własnych środowisk oraz komponentów open source. W założeniu ma to skrócić czas od wykrycia luki do wdrożenia poprawki i dać przewagę obrońcom, zanim podobne możliwości pojawią się szerzej na rynku.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją może być dalsze skrócenie okna między odkryciem podatności a jej aktywną eksploatacją. Jeżeli AI potrafi analizować złożone projekty, szybko lokalizować błąd i jednocześnie proponować gotową ścieżkę jego wykorzystania, organizacje z wolnym procesem patch managementu znajdą się pod jeszcze większą presją czasową.

Drugim ryzykiem jest demokratyzacja zaawansowanych technik ofensywnych. Nawet jeśli konkretny model pozostaje dziś za kontrolowaną bramką dostępu, sam poziom zadeklarowanych możliwości pokazuje kierunek rozwoju całego sektora. W perspektywie kolejnych miesięcy lub lat podobne funkcje mogą pojawić się w innych modelach komercyjnych, narzędziach prywatnych albo systemach rozwijanych poza restrykcyjnymi zasadami bezpieczeństwa.

Istotne jest też ryzyko związane z asymetrią informacji. W przypadku rozwiązań zamkniętych rynek musi opierać się głównie na komunikatach producenta i ograniczonej liczbie partnerów. To utrudnia chłodną ocenę realnych korzyści oraz ograniczeń narzędzia. Dla zespołów bezpieczeństwa kluczowe będzie więc nie tyle to, czy model brzmi przełomowo, ile czy faktycznie obniża czas wykrywania i usuwania podatności bez nadmiernego generowania fałszywych ustaleń.

Nie można również zakładać, że kontrola dostępu gwarantuje pełne bezpieczeństwo. Historia cyberbezpieczeństwa wielokrotnie pokazywała, że narzędzia opracowane do legalnych testów, administracji lub red teamingu z czasem były wykorzystywane również w nieautoryzowanych działaniach. W przypadku AI zagrożeniem jest nie tylko sam dostęp do modelu, ale także możliwość odtworzenia jego workflow i technik przez kolejne systemy.

Rekomendacje

Organizacje powinny przyjąć założenie, że AI będzie przyspieszać zarówno wykrywanie podatności, jak i proces ich uzbrajania w exploity. Oznacza to konieczność przejścia z modelu bezpieczeństwa opartego głównie na prewencji do podejścia łączącego prewencję, szybką detekcję, walidację i bardzo sprawne reagowanie.

Skrócić cykle łatania systemów krytycznych i usług wystawionych do Internetu.
Priorytetyzować luki umożliwiające łańcuchowanie, eskalację uprawnień i zdalne wykonanie kodu.
Rozwijać detekcję behawioralną oraz monitorowanie anomalii wskazujących na zautomatyzowaną eksploitację.
Wzmacniać segmentację sieci i architekturę zero trust.
Monitorować procesy, ruch lateralny i nietypowe wzorce wykonania kodu, zamiast polegać wyłącznie na sygnaturach.
Przyspieszyć ocenę ryzyka i aktualizacje komponentów open source.
Regularnie ćwiczyć scenariusze, w których exploit pojawia się niemal natychmiast po odkryciu podatności.

Dla zespołów AppSec i product security równie ważne będzie wdrażanie narzędzi do ciągłego skanowania kodu, reprodukcji błędów i walidacji poprawek. Jeśli AI przyspiesza ofensywę, obrona musi w analogicznym tempie przyspieszyć triage, remediację i niezależną ocenę wyników generowanych przez modele.

Podsumowanie

Claude Mythos Preview pokazuje, że granica między defensywnym i ofensywnym zastosowaniem AI w cyberbezpieczeństwie staje się coraz mniej wyraźna. Model, który pomaga znajdować i naprawiać krytyczne błędy, może jednocześnie obniżać koszt tworzenia skutecznych exploitów. Project Glasswing jest próbą skierowania tych możliwości najpierw do obrońców, ale nie rozwiązuje fundamentalnego problemu: podobne kompetencje prawdopodobnie będą się stopniowo upowszechniać.

Dla firm, instytucji publicznych i operatorów infrastruktury krytycznej wniosek jest jasny. Należy przygotować się na erę AI-assisted exploitation i modernizować procesy wykrywania, priorytetyzacji, łatania oraz reagowania szybciej niż dotychczas. W nowym krajobrazie zagrożeń przewagę zyskają nie ci, którzy najlepiej deklarują gotowość, ale ci, którzy potrafią skrócić czas od wykrycia ryzyka do skutecznej remediacji.