Archiwa: AI - Strona 46 z 101 - Security Bez Tabu

Krytyczna luka SQL Injection w LiteLLM aktywnie wykorzystywana. Zagrożone klucze API i sekrety środowiskowe

Wprowadzenie do problemu / definicja

LiteLLM to popularna warstwa pośrednia i brama API dla dużych modeli językowych, używana do ujednolicania dostępu do wielu dostawców AI. Najnowszy incydent dotyczy krytycznej podatności typu SQL Injection oznaczonej jako CVE-2026-42208, która może być wykorzystana bez uwierzytelnienia podczas weryfikacji klucza API w komponencie proxy.

Problem jest szczególnie poważny, ponieważ dotyczy elementu stojącego często w centrum architektury aplikacji AI. W praktyce taka brama może przechowywać klucze dostępu do usług zewnętrznych, sekrety środowiskowe, konfigurację oraz dane niezbędne do routingu ruchu do modeli.

W skrócie

Podatność CVE-2026-42208 wynika z nieprawidłowego osadzania danych wejściowych w zapytaniu SQL podczas sprawdzania klucza API. Atakujący może przesłać spreparowany nagłówek Authorization do endpointów API i uruchomić podatny kod bez wcześniejszego logowania.

Zagrożone są wersje LiteLLM od 1.81.16 do 1.83.6.
Poprawka została opublikowana w wersji 1.83.7.
Zaobserwowano aktywne próby wykorzystania krótko po publicznym ujawnieniu luki.
Możliwy jest odczyt danych z bazy oraz potencjalna ich modyfikacja.

Kontekst / historia

LiteLLM zyskał dużą popularność jako warstwa pośrednia upraszczająca integrację z wieloma modelami za pomocą jednego interfejsu. To sprawia, że rozwiązanie staje się atrakcyjnym celem dla cyberprzestępców, ponieważ kompromitacja jednej instancji może otworzyć drogę do wielu backendów jednocześnie.

W przypadku CVE-2026-42208 problem został opisany jako krytyczna luka w ścieżce weryfikacji klucza API. Poprawka pojawiła się 20 kwietnia 2026 roku, a pierwsze publicznie odnotowane próby wykorzystania wykryto już około 36 godzin później. Taka dynamika potwierdza, że infrastruktura AI jest obecnie monitorowana przez atakujących niemal natychmiast po publikacji informacji o nowych błędach.

Znaczenie incydentu zwiększa szerszy kontekst bezpieczeństwa projektu. W ostatnim czasie wokół LiteLLM pojawiały się również informacje o incydentach związanych z łańcuchem dostaw, co dodatkowo podnosi poziom ryzyka dla organizacji korzystających z tego narzędzia w środowiskach produkcyjnych.

Analiza techniczna

Źródłem podatności jest sposób budowania zapytania do bazy danych podczas weryfikacji klucza API przez proxy. Zamiast bezpiecznego użycia parametryzowanych zapytań, podatny kod miał osadzać dane wejściowe bezpośrednio w treści SQL, co otwiera drogę do klasycznego SQL Injection.

Szczególnie niebezpieczny jest fakt, że luka jest osiągalna bez uwierzytelnienia. Atakujący może wysłać odpowiednio przygotowany nagłówek Authorization: Bearer do jednego z endpointów obsługujących ruch do modeli i uruchomić podatny fragment kodu jeszcze przed poprawną walidacją dostępu.

Z analiz badaczy wynika, że obserwowane działania nie przypominały prostego, masowego skanowania. Kampanie miały charakter bardziej ukierunkowany i skupiały się na tabelach zawierających klucze API, dane konfiguracyjne, poświadczenia dostawców modeli oraz sekrety środowiskowe. W kolejnych etapach ataku zmieniano adresy IP i dopasowywano ładunki do rozpoznanego schematu bazy, co sugeruje iteracyjne doskonalenie exploitu.

Usunięcie błędu polegało na zastąpieniu konkatenacji tekstu parametryzowanymi zapytaniami SQL. Producent wskazał również obejście tymczasowe polegające na ustawieniu disable_error_logs: true w general_settings, jednak należy je traktować jedynie jako środek awaryjny, a nie pełne rozwiązanie problemu.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2026-42208 jest bardzo wysokie, ponieważ łączy zdalny wektor ataku, brak potrzeby logowania, niski poziom złożoności oraz możliwość uzyskania dostępu do danych o wysokiej wartości operacyjnej i finansowej.

Potencjalne skutki kompromitacji instancji LiteLLM obejmują:

wyciek kluczy API do usług AI i platform chmurowych,
przejęcie kluczy wirtualnych i kluczy nadrzędnych,
ujawnienie sekretów środowiskowych oraz konfiguracji aplikacyjnej,
możliwość modyfikacji danych w bazie proxy,
ryzyko dalszego ruchu bocznego do innych systemów zależnych od przechowywanych poświadczeń.

Dla organizacji wykorzystujących LiteLLM jako centralną bramę do wielu modeli skutki mogą być szczególnie dotkliwe. Jeden skuteczny atak może zapewnić przeciwnikowi dostęp do wielu usług jednocześnie, w tym środowisk produkcyjnych, kont rozliczeniowych oraz integracji chmurowych.

Rekomendacje

Najważniejszym działaniem jest natychmiastowa aktualizacja LiteLLM do wersji 1.83.7 lub nowszej. Organizacje korzystające z wersji od 1.81.16 do 1.83.6 powinny przyjąć, że instancje wystawione do internetu mogły już zostać objęte próbami wykorzystania.

zaktualizować wszystkie instancje do bezpiecznej wersji,
jeśli aktualizacja nie jest możliwa od razu, wdrożyć obejście z wyłączeniem wskazanej ścieżki logowania błędów,
obrócić wszystkie klucze przechowywane w bazie LiteLLM, w tym master keys, virtual keys i poświadczenia dostawców modeli,
przeanalizować logi HTTP pod kątem nietypowych nagłówków Authorization i podejrzanych żądań do endpointów LLM,
sprawdzić historię połączeń do bazy danych oraz anomalie związane z odczytem wrażliwych tabel,
ograniczyć ekspozycję endpointów LiteLLM do zaufanych sieci lub warstwy VPN,
wdrożyć reguły WAF i mechanizmy detekcji anomalii dla wzorców charakterystycznych dla SQL Injection,
przeprowadzić pełny przegląd tajemnic i integracji zależnych od LiteLLM.

W środowiskach o wysokiej krytyczności uzasadnione jest także wszczęcie standardowego postępowania incydentowego, obejmującego analizę artefaktów, weryfikację integralności systemu, przegląd zmian konfiguracyjnych oraz ocenę ewentualnego wtórnego wykorzystania przechowywanych poświadczeń.

Podsumowanie

CVE-2026-42208 pokazuje, że komponenty pośredniczące w ruchu do modeli AI stały się infrastrukturą wysokiej wartości dla atakujących. W przypadku LiteLLM pre-auth SQL Injection może prowadzić do ujawnienia najbardziej wrażliwych danych przechowywanych przez proxy, a szybkie pojawienie się prób wykorzystania potwierdza, że okno reakcji dla obrońców jest dziś bardzo krótkie.

Dla zespołów bezpieczeństwa oznacza to konieczność priorytetowego patchowania, rotacji sekretów oraz traktowania publicznie dostępnych, podatnych instancji jako potencjalnie naruszonych do czasu przeprowadzenia pełnej weryfikacji.

Źródła

LiteLLM: SQL injection in Proxy API key verification — https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc
BerriAI/litellm repository — https://github.com/BerriAI/litellm
Hackers are exploiting a critical LiteLLM pre-auth SQLi flaw — https://www.bleepingcomputer.com/news/security/hackers-are-exploiting-a-critical-litellm-pre-auth-sqli-flaw/
Popular LiteLLM PyPI package backdoored to steal credentials, auth tokens — https://www.bleepingcomputer.com/news/security/popular-litellm-pypi-package-compromised-in-teampcp-supply-chain-attack/
Sysdig blog: CVE-2026-42208 targeted SQL injection against LiteLLM — https://www.sysdig.com/blog/cve-2026-42208-targeted-sql-injection-against-litellms-authentication-path-discovered-36-hours-following-vulnerability-disclosure

Ataki prompt injection na AI rosną, ale wciąż są mało zaawansowane

Wprowadzenie do problemu / definicja

Prompt injection to technika manipulowania systemami sztucznej inteligencji poprzez dostarczanie im specjalnie przygotowanych instrukcji. Atak może mieć charakter bezpośredni, gdy użytkownik próbuje wpłynąć na model w trakcie rozmowy, lub pośredni, gdy złośliwe polecenia są ukryte w treściach przetwarzanych przez AI, takich jak strony internetowe, dokumenty czy wiadomości e-mail.

To właśnie pośredni prompt injection budzi dziś szczególne zainteresowanie środowiska bezpieczeństwa. Wraz z rozwojem agentów AI, które analizują treści z internetu i wykonują zadania w imieniu użytkownika, rośnie ryzyko, że model potraktuje spreparowaną zawartość jako wiążące polecenie.

W skrócie

Google odnotował wzrost liczby złośliwych przypadków pośredniego prompt injection w publicznej sieci. Między listopadem 2025 a lutym 2026 liczba wykryć w kategorii złośliwej wzrosła o 32%, co sugeruje rosnące zainteresowanie tym wektorem ataku.

Jednocześnie badacze podkreślają, że obecnie dominują próby mało zaawansowane technicznie. Wiele z nich przypomina eksperymenty, żarty lub proste próby manipulowania odpowiedzią modelu, choć pojawiają się też scenariusze związane z eksfiltracją danych i próbami działań destrukcyjnych.

Kontekst / historia

Prompt injection od dawna był postrzegany jako obiecujący wektor nadużyć wobec systemów generatywnej AI. W przeciwieństwie do klasycznych podatności, nie wymaga on błędu w kodzie, lecz wykorzystuje sposób, w jaki model interpretuje dane wejściowe i priorytetyzuje instrukcje.

Znaczenie tego zagrożenia wzrosło wraz z popularyzacją agentów AI zdolnych do przeglądania stron, streszczania treści, korzystania z narzędzi i podejmowania działań operacyjnych. W takich środowiskach złośliwa treść może wpływać nie tylko na odpowiedź tekstową, ale również na konkretne operacje wykonywane przez system.

Analiza Google opierała się na archiwalnych migawkach stron internetowych pochodzących z repozytorium Common Crawl. Celem było sprawdzenie, czy techniki znane z badań naukowych i demonstracji laboratoryjnych są już wykorzystywane w realnym, publicznym internecie na większą skalę.

Analiza techniczna

Pośredni prompt injection działa wtedy, gdy model lub agent AI przetwarza zewnętrzną treść zawierającą ukryte instrukcje. Jeśli zabezpieczenia nie zadziałają prawidłowo, system może nadać takim instrukcjom zbyt wysoki priorytet i zmienić swoje zachowanie w sposób niezgodny z polityką bezpieczeństwa lub intencją użytkownika.

W badaniu zastosowano podejście wieloetapowe. Najpierw wyszukiwano charakterystyczne wzorce tekstowe, takie jak polecenia nakazujące ignorowanie wcześniejszych instrukcji lub zwroty kierowane bezpośrednio do modeli AI. Następnie kandydackie przypadki klasyfikowano przy użyciu modelu Gemini, a ostateczna ocena była wspierana ręczną weryfikacją, aby ograniczyć liczbę fałszywych alarmów.

Wykryte przypadki obejmowały kilka kategorii. Część stanowiły nieszkodliwe żarty próbujące zmienić ton odpowiedzi asystenta. Inne miały charakter pozornie pomocnych wskazówek dla systemów streszczających zawartość stron. Odnotowano również wykorzystanie prompt injection w celach SEO, gdzie autorzy treści starali się skłonić modele do promowania określonych marek lub firm.

Osobną grupę stanowiły instrukcje mające zakłócać działanie agentów AI. W niektórych przypadkach próbowano odsyłać systemy do źródeł generujących niekończący się strumień tekstu, co mogło prowadzić do timeoutów, nadmiernego zużycia zasobów lub spadku jakości działania.

Z perspektywy bezpieczeństwa najistotniejsze były jednak przypadki złośliwe. Badacze wskazali próby skłaniania AI do gromadzenia informacji, takich jak adresy IP czy poświadczenia, a następnie przesyłania ich pod kontrolowany adres. Zaobserwowano też prompty próbujące nakłonić system do usuwania plików z urządzenia użytkownika. Mimo to Google ocenia, że nie są to jeszcze kampanie szczególnie wyrafinowane.

Konsekwencje / ryzyko

Obecny niski poziom zaawansowania nie powinien prowadzić do bagatelizowania zagrożenia. Sam wzrost liczby złośliwych prób pokazuje, że atakujący testują skuteczność tego podejścia i mogą rozwijać je wraz z dojrzewaniem ekosystemu agentów AI.

Najważniejsze ryzyka obejmują wyciek danych, manipulowanie odpowiedziami modeli, nadużycia w przepływach roboczych oraz zakłócanie pracy agentów przetwarzających treści zewnętrzne. Szczególnie narażone są środowiska, w których modele mają dostęp do poczty, dokumentów, repozytoriów kodu, systemów SaaS lub funkcji wykonywania działań o podwyższonym ryzyku.

W praktyce prompt injection może stać się odpowiednikiem złośliwego wejścia sterującego logiką operacyjną systemu. Jeśli agent ma możliwość korzystania z narzędzi i wykonywania akcji, nawet prosty prompt osadzony w zewnętrznej treści może doprowadzić do realnego incydentu bezpieczeństwa.

Warto również pamiętać, że analiza objęła głównie publiczną sieć i nie uwzględniała w pełni wszystkich trudniejszych do monitorowania kanałów, takich jak duże platformy społecznościowe. Rzeczywista skala zjawiska może więc być większa, niż wskazują obecne wyniki.

Rekomendacje

Organizacje wdrażające agentów AI powinny traktować prompt injection jako odrębną klasę zagrożeń aplikacyjnych. Kluczowe jest rozdzielenie instrukcji systemowych, danych użytkownika i treści pochodzących ze źródeł zewnętrznych, tak aby model nie ufał automatycznie zawartości pobranej z internetu, dokumentów czy poczty.

Równie istotne jest ograniczanie uprawnień agentów zgodnie z zasadą najmniejszych uprawnień. System analizujący strony lub streszczający dokumenty nie powinien samodzielnie wykonywać działań wysokiego ryzyka bez dodatkowej autoryzacji człowieka.

filtrowanie i oznaczanie niezaufanych treści wejściowych,
walidacja kontekstu przed wykonaniem akcji,
potwierdzenia człowieka dla operacji wrażliwych,
izolacja środowisk wykonawczych i sandboxing,
monitorowanie anomalii w zachowaniu agentów,
logowanie pełnego łańcucha decyzji modelu oraz użytych narzędzi.

Z perspektywy zespołów SOC i AppSec ważne jest także rozszerzenie modeli zagrożeń o scenariusze, w których nośnikiem poleceń dla modelu stają się treści HTML, e-maile, komentarze, pliki tekstowe lub dokumenty PDF. Dodatkowo warto regularnie prowadzić red teaming i testy odporności rozwiązań AI na manipulację treścią.

Podsumowanie

Obserwacje Google pokazują, że pośrednie ataki prompt injection w publicznym internecie stają się coraz częstsze, ale nadal pozostają w większości prymitywne i eksperymentalne. To jednak etap, którego nie należy lekceważyć, ponieważ wraz ze wzrostem autonomii agentów AI skutki nawet prostych ataków mogą być coraz poważniejsze.

Dla organizacji oznacza to konieczność projektowania systemów AI w modelu zero trust wobec danych wejściowych. Ochrona przed prompt injection powinna obejmować segmentację uprawnień, kontrolę narzędzi, nadzór człowieka nad operacjami wysokiego ryzyka oraz ciągłe testowanie odporności modeli i agentów na manipulację.

Źródła

SecurityWeek — Malicious AI Prompt Injection Attacks Increasing, but Sophistication Still Low: Google — https://www.securityweek.com/malicious-ai-prompt-injection-attacks-increasing-but-sophistication-still-low-google/
Google Online Security Blog — AI threats in the wild: The current state of prompt injections on the web — https://security.googleblog.com/2026/04/ai-threats-in-wild-current-state-of.html

Fałszywe CAPTCHA i nadużycia Keitaro TDS napędzają globalne oszustwa SMS oraz kampanie kryptowalutowe

Wprowadzenie do problemu / definicja

Cyberprzestępcy coraz częściej łączą socjotechnikę z infrastrukturą reklamową oraz mechanizmami przekierowań, aby monetyzować ruch ofiar na dużą skalę. Najnowsze analizy pokazują dwa istotne zjawiska: fałszywe strony CAPTCHA, które nakłaniają użytkowników do wysyłania kosztownych wiadomości SMS, oraz nadużywanie platformy Keitaro TDS do kierowania ofiar do oszustw inwestycyjnych, kampanii kryptowalutowych i innych szkodliwych treści.

To wyraźny przykład ewolucji współczesnej cyberprzestępczości, w której kluczową rolę odgrywa już nie tylko sam złośliwy kod, ale również precyzyjne zarządzanie ruchem, profilowanie użytkowników i ukrywanie właściwego celu ataku.

W skrócie

Badacze opisali kampanię typu International Revenue Share Fraud, w której ofiara trafia na fałszywą stronę CAPTCHA i otrzymuje polecenie wysłania SMS-a w celu rzekomego potwierdzenia, że jest człowiekiem. W praktyce mechanizm może prowadzić do wygenerowania wielu wiadomości do numerów premium lub numerów międzynarodowych, co skutkuje dodatkowymi kosztami dla użytkownika i zyskiem dla operatorów oszustwa.

Równolegle ujawniono szeroką skalę nadużyć platformy Keitaro TDS. Narzędzie to było wykorzystywane do warunkowego przekierowywania ofiar do phishingu, fałszywych inwestycji opartych rzekomo na AI oraz kampanii typu wallet drainer wymierzonych w użytkowników kryptowalut. W analizowanym okresie zidentyfikowano ponad 120 odrębnych kampanii wykorzystujących taką infrastrukturę.

Kontekst / historia

Schemat IRSF od lat jest znany w branży telekomunikacyjnej. Tradycyjnie polegał na sztucznym generowaniu połączeń lub wiadomości do numerów, z których część opłat wracała do organizatorów nadużycia w modelu revenue sharing. Obecnie technika ta przeszła istotną transformację i coraz częściej wykorzystuje przeglądarkę internetową, urządzenia mobilne oraz interfejsy systemowe do wywoływania płatnych działań po stronie użytkownika.

W analizowanej kampanii aktywność miała trwać co najmniej od czerwca 2020 roku. Badacze powiązali ją z numerami telefonicznymi z wielu państw, w tym z regionów charakteryzujących się wysokimi opłatami za zakańczanie ruchu lub słabszym nadzorem regulacyjnym. Atak wymierzony był jednocześnie w użytkowników końcowych oraz operatorów telekomunikacyjnych.

Drugi istotny wątek dotyczy platform typu Traffic Distribution System. Takie rozwiązania powstały z myślą o legalnym marketingu, analityce kampanii i segmentacji ruchu. Jednak ich funkcje, takie jak filtrowanie użytkowników, reguły warunkowe i cloaking, są wyjątkowo atrakcyjne również dla cyberprzestępców, ponieważ pozwalają skutecznie ukrywać właściwy cel kampanii i utrudniać jej analizę.

Analiza techniczna

Atak z użyciem fałszywego CAPTCHA zwykle rozpoczyna się od przekierowania użytkownika do spreparowanej strony za pośrednictwem komercyjnego lub nadużywanego systemu TDS. Ofiara widzi komunikat sugerujący konieczność wykonania prostego testu weryfikacyjnego, ale zamiast standardowego pola wyboru otrzymuje instrukcję wysłania wiadomości SMS.

Kluczowym elementem oszustwa jest automatyzacja. Strona może otwierać aplikację SMS na urządzeniu mobilnym z predefiniowanym numerem i treścią wiadomości. Proces bywa powtarzany wieloetapowo, dzięki czemu pojedyncza sesja może skutkować nie jedną, lecz wieloma wiadomościami wysłanymi do różnych numerów. Według ustaleń badaczy cztery etapy fałszywej weryfikacji mogły prowadzić do wysłania nawet kilkudziesięciu SMS-ów do kilkunastu unikalnych numerów.

Kampania wykorzystywała również ciasteczka do śledzenia postępu użytkownika i sterowania kolejnymi krokami scenariusza. Parametry zapisane po stronie przeglądarki decydowały o tym, czy ofiara pozostanie w danym łańcuchu weryfikacyjnym, czy zostanie przekierowana do innej wersji strony. To znacząco utrudnia analizę incydentu, ponieważ przebieg zdarzeń może się różnić pomiędzy użytkownikami.

Dodatkowym mechanizmem była manipulacja historią przeglądarki, określana jako back button hijacking. Kod JavaScript modyfikował zachowanie nawigacji tak, aby próba opuszczenia strony przyciskiem wstecz prowadziła ponownie do fałszywego CAPTCHA. W efekcie ofiara mogła utknąć w pętli, która zwiększała prawdopodobieństwo wykonania sugerowanych działań.

W przypadku Keitaro TDS problem nie wynika z jednej konkretnej podatności, lecz z funkcjonalności samej platformy. System umożliwia tworzenie warunkowych reguł przekierowań, śledzenie parametrów kampanii, filtrowanie użytkowników oraz ukrywanie właściwej treści przed moderatorami reklam, analitykami i systemami bezpieczeństwa. W rękach przestępców taki zestaw cech staje się wydajnym narzędziem dystrybucji oszustw na dużą skalę.

Z analiz wynika, że od października 2025 do stycznia 2026 zidentyfikowano ponad 120 kampanii nadużywających Keitaro do dostarczania złośliwych lub oszukańczych treści. Telemetria DNS obejmowała setki tysięcy zapytań związanych z tysiącami domen. Szczególnie aktywne były kampanie promujące oszustwa kryptowalutowe, w tym fałszywe airdropy, giveawaye i strony wyłudzające dostęp do portfeli.

Konsekwencje / ryzyko

Najbardziej bezpośrednią konsekwencją kampanii IRSF są nieautoryzowane koszty po stronie użytkownika. Problem jest szczególnie groźny, ponieważ opłaty za międzynarodowe SMS-y mogą pojawić się z opóźnieniem, a sama interakcja z fałszywą stroną bywa postrzegana jako zwykła procedura weryfikacyjna.

Ryzyko obejmuje również operatorów telekomunikacyjnych uczestniczących w modelach rozliczeń międzyoperatorskich. W przypadku reklamacji klientów, sporów rozliczeniowych i nadużyć część strat może zostać przeniesiona na podmioty infrastrukturalne. Oznacza to, że kampania obciąża jednocześnie użytkownika końcowego i cały ekosystem telekomunikacyjny.

Nadużycia TDS generują z kolei szersze ryzyko dla cyberbezpieczeństwa. Tego rodzaju infrastruktura zwiększa skuteczność phishingu, oszustw inwestycyjnych i kampanii kryptowalutowych, ponieważ pozwala dynamicznie dobierać ofiarę na podstawie lokalizacji, urządzenia, źródła ruchu czy pory dnia. To utrudnia wykrywanie przez klasyczne filtry URL i systemy reputacyjne, które często rejestrują jedynie stronę pośrednią.

Z perspektywy organizacji oznacza to rosnące ryzyko obejścia zabezpieczeń na styku sieci, reklamy i ruchu webowego. Dla użytkowników indywidualnych zagrożenie wykracza poza same rachunki telefoniczne i może obejmować utratę środków w portfelach kryptowalutowych, kradzież danych, a nawet dalsze infekcje malware.

Rekomendacje

Organizacje powinny traktować strony wymuszające interakcję z aplikacją SMS, komunikatami systemowymi lub nietypowymi mechanizmami CAPTCHA jako sygnał wysokiego ryzyka. W praktyce warto wdrożyć monitorowanie ruchu webowego pod kątem wieloetapowych przekierowań, domen jednorazowych i anomalii związanych z wykorzystaniem TDS.

Monitorować nietypowe łańcuchy przekierowań HTTP.
Analizować szybkie rotacje domen i subdomen.
Wykrywać domeny powiązane z cloakingiem.
Korelować zdarzenia DNS z ruchem do nowo zarejestrowanych domen.
Śledzić wzorce kampanii prowadzonych przez reklamy społecznościowe.

W środowiskach mobilnych warto ograniczać możliwość inicjowania kosztownych działań przez przeglądarkę oraz prowadzić regularną edukację użytkowników. Prawidłowe CAPTCHA nie wymagają wysyłania wiadomości SMS ani wykonywania płatnych czynności, dlatego każda taka prośba powinna być traktowana jako potencjalne oszustwo.

Operatorzy i dostawcy usług telekomunikacyjnych powinni rozwijać mechanizmy wykrywania anomalii w ruchu SMS, zwłaszcza krótkotrwałych wzrostów wiadomości kierowanych do zagranicznych numerów o podwyższonym koszcie. Ważne są także procedury szybkiego blokowania zakresów numeracyjnych powiązanych z nadużyciami revenue share fraud.

W kontekście kampanii kryptowalutowych kluczowe pozostaje również:

blokowanie dostępu do znanych domen wallet drainer,
ostrzeganie użytkowników przed fałszywymi airdropami i giveawayami,
analiza reklam i stron docelowych pod kątem cloakingu,
separacja przeglądania treści reklamowych od środowisk uprzywilejowanych,
wzmacnianie ochrony DNS i filtracji reputacyjnej.

Podsumowanie

Opisane kampanie pokazują, że współczesna cyberprzestępczość skutecznie łączy oszustwa telekomunikacyjne, socjotechnikę i narzędzia marketingowo-reklamowe. Fałszywe CAPTCHA wykorzystywane do IRSF dowodzą, że nawet pozornie błaha interakcja webowa może prowadzić do realnych strat finansowych.

Z kolei nadużycia Keitaro TDS pokazują, jak legalne technologie mogą zostać przekształcone w warstwę dystrybucji i ukrywania kampanii phishingowych, inwestycyjnych oraz kryptowalutowych. Dla zespołów bezpieczeństwa najważniejszy wniosek jest jasny: sama analiza payloadów już nie wystarcza, a coraz większe znaczenie mają infrastruktura przekierowań, zależności DNS, mechanizmy cloakingu i zachowanie przeglądarki po stronie ofiary.

Źródła

The Hacker News — https://thehackernews.com/2026/04/fake-captcha-irsf-scam-and-120-keitaro.html
Inside Keitaro Abuse Part 1: Cloaking AI-Enhanced Scams — https://www.infoblox.com/blog/threat-intelligence/inside-keitaro-abuse-a-persistent-stream-of-ai-driven-investment-scams/
Inside Keitaro Abuse Part 2: One Platform, Many Threats — https://www.infoblox.com/blog/threat-intelligence/no-reach-no-risk-the-keitaro-abuse-in-modern-cybercrime-distribution/
Inside Keitaro Abuse Part 3: Trends, Cracked Keys & Response — https://www.infoblox.com/blog/threat-intelligence/patterns-pirates-and-provider-action-what-we-learned-working-with-keitaro/
International Revenue Share Fraud — https://www.ndss-symposium.org/ndss-paper/international-revenue-share-fraud/

Ataki deepfake voice wyprzedzają obronę organizacji

Wprowadzenie do problemu / definicja

Ataki typu deepfake voice to zaawansowana forma socjotechniki, w której przestępcy wykorzystują generatywną sztuczną inteligencję do klonowania głosu i tworzenia wiarygodnych rozmów telefonicznych lub komunikatów audio. W praktyce oznacza to podszywanie się pod członków zarządu, dyrektorów finansowych, administratorów IT lub inne osoby obdarzone wysokim poziomem zaufania, aby skłonić pracowników do wykonania określonych działań.

Najczęściej celem takich operacji są przelewy, zmiany danych płatniczych, reset haseł, modyfikacja uprawnień albo uruchomienie niestandardowych procedur operacyjnych. Problem polega na tym, że wiele tradycyjnych mechanizmów bezpieczeństwa zostało zaprojektowanych z myślą o poczcie elektronicznej, złośliwym oprogramowaniu i ruchu sieciowym, a nie o kanałach głosowych czy wideokonferencjach.

W skrócie

Deepfake voice staje się jednym z najszybciej rosnących zagrożeń w obszarze oszustw biznesowych. Do stworzenia przekonującej repliki głosu wystarcza dziś bardzo krótka próbka audio, a dostępne narzędzia są coraz tańsze i prostsze w użyciu.

Najczęściej atakowane są działy finansowe, HR oraz help deski IT.
Atak opiera się na autorytecie, presji czasu i pozornie wiarygodnym kontekście rozmowy.
Klasyczne zabezpieczenia techniczne często nie wykrywają nadużyć realizowanych przez kanał głosowy.
Najskuteczniejszą odpowiedzią są procedury weryfikacyjne, szkolenia i wielokanałowe potwierdzanie krytycznych żądań.

Kontekst / historia

W ostatnich latach oszustwa oparte na podszywaniu się pod kadrę kierowniczą przeszły istotną ewolucję. Klasyczne scenariusze Business Email Compromise coraz częściej ustępują miejsca bardziej zaawansowanym kampaniom, w których wykorzystywany jest syntetyczny dźwięk, a niekiedy również obraz.

Głośne incydenty pokazały, że przestępcy potrafią wykorzystać fałszywe rozmowy telefoniczne lub wideokonferencje do nakłonienia pracowników do autoryzacji dużych przelewów czy zmiany krytycznych danych. Co istotne, przeprowadzenie takiego ataku nie wymaga już rozbudowanego zaplecza technicznego ani wielomiesięcznego przygotowania materiału treningowego.

To zmienia profil zagrożenia. Jeszcze niedawno organizacje skupiały się głównie na phishingu, złośliwych załącznikach i przejęciach kont. Obecnie realnym wektorem ataku staje się także rozmowa telefoniczna, komunikator lub spotkanie online, podczas którego ofiara słyszy głos pozornie należący do przełożonego.

Analiza techniczna

Techniczny fundament deepfake voice opiera się na modelach AI zdolnych do syntezy mowy na podstawie bardzo krótkiej próbki referencyjnej. Materiał źródłowy może pochodzić z wiadomości głosowych, publicznych wystąpień, webinarów, podcastów, mediów społecznościowych lub nagrań ze spotkań firmowych.

Po stworzeniu modelu głosu atakujący może prowadzić rozmowę niemal w czasie rzeczywistym, zachowując intonację, tempo wypowiedzi i charakterystyczne cechy mowy danej osoby. Sama technologia syntezy to jednak tylko jeden element całego łańcucha ataku.

Skuteczna operacja zwykle poprzedzana jest dokładnym rozpoznaniem organizacji. Przestępcy analizują strukturę firmy, identyfikują osoby odpowiedzialne za zatwierdzanie płatności, poznają procedury akceptacji i wybierają moment, w którym presja operacyjna jest najwyższa. Następnie wykorzystują autorytet przełożonego oraz pilny ton komunikacji, aby skłonić ofiarę do działania bez dodatkowej weryfikacji.

Kluczowe znaczenie ma fakt, że klasyczny stos bezpieczeństwa zazwyczaj nie analizuje rozmów głosowych tak, jak analizuje wiadomości e-mail, pliki czy ruch HTTP. Firewall, EDR, bramka pocztowa czy sandbox nie zatrzymają decyzji podjętej przez pracownika po wiarygodnie brzmiącym połączeniu. Z tego powodu deepfake voice należy postrzegać nie tylko jako problem cyberbezpieczeństwa, lecz także jako zagrożenie z obszaru fraud prevention i kontroli procesowej.

Coraz częściej obserwuje się również rozszerzanie tej techniki na inne scenariusze. Oprócz oszustw finansowych rośnie ryzyko podszywania się pod pracowników technicznych w celu wymuszenia resetu poświadczeń, obejścia mechanizmów MFA przez help desk, zmiany danych payrollowych czy wejścia do procesów rekrutacyjnych z wykorzystaniem syntetycznych person.

Konsekwencje / ryzyko

Najbardziej bezpośrednią konsekwencją są straty finansowe wynikające z nieautoryzowanych przelewów i oszustw płatniczych. Jednak skutki takich incydentów mogą być znacznie szersze i obejmować także wyciek danych, nieuprawnione zmiany w systemach kadrowych, przejęcie kont uprzywilejowanych oraz naruszenie obowiązków regulacyjnych.

Szczególnie narażone pozostają zespoły finansowe, księgowość, HR oraz wsparcie IT. Łączy je dostęp do procesów o wysokiej wrażliwości biznesowej i codzienna obsługa żądań, które często mają charakter pilny. Jeśli organizacja nie posiada formalnego wymogu dodatkowej weryfikacji, pojedyncza rozmowa może uruchomić ciąg działań trudnych do cofnięcia.

Ryzyko wzrasta również dlatego, że ataki deepfake voice są relatywnie tanie, skalowalne i trudne do wykrycia na poziomie technicznym. Im łatwiej zdobyć próbki głosu kadry kierowniczej z internetu, tym niższy staje się próg wejścia dla cyberprzestępców. W efekcie nawet firmy dysponujące dojrzałą architekturą bezpieczeństwa mogą pozostać podatne, jeśli ich procedury nadal opierają się na zaufaniu do samego brzmienia głosu.

Rekomendacje

Podstawą obrony powinno być wdrożenie twardych procedur weryfikacyjnych dla wszystkich żądań wysokiego ryzyka. Każda dyspozycja dotycząca przelewu, zmiany rachunku bankowego, modyfikacji payrollu, nadania uprawnień lub resetu dostępu powinna wymagać potwierdzenia niezależnym kanałem komunikacji.

Najlepszą praktyką jest oddzwanianie na wcześniej zapisany numer lub potwierdzanie dyspozycji w zatwierdzonym systemie workflow. Sama rozmowa telefoniczna, nawet jeśli brzmi wiarygodnie, nie powinna być traktowana jako wystarczający dowód autentyczności.

Wprowadzenie obowiązkowego potwierdzenia poza kanałem inicjującym żądanie.
Zastosowanie zasady dwóch par oczu dla płatności i zmian danych beneficjenta.
Zakaz realizacji pilnych dyspozycji finansowych wyłącznie na podstawie telefonu lub komunikatora.
Ustanowienie stałych numerów kontaktowych i zdefiniowanych ścieżek eskalacji.
Wdrożenie fraz lub haseł weryfikacyjnych dla procesów wysokiego ryzyka.

Równie ważne są szkolenia praktyczne. Jednorazowy moduł compliance nie wystarcza, ponieważ deepfake voice oddziałuje przede wszystkim na emocje, autorytet i presję czasu. Organizacje powinny regularnie prowadzić ćwiczenia symulacyjne obejmujące połączenia głosowe, SMS-y, wiadomości e-mail oraz scenariusze wideokonferencyjne.

Z perspektywy architektury bezpieczeństwa warto powiązać działania awareness z mapowaniem kontroli do procesów biznesowych. Należy zidentyfikować wszystkie punkty, w których pojedyncza osoba może wykonać krytyczną akcję po rozmowie głosowej, a następnie ograniczyć tę możliwość poprzez segmentację uprawnień, formalne workflow, logowanie działań administracyjnych i monitorowanie anomalii.

Dobrą praktyką pozostaje również ograniczenie nadmiernej ekspozycji próbek głosu i materiałów wideo kadry zarządzającej. Nie rozwiązuje to problemu całkowicie, ale może utrudnić przygotowanie wiarygodnego modelu głosu. Kluczowe jest jednak przede wszystkim takie projektowanie procesów, aby sam głos nie był traktowany jako czynnik uwierzytelniający.

Podsumowanie

Deepfake voice zmienia socjotechnikę w zagrożenie bardziej realistyczne, tańsze i trudniejsze do zatrzymania niż klasyczny phishing. Atakujący nie muszą już przejmować skrzynek pocztowych ani omijać zaawansowanych zabezpieczeń technicznych, jeśli są w stanie skłonić pracownika do działania przy użyciu syntetycznego głosu osoby z autorytetem.

Najważniejszy wniosek dla organizacji jest praktyczny: każde pilne żądanie przekazane głosem powinno być traktowane jako potencjalna próba oszustwa. Firmy, które wdrożą wielokanałową weryfikację, rozdział obowiązków i regularne symulacje ataków, znacząco ograniczą ryzyko skutecznego fraudu w erze generatywnej AI.

Źródła

BleepingComputer – Deepfake Voice Attacks are Outpacing Defenses: What Security Leaders Should Know
https://www.bleepingcomputer.com/news/security/deepfake-voice-attacks-are-outpacing-defenses-what-security-leaders-should-know/

Phishing wspierany przez AI znów liderem wektorów początkowego dostępu w 2026 roku

Wprowadzenie do problemu / definicja

Phishing wspierany przez sztuczną inteligencję stał się jednym z najważniejszych zjawisk we współczesnym krajobrazie zagrożeń. Atakujący wykorzystują narzędzia AI do szybkiego tworzenia przekonujących wiadomości, personalizacji treści, generowania fałszywych stron logowania oraz przygotowywania kampanii w wielu językach. W rezultacie tradycyjne sygnały ostrzegawcze, takie jak błędy językowe czy nienaturalna składnia, przestają być wiarygodnym wskaźnikiem oszustwa.

W skrócie

W pierwszym kwartale 2026 roku phishing ponownie znalazł się na pierwszym miejscu wśród najczęściej obserwowanych wektorów początkowego dostępu w analizowanych incydentach. Ponad jedna trzecia przypadków, w których udało się ustalić sposób wejścia napastnika, rozpoczęła się od skutecznego phishingu. Jednocześnie rośnie znaczenie przejęcia tożsamości, nadużywania legalnych kont oraz obchodzenia mechanizmów MFA.

Phishing wrócił na pozycję lidera wśród wektorów initial access.
AI zwiększa jakość, skalę i wiarygodność kampanii.
Ataki częściej koncentrują się na przejęciu tożsamości niż na klasycznej eksploatacji podatności.
Organizacje muszą wzmacniać ochronę tożsamości, detekcję behawioralną i widoczność w środowisku.

Kontekst / historia

W poprzednich kwartałach znaczącą rolę odgrywało wykorzystywanie podatności w usługach publicznie dostępnych, szczególnie po głośnych kampaniach wymierzonych w systemy brzegowe i aplikacje wystawione do Internetu. W pierwszej połowie 2025 roku phishing dominował jako sposób uzyskania początkowego dostępu, lecz później został częściowo wyparty przez eksploatację systemów public-facing.

W 2026 roku obserwowany jest wyraźny powrót phishingu na pierwsze miejsce. Nie chodzi jednak o prosty powrót do masowych kampanii niskiej jakości. Obecne operacje są bardziej dopracowane, częściej spersonalizowane i trudniejsze do wykrycia zarówno dla użytkowników, jak i dla klasycznych filtrów pocztowych. Zmiana ta zbiega się z szeroką dostępnością generatywnej AI, która obniża próg wejścia nawet dla mniej doświadczonych operatorów.

Analiza techniczna

AI wzmacnia phishing na kilku poziomach jednocześnie. Przede wszystkim automatyzuje przygotowanie wiadomości. Modele językowe potrafią tworzyć poprawne stylistycznie i gramatycznie e-maile dopasowane do konkretnej branży, stanowiska lub sytuacji biznesowej. To zwiększa skuteczność socjotechniki, ponieważ odbiorca otrzymuje komunikat przypominający autentyczną korespondencję operacyjną.

Kolejnym elementem jest przyspieszenie budowy infrastruktury ataku. W opisywanych przypadkach odnotowano użycie narzędzia AI do tworzenia stron przechwytujących poświadczenia użytkowników Microsoft Exchange i Outlook Web Access. Tego typu rozwiązania pozwalają wygenerować formularz wyłudzający dane logowania przy użyciu kilku poleceń tekstowych, bez konieczności ręcznego programowania. Dane mogą być następnie przekazywane do zewnętrznych repozytoriów, a operator może otrzymywać automatyczne powiadomienia o nowych przechwyconych rekordach.

Istotną rolę odgrywa również polimorfizm wiadomości. Zamiast rozsyłać identyczne kampanie do szerokich grup odbiorców, napastnicy tworzą wiele wariantów tej samej przynęty. Utrudnia to wykrywanie oparte na sygnaturach, statycznych regułach i prostym grupowaniu podobnych wiadomości. Każdy e-mail może różnić się treścią, tonem, formatowaniem lub elementami osadzonymi, mimo że prowadzi do tego samego celu operacyjnego.

Coraz częściej phishing wykorzystuje również legalne usługi chmurowe i rozpoznawalne platformy komunikacyjne. Linki oraz formularze bywają ukrywane w powiadomieniach pochodzących z powszechnie używanych narzędzi, co dodatkowo obniża czujność użytkowników. Atak nie musi wyglądać podejrzanie w tradycyjnym sensie, ponieważ może być osadzony w wiarygodnym przepływie biznesowym.

W praktyce głównym celem takich kampanii pozostają tożsamości cyfrowe: skrzynki pocztowe, konta uprzywilejowane, dostępy administracyjne i konta działów finansowych. Po przejęciu poświadczeń napastnik może poruszać się po środowisku znacznie ciszej niż przy użyciu exploita, korzystając z legalnego dostępu oraz natywnych interfejsów platform chmurowych.

Konsekwencje / ryzyko

Najważniejszą konsekwencją jest wzrost skuteczności ataków początkowego dostępu przy stosunkowo niskim koszcie operacyjnym. AI sprawia, że przygotowanie przekonującej kampanii staje się szybsze, tańsze i bardziej skalowalne. Oznacza to więcej ataków ukierunkowanych, lepsze dopasowanie do ofiary i krótszy czas potrzebny do uruchomienia kampanii.

Drugim problemem jest spadek skuteczności tradycyjnych metod świadomościowych. Przez lata użytkowników uczono, aby rozpoznawali phishing po literówkach, błędach gramatycznych i językowych niespójnościach. W modelu wspieranym przez AI takie cechy coraz częściej znikają, dlatego ocena ryzyka musi opierać się bardziej na analizie kontekstu niż samej formy wiadomości.

Trzecim ryzykiem jest nadmierne zaufanie do MFA. Uwierzytelnianie wieloskładnikowe pozostaje kluczowym zabezpieczeniem, ale nie eliminuje zagrożenia samo w sobie. Słabe wdrożenie, niepełne objęcie usług, możliwość rejestracji nowych metod uwierzytelniania czy obchodzenie polityk przez alternatywne ścieżki dostępu mogą pozostawić organizację podatną mimo formalnego wdrożenia MFA.

Czwartym wyzwaniem jest trudniejsza detekcja w SOC. Nadużywanie legalnych kont, aplikacji i API powoduje, że aktywność napastnika może przypominać zwykłą pracę użytkownika. W takich warunkach brak centralnego logowania, uboga telemetria oraz słaba korelacja zdarzeń znacząco zwiększają czas wykrycia i skalę potencjalnych strat.

Rekomendacje

Organizacje powinny traktować phishing wspierany przez AI przede wszystkim jako problem tożsamości, a nie wyłącznie jako problem poczty elektronicznej.

Wdrożyć pełne MFA dla wszystkich usług zdalnych i krytycznych oraz ograniczyć możliwość samodzielnej rejestracji metod uwierzytelniania.
Rozszerzyć polityki conditional access i regularnie przeglądać konta uprzywilejowane.
Rozwinąć detekcję behawioralną obejmującą nietypowe logowania, rejestrację nowych urządzeń, anomalie geograficzne i nietypowe operacje w usługach SaaS.
Uzupełnić ochronę poczty o analizę kontekstową i semantyczną, ponieważ klasyczne filtry sygnaturowe są niewystarczające wobec kampanii polimorficznych.
Inwestować w centralne logowanie i retencję danych śledczych z usług tożsamości, endpointów, poczty i aplikacji chmurowych.
Prowadzić realistyczne symulacje phishingowe o wysokiej jakości językowej i biznesowym kontekście.
Konsekwentnie ograniczać ekspozycję infrastruktury poprzez łatanie podatności, zamykanie zbędnych portów administracyjnych i segmentację dostępu.

Podsumowanie

Phishing wspierany przez AI osiągnął dojrzałość operacyjną i nie jest już ciekawostką ani eksperymentem. Stał się pełnoprawnym, skutecznym i skalowalnym wektorem początkowego dostępu. Jego przewaga wynika z połączenia automatyzacji, personalizacji, wielojęzyczności oraz możliwości ukrywania ataku w legalnych usługach. Dla obrońców oznacza to konieczność przesunięcia akcentu z prostego filtrowania wiadomości na ochronę tożsamości, analizę zachowania oraz budowę głębszej widoczności w środowisku.

Źródła

Dark Reading — AI Phishing Is No. 1 With a Bullet for Cyberattackers — https://www.darkreading.com/cyber-risk/ai-phishing-no-1-cyberattackers
Cisco Talos — IR Trends Q1 2026: Phishing reemerges as top initial access vector, as attacks targeting public administration persist — https://blog.talosintelligence.com/ir-trends-q1-2026/

Locked Shields 2026: 41 państw wzmacnia cyberodporność w największych ćwiczeniach cyberobrony

Wprowadzenie do problemu / definicja

Locked Shields 2026 to największe na świecie ćwiczenia typu live-fire w obszarze cyberobrony, zaprojektowane do realistycznego testowania zdolności reagowania na złożone ataki wymierzone w infrastrukturę krytyczną i systemy wojskowe. Tego rodzaju inicjatywy pozwalają sprawdzić nie tylko skuteczność technologii bezpieczeństwa, ale także gotowość organizacyjną, procesy decyzyjne oraz zdolność utrzymania operacji w warunkach wysokiej presji.

Współczesne zagrożenia cybernetyczne coraz częściej łączą klasyczne włamania, sabotaż usług, działania dezinformacyjne i presję polityczną. Z tego powodu odporność cybernetyczna przestaje być wyłącznie domeną zespołów technicznych, a staje się elementem bezpieczeństwa państwa, administracji i operatorów usług krytycznych.

W skrócie

W edycji Locked Shields 2026 uczestniczyło ponad 4 tysiące osób z 41 państw, co potwierdza rosnącą skalę i znaczenie ćwiczenia w międzynarodowym ekosystemie bezpieczeństwa. Scenariusz obejmował obronę kluczowych usług, w tym systemów obrony powietrznej, platform e-głosowania oraz innych zasobów o wysokim znaczeniu operacyjnym.

W rywalizacji wystąpiło 16 zespołów międzynarodowych. Wśród najwyżej ocenionych znalazły się zespoły Francji i Szwecji, Łotwy i Singapuru oraz wspólna reprezentacja Niemiec, Austrii, Luksemburga i Szwajcarii.

Ponad 4 tysiące uczestników z 41 państw
16 zespołów międzynarodowych
Scenariusze obejmujące systemy wojskowe i cywilne
Nacisk na ciągłość działania, współpracę i odporność na presję informacyjną

Kontekst / historia

Ćwiczenia Locked Shields są organizowane od 2010 roku i w ciągu 16 lat przeszły wyraźną transformację pod względem skali oraz złożoności. W pierwszej edycji brały udział jedynie cztery państwa i około 60 uczestników, podczas gdy dziś wydarzenie angażuje tysiące specjalistów z różnych sektorów i krajów.

Ten rozwój dobrze odzwierciedla zmianę charakteru zagrożeń. Dawniej nacisk kładziono głównie na ochronę systemów IT przed pojedynczymi incydentami, natomiast obecnie cyberataki są często elementem szerszych operacji wymierzonych w komunikację kryzysową, zaufanie społeczne, procesy wyborcze oraz zdolność państwa do podejmowania szybkich decyzji.

Dlatego nowoczesne ćwiczenia cyberobrony muszą obejmować nie tylko warstwę techniczną, ale również zarządzanie kryzysowe, współpracę międzyinstytucjonalną oraz reakcję na działania wpływu informacyjnego. Locked Shields 2026 wpisuje się właśnie w taki model kompleksowego testowania odporności.

Analiza techniczna

Locked Shields 2026 zostało przygotowane jako realistyczne środowisko operacyjne, w którym uczestnicy bronili infrastruktury przed intensywnymi atakami prowadzonymi w czasie rzeczywistym. Charakter live-fire oznacza wykorzystanie dynamicznego scenariusza odwzorowującego techniki, taktyki i procedury znane z nowoczesnych operacji cybernetycznych.

Z perspektywy technicznej ćwiczenie koncentrowało się na kilku kluczowych zdolnościach. Pierwszą była szybka detekcja aktywności przeciwnika, w tym identyfikacja anomalii, nieautoryzowanych zmian oraz prób zakłócenia działania usług krytycznych. Drugą była skuteczna reakcja incydentowa, obejmująca izolację zagrożonych zasobów, analizę śladów, odtwarzanie środowiska i ograniczanie wpływu operacyjnego. Trzeci obszar dotyczył utrzymania dostępności systemów mimo ciągłej presji i wielowektorowych działań przeciwnika.

Szczególnie istotna była ochrona systemów o znaczeniu państwowym i wojskowym, takich jak obrona powietrzna oraz platformy e-głosowania. W przypadku systemów wojskowych priorytetem pozostają integralność danych, dostępność usług i odporność na zakłócenia. W środowisku wyborczym równie ważne są wiarygodność procesu, odporność na manipulację informacyjną oraz zdolność szybkiego wykrywania prób podważenia zaufania do wyników.

Scenariusz obejmował również komponenty pozatechniczne, takie jak dezinformacja i presja polityczna. To ważny element, ponieważ nowoczesne operacje przeciwnika są wielowarstwowe i często łączą incydent sieciowy z kampanią wpływu, próbą destabilizacji procesów decyzyjnych lub atakiem na reputację instytucji.

W komunikatach po ćwiczeniach zwrócono także uwagę na rosnący wpływ sztucznej inteligencji na cyberobronę i działania ofensywne. W praktyce oznacza to konieczność przygotowania się zarówno na automatyzację po stronie obrońców, jak i na szybsze, bardziej skalowalne i adaptacyjne działania po stronie atakujących.

Konsekwencje / ryzyko

Najważniejszy wniosek płynący z Locked Shields 2026 jest taki, że odporności cybernetycznej nie da się ocenić wyłącznie przez skuteczność pojedynczych narzędzi ochronnych. W sytuacji kryzysowej kluczowe stają się zdolność organizacji do utrzymania działania, szybkość podejmowania decyzji oraz współpraca między zespołami technicznymi, prawnymi, operacyjnymi i komunikacyjnymi.

Dla operatorów infrastruktury krytycznej ryzyko obejmuje utratę dostępności usług, zakłócenie procesów operacyjnych, błędne decyzje wynikające z manipulacji informacyjnej oraz spadek zaufania do systemów publicznych. W środowisku wojskowym skutkami mogą być opóźnienia operacyjne, obniżenie świadomości sytuacyjnej i wzrost ryzyka błędnej oceny incydentów. W sektorze cywilnym szczególnie groźne są scenariusze, w których atak techniczny jest wzmacniany działaniami wymierzonymi w opinię publiczną.

Dodatkowym czynnikiem ryzyka jest rozwój AI. Automatyzacja może skrócić czas między rozpoznaniem a wykonaniem ataku, zwiększyć liczbę równoległych działań oraz utrudnić analitykom odróżnienie realnych incydentów od działań pozorowanych i odwracających uwagę.

Rekomendacje

Organizacje odpowiedzialne za infrastrukturę krytyczną oraz środowiska o wysokiej wrażliwości powinny traktować podobne ćwiczenia jako punkt odniesienia dla budowy dojrzałości operacyjnej. W praktyce warto wdrożyć zestaw działań obejmujących zarówno technologię, jak i procesy oraz współpracę między zespołami.

Regularnie prowadzić ćwiczenia typu purple team, tabletop oraz symulacje kryzysowe obejmujące warstwę techniczną, prawną i komunikacyjną
Testować ciągłość działania systemów krytycznych, w tym procedury odtwarzania, przełączania awaryjnego i pracy w trybie degradacji
Rozwijać zdolności SOC i CSIRT w zakresie korelacji zdarzeń, analizy behawioralnej i priorytetyzacji alertów
Uwzględniać scenariusze hybrydowe łączące incydenty techniczne z dezinformacją i atakami reputacyjnymi
Wzmacniać współpracę międzynarodową i międzysektorową, ponieważ współczesne incydenty rzadko ograniczają się do jednej organizacji
Analizować wpływ narzędzi opartych na AI na modele obrony oraz potencjalne techniki przeciwnika

Podsumowanie

Locked Shields 2026 potwierdza, że cyberodporność stała się zagadnieniem strategicznym, które łączy technologię, operacje, komunikację i współpracę międzynarodową. Skala wydarzenia oraz zakres scenariuszy pokazują, że przygotowanie na nowoczesne zagrożenia wymaga znacznie więcej niż tradycyjnej ochrony perymetru.

Największą wartością takich ćwiczeń jest możliwość sprawdzenia, czy organizacje potrafią utrzymać działanie kluczowych usług pod presją, reagować na złożone incydenty i jednocześnie odpierać działania wpływu. To właśnie ta zdolność do działania w warunkach zakłóceń będzie jednym z najważniejszych filarów bezpieczeństwa państw i instytucji w najbliższych latach.

Źródła

SecurityWeek — Locked Shields 2026: 41 Nations Strengthen Cyber Resilience in World’s Biggest Exercise

CVE-2026-33626 w LMDeploy: luka SSRF wykorzystana kilkanaście godzin po ujawnieniu

Wprowadzenie do problemu / definicja

CVE-2026-33626 to podatność typu Server-Side Request Forgery (SSRF) wykryta w projekcie LMDeploy, otwartoźródłowym narzędziu do kompresji, wdrażania i udostępniania dużych modeli językowych oraz modeli vision-language. Problem dotyczył mechanizmu pobierania obrazów, który akceptował zdalne adresy URL bez właściwej walidacji hostów i adresów IP. W praktyce oznaczało to możliwość wymuszenia po stronie serwera połączeń do zasobów wewnętrznych, usług metadanych chmurowych i innych systemów niedostępnych bezpośrednio z Internetu.

W skrócie

Luka została sklasyfikowana jako podatność wysokiego ryzyka z oceną CVSS 7.5 i dotyczyła LMDeploy 0.12.0 oraz starszych wersji, jeśli środowisko miało włączoną obsługę vision-language. Podatny mechanizm znajdował się w funkcji pobierającej obrazy na podstawie pola image_url. Z publicznych analiz wynika, że pierwsze próby wykorzystania odnotowano już około 12 godzin i 31 minut po publikacji ostrzeżenia bezpieczeństwa.

podatność umożliwiała skanowanie zasobów wewnętrznych z poziomu serwera modeli,
atakujący testowali dostęp do AWS IMDS, Redis, MySQL i lokalnych interfejsów administracyjnych,
krótkie okno między ujawnieniem a atakiem pokazuje rosnące zainteresowanie cyberprzestępców infrastrukturą AI.

Kontekst / historia

LMDeploy jest wykorzystywany do serwowania modeli LLM i VLM przez interfejs HTTP zgodny z popularnym wzorcem API dla systemów generatywnej AI. Tego rodzaju komponenty coraz częściej trafiają do środowisk produkcyjnych, gdzie mają łączność z segmentami prywatnymi, usługami pomocniczymi, magazynami danych i mechanizmami autoryzacji w chmurze.

Advisory dotyczące CVE-2026-33626 opublikowano 21 kwietnia 2026 roku. Badacze zwrócili uwagę, że przypadek ten wpisuje się w szerszy trend błyskawicznej operacjonalizacji błędów w infrastrukturze AI. W tym incydencie czas między publicznym ujawnieniem a pierwszą zaobserwowaną próbą ataku był wyjątkowo krótki, co potwierdza, że operatorzy zagrożeń aktywnie monitorują nowe zgłoszenia bezpieczeństwa dotyczące narzędzi AI.

Analiza techniczna

Źródłem problemu był sposób obsługi pola image_url w żądaniach kierowanych do endpointu czatu. Gdy użytkownik przekazywał adres obrazu HTTP lub HTTPS, serwer pobierał wskazany zasób po swojej stronie. W podatnej implementacji zabrakło kilku kluczowych zabezpieczeń.

braku walidacji docelowego hosta przed wykonaniem żądania,
braku blokady dla zakresów prywatnych i lokalnych, takich jak 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 i 169.254.0.0/16,
braku kontroli rozwiązywania DNS oraz powiązania odpowiedzi z bezpiecznym adresem,
braku domyślnych ograniczeń ekspozycji usługi i dodatkowych wymogów autoryzacyjnych.

W efekcie atakujący mógł wysłać prawidłowo sformułowane żądanie do API i zmusić serwer LMDeploy do pobrania zasobu z sieci lokalnej lub z usług metadanych instancji chmurowej. Szczególnie niebezpieczny pozostaje dostęp do adresu 169.254.169.254, który w wielu środowiskach chmurowych udostępnia metadane instancji oraz czasowe poświadczenia.

Z publicznie opisanych obserwacji wynika, że atak przebiegał etapami. Najpierw testowano dostęp do AWS IMDS i usług Redis. Następnie sprawdzano możliwość komunikacji wychodzącej przez zewnętrzne kanały DNS lub OOB. W kolejnym kroku prowadzono rozpoznanie interfejsu loopback, aby ustalić, jakie usługi są osiągalne z hosta uruchamiającego silnik inferencyjny.

Konsekwencje / ryzyko

Ryzyko związane z CVE-2026-33626 wykracza daleko poza zwykłe ujawnienie danych. W środowiskach produkcyjnych SSRF w serwerze inferencyjnym może stać się punktem wejścia do dalszej kompromitacji infrastruktury.

kradzież poświadczeń chmurowych z usług metadanych,
dostęp do wewnętrznych baz danych, cache i paneli administracyjnych,
mapowanie topologii sieci oraz wykrywanie otwartych portów,
budowanie ścieżki do ruchu bocznego,
eskalacja incydentu z poziomu komponentu AI do poziomu całego środowiska aplikacyjnego lub chmurowego.

Podatność jest szczególnie groźna tam, gdzie serwer modeli działa w tej samej sieci co usługi backendowe, ma szerokie uprawnienia IAM lub korzysta z domyślnie otwartego ruchu wychodzącego. Nawet jeśli SSRF nie prowadzi bezpośrednio do wykonania kodu, może dostarczyć napastnikowi danych i wiedzy niezbędnych do kolejnych etapów ataku.

Rekomendacje

Organizacje korzystające z LMDeploy powinny potraktować tę lukę jako wymagającą pilnej reakcji operacyjnej. Ochrona nie powinna ograniczać się wyłącznie do aktualizacji aplikacji, lecz obejmować również warstwę sieciową i kontrolę uprawnień.

zidentyfikować wszystkie instancje LMDeploy z aktywną obsługą vision-language,
przeprowadzić aktualizację lub wdrożyć obejścia ograniczające pobieranie zewnętrznych URL-i,
zablokować dostęp procesu inferencyjnego do adresów lokalnych, link-local, RFC1918 i usług metadanych chmurowych,
stosować listy dozwolonych domen lub repozytoriów obrazów zamiast dowolnych adresów URL,
wymusić kontrolę egress na poziomie hosta, kontenera, klastra i VPC,
odseparować serwery inferencyjne od baz danych, cache i interfejsów administracyjnych,
włączyć uwierzytelnianie do API oraz ograniczyć nasłuch wyłącznie do niezbędnych interfejsów,
monitorować nietypowe połączenia wychodzące, zwłaszcza do adresów lokalnych i usług metadanych,
przejrzeć logi pod kątem nietypowych wartości image_url, prób skanowania portów i wywołań OOB,
rozważyć rotację poświadczeń chmurowych, jeśli istnieje podejrzenie kontaktu z usługą metadanych.

Podsumowanie

CVE-2026-33626 pokazuje, że podatności SSRF w infrastrukturze AI mogą być wykorzystywane niemal natychmiast po publicznym ujawnieniu. W przypadku LMDeploy problem dotyczył z pozoru prostego mechanizmu pobierania obrazów, ale skutki obejmowały dostęp do zasobów wewnętrznych, usług metadanych i możliwość prowadzenia rozpoznania sieci z poziomu serwera modeli. Dla zespołów bezpieczeństwa to wyraźny sygnał, że komponenty LLM i VLM należy traktować jak krytyczne elementy powierzchni ataku.