Archiwa: AI - Strona 135 z 183 - Security Bez Tabu

Luka projektowa w MCP zwiększa ryzyko ataków na łańcuch dostaw AI

Cybersecurity news

Wprowadzenie do problemu / definicja

Model Context Protocol, czyli MCP, to standard wykorzystywany do łączenia modeli i agentów AI z lokalnymi narzędziami, plikami, usługami oraz źródłami danych. Jego rosnąca popularność wynika z uproszczenia integracji, ale właśnie ta wygoda staje się dziś przedmiotem poważnych obaw bezpieczeństwa.

Badacze zwracają uwagę na architektoniczną słabość występującą w lokalnych wdrożeniach MCP opartych o STDIO. W określonych scenariuszach przekazanie polecenia uruchomienia procesu może doprowadzić do wykonania komendy systemowej nawet wtedy, gdy sam proces nie uruchomi się poprawnie. To tworzy warunki do cichego wykonania nieautoryzowanych działań bez jednoznacznego ostrzeżenia dla użytkownika.

W skrócie

Problem nie dotyczy wyłącznie pojedynczego produktu, lecz wzorca implementacyjnego obecnego w części ekosystemu MCP. Oznacza to, że ryzyko może rozprzestrzeniać się wraz z adapterami, serwerami i pochodnymi wdrożeniami tworzonymi przez różnych dostawców.

  • zagrożenie może prowadzić do wykonania poleceń na stacji roboczej dewelopera,
  • atak może pozostać ukryty pod pozorną awarią uruchomienia procesu,
  • skutkiem może być wyciek sekretów, danych firmowych i historii pracy z AI,
  • w najgorszym przypadku możliwe jest pełne przejęcie środowiska roboczego.

Kontekst / historia

MCP powstał jako sposób standaryzacji komunikacji pomiędzy agentami AI a zewnętrznymi zasobami. Dzięki temu firmy i zespoły developerskie mogą szybciej integrować modele z repozytoriami kodu, bazami danych, systemami plików czy narzędziami automatyzacji.

Wraz z szybkim wzrostem popularności tego podejścia pojawiło się wiele serwerów MCP oraz adapterów budowanych na podobnych założeniach. To właśnie ta powtarzalność staje się dziś kluczowym problemem: jeśli błąd wynika z samego modelu projektowego, może być dziedziczony przez wiele implementacji. W efekcie pojedyncza słabość zaczyna przypominać podatność klasy supply chain, obejmującą szeroki ekosystem narzędzi AI.

Analiza techniczna

Techniczny rdzeń problemu dotyczy sposobu uruchamiania procesów podrzędnych przez lokalny serwer MCP. Gdy implementacja dopuszcza niepoprawnie zweryfikowane polecenia, argumenty lub ścieżki, możliwe staje się wykonanie dodatkowych instrukcji systemowych. Nawet jeżeli docelowy proces kończy się błędem, część złośliwego łańcucha wykonania może zostać już zrealizowana.

To szczególnie niebezpieczne w środowiskach deweloperskich, gdzie agenci AI często mają dostęp do kodu źródłowego, zmiennych środowiskowych, kluczy API, tokenów sesyjnych oraz narzędzi CI/CD. Użytkownik może zobaczyć jedynie informację o nieudanym uruchomieniu usługi, nie mając świadomości, że po drodze doszło do uruchomienia polecenia systemowego.

W praktyce potencjalny wektor nadużycia może obejmować kilka scenariuszy:

  • podstawienie złośliwego polecenia do konfiguracji serwera MCP,
  • wykorzystanie adaptera lub konektora obdarzonego nadmiernym zaufaniem,
  • przejęcie etapu instalacji albo bootstrapu lokalnego komponentu,
  • nadużycie automatyzacji wspieranej przez narzędzia agentowe.

Największy problem polega na zacieraniu granicy między komponentem lokalnym a niezaufanym wejściem. W nowoczesnych środowiskach AI agent przetwarza dane pochodzące z wielu źródeł, a każde miejsce, w którym dochodzi do uruchamiania procesów lub przekazywania poleceń do systemu operacyjnego, powinno być traktowane jako obszar wysokiego ryzyka.

Konsekwencje / ryzyko

Z perspektywy bezpieczeństwa przedsiębiorstwa słabość ta może mieć znaczenie znacznie większe niż typowa lokalna podatność. Jeśli ten sam wzorzec występuje w wielu narzędziach, zagrożenie może objąć dużą liczbę zespołów i środowisk jednocześnie.

  • wykonanie dowolnego kodu na stacji roboczej,
  • instalacja złośliwego oprogramowania bez wyraźnych objawów kompromitacji,
  • kradzież tokenów, kluczy API i poświadczeń developerskich,
  • wyciek kodu źródłowego oraz danych wewnętrznych,
  • ruch boczny do kolejnych systemów firmowych,
  • kompromitacja pipeline’ów budowania i wdrażania aplikacji.

Szczególnie narażone są organizacje, które połączyły agentową AI z repozytoriami, systemami ticketowymi, narzędziami administracyjnymi oraz magazynami sekretów. W takich środowiskach przejęcie jednego hosta narzędziowego lub stacji dewelopera może stać się początkiem znacznie większego incydentu obejmującego dane, infrastrukturę i proces dostarczania oprogramowania.

Rekomendacje

Firmy korzystające z MCP powinny traktować lokalne serwery i adaptery jak komponenty krytyczne, a nie jedynie wygodne dodatki integracyjne. Ochrona powinna obejmować zarówno warstwę techniczną, jak i procedury operacyjne.

  • ograniczyć użycie lokalnych serwerów STDIO do ściśle kontrolowanych scenariuszy,
  • wymuszać listy dozwolonych binariów oraz argumentów uruchomieniowych,
  • blokować przekazywanie niezweryfikowanych komend do powłoki systemowej,
  • uruchamiać serwery MCP w kontenerach, sandboxach lub innych środowiskach izolowanych,
  • rozdzielać uprawnienia agentów od uprawnień użytkowników końcowych,
  • monitorować tworzenie procesów podrzędnych i anomalie w wywołaniach shell,
  • regularnie przeglądać konfiguracje konektorów pod kątem injection i command execution,
  • ograniczać dostęp agentów do sekretów i danych wrażliwych zgodnie z zasadą najmniejszych uprawnień,
  • weryfikować pochodzenie oraz bezpieczeństwo adapterów przed wdrożeniem,
  • włączyć komponenty AI do programu zarządzania ryzykiem łańcucha dostaw.

Dodatkowo zespoły bezpieczeństwa powinny przygotować reguły detekcyjne dla nietypowych procesów uruchamianych przez narzędzia AI oraz objąć integracje agentowe przeglądami kodu i testami red team. Tam, gdzie to możliwe, lepszym rozwiązaniem jest model jawnego opt-in dla niebezpiecznych operacji niż domyślne zaufanie do lokalnego wykonania poleceń.

Podsumowanie

Opisana słabość pokazuje, że w ekosystemie AI zagrożenia coraz częściej wynikają z decyzji architektonicznych, które są następnie kopiowane przez kolejne implementacje. W przypadku MCP problem dotyczy warstwy integracyjnej zaprojektowanej z myślą o wygodzie, ale potencjalnie otwierającej drogę do poważnych incydentów bezpieczeństwa.

Dla organizacji najważniejszy wniosek jest jednoznaczny: mechanizmy AI, które uruchamiają procesy lokalne, mają dostęp do sekretów lub pośredniczą w automatyzacji, muszą być objęte takimi samymi rygorami jak narzędzia administracyjne i elementy CI/CD. Bez tego wygoda integracji może szybko zamienić się w ryzyko dla całego łańcucha dostaw oprogramowania.

Źródła

  1. SecurityWeek – By Design Flaw in MCP Could Enable Widespread AI Supply Chain Attacks — https://www.securityweek.com/by-design-flaw-in-mcp-could-enable-widespread-ai-supply-chain-attacks/
  2. OX Security Research Report – MCP flaw findings — https://20204725.hs-sites.com/mcp-security-report
  3. Anthropic – Model Context Protocol documentation — https://modelcontextprotocol.io/

Microsoft wypłacił 2,3 mln dolarów za luki w chmurze i AI wykryte podczas Zero Day Quest

Cybersecurity news

Wprowadzenie do problemu / definicja

Programy bug bounty oraz wydarzenia typu live hacking odgrywają dziś istotną rolę w ekosystemie cyberbezpieczeństwa. Ich głównym celem jest identyfikacja podatności zanim zostaną wykorzystane przez cyberprzestępców, grupy APT lub innych nieautoryzowanych aktorów. Najnowsza edycja Zero Day Quest pokazuje, że szczególnie newralgiczne stają się obecnie usługi chmurowe, mechanizmy izolacji tenantów oraz komponenty oparte na sztucznej inteligencji.

Microsoft poinformował, że w ramach tegorocznej odsłony programu wypłacił badaczom bezpieczeństwa łącznie 2,3 mln dolarów. Skala zgłoszeń oraz ich charakter potwierdzają, że współczesna powierzchnia ataku coraz częściej obejmuje nie pojedyncze aplikacje, lecz złożone środowiska usługowe i architektury wielodzierżawne.

W skrócie

Tegoroczny Zero Day Quest przyniósł blisko 700 zgłoszeń od badaczy bezpieczeństwa. Według Microsoftu ponad 80 z nich dotyczyło wysoko wpływowych problemów związanych z chmurą i AI.

  • Łączna wartość wypłat wyniosła 2,3 mln dolarów.
  • Zidentyfikowane scenariusze obejmowały m.in. ekspozycję poświadczeń, łańcuchy SSRF oraz potencjalne ścieżki dostępu między tenantami.
  • Program wpisuje się w szerszą strategię Secure Future Initiative.
  • Największe ryzyko dotyczy dziś architektury usług online, tożsamości oraz granic izolacji w środowiskach współdzielonych.

Kontekst / historia

Zero Day Quest łączy klasyczny model bug bounty z kwalifikacją uczestników oraz kontrolowanym etapem live hacking. Takie podejście pozwala nie tylko zbierać zgłoszenia od szerokiej społeczności badaczy, ale też kierować ich uwagę na najbardziej krytyczne obszary, w tym usługi tożsamościowe, platformy chmurowe, mechanizmy separacji tenantów i systemy AI.

Poprzednia edycja programu, zorganizowana w 2025 roku, przyniosła ponad 600 zgłoszeń i wypłaty przekraczające 1,6 mln dolarów. W kolejnej odsłonie firma zwiększyła pulę potencjalnych nagród do 5 mln dolarów, co pokazuje rosnące znaczenie zewnętrznych badań bezpieczeństwa w procesie doskonalenia usług.

Istotnym tłem dla tych działań pozostaje Secure Future Initiative, czyli szerszy program wzmacniania bezpieczeństwa produktów i usług. Inicjatywa zakłada większy nacisk na podejście security by design, security by default oraz usprawnienie procesów reagowania na podatności już na poziomie projektowania i wdrożenia.

Analiza techniczna

Najważniejsze wnioski z tegorocznego Zero Day Quest nie dotyczą jednej spektakularnej luki, lecz całych klas problemów architektonicznych. To szczególnie ważne, ponieważ nowoczesne ataki coraz częściej polegają na łączeniu kilku pozornie mniej groźnych słabości w jeden skuteczny łańcuch naruszenia bezpieczeństwa.

Pierwszą istotną kategorią była ekspozycja poświadczeń. W środowiskach chmurowych i AI ujawnienie tokenów, sekretów, kluczy dostępowych lub tymczasowych danych uwierzytelniających może prowadzić do eskalacji uprawnień, przejęcia kontekstu usługi lub dalszego ruchu bocznego. Szczególnie niebezpieczne są sytuacje, w których wyciek poświadczeń łączy się z nadmiernymi uprawnieniami albo zbyt długim czasem życia tokenów.

Drugą kategorię stanowiły łańcuchy SSRF. Server-Side Request Forgery pozostaje jednym z najgroźniejszych błędów w usługach online, ponieważ pozwala wymuszać połączenia z zasobami wewnętrznymi, interfejsami administracyjnymi lub usługami metadanych niedostępnymi z poziomu publicznego Internetu. Jeśli SSRF zostanie połączone z błędami segmentacji lub niewłaściwą kontrolą tożsamości usługi, może prowadzić do znacznie poważniejszych skutków niż pojedynczy błąd wejścia.

Trzecią i najpoważniejszą grupą były potencjalne ścieżki dostępu między tenantami. W modelu multitenant szczelna izolacja danych, procesów i uprawnień stanowi podstawę bezpieczeństwa całej platformy. Każda możliwość obejścia tej granicy, nawet wymagająca połączenia kilku błędów, jest szczególnie krytyczna, ponieważ podważa zaufanie do modelu współdzielonej infrastruktury.

Warto podkreślić, że badania były prowadzone w kontrolowanych i autoryzowanych warunkach. Taki model umożliwia wykazanie realnego wpływu podatności bez ryzyka naruszenia danych klientów oraz bez ingerencji w rzeczywiste środowiska osób trzecich.

Konsekwencje / ryzyko

Dla organizacji korzystających z usług chmurowych najważniejszy wniosek jest prosty: największe zagrożenie coraz częściej wynika z kombinacji błędów, a nie z pojedynczej krytycznej podatności. Ekspozycja sekretu, niedoskonała kontrola uprawnień i możliwość wykonania żądania po stronie serwera mogą razem otworzyć drogę do przejęcia zasobów lub naruszenia izolacji tenantów.

  • nieautoryzowany dostęp do danych i obciążeń w chmurze,
  • eskalacja uprawnień przez błędy tożsamości i autoryzacji,
  • naruszenie granic tenantów w środowiskach współdzielonych,
  • obejście zabezpieczeń w usługach AI oraz warstwach integracyjnych,
  • trudności w wykrywaniu ataków wieloetapowych opartych na kilku słabych sygnałach telemetrycznych.

Z perspektywy dostawców usług skutki wykraczają poza sam incydent techniczny. Problemy z separacją tenantów lub ochroną poświadczeń niosą również ryzyko reputacyjne, regulacyjne i biznesowe, ponieważ mogą podważyć zaufanie klientów do całej platformy.

Rekomendacje

Organizacje powinny potraktować ustalenia z Zero Day Quest jako praktyczny sygnał do przeglądu własnych zabezpieczeń w obszarze chmury i AI. Najważniejsze jest ograniczenie skutków potencjalnych błędów architektonicznych zanim zostaną połączone w pełny łańcuch ataku.

  • Ograniczaj i regularnie rotuj poświadczenia, stosując zasadę minimalnych uprawnień oraz krótkiego czasu życia tokenów.
  • Wdrażaj mechanizmy wykrywania wycieków sekretów w repozytoriach, pipeline’ach CI/CD i konfiguracjach usług.
  • Redukuj powierzchnię ataku SSRF poprzez walidację adresów docelowych, kontrolę egress i blokowanie dostępu do adresów wewnętrznych oraz metadanych.
  • Regularnie testuj izolację tenantów, logikę autoryzacji, routing żądań i sposób propagacji tokenów między usługami.
  • Analizuj incydenty jako łańcuchy zdarzeń, korelując telemetrykę z obszarów IAM, aplikacji, sieci i usług AI.
  • Rozwijaj praktyki secure by design dla systemów AI, w tym kontrolę uprawnień narzędzi, separację danych i dodatkową autoryzację dla operacji wysokiego ryzyka.

Podsumowanie

Tegoroczny Zero Day Quest potwierdza, że ciężar współczesnego cyberbezpieczeństwa przesuwa się w stronę chmury, tożsamości, izolacji tenantów i usług AI. Wypłata 2,3 mln dolarów oraz niemal 700 zgłoszeń pokazują zarówno ogromne zaangażowanie społeczności badaczy, jak i złożoność obecnej powierzchni ataku.

Ponad 80 wysoko wpływowych ustaleń wskazuje, że najgroźniejsze scenariusze nie zawsze wynikają z pojedynczej luki typu RCE, lecz z możliwości połączenia błędów w logice usług, autoryzacji, sieci i zarządzaniu poświadczeniami. Dla firm oznacza to konieczność wzmacniania zabezpieczeń wokół sekretów, SSRF, segmentacji oraz architektury wielodzierżawnej, zwłaszcza tam, gdzie rośnie znaczenie komponentów AI.

Źródła

  1. https://www.microsoft.com/en-us/msrc/blog/2026/04/zero-day-quest-2026-over-2-million-awarded-vulnerability-research
  2. https://www.bleepingcomputer.com/news/microsoft/microsoft-pays-23-million-for-cloud-and-ai-flaws-at-zero-day-quest/
  3. https://www.microsoft.com/en-us/msrc/blog/2025/04/zero-day-quest-2025-1-6-million-awarded-for-vulnerability-research/
  4. https://www.microsoft.com/en-us/msrc/zero-day-quest-live-hacking-event-2025
  5. https://msrc.microsoft.com/blog/2025/08/zero-day-quest-join-the-largest-hacking-event-with-up-to-5-million-in-total-bounty-awards/

Claude Mythos Preview pokazuje ofensywny potencjał AI, ale bez pełnej autonomii ataku

Cybersecurity news

Wprowadzenie do problemu / definicja

Rozwój dużych modeli językowych coraz mocniej wpływa na krajobraz cyberbezpieczeństwa. Systemy AI nie są już wyłącznie narzędziem wspierającym analityków, lecz coraz częściej stają się platformą zdolną do wykrywania podatności, analizy błędów w kodzie oraz częściowej automatyzacji działań ofensywnych.

Claude Mythos Preview jest przykładem modelu, który według opublikowanych testów osiąga wysoki poziom skuteczności w zadaniach związanych z analizą bezpieczeństwa. Jednocześnie dostępne wyniki wskazują, że mimo wyraźnego postępu AI nadal nie gwarantuje niezawodnego, autonomicznego prowadzenia ataków przeciwko dobrze zabezpieczonym środowiskom korporacyjnym.

W skrócie

  • Claude Mythos Preview to wyspecjalizowany model AI ukierunkowany na analizę kodu, wykrywanie podatności i zadania agentowe.
  • W testach typu capture-the-flag model osiągnął bardzo dobre wyniki i poradził sobie z częścią złożonych scenariuszy ofensywnych.
  • W symulacji wieloetapowego przejęcia sieci korporacyjnej ukończył pełny łańcuch ataku w części prób.
  • Wyniki nie dowodzą jeszcze zdolności do niezawodnego atakowania realnych, dobrze bronionych organizacji.
  • Dla obrońców najważniejszym skutkiem jest skrócenie czasu potrzebnego napastnikom na analizę i wykorzystanie podatności.

Kontekst / historia

Na początku kwietnia 2026 roku Anthropic zaprezentował Claude Mythos Preview jako model o ponadprzeciętnej skuteczności w identyfikowaniu trudnych błędów bezpieczeństwa w systemach operacyjnych, aplikacjach webowych, bibliotekach kryptograficznych i innych komponentach infrastruktury. Ze względu na potencjał nadużyć dostęp do rozwiązania został objęty ograniczeniami i nie przewidziano jego szerokiego, publicznego udostępnienia.

Równolegle rozpoczęła się dyskusja o tym, czy najnowsza generacja modeli AI jest już w stanie samodzielnie realizować pełne operacje ofensywne. Ważnym punktem odniesienia stały się niezależne testy prowadzone przez AI Security Institute, które miały ocenić, czy model potrafi utrzymać kontekst, planować działania i kończyć złożone sekwencje ataku bez stałego wsparcia człowieka.

Debata zbiegła się także z ostrzeżeniami organizacji branżowych, według których AI może istotnie skracać czas od ujawnienia luki do pojawienia się praktycznych metod jej wykorzystania. To zmienia tempo działania zarówno po stronie atakujących, jak i zespołów odpowiedzialnych za obronę.

Analiza techniczna

Z technicznego punktu widzenia największą wartością Claude Mythos Preview jest połączenie rozumowania, analizy kodu oraz wykonywania sekwencyjnych działań typowych dla testera penetracyjnego lub operatora bezpieczeństwa. Model dobrze radzi sobie w zadaniach laboratoryjnych, gdzie musi rozpoznawać podatność, dobierać metodę eksploatacji i osiągać zdefiniowany cel.

Szczególnie istotne są wyniki symulacji wieloetapowego ataku na sieć korporacyjną. W scenariuszu obejmującym 32 kroki, od rekonesansu do pełnego przejęcia środowiska, model ukończył cały łańcuch ataku w 3 z 10 prób. Oznacza to, że AI potrafi już wykonywać złożone operacje wymagające planowania, korekty błędów i utrzymania kontekstu przez dłuższy czas.

Jednocześnie ograniczenia testu są kluczowe dla właściwej interpretacji wyników. Badane środowisko było uproszczone i pozbawione wielu elementów typowych dla produkcyjnej infrastruktury przedsiębiorstw. Nie działał aktywny zespół obrony, nie istniały realne konsekwencje wykrycia, a mechanizmy takie jak EDR, SIEM, dojrzała segmentacja sieci czy aktywny monitoring SOC nie odzwierciedlały poziomu spotykanego w dobrze chronionych organizacjach.

Najważniejszy wniosek techniczny jest więc dwutorowy. Z jednej strony model potrafi samodzielnie przejść dużą część kill chain w środowiskach słabiej zabezpieczonych lub kontrolowanych laboratoryjnie. Z drugiej strony nadal wykazuje ograniczoną niezawodność tam, gdzie musi omijać aktywne mechanizmy obronne, reagować na dynamiczne zmiany oraz prowadzić operację pod presją szybkiego wykrycia.

Dodatkowym elementem ryzyka jest zdolność przyspieszania tworzenia exploitów dla znanych, ale niezałatanych podatności. W praktyce może to oznaczać dalsze skracanie okna bezpieczeństwa pomiędzy publikacją informacji o luce a jej operacyjnym wykorzystaniem.

Konsekwencje / ryzyko

Największym zagrożeniem dla organizacji nie musi być dziś w pełni autonomiczny atak AI, lecz znaczące zwiększenie efektywności działań prowadzonych przez ludzi wspieranych przez model. Takie systemy mogą skracać czas potrzebny na rekonesans, analizę powierzchni ataku, identyfikację słabych punktów, przygotowanie exploitów, eskalację uprawnień i ruch boczny w infrastrukturze.

Najbardziej narażone pozostają środowiska obciążone długiem technologicznym, z opóźnionym patchowaniem, słabą segmentacją, nadmiernymi uprawnieniami i niewystarczającą widocznością telemetryczną. W takich organizacjach AI może działać jako mnożnik skuteczności dla cyberprzestępców, przyspieszając wykorzystanie nawet dobrze znanych podatności.

Zmianie ulega również ocena procesów operacyjnych. Klasyczne modele vulnerability management, oparte na tygodniowych lub miesięcznych cyklach, przestają odpowiadać rzeczywistości, jeśli przeciwnik może działać z prędkością maszyny. Organizacje muszą zakładać, że czas reakcji staje się jednym z najważniejszych parametrów odporności.

Rekomendacje

Organizacje powinny przyjąć, że zdolności ofensywne AI będą nadal szybko rosnąć, nawet jeśli obecne modele nie są jeszcze w pełni autonomicznymi operatorami ataku. Odpowiedzią powinno być jednoczesne przyspieszenie procesów bezpieczeństwa i ograniczanie skutków ewentualnego przełamania.

  • Skrócenie czasu wdrażania poprawek, szczególnie dla podatności aktywnie wykorzystywanych, posiadających publiczne PoC lub dotyczących krytycznych zależności.
  • Wzmocnienie kontroli dostępu poprzez zasadę najmniejszych uprawnień, separację kont uprzywilejowanych oraz odporne na phishing mechanizmy MFA.
  • Rozbudowa segmentacji sieci i ograniczanie możliwości lateral movement po uzyskaniu punktu wejścia.
  • Zapewnienie pełnej telemetrii obejmującej hosty, tożsamości, chmurę, ruch sieciowy i aktywność administracyjną.
  • Wykorzystanie AI po stronie defensywnej do priorytetyzacji podatności, triage alertów, analizy konfiguracji oraz wsparcia reagowania.
  • Regularne ćwiczenia red team i blue team zakładające przeciwnika korzystającego z automatyzacji wspieranej przez AI.

Podsumowanie

Claude Mythos Preview pokazuje, że ofensywne zastosowania AI w cyberbezpieczeństwie przestały być wyłącznie teoretycznym scenariuszem. Najnowsze wyniki wskazują na realny postęp w obszarze wykrywania podatności, analizy kodu i realizacji złożonych sekwencji ataku.

Nie oznacza to jednak, że modele AI są już zdolne do niezawodnego, autonomicznego przełamywania dobrze chronionych środowisk korporacyjnych. Kluczowa zmiana polega dziś na skróceniu czasu działania napastników i obniżeniu kosztu realizacji części etapów ataku. Przewagę zyskają te organizacje, które przyspieszą patchowanie, ograniczą ekspozycję, poprawią widoczność oraz wdrożą automatyzację obrony na porównywalnym poziomie szybkości.

Źródła

  1. https://www.helpnetsecurity.com/2026/04/14/claude-mythos-test-attack-capabilities-limits/
  2. https://www.anthropic.com/project/glasswing
  3. https://red.anthropic.com/2026/mythos-preview/
  4. https://labs.cloudsecurityalliance.org/mythos-ciso/
  5. https://cloudsecurityalliance.org/articles/sans-institute-cloud-security-alliance-un-prompted-and-owasp-genai-security-project-release-emergency-strategy-briefing-as-ai-driven-vulnerability-discovery-compresses-exploit-timelines-from-weeks-to-hours

Fałszywy instalator Claude rozprzestrzenia PlugX przez DLL sideloading

Cybersecurity news

Wprowadzenie do problemu / definicja

Cyberprzestępcy coraz częściej wykorzystują rozpoznawalność narzędzi opartych na sztucznej inteligencji jako przynętę w kampaniach malware. W opisywanym przypadku fałszywa strona podszywająca się pod usługę Claude dystrybuuje trojanizowany instalator dla systemu Windows, który poza uruchomieniem pozornie legalnej aplikacji wdraża również zdalnego trojana PlugX.

Kluczową techniką używaną w tym łańcuchu infekcji jest DLL sideloading, czyli uruchomienie złośliwej biblioteki DLL przez legalny, podpisany plik wykonywalny. Taki mechanizm pozwala atakującym ukryć właściwy kod malware w zaufanym kontekście procesu i utrudnić wykrycie incydentu.

W skrócie

Atak rozpoczyna się od socjotechniki i fałszywej oferty pobrania rzekomej „wersji Pro” Claude dla Windows. Ofiara otrzymuje archiwum ZIP zawierające instalator MSI, który tworzy wrażenie poprawnej instalacji programu, jednocześnie uruchamiając w tle wieloetapowy mechanizm infekcji.

  • użytkownik pobiera spreparowane archiwum ZIP z instalatorem MSI,
  • na pulpicie tworzony jest skrót uruchamiający skrypt VBScript,
  • skrypt startuje aplikację-wabik i równolegle inicjuje wdrożenie malware,
  • do folderu autostartu kopiowane są pliki wykorzystywane do persistence i uruchomienia PlugX.

Kontekst / historia

PlugX to dobrze znana rodzina zdalnych trojanów administracyjnych, od lat obserwowana w kampaniach szpiegowskich i ukierunkowanych operacjach intruzyjnych. Malware tego typu bywał historycznie łączony z działaniami cyberwywiadowczymi, ale z czasem jego warianty zaczęły pojawiać się także w szerszych kampaniach wykorzystujących podobne schematy infekcji.

Obecna kampania wpisuje się w wyraźny trend nadużywania popularnych marek i usług AI. Zamiast podszywania się pod aktualizacje przeglądarek, pakietów biurowych czy narzędzi systemowych, operatorzy wykorzystują zainteresowanie aplikacjami AI, licząc na to, że użytkownik szybciej zaufa stronie pobierania i zignoruje sygnały ostrzegawcze.

Istotne jest również to, że sam techniczny model wdrożenia nie jest całkowicie nowy. W przeszłości dokumentowano podobne scenariusze użycia legalnego komponentu, złośliwej biblioteki DLL i zaszyfrowanego ładunku, co sugeruje ponowne użycie sprawdzonego łańcucha z nową przynętą tematyczną.

Analiza techniczna

Łańcuch ataku rozpoczyna się od fałszywej strony, z której pobierane jest archiwum o nazwie zbliżonej do legalnego instalatora Claude dla Windows. Wewnątrz znajduje się pakiet MSI tworzący strukturę katalogów przypominającą prawdziwą instalację aplikacji. Jednym z potencjalnych wskaźników kompromitacji jest literówka w ścieżce instalacyjnej, sugerująca ręcznie przygotowany pakiet podszywający się pod legalne oprogramowanie.

Po instalacji na pulpicie pojawia się skrót, który nie uruchamia bezpośrednio głównego pliku programu, lecz skrypt VBScript. Po jego wykonaniu użytkownik widzi działającą aplikację, co obniża prawdopodobieństwo szybkiego wykrycia incydentu. W tle skrypt realizuje jednak kolejne etapy wdrożenia złośliwego oprogramowania.

Dropper kopiuje do folderu autostartu trzy kluczowe pliki:

  • NOVUpdate.exe,
  • avk.dll,
  • NOVUpdate.exe.dat.

Plik NOVUpdate.exe jest legalnie podpisanym komponentem aktualizacyjnym pochodzącym z oprogramowania bezpieczeństwa. W normalnych warunkach binarium ładowałoby bibliotekę DLL z oczekiwanej lokalizacji, jednak w tym przypadku atakujący podstawiają złośliwy plik avk.dll w tym samym katalogu. To właśnie prowadzi do wykonania kodu malware w zaufanym procesie i stanowi klasyczny przykład DLL sideloading.

Złośliwa biblioteka odpowiada następnie za odszyfrowanie i uruchomienie ładunku ukrytego w pliku NOVUpdate.exe.dat. Taki model — legalny plik EXE, trojanizowana biblioteka DLL i zaszyfrowany payload — jest charakterystyczny dla wielu wariantów PlugX i znacząco utrudnia zarówno analizę statyczną, jak i detekcję opartą wyłącznie na reputacji uruchamianego procesu.

Zaobserwowano również szybkie przejście do komunikacji sieciowej. Krótko po uruchomieniu komponentu wykonywane jest połączenie wychodzące do zewnętrznego adresu IP przez port 443, co wskazuje na próbę ustanowienia kanału command-and-control. Dodatkowo malware modyfikuje wybrane ustawienia rejestru związane z konfiguracją TCP/IP, co może przygotowywać środowisko do dalszych działań operatora.

Na uwagę zasługuje także prosty mechanizm anti-forensics. Skrypt VBScript tworzy plik wsadowy odpowiedzialny za opóźnione usunięcie części artefaktów, w tym samego skryptu i pliku pomocniczego. W efekcie po kilku sekundach główny dropper znika z dysku, pozostawiając ograniczoną liczbę łatwo dostępnych śladów.

Konsekwencje / ryzyko

Najważniejszym skutkiem udanej infekcji jest uzyskanie przez operatora zdalnego dostępu do stacji roboczej. PlugX jako RAT może wspierać wykonywanie poleceń, rekonesans środowiska, utrzymywanie trwałości, pobieranie dodatkowych ładunków oraz potencjalną kradzież danych i poświadczeń.

Z perspektywy organizacji szczególnie niebezpieczne jest to, że użytkownik otrzymuje działającą aplikację-wabik. Incydent może więc przez dłuższy czas pozostawać niezauważony, a wykorzystanie podpisanego komponentu jako hosta dla złośliwej DLL może dodatkowo utrudniać analizę i generować błędne poczucie bezpieczeństwa.

Ryzyko operacyjne rośnie również dlatego, że malware utrzymuje swoje elementy w folderze autostartu, zwiększając szansę na ponowne uruchomienie po restarcie systemu. Dla zespołów SOC i DFIR problemem jest ograniczona liczba artefaktów po stronie hosta, co wydłuża triage i zwiększa znaczenie telemetrii EDR, analizy ścieżek startowych oraz korelacji z ruchem sieciowym.

Rekomendacje

W odpowiedzi na tego typu kampanie organizacje powinny połączyć działania prewencyjne, kontrolne i detekcyjne. Szczególnie ważne jest ograniczenie możliwości instalowania oprogramowania spoza zatwierdzonych źródeł oraz monitorowanie nietypowych relacji procesów i ścieżek uruchomieniowych.

  • wdrożyć allowlisting aplikacji i ograniczyć pobieranie oprogramowania z nieoficjalnych źródeł,
  • blokować lub ściśle monitorować uruchamianie VBScript oraz innych interpreterów skryptowych tam, gdzie nie są wymagane biznesowo,
  • kontrolować foldery autostartu pod kątem nieoczekiwanych plików EXE, DLL i plików danych,
  • tworzyć reguły detekcyjne dla przypadków ładowania bibliotek DLL przez legalne aplikacje spoza standardowych katalogów producenta,
  • analizować nietypowe sekwencje procesów, zwłaszcza uruchomienie wscript.exe, a następnie start podpisanego binarium z niestandardowej lokalizacji,
  • monitorować połączenia wychodzące do nieznanych adresów IP przez port 443, szczególnie bezpośrednio po instalacji nowego oprogramowania,
  • regularnie szkolić użytkowników z rozpoznawania fałszywych stron pobierania i nieoficjalnych instalatorów narzędzi AI.

Na etapie reagowania warto sprawdzić obecność plików NOVUpdate.exe, avk.dll i NOVUpdate.exe.dat w folderze Startup oraz zweryfikować nietypowe ścieżki instalacji aplikacji Claude. W przypadku potwierdzenia wskaźników kompromitacji zalecane jest natychmiastowe odizolowanie hosta, analiza pamięci, przegląd logów proxy i firewalli oraz rotacja poświadczeń używanych na potencjalnie zainfekowanym systemie.

Podsumowanie

Opisana kampania pokazuje, że popularność narzędzi AI stała się skutecznym wektorem socjotechnicznym dla operatorów malware. Wystarczy wiarygodna strona pobierania, działająca aplikacja-wabik i sprawdzony mechanizm DLL sideloading, aby doprowadzić do wdrożenia zaawansowanego trojana zdalnego dostępu.

Z technicznego punktu widzenia przypadek jest istotny, ponieważ łączy kilka skutecznych elementów: legalnie podpisany komponent, złośliwą bibliotekę DLL, zaszyfrowany payload oraz samousuwający się dropper. Dla zespołów bezpieczeństwa to wyraźny sygnał, że proces instalacji popularnych aplikacji użytkowych — zwłaszcza tych związanych z AI — powinien być objęty równie ścisłym nadzorem jak klasyczne wektory phishingu i malware.

Źródła

  • Security Affairs – Fake Claude AI installer abuses DLL sideloading to deploy PlugX — https://securityaffairs.com/190754/malware/fake-claude-ai-installer-abuses-dll-sideloading-to-deploy-plugx.html
  • Malwarebytes – Fake Claude site installs malware that gives attackers access to your computer — https://www.malwarebytes.com/blog/scams/2026/04/fake-claude-site-installs-malware-that-gives-attackers-access-to-your-computer
  • MITRE ATT&CK – Hijack Execution Flow: DLL Side-Loading — https://attack.mitre.org/techniques/T1574/001/
  • LAB52 – PlugX Meeting Invitation via MSBuild and GDATA — https://lab52.io/blog/plugx-meeting-invitation-via-msbuild-and-gdata/
  • CISA – Intrusions Affecting Multiple Victims Across Multiple Sectors — https://www.cisa.gov/news-events/alerts/2017/04/27/intrusions-affecting-multiple-victims-across-multiple-sectors

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

Cybersecurity news

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

Cybersecurity news

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

Cybersecurity news

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

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