Archiwa: LLM - Strona 2 z 24 - Security Bez Tabu

Carbonato atakuje niezabezpieczone hosty Docker i wdraża agenta Hermes AI sterowanego przez Telegram

Wprowadzenie do problemu / definicja

Carbonato to nowo opisany botnet ukierunkowany na hosty z publicznie wystawionym i niezabezpieczonym demonem Docker. Zagrożenie wyróżnia się tym, że po przejęciu systemu nie ogranicza się do klasycznej instalacji malware, lecz wdraża również agenta Hermes AI, który może wykonywać zadania przesyłane operatorom przez Telegram.

W praktyce oznacza to połączenie tradycyjnego przejęcia infrastruktury kontenerowej z automatyzacją działań po kompromitacji. Taki model zwiększa elastyczność ataku, skraca czas reakcji operatora i pozwala szybciej realizować zadania na zainfekowanym hoście.

W skrócie

Carbonato wyszukuje hosty Docker dostępne bez uwierzytelniania, zwłaszcza na porcie 2375.
Po uzyskaniu dostępu uruchamia uprzywilejowany kontener i wykonuje polecenia bezpośrednio na hoście.
Malware ustanawia trwałość, zdalny dostęp i raportuje infekcję przez Telegram.
Na przejętych systemach wdrażany jest Hermes Agent ze zmodyfikowaną personą do działań ofensywnych.
Botnet skanuje sąsiednie sieci i próbuje samodzielnie rozprzestrzeniać się dalej.

Kontekst / historia

Publicznie wystawione interfejsy Docker od lat pozostają atrakcyjnym celem dla operatorów cryptominerów, botnetów i ransomware. Błędna konfiguracja demona może umożliwić wykonanie kodu bez dodatkowej autoryzacji, co czyni takie hosty wyjątkowo podatnymi na szybkie przejęcie.

W przypadku Carbonato szczególne znaczenie ma jednak ewolucja modelu operacyjnego. Badacze powiązali kampanię z publicznie dostępnym, nieuwierzytelnionym rejestrem Docker, który miał być osiągalny co najmniej od maja 2026 roku. Zgromadzone artefakty miały obejmować zarówno komponenty samego botnetu, jak i materiały związane z inną operacją dystrybucji trojanizowanych aplikacji portfeli kryptowalutowych.

To sugeruje, że Carbonato nie jest incydentalnym narzędziem, lecz elementem szerszego ekosystemu przestępczego. Jednocześnie kampania wpisuje się w rosnący trend wykorzystywania agentów AI do automatyzacji etapów post-exploitation.

Analiza techniczna

Łańcuch ataku rozpoczyna się od wyszukiwania hostów z demonem Docker wystawionym bez uwierzytelniania. Po znalezieniu celu Carbonato uruchamia kontener z uprawnieniami uprzywilejowanymi, co pozwala mu wykonywać polecenia na systemie bazowym, a nie tylko wewnątrz izolacji kontenera.

Następnie malware ustanawia trwałość i kanał zdalnego dostępu. Opis kampanii wskazuje na wykorzystanie odwrotnego tunelu SSH do przekaźnika, instalację serwera SSH z kluczem operatora oraz raportowanie nowej infekcji przez Telegram. Dodatkowo stosowane są zadania cron i skrypty watchdog odpowiadające za ponowne uruchomienie komponentów po ich usunięciu.

Istotnym elementem technicznym jest również maskowanie się pod komponent systemowy, co ma utrudnić wykrycie przez administratorów i narzędzia bezpieczeństwa. Po ustanowieniu trwałości botnet wdraża Hermes Agent w niemal niezmienionej postaci, ale nadpisuje plik SOUL.md, który definiuje personę i sposób działania agenta.

Zmodyfikowana persona instruuje Hermes Agent, aby działał jako operator ofensywny, utrzymywał trwałość, reagował na komendy z Telegrama i realizował wskazane operacje. W efekcie agent odbiera zadania, przekazuje je do zaplecza LLM, uzyskuje wygenerowane komendy terminalowe, uruchamia je na przejętym hoście i odsyła wyniki operatorowi.

Carbonato ma także zdolności samorozprzestrzeniania. Malware skanuje sąsiednie segmenty sieci co kilka minut i próbuje identyfikować kolejne hosty Docker dostępne bez uwierzytelniania. W środowiskach o słabej segmentacji może to prowadzić do szybkiego rozszerzenia kompromitacji.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem infekcji jest pełne przejęcie hosta obsługującego kontenery. Atakujący może wykonywać polecenia systemowe, instalować dodatkowe narzędzia, kraść poświadczenia, utrzymywać ukryty dostęp i wykorzystywać maszynę do ruchu bocznego.

W środowiskach produkcyjnych ryzyko jest szczególnie wysokie, ponieważ host Docker często posiada dostęp do sekretów aplikacyjnych, rejestrów obrazów, zasobów CI/CD, wolumenów z danymi oraz poświadczeń do usług chmurowych. Jeśli operator wykorzysta agenta Hermes do pozyskiwania kluczy API i innych sekretów, konsekwencją może być dalsza eskalacja do kolejnych warstw infrastruktury.

Dodatkowym zagrożeniem jest skala automatyzacji. Połączenie sterowania przez komunikator z agentem wspieranym przez modele językowe obniża koszt operacyjny ataku i pozwala sprawniej obsługiwać większą liczbę ofiar. To może utrudniać detekcję opartą na tradycyjnych wzorcach aktywności.

Rekomendacje

Podstawowym działaniem ochronnym jest natychmiastowe usunięcie publicznej ekspozycji demona Docker bez uwierzytelniania. Port 2375 nie powinien być dostępny z Internetu ani z niekontrolowanych segmentów wewnętrznych. Jeżeli zdalne zarządzanie jest konieczne, należy wdrożyć szyfrowanie, wzajemne uwierzytelnianie certyfikatami oraz ścisłe ograniczenia sieciowe.

Organizacje powinny przeprowadzić przegląd konfiguracji hostów kontenerowych, zwracając uwagę na:

ekspozycję interfejsów administracyjnych,
użycie kontenerów uprzywilejowanych,
mapowanie socketu Docker do kontenerów,
obecność nieautoryzowanych zadań cron,
anomalie w konfiguracji SSH,
nietypowe połączenia wychodzące i tunele zwrotne.

W warstwie detekcji warto monitorować:

uruchamianie uprzywilejowanych kontenerów,
procesy tworzące lub modyfikujące harmonogramy cron,
nieoczekiwane instalacje serwera SSH,
modyfikacje plików związanych z agentami AI i automatyzacją,
komunikację z Telegramem z hostów serwerowych,
intensywne skanowanie sieci lokalnej przez hosty Docker.

W przypadku podejrzenia kompromitacji nie należy ograniczać się do usunięcia pojedynczego kontenera. Konieczna jest pełna analiza hosta, mechanizmów trwałości, kluczy SSH, tuneli, sekretów aplikacyjnych oraz możliwego ruchu bocznego. Należy również zrotować wszystkie poświadczenia dostępne z poziomu skompromitowanego systemu.

Podsumowanie

Carbonato pokazuje nową klasę zagrożeń, w której klasyczne błędy konfiguracyjne infrastruktury są łączone z automatyzacją opartą na AI. Publicznie wystawiony Docker pozostaje prostym punktem wejścia, ale integracja z Hermes Agent oraz sterowaniem przez Telegram nadaje tej kampanii nowy wymiar operacyjny.

Dla zespołów bezpieczeństwa najważniejszy wniosek jest jednoznaczny: ochrona środowisk kontenerowych nie może opierać się wyłącznie na izolacji workloadów. Konieczne są także zabezpieczenie interfejsów zarządzania, monitoring trwałości oraz wykrywanie nietypowych mechanizmów automatyzacji po kompromitacji.

Źródła

Carbonato Botnet Compromises Docker Hosts to Deploy Telegram-Controlled Hermes AI Agent — https://thehackernews.com/2026/09/carbonato-botnet-compromises-docker.html

MikroTrick w MikroTik RouterOS: krytyczny łańcuch podatności SSH umożliwia przejęcie urządzeń bez logowania

Wprowadzenie do problemu / definicja

MikroTrick to nazwa łańcucha ataku wykorzystującego dwie podatności w MikroTik RouterOS, które po połączeniu pozwalają ominąć mechanizmy uwierzytelniania i uzyskać pełne uprawnienia administracyjne na urządzeniu. Problem dotyczy obsługi sesji SSH oraz sposobu przekazywania danych do procesu logowania, co czyni go szczególnie niebezpiecznym dla routerów pełniących funkcje brzegowe i zarządzające.

To zdarzenie ma duże znaczenie dla zespołów bezpieczeństwa, ponieważ pokazuje, jak szybko analiza opublikowanych poprawek może doprowadzić do odtworzenia praktycznego scenariusza eksploatacji. W efekcie okno czasowe na bezpieczne wdrożenie aktualizacji staje się coraz krótsze.

W skrócie

Na początku września 2026 roku producent udostępnił ważną aktualizację bezpieczeństwa dla RouterOS, nie ujawniając od razu pełnych szczegółów technicznych. Badacze z CERT Polska zrekonstruowali jednak mechanizm ataku na podstawie różnic między wersją podatną a poprawioną i opisali łańcuch nazwany MikroTrick.

atak wykorzystuje dwa błędy związane z obsługą SSH i procesu logowania,
efektem może być pełne przejęcie urządzenia bez poprawnego uwierzytelnienia,
obserwowano przesłanki wskazujące na realne wykorzystanie podatności,
incydent podkreśla konieczność natychmiastowego wdrażania łatek.

Kontekst / historia

3 września 2026 roku MikroTik opublikował aktualizację bezpieczeństwa dla RouterOS, opisując ją w ograniczonym zakresie. Taki model komunikacji miał utrudnić szybkie odtworzenie szczegółów błędów, jednak analiza zmian w pakietach okazała się wystarczająca, by wskazać obszar podatności.

W dalszej analizie CERT Polska opisał, że aktywność sugerująca wykorzystanie podatności mogła występować jeszcze przed publicznym ujawnieniem mechanizmu. Szczególną uwagę zwracały nietypowe wpisy w logach, obejmujące nieudane logowania z podejrzaną nazwą użytkownika, po których następowało utworzenie uprzywilejowanego konta lub uzyskanie sesji o wysokich uprawnieniach.

Sprawa szybko nabrała znaczenia operacyjnego. Dodanie wybranych podatności RouterOS do katalogu Known Exploited Vulnerabilities przez CISA potwierdziło, że zagrożenie nie miało wyłącznie charakteru teoretycznego i wymagało pilnej reakcji ze strony administratorów.

Analiza techniczna

Techniczny rdzeń MikroTrick opiera się na połączeniu dwóch błędów. Pierwszy dotyczy mechanizmu renegocjacji kluczy w sesji SSH. W prawidłowym modelu klient nie powinien uzyskać dostępu do kanałów sesyjnych przed zakończeniem uwierzytelnienia, jednak w podatnej implementacji możliwe było doprowadzenie do stanu, w którym serwer zaczynał obsługiwać kanał sesji tak, jakby logowanie zostało już zakończone.

Druga podatność dotyczy logiki uruchamiania procesu logowania. RouterOS przekazywał do niego nazwę użytkownika i informacje związane z poziomem uprawnień, ale bez wystarczającej walidacji wartości wejściowej. Atakujący mógł więc dostarczyć spreparowaną nazwę użytkownika, która była interpretowana nie jako zwykła tożsamość konta, lecz jako argument wpływający na dalsze zachowanie procesu.

W analizach wskazano, że odpowiednio przygotowany ciąg znaków mógł doprowadzić do błędnej interpretacji parametrów przez proces login. W praktyce otwierało to drogę do sterowania danymi związanymi z tożsamością i uprawnieniami bez znajomości prawidłowych poświadczeń. Połączenie tej techniki z obejściem uwierzytelnienia w SSH prowadziło do uruchomienia sesji administracyjnej bez poprawnego logowania.

Ważnym elementem całej sprawy była również sama metodyka badawcza. CERT Polska opisał wykorzystanie modeli LLM do analizy binariów, testowania nietypowych sekwencji protokołu oraz budowy izolowanego laboratorium z wieloma wersjami RouterOS. To pokazuje, że narzędzia wspierane przez AI realnie skracają czas potrzebny do odtwarzania scenariuszy ataku po publikacji poprawek.

Konsekwencje / ryzyko

Skuteczne wykorzystanie łańcucha MikroTrick może prowadzić do pełnego przejęcia urządzenia sieciowego. W praktyce oznacza to możliwość zmiany konfiguracji routingu, podsłuchiwania lub przekierowywania ruchu, tworzenia dodatkowych kont administracyjnych, modyfikacji reguł zapory czy zestawiania nieautoryzowanych tuneli.

Ryzyko jest szczególnie wysokie tam, gdzie SSH jest dostępne z internetu lub gdzie urządzenia MikroTik pełnią funkcję elementów brzegowych. Kompromitacja routera daje napastnikowi uprzywilejowaną pozycję w topologii sieci i może stać się punktem wyjścia do ruchu bocznego, dalszej penetracji infrastruktury oraz utrzymania trwałego dostępu.

Na poziomie strategicznym przypadek ten pokazuje, że koszt i czas analizy łatek maleją szybciej niż możliwości wielu organizacji w zakresie testowania i wdrażania aktualizacji. Odkładanie poprawek na późniejsze okna serwisowe może dziś oznaczać realne zwiększenie ryzyka kompromitacji.

Rekomendacje

Najważniejszym krokiem powinno być niezwłoczne zaktualizowanie RouterOS do wersji zawierających poprawki bezpieczeństwa. Organizacje korzystające z wielu gałęzi wydań powinny upewnić się, że wszystkie klasy urządzeń zostały objęte odpowiednią aktualizacją, a nie tylko systemy działające w głównym kanale stable.

ograniczyć lub całkowicie wyłączyć dostęp SSH z internetu, jeśli nie jest niezbędny,
udostępniać zarządzanie wyłącznie przez VPN, ACL i dedykowane adresy administracyjne,
oddzielić płaszczyznę zarządzania od ruchu użytkowników i usług publicznych,
przeanalizować logi pod kątem nietypowych prób logowania oraz podejrzanych nazw użytkownika,
sprawdzić, czy nie pojawiły się nowe konta uprzywilejowane, zmiany reguł firewalla, kluczy SSH, harmonogramów i tuneli.

Jeżeli istnieje podejrzenie kompromitacji, sama aktualizacja nie powinna być uznana za wystarczającą. Konieczny jest przegląd konfiguracji, rotacja poświadczeń administracyjnych, weryfikacja integralności ustawień oraz ocena, czy urządzenie nie zostało użyte do dalszych działań w sieci. W środowiskach krytycznych uzasadnione może być odtworzenie konfiguracji na zaufanym obrazie systemu po zabezpieczeniu materiału dowodowego.

Podsumowanie

MikroTrick jest jednym z najważniejszych przykładów krytycznego łańcucha podatności w urządzeniach sieciowych w 2026 roku. Połączenie błędu w logice uwierzytelniania SSH z niewłaściwą walidacją argumentów procesu logowania umożliwiało pełne przejęcie RouterOS bez poprawnego logowania.

Dla administratorów wnioski są jednoznaczne: aktualizacje bezpieczeństwa muszą być wdrażane priorytetowo, ekspozycja SSH powinna zostać ograniczona do minimum, a analiza logów i konfiguracji po wdrożeniu poprawek jest konieczna wszędzie tam, gdzie urządzenia mogły być osiągalne z sieci publicznej.

Źródła

MikroTrick: analiza techniczna, proces ujawnienia i zastosowanie agentów LLM | CERT Polska — https://cert.pl/posts/2026/09/mikrotrick-analiza-techniczna/
September 2026 vulnerability | MikroTik — https://mikrotik.com/supportsec/september-2026-vulnerability/
AI Helps Uncover MikroTrick Attack Chain in MikroTik RouterOS | Security Affairs — https://securityaffairs.com/199678/hacking/ai-helps-uncover-mikrotrick-attack-chain-in-mikrotik-routeros.html
U.S. CISA adds Microsoft SharePoint and Mikrotik RouterOS flaws to its Known Exploited Vulnerabilities catalog | Security Affairs — https://securityaffairs.com/199703/hacking/u-s-cisa-adds-microsoft-sharepoint-and-mikrotik-routeros-flaws-to-its-known-exploited-vulnerabilities-catalog.html
Mikrotik security advisory (AV26-887) – Update 1 | Canadian Centre for Cyber Security — https://www.cyber.gc.ca/en/alerts-advisories/mikrotik-security-advisory-av26-887

CLOSEDQUORUM: malware dla Windows wykorzystuje głosowanie modeli AI do wyboru działań operacyjnych

Wprowadzenie do problemu / definicja

CLOSEDQUORUM to nowy typ złośliwego oprogramowania dla systemów Windows, którego cechą wyróżniającą jest delegowanie wybranych decyzji taktycznych do kilku komercyjnych modeli sztucznej inteligencji. Zamiast polegać wyłącznie na operatorze lub klasycznej infrastrukturze dowodzenia, implant sam zbiera informacje o środowisku, tworzy zapytania i realizuje działanie wskazane przez większość odpowiedzi.

Taki model działania oznacza istotne przesunięcie w automatyzacji ataku. AI nie pełni tu wyłącznie roli pomocniczej, ale staje się elementem mechanizmu decyzyjnego, który wpływa na dalszy przebieg operacji po stronie napastnika.

W skrócie

Analizowany malware po uruchomieniu konsultuje kolejne kroki z czterema modelami LLM. Na podstawie odpowiedzi wybiera jedną z predefiniowanych akcji, takich jak kradzież danych, utrwalenie obecności, iniekcja kodu lub przygotowanie do ruchu bocznego.

działa na systemach Windows,
zbiera informacje o hoście i danych użytkownika,
wykorzystuje mechanizm większościowego głosowania modeli AI,
eksfiltruje dane z użyciem webhooka,
ogranicza potrzebę bieżącej interakcji operatora z implantem.

Kontekst / historia

W ostatnich latach wykorzystanie AI w cyberprzestępczości skupiało się głównie na zwiększaniu skali i tempa działań. Sztuczna inteligencja pomagała generować wiadomości phishingowe, wspierała socjotechnikę i przyspieszała przygotowywanie wariantów złośliwego kodu, ale człowiek nadal pozostawał centralnym punktem decyzyjnym.

CLOSEDQUORUM wpisuje się w kolejny etap ewolucji zagrożeń. W tym modelu AI nie tylko wspiera operatora, ale przejmuje część odpowiedzialności za wybór działań operacyjnych. To ważny sygnał, że malware może stopniowo stawać się bardziej autonomiczne, elastyczne i mniej zależne od stałej kontroli człowieka.

Analiza techniczna

Po uruchomieniu CLOSEDQUORUM zbiera podstawowe informacje o środowisku, takie jak nazwa hosta, wersja systemu oraz poziom uprawnień. Dane te są następnie osadzane w promptach wysyłanych do czterech modeli AI, z których każdy ma wskazać jedną z czterech akcji operacyjnych: kradzież danych, iniekcję, utrwalenie lub ruch boczny.

Odpowiedzi są zliczane, a implant wykonuje wariant, który uzyskał większość głosów. Jeżeli dojdzie do remisu, próbka stosuje z góry ustalony mechanizm rozstrzygania. To sprawia, że mimo nowatorskiej architektury sama logika decyzyjna pozostaje stosunkowo przewidywalna i może zostawiać ślady użyteczne z perspektywy detekcji.

W analizowanym wariancie funkcja kradzieży danych obejmuje pozyskiwanie poświadczeń z pamięci procesu LSASS, odczyt zapisanych haseł z popularnych przeglądarek oraz wyszukiwanie portfeli kryptowalutowych. Funkcja iniekcji odpowiada za zapis i uruchamianie shellcode, natomiast mechanizm persistence służy do przetrwania restartu systemu. Moduł związany z ruchem bocznym został zdefiniowany, ale według opisu nie był jeszcze w pełni zaimplementowany.

Na uwagę zasługuje także kanał eksfiltracji. Zamiast klasycznego serwera C2 próbka wykorzystuje webhook, a skradzione dane są szyfrowane i kodowane przed wysłaniem. Opis implementacji sugeruje jednak raczej zaciemnianie informacji niż dojrzały model kryptograficzny, ponieważ sposób wyprowadzania klucza ma przewidywalny charakter.

Interesujący jest również model dystrybucji. Publicznie opisana próbka zawierała placeholdery dla kluczy API i webhooka, co może wskazywać na wersję demonstracyjną lub zanonimizowaną. Jednocześnie artefakty rozwojowe sugerują możliwość tworzenia spersonalizowanych buildów z osadzonymi danymi dostępowymi dla konkretnych operatorów.

Konsekwencje / ryzyko

Największe ryzyko związane z CLOSEDQUORUM wynika nie tylko z samych technik kradzieży danych, ale przede wszystkim z jego architektury operacyjnej. Malware korzystające z legalnie wyglądających usług AI może trudniej wpisywać się w klasyczne wzorce wykrywania komunikacji C2, zwłaszcza w środowiskach o ograniczonej widoczności ruchu szyfrowanego.

Z punktu widzenia organizacji zagrożone są poświadczenia użytkowników, sesje przeglądarkowe, dostęp do zasobów chmurowych oraz portfele kryptowalutowe. Dodatkowym problemem pozostaje możliwość samodzielnego wyboru kolejnych działań bez potrzeby natychmiastowego kontaktu operatora z implantem.

Ryzyko strategiczne polega na tym, że podobne konstrukcje mogą szybko ewoluować. W przyszłości takie zagrożenia mogą stać się bardziej modularne, odporniejsze na błędne odpowiedzi modeli oraz lepiej dostosowane do środowiska ofiary. CLOSEDQUORUM należy więc traktować jako wczesny sygnał kierunku rozwoju malware wspieranego przez AI.

Rekomendacje

Organizacje powinny rozszerzyć podejście do detekcji poza tradycyjne wskaźniki kompromitacji i większy nacisk położyć na korelację zachowań procesów. Szczególnie niepokojące są sytuacje, w których nieznany proces systemu Windows jednocześnie uzyskuje dostęp do pamięci LSASS, tworzy mechanizmy persistence, uruchamia techniki iniekcji i komunikuje się z wieloma usługami AI lub webhookami.

monitorować dostęp do pamięci LSASS i próby dumpingu poświadczeń,
wykrywać tworzenie procesów w stanie suspended oraz uruchamianie shellcode,
analizować modyfikacje kluczy autostartu i innych mechanizmów persistence,
profilować nietypowe połączenia wychodzące do usług AI z procesów, które zwykle z nich nie korzystają,
korelować eksfiltrację danych z próbami kradzieży poświadczeń i aktywnością webhookową.

Z perspektywy hardeningu warto ograniczyć możliwość pozyskiwania poświadczeń z pamięci, stosować zasadę najmniejszych uprawnień, segmentować dostęp do systemów krytycznych oraz wzmacniać ochronę przeglądarek i danych użytkownika. Istotne pozostaje także wdrażanie MFA wszędzie tam, gdzie jest to możliwe.

Zespoły SOC powinny przygotować reguły analityczne oparte na całym łańcuchu zdarzeń. Pojedyncze połączenie do API modelu AI nie musi oznaczać incydentu, ale zestawienie go z kradzieżą poświadczeń, persistence i webhookową eksfiltracją stanowi już silny sygnał kompromitacji.

Podsumowanie

CLOSEDQUORUM pokazuje, że komercyjne modele AI mogą być wykorzystywane nie tylko do tworzenia treści czy pomocniczej automatyzacji, ale również do podejmowania decyzji operacyjnych w trakcie ataku. To ważny krok w kierunku bardziej autonomicznych implantów, które ograniczają rolę operatora i zacierają granicę między klasycznym C2 a legalną komunikacją z usługami chmurowymi.

Choć opisana próbka nie wygląda jeszcze na technicznie doskonałą, jej znaczenie wyraźnie wykracza poza pojedynczy przypadek. Dla obrońców kluczowe będzie wykrywanie skorelowanych zachowań obejmujących dostęp do poświadczeń, iniekcję, persistence oraz nietypową komunikację z usługami AI.

Źródła

Security Affairs — CLOSEDQUORUM, the malware that asks four AI models what to do next — https://securityaffairs.com/199640/malware/closedquorum-the-malware-that-asks-four-ai-models-what-to-do-next.html
Cisco Talos Blog — CLOSEDQUORUM technical report — https://blog.talosintelligence.com/closedquorum/

Przejęcie domeny placeholder ujawnia nowe ryzyko dla dokumentacji, repozytoriów i agentów AI

Wprowadzenie do problemu / definicja

Domeny placeholder od lat pojawiają się w dokumentacji technicznej, przykładach konfiguracji, materiałach szkoleniowych oraz repozytoriach kodu. Problem zaczyna się wtedy, gdy taki adres nie jest formalnie zarezerwowany i może zostać zarejestrowany przez osobę trzecią. Wówczas historyczne odwołania obecne w README, skryptach, przykładach API czy instrukcjach wdrożeniowych zaczynają kierować użytkowników do realnej infrastruktury kontrolowanej przez atakującego.

Taki scenariusz tworzy nietypowy, ale bardzo praktyczny wektor ataku. Zagrożone są nie tylko osoby korzystające z dokumentacji, lecz także procesy automatyczne, narzędzia integracyjne i agenci AI, którzy mogą traktować taki adres jako prawidłowe źródło danych lub punkt komunikacji.

W skrócie

Badacze bezpieczeństwa opisali przypadek domeny placeholder wykorzystywanej wcześniej jako przykładowy adres w ponad 1700 publicznych repozytoriach. Po jej przejęciu zaczęła ona serwować złośliwe treści, dostosowane do platformy ofiary.

Użytkownicy Windows otrzymywali przynętę typu ClickFix.
Atak wykorzystywał socjotechnikę i nakłaniał do uruchomienia polecenia pobierającego ładunek PowerShell.
Inni użytkownicy mogli widzieć treści neutralne, mniej podejrzane lub parking domeny.
Incydent pokazał ryzyko dla łańcucha dostaw oprogramowania, dokumentacji oraz środowisk opartych na AI.

Kontekst / historia

W cyberbezpieczeństwie od dawna rozróżnia się domeny formalnie zarezerwowane do celów demonstracyjnych od nazw, które jedynie wyglądają jak przykładowe. Te pierwsze są znacznie bezpieczniejsze, ponieważ nie mogą zostać łatwo przejęte i użyte w kampaniach phishingowych, malware czy oszustwach.

Problem dotyczy natomiast nazw brzmiących realistycznie, takich jak przykładowe domeny firmowe, usługowe lub integracyjne, które trafiają do dokumentacji wyłącznie jako wygodne atrapy. Jeśli taka nazwa nie znajduje się pod kontrolą organizacji i nie jest zarezerwowana, może po latach stać się aktywnym elementem infrastruktury atakującego.

To sprawia, że dawne decyzje redakcyjne i developerskie mogą wrócić jako podatność operacyjna. Wystarczy, że adres został skopiowany do wielu miejsc — od repozytoriów i wiki po samouczki, testy i opisy integracji — aby późniejsze przejęcie domeny przełożyło się na szeroką ekspozycję.

Analiza techniczna

W opisanym scenariuszu przejęta domena nie serwowała identycznej treści każdemu użytkownikowi. Infrastruktura odpowiadała zależnie od platformy i kontekstu żądania, co utrudniało wykrycie zagrożenia zwykłym, jednorazowym sprawdzeniem adresu.

Użytkownicy systemu Windows otrzymywali stronę stylizowaną na mechanizm bezpieczeństwa lub weryfikacji dostępu. W rzeczywistości był to wariant techniki ClickFix, która nie opiera się na klasycznym exploit chain, lecz na socjotechnice. Ofiara widzi komunikat o rzekomym problemie, po czym otrzymuje instrukcję skopiowania i uruchomienia polecenia w oknie „Uruchom”, PowerShellu lub terminalu.

W analizowanym przypadku mechanizm wykorzystywał również zatruwanie schowka, aby przygotować gotowy ciąg poleceń do wklejenia. Taki model bywa skuteczny, ponieważ część zabezpieczeń nie blokuje działań inicjowanych formalnie przez użytkownika. Z perspektywy obrony oznacza to, że klasyczne podejście oparte wyłącznie na detekcji exploita może okazać się niewystarczające.

Dodatkowe ryzyko dotyczy agentów AI i automatyzacji. Jeśli dokumentacja, opis narzędzia, konfiguracja lub endpoint referencyjny wskazuje na niekontrolowaną domenę placeholder, agent może potraktować ją jako wiarygodny zasób. W konsekwencji może pobrać spreparowane instrukcje, wykonać niepożądane akcje lub wejść w interakcję z infrastrukturą atakującego.

Konsekwencje / ryzyko

Najbardziej oczywistym skutkiem jest możliwość dostarczenia złośliwego kodu lub skryptu inicjującego dalsze etapy kompromitacji stacji roboczej. Jeśli użytkownik zaufa instrukcji i uruchomi polecenie, atak może doprowadzić do pobrania kolejnego ładunku, kradzieży danych, ustanowienia trwałości lub ruchu lateralnego w sieci firmowej.

Drugim zagrożeniem jest skażenie zaufanych artefaktów technicznych. Dokumentacja, tutoriale, przykłady kodu i konfiguracje są często kopiowane między projektami bez pełnego przeglądu bezpieczeństwa. Jedna pozornie niewinna domena może więc rozprzestrzenić się do setek lub tysięcy lokalizacji.

Trzeci problem stanowi zawodność prostych metod detekcji. Jeżeli złośliwa treść jest serwowana warunkowo, statyczne skany, pojedyncze wejście na stronę albo podstawowa analiza reputacyjna mogą nie odtworzyć doświadczenia właściwej ofiary. Atakujący może różnicować odpowiedzi według systemu operacyjnego, nagłówków HTTP, lokalizacji czy pory dnia.

W środowiskach wykorzystujących LLM, agentów i narzędzia integracyjne dochodzi jeszcze ryzyko pośredniej manipulacji. Model lub agent może uznać spreparowany adres za prawidłowy element dokumentacji, co otwiera drogę do pobierania nieautoryzowanych treści, wykonywania błędnych czynności i kontaktu z wrogą infrastrukturą bez klasycznego włamania do repozytorium.

Rekomendacje

Podstawowym krokiem powinien być audyt dokumentacji, repozytoriów kodu, wiki, materiałów szkoleniowych i plików testowych pod kątem domen, które wyglądają jak placeholder, ale nie są formalnie zarezerwowane. Warto objąć kontrolą także prompty, opisy narzędzi, definicje endpointów i przykłady integracyjne.

Stosować wyłącznie bezpieczne, zarezerwowane domeny demonstracyjne.
Blokować użycie realistycznie brzmiących nazw, jeśli organizacja ich nie kontroluje.
Wdrożyć reguły linterów i skanerów wykrywających ryzykowne domeny w commitach i pipeline’ach CI/CD.
Monitorować odniesienia do takich adresów w publicznych i prywatnych repozytoriach.
Prowadzić okresowe testy rozwiązywania DNS dla domen występujących w treściach technicznych.
Stosować egress filtering oraz kontrolowane otwieranie linków z dokumentacji.

Od strony użytkownika końcowego kluczowa pozostaje edukacja dotycząca techniki ClickFix. Pracownicy powinni wiedzieć, że wiarygodne serwisy praktycznie nigdy nie wymagają ręcznego kopiowania poleceń do PowerShella, terminala czy okna „Uruchom” w celu naprawy dostępu do strony.

W środowiskach opartych na agentach AI należy ograniczać automatyczne podążanie za linkami z niezweryfikowanej dokumentacji oraz stosować listy dozwolonych domen dla połączeń zewnętrznych. Dobrą praktyką jest także logowanie i analiza domen, do których odwołują się agenci podczas realizacji zadań.

Podsumowanie

Przejęcie niezastrzeżonej domeny placeholder i wykorzystanie jej do dystrybucji złośliwej treści pokazuje, że nawet drobny element dokumentacji może stać się pełnoprawnym wektorem ataku. Problem dotyczy użytkowników końcowych, zespołów developerskich, repozytoriów kodu, procesów automatyzacji oraz agentów AI.

Najważniejszy wniosek jest prosty: przykładowe domeny należy traktować jako element powierzchni ataku. Jeśli organizacja nie kontroluje danej nazwy albo nie jest ona formalnie zarezerwowana, nie powinna pojawiać się w dokumentacji, przykładach ani materiałach referencyjnych.

Źródła

The Hacker News — https://thehackernews.com/2026/09/placeholder-third-partycom-referenced.html
IANA — Example Domains — https://www.iana.org/help/example-domains
VirusTotal — https://www.virustotal.com/
Google Transparency Report / Safe Browsing — https://transparencyreport.google.com/safe-browsing/search
Manifold Security — https://www.manifold.security/

Sieć serwerów relay ukrywających dostęp do czołowych modeli AI nowym wyzwaniem dla cyberbezpieczeństwa

Wprowadzenie do problemu / definicja

Rosnące znaczenie zaawansowanych modeli sztucznej inteligencji sprawia, że wokół nich powstaje nowa klasa zagrożeń. Jednym z najważniejszych zjawisk są serwery relay, czyli pośredniczące bramy komunikacyjne ukrywające rzeczywiste źródło zapytań kierowanych do dostawców modeli AI. Taka infrastruktura utrudnia identyfikację użytkowników końcowych, maskuje lokalizację operatorów i osłabia skuteczność mechanizmów bezpieczeństwa, takich jak limity użycia, geofencing czy analiza nadużyć.

Problem nie sprowadza się wyłącznie do obchodzenia zasad korzystania z usług. W praktyce relay’e mogą wspierać współdzielenie poświadczeń, odsprzedaż dostępu do modeli, a także masowe pozyskiwanie odpowiedzi generowanych przez systemy AI. To z kolei otwiera drogę do ekstrakcji wiedzy i trenowania tańszych modeli na podstawie wyników uzyskanych z bardziej zaawansowanych platform.

W skrócie

Badacze opisali infrastrukturę obejmującą ponad 80 tys. serwerów relay używanych do pośredniego dostępu do czołowych modeli AI.
Serwery te maskują tożsamość użytkowników, utrudniają egzekwowanie polityk bezpieczeństwa i mogą wspierać handel poświadczeniami.
Zaobserwowane wzorce ruchu sugerują możliwe wykorzystanie tej infrastruktury do destylacji modeli i przemysłowej ekstrakcji odpowiedzi.
Zjawisko stanowi ryzyko zarówno dla dostawców AI, jak i organizacji przesyłających dane przez nieautoryzowane bramy pośredniczące.

Kontekst / historia

Temat bezpieczeństwa generatywnej AI w ostatnim czasie wyraźnie przesunął się z obszaru teoretycznych zagrożeń do praktycznych problemów operacyjnych. Coraz większą uwagę zwraca się nie tylko na jailbreaki, nadużycia kont czy wycieki danych, ale również na zorganizowane sposoby obchodzenia ograniczeń nakładanych przez dostawców modeli. Relay’e wpisują się właśnie w ten szerszy trend.

Ich rola przypomina znane z klasycznego cyberbezpieczeństwa proxy, brokerów dostępu oraz warstwy pośredniczące służące do ukrywania atrybucji. Różnica polega na celu operacyjnym. W przypadku usług AI nie chodzi jedynie o anonimowość, lecz także o skalowanie dostępu do zewnętrznych modeli, agregowanie poświadczeń oraz upraszczanie masowego wykorzystania zasobów przez wielu użytkowników jednocześnie.

W tle pojawia się również kwestia własności intelektualnej i przewagi technologicznej. Jeśli odpowiedzi zaawansowanych modeli są pozyskiwane hurtowo i wykorzystywane jako materiał do szkolenia słabszych odpowiedników, problem przestaje być wyłącznie naruszeniem regulaminu. Staje się zagadnieniem o znaczeniu strategicznym dla firm rozwijających systemy frontier AI oraz dla szeroko rozumianego bezpieczeństwa gospodarczego.

Analiza techniczna

Serwer relay działa jako warstwa pośrednia między użytkownikiem a usługą AI. Klient nie komunikuje się bezpośrednio z interfejsem API lub kontem subskrypcyjnym dostawcy modelu. Zamiast tego wysyła żądanie do pośrednika, który przekazuje je dalej przy użyciu własnego adresu IP, własnych tokenów lub zalogowanych kont upstream. W efekcie operator modelu widzi przede wszystkim ruch wychodzący z infrastruktury relay, a nie prawdziwego nadawcę zapytania.

Taki schemat działania podważa podstawowe założenia kontroli bezpieczeństwa. Mechanizmy rate limiting, rozliczanie wykorzystania, analiza anomalii, geolokalizacja oraz wykrywanie nadużyć są zwykle powiązane z kontem, kluczem API i źródłowym adresem IP. Jeżeli wielu użytkowników korzysta z jednego wspólnego punktu pośredniczącego, a ruch jest rozpraszany między wieloma kontami i węzłami, precyzyjna atrybucja staje się znacznie trudniejsza.

W opisywanym przypadku badacze wskazali na rozległą infrastrukturę przekaźnikową obsługującą dostęp do modeli rozwijanych przez czołowych zachodnich dostawców AI. Zwrócono też uwagę na intensywny ruch pochodzący z adresów IP powiązanych z Chinami i Hongkongiem do klastrów serwerów utrzymywanych u amerykańskich dostawców VPS. W krótkim okresie obserwacyjnym wolumen transmisji miał sięgać dziesiątek terabajtów, co wskazuje na zautomatyzowany i wysokoskalowy charakter operacji.

Istotny jest również profil ruchu. Badacze odnotowali dużą ilość danych wejściowych przy relatywnie niewielkiej objętości odpowiedzi. Taki stosunek uploadu do downloadu może odpowiadać scenariuszowi masowego zadawania pytań modelom w celu budowy zbiorów odpowiedzi, testowania zachowań systemów lub porównywania rezultatów wielu modeli. Sam wzorzec nie stanowi jeszcze dowodu konkretnej operacji, ale jest spójny z procesami destylacji modeli i ekstrakcji wiedzy.

Na uwagę zasługuje także warstwa narzędziowa. W raporcie wymieniono projekty open source, takie jak Claude Relay Service oraz jego nowszy następca sub2api, które mogą stanowić fundament dla takich bram. To rozwiązania oferujące nie tylko proste przekazywanie ruchu, ale również zarządzanie użytkownikami, mapowanie subskrypcji na interfejsy API, rozliczenia per użytkownik, audyt promptów i centralne zarządzanie wieloma kontami upstream. Oznacza to, że relay może działać jak pełnoprawna platforma usługowa, a nie tylko zwykłe reverse proxy.

Konsekwencje / ryzyko

Dla dostawców modeli AI najważniejsze ryzyko to utrata kontroli nad tym, kto faktycznie korzysta z usługi i z jakiej lokalizacji. Taka infrastruktura utrudnia egzekwowanie ograniczeń regionalnych, polityk eksportowych oraz warunków licencyjnych. Jednocześnie sprzyja współdzieleniu poświadczeń i nadużyciom abonamentowym, co przekłada się na straty finansowe oraz osłabienie skuteczności zabezpieczeń.

Jeszcze poważniejsze mogą być skutki związane z masową ekstrakcją odpowiedzi modeli. Jeżeli zaawansowane systemy są wykorzystywane jako źródło wiedzy dla trenowania tańszych i słabszych alternatyw, firmy rozwijające frontier AI tracą część przewagi technologicznej. W praktyce relay’e mogą więc odgrywać rolę infrastruktury wspierającej nieautoryzowane pozyskiwanie wartości intelektualnej na skalę przemysłową.

Z perspektywy przedsiębiorstw korzystających z zewnętrznych modeli zagrożenie jest jeszcze szersze. Operator relay’a może mieć dostęp do promptów, danych wejściowych, odpowiedzi modelu, metadanych użycia, a nawet informacji rozliczeniowych. Korzystanie z niezweryfikowanych pośredników zwiększa ryzyko wycieku danych, utraty poufności, kradzieży własności intelektualnej oraz naruszeń zgodności regulacyjnej.

Istnieje też wymiar systemowy. Jeśli relay’e staną się powszechną warstwą dostępu do modeli AI w szarej strefie, dostawcy usług będą zmuszeni do wdrażania bardziej agresywnych mechanizmów kontroli. To może oznaczać większą liczbę fałszywych alarmów, wzrost kosztów operacyjnych bezpieczeństwa oraz silniejsze wiązanie kont z tożsamością użytkowników. Skutki odczują wtedy również legalni klienci.

Rekomendacje

Dostawcy modeli AI powinni traktować infrastrukturę relay jako osobną kategorię nadużyć i uwzględnić ją w systemach detekcji. Kluczowe znaczenie ma korelacja sygnałów z wielu warstw, obejmujących reputację IP, geograficzne wzorce użycia, powiązania między kontami, charakterystyki sesji oraz relacje między wolumenem danych wejściowych i wyjściowych.

wdrażanie silniejszego wiązania kont API z organizacją, urządzeniem i profilem behawioralnym użytkownika,
wykrywanie współdzielenia poświadczeń przez wiele niespójnych profili,
identyfikacja znanych węzłów relay i analiza łańcuchów pośredniczących,
stosowanie adaptacyjnych limitów szybkości dla ruchu wysokiego ryzyka,
monitorowanie wzorców sugerujących masową ekstrakcję odpowiedzi modeli,
segmentacja dostępu do najbardziej wrażliwych funkcji i modeli.

Organizacje korzystające z zewnętrznych usług AI powinny unikać nieautoryzowanych bram pośredniczących. Jeżeli użycie pośrednika jest uzasadnione biznesowo, konieczne stają się: ocena ryzyka dostawcy, przegląd architektury przetwarzania danych, weryfikacja retencji logów, kontrola lokalizacji przetwarzania, szyfrowanie oraz jednoznaczne zapisy umowne dotyczące poufności i dalszego wykorzystania danych.

Dla zespołów SOC i threat intelligence oznacza to potrzebę rozszerzenia monitoringu o wskaźniki nadużyć związanych z usługami AI. W praktyce warto analizować zarówno połączenia wychodzące do podejrzanych bram, jak i nieautoryzowane użycie firmowych kont w zewnętrznych platformach sztucznej inteligencji. Ważna będzie również współpraca pomiędzy dostawcami chmury, operatorami usług i podmiotami analizującymi ruch sieciowy.

Podsumowanie

Wykrycie rozległej sieci serwerów relay używanych do pośredniego dostępu do zaawansowanych modeli AI pokazuje, że bezpieczeństwo generatywnej sztucznej inteligencji coraz bardziej przypomina klasyczne pole walki cybernetycznej. Kluczowe znaczenie mają dziś ukrywanie atrybucji, nadużywanie poświadczeń, obchodzenie kontroli regionalnych oraz automatyzacja dostępu na dużą skalę.

Dla rynku oznacza to konieczność rozwijania nowych metod obrony, które będą wymierzone nie tylko w pojedynczych użytkowników końcowych, ale także w całe warstwy infrastruktury pośredniczącej. Relay’e dla modeli AI mogą w najbliższym czasie stać się jednym z najważniejszych obszarów monitorowania w cyberbezpieczeństwie usług opartych na LLM.

Źródła

https://www.darkreading.com/cyber-risk/relays-masking-chinese-access-frontier-ai-models
https://www.team-cymru.com/post/llm-gateway-frontier-model-abuse
https://www.cisa.gov/news-events/news/cisa-nsa-and-fbi-warn-china-based-ai-companies-targeting-us-ai-models-industrial-scale-knowledge
https://arstechnica.com/tech-policy/2026/09/six-chinese-ai-firms-accused-of-aggressively-copying-us-frontier-models/

Agenci AI zmieniają zasady ruchu bocznego w środowiskach IT

Wprowadzenie do problemu / definicja

Ruch boczny od lat pozostaje jednym z najważniejszych etapów nowoczesnych ataków na środowiska firmowe. Klasycznie oznacza przemieszczanie się napastnika pomiędzy systemami, kontami i strefami zaufania po uzyskaniu początkowego dostępu. Wraz z upowszechnieniem agentów AI zagrożenie to nabiera jednak nowego znaczenia, ponieważ autonomiczne systemy mogą samodzielnie analizować dostępne ścieżki, łączyć uprawnienia i wykonywać kolejne kroki bez bieżącej ingerencji człowieka.

To sprawia, że ocena ryzyka nie może już opierać się wyłącznie na pytaniu, do czego dany byt ma bezpośredni dostęp. Coraz istotniejsze staje się ustalenie, jakie pośrednie ścieżki może odkryć i wykorzystać agent działający z określonym celem biznesowym, zestawem narzędzi oraz przypisanymi tożsamościami.

W skrócie

Agenci AI zmieniają model zagrożeń, ponieważ łączą szeroki zakres dostępu z wysokim poziomem autonomii. Nawet pozornie uzasadnione uprawnienia mogą zostać zestawione w nieoczywisty łańcuch eskalacji, prowadzący do systemów, do których agent formalnie nie powinien mieć dostępu.

Ryzyko wynika nie tylko z poziomu uprawnień, ale również z możliwości samodzielnej eksploracji środowiska.
Bezpośrednie uprawnienia nie pokazują pełnego zasięgu operacyjnego agenta.
Klasyczne mechanizmy detekcji mogą mylić legalną automatyzację z aktywnością przypominającą atak.
Kluczowe znaczenie zyskują zarządzanie tożsamością, kontrola sekretów i analiza pełnych łańcuchów dostępu.

Kontekst / historia

W ostatnich latach organizacje zaczęły intensywnie wdrażać agentowe systemy AI do automatyzacji procesów biznesowych, operacyjnych i deweloperskich. W przeciwieństwie do tradycyjnych aplikacji, które działają według z góry zdefiniowanych reguł, agenci są projektowani tak, aby samodzielnie wybierać ścieżki prowadzące do realizacji celu. To zwiększa ich użyteczność, ale jednocześnie rozszerza powierzchnię ataku.

Obserwowany trend pokazuje, że bezpieczeństwa agentów nie da się analizować wyłącznie przez pryzmat pojedynczych uprawnień. Problemem staje się ich zdolność do odkrywania tras, których administratorzy nie zaplanowali wprost. Dodatkowo wiele środowisk nadal opiera działania agentów na statycznych poświadczeniach, a część wdrożonych rozwiązań pozostaje nieużywana, choć nadal aktywna. To sprzyja kumulacji ryzyka i utrudnia realną ocenę ekspozycji organizacji.

Analiza techniczna

Od strony technicznej agent AI działa jak wytrwały operator automatyczny, który może wykonywać ogromną liczbę prób, iteracji i testów zależności. Jeżeli ma dostęp do kilku narzędzi, tokenów, sekretów lub usług pośrednich, może łączyć je w kolejne scenariusze, odrzucać nieskuteczne warianty i wracać do wcześniej odkrytych punktów zaczepienia. Taki model działania przypomina automatyczne przeszukiwanie grafu zależności w obszarze tożsamości i uprawnień.

Najważniejsza zmiana polega na tym, że formalne uprawnienia agenta nie odzwierciedlają jego rzeczywistego zasięgu. Agent może rozpocząć od legalnego dostępu do jednego systemu, następnie odnaleźć sekret należący do innej tożsamości nieosobowej, przejąć bardziej uprzywilejowaną rolę i wykorzystać ją do wejścia do kolejnego środowiska. W ten sposób powstaje wieloetapowy łańcuch dostępu, który nie jest widoczny podczas prostego przeglądu pojedynczych kont czy integracji.

Przykładowo agent wspierający proces sprzedażowy może mieć poprawnie nadany dostęp do systemu CRM, ale jednocześnie dysponować zbyt szerokimi uprawnieniami do platformy deweloperskiej lub chmurowej. Jeżeli w tej drugiej lokalizacji znajdzie poświadczenie innej tożsamości usługowej, może przejść dalej do hurtowni danych, systemu administracyjnego albo zasobów operacyjnych. Z perspektywy grafu uprawnień bezpośredni dostęp do celu końcowego nie jest konieczny, jeśli agent potrafi ułożyć skuteczny ciąg pośrednich kroków.

Dodatkowym wyzwaniem pozostaje telemetria. Klasyczne systemy detekcji często uznają przechodzenie między usługami, pobieranie sekretów lub przyjmowanie nowych ról za symptomy kompromitacji. W przypadku agentów AI podobne działania mogą jednak stanowić element normalnej realizacji zadania. Dlatego sama obserwacja ruchu między systemami przestaje wystarczać i musi zostać uzupełniona o kontekst biznesowy, tożsamościowy i operacyjny.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem jest wzrost rzeczywistego promienia oddziaływania pojedynczego komponentu AI. Organizacja może zakładać, że agent działa w ograniczonym zakresie, podczas gdy w praktyce jest on w stanie osiągnąć znacznie więcej poprzez łańcuch zależności tożsamościowych, integracyjnych i sekretowych.

eskalacja uprawnień przez przejęcie pośrednich tożsamości,
nieautoryzowany dostęp do danych wrażliwych,
przekraczanie granic między strefami zaufania,
nadużycie nieużywanych lub osieroconych agentów,
trudność w odróżnieniu legalnej automatyzacji od aktywności zbliżonej do działań intruza.

Szczególnie narażone są środowiska chmurowe, repozytoria kodu, klastry Kubernetes, systemy CI/CD oraz magazyny sekretów. W takich obszarach pojedynczy błąd w delegowaniu dostępu może zostać przez agenta wykorzystany jako etap przejściowy do znacznie cenniejszych zasobów.

Rekomendacje

Organizacje wdrażające agentów AI powinny traktować tożsamość jako główną warstwę kontroli bezpieczeństwa. Każdy agent powinien mieć jednoznacznie określony cel, właściciela biznesowego oraz minimalny zestaw uprawnień dopasowany do rzeczywistej funkcji. Niezbędne staje się także mapowanie pełnego łańcucha dostępu, a nie tylko bezpośrednich integracji.

zinwentaryzować wszystkich agentów AI, również tych uruchamianych poza formalnym procesem IT,
przypisać odpowiedzialność za każdego agenta konkretnej osobie lub zespołowi,
analizować zależności agent → tożsamość → narzędzie → sekret → zasób,
porównywać rzeczywiste możliwości agenta z jego uzasadnionym celem biznesowym,
ograniczać uprawnienia do minimum i regularnie je korygować,
usuwać nieużywane poświadczenia, integracje i porzucone wdrożenia,
traktować współdzielone cache, repozytoria i magistrale komunikacyjne jako granice zaufania wymagające dodatkowych zabezpieczeń,
rozwijać mechanizmy detekcji uwzględniające kontekst intencji, a nie wyłącznie sam fakt przemieszczania się między systemami.

Warto również pamiętać, że zabezpieczenia na poziomie promptów i filtrów odpowiedzi nie rozwiązują problemu ruchu bocznego. Mogą ograniczać część ryzyk związanych z wejściem i wyjściem modelu, ale nie kontrolują tego, do jakich systemów agent jest w stanie realnie dotrzeć przy użyciu dostępnych tożsamości, narzędzi i sekretów.

Podsumowanie

Agenci AI wprowadzają jakościową zmianę w obszarze ruchu bocznego. Kluczowe staje się nie tylko to, jakie uprawnienia posiada dany byt, ale przede wszystkim to, jakie ścieżki potrafi autonomicznie odkryć i wykorzystać. W efekcie bezpieczeństwo agentów wymaga podejścia opartego na zarządzaniu tożsamością, analizie intencji oraz ciągłym monitorowaniu pełnych łańcuchów dostępu.

Firmy, które nie zbudują takiej widoczności, mogą zbyt późno zrozumieć realny zasięg swoich agentów i dopiero po incydencie odkryć, że legalna automatyzacja stała się narzędziem do nieplanowanego przekraczania granic zaufania.

Źródła

AI Agents Are Rewriting the Rules of Lateral Movement — https://thehackernews.com/2026/09/ai-agents-are-rewriting-rules-of.html
OWASP Top 10 for LLM Applications and Agentic AI — https://genai.owasp.org/
Hugging Face Technical Postmortem — https://huggingface.co/
METR Research — https://metr.org/
Token Security — Agentic Pulse — https://www.token.security/

Sieć serwerów relay ukrywa dostęp do czołowych modeli AI i osłabia mechanizmy kontroli

Wprowadzenie do problemu / definicja

Rosnąca popularność zaawansowanych modeli AI doprowadziła do pojawienia się nowej klasy ryzyka z obszaru cyberbezpieczeństwa. Chodzi o serwery relay, czyli infrastrukturę pośredniczącą, która ukrywa rzeczywiste źródło zapytań kierowanych do dostawców modeli językowych i utrudnia identyfikację końcowego użytkownika.

W praktyce taka warstwa pośrednia osłabia skuteczność kontroli opartych na geolokalizacji, reputacji adresów IP, limitach API oraz mechanizmach wykrywania nadużyć. Problem przestaje więc dotyczyć wyłącznie dostępu technicznego do modelu, a zaczyna obejmować także egzekwowanie polityk bezpieczeństwa, zgodności i licencjonowania.

W skrócie

Badacze opisali rozległą sieć ponad 80 tys. serwerów relay wykorzystywanych do pośredniczenia w dostępie do czołowych modeli AI. Infrastruktura ta może służyć do ukrywania lokalizacji i tożsamości użytkowników, współdzielenia kont, omijania ograniczeń regionalnych oraz obchodzenia mechanizmów kontroli stosowanych przez dostawców usług.

Analiza ruchu wskazuje również, że podobne kanały mogą być używane do masowego pozyskiwania odpowiedzi generowanych przez modele. Taki scenariusz budzi obawy o destylację modeli, czyli trenowanie tańszych systemów na podstawie wyników uzyskanych z bardziej zaawansowanych platform.

Kontekst / historia

Nadużywanie infrastruktury pośredniczącej nie jest zjawiskiem nowym, jednak w świecie AI zyskało szczególne znaczenie wraz z komercjalizacją modeli o wysokiej wartości technologicznej. Dostęp do części usług bywa ograniczony regionalnie, objęty dodatkowymi warunkami licencyjnymi lub chroniony przez limity i systemy antyabuse.

To właśnie dlatego relaye stały się atrakcyjnym narzędziem dla podmiotów, które chcą ominąć blokady albo zaoferować dostęp do zagranicznych modeli jako usługę. Według analiz nie mamy już do czynienia z pojedynczymi obejściami zabezpieczeń, lecz z rozbudowanym ekosystemem pośredników, działających w skali przemysłowej.

W opisywanym przypadku skala zjawiska wzrosła od kilkunastu tysięcy wykrytych punktów pośredniczących do ponad 80 tysięcy relayów. Taki wzrost pokazuje, że infrastruktura dostępu do modeli AI staje się osobnym obszarem ryzyka wymagającym monitorowania podobnego do klasycznych zagrożeń sieciowych i API.

Analiza techniczna

Serwer relay działa jako pośrednik pomiędzy klientem a właściwym dostawcą modelu. To on zestawia połączenie, przekazuje żądanie dalej i odbiera odpowiedź, przez co dostawca widzi adres IP przekaźnika oraz jego dane uwierzytelniające, a nie prawdziwego użytkownika końcowego.

Taki model działania przełamuje podstawowe założenia wielu systemów kontroli. Konto wysyłające zapytanie nie musi być bowiem tym samym podmiotem, który faktycznie konsumuje odpowiedź. W efekcie operator relay może agregować wiele kont lub kluczy API, rozdzielać ruch pomiędzy użytkowników i dynamicznie zmieniać ścieżki routingu, aby utrudnić blokowanie aktywności.

Badacze zwrócili uwagę na intensywny profil ruchu związany z tą infrastrukturą. W krótkim czasie tysiące adresów IP miały komunikować się z klastrem relayów hostowanych u amerykańskich dostawców VPS, a wolumen przesyłanych danych liczony był w terabajtach. Taki wzorzec może wskazywać nie tylko na obchodzenie kontroli dostępu, ale też na automatyzację na dużą skalę.

Z perspektywy bezpieczeństwa AI szczególnie ważny jest wątek destylacji modeli. Jeżeli zewnętrzny podmiot jest w stanie seryjnie wysyłać ogromne liczby zapytań i gromadzić odpowiedzi modelu granicznego, może wykorzystać te dane jako zbiór referencyjny do budowy tańszego systemu o zbliżonych kompetencjach w wybranych zadaniach.

Istotne jest również to, że do budowy takich bram wykorzystywane są narzędzia open source oferujące funkcje zarządzania użytkownikami, rozliczeń, audytu promptów czy łączenia wielu kont upstreamowych w jeden wspólny interfejs. To sygnał, że relay AI przestaje być improwizowanym proxy, a staje się dojrzałą warstwą middleware gotową do komercyjnego wdrożenia.

Konsekwencje / ryzyko

Dla dostawców modeli AI oznacza to utratę części widoczności telemetrycznej i słabszą możliwość przypisywania aktywności do konkretnych podmiotów. W praktyce trudniej wykrywać nadużycia, obchodzenie limitów, zautomatyzowane kampanie czy próby pozyskiwania dużych wolumenów odpowiedzi do dalszego wykorzystania.

Ryzyko dotyczy także organizacji korzystających z zewnętrznych modeli. Jeśli pracownicy, partnerzy lub nieautoryzowane integracje przesyłają prompty przez prywatne bramy pośredniczące, firma może stracić kontrolę nad tym, gdzie trafiają dane wejściowe i wyniki generowane przez model.

To z kolei otwiera drogę do wycieku informacji, naruszeń zgodności oraz obchodzenia wewnętrznych polityk bezpieczeństwa. W szerszym ujęciu problem ma również wymiar rynkowy, ponieważ może wpływać na ochronę własności intelektualnej, egzekwowanie licencji i uczciwość konkurencji technologicznej.

Rekomendacje

Dostawcy AI powinni rozwijać mechanizmy wykrywania zachowań typowych dla relayów. Chodzi przede wszystkim o analizę anomalii topologicznych, współdzielenia kont, nietypowych wolumenów ruchu, reputacji infrastruktury VPS oraz rozbieżności między profilem użytkownika a pochodzeniem sesji.

Ważne jest również wzmocnienie modelu uwierzytelniania i autoryzacji. Pomóc mogą silniejsze powiązanie kont z urządzeniami lub środowiskami, segmentacja poziomów dostępu, dokładniejsze monitorowanie wykorzystania API oraz adaptacyjne limity szybkości zależne od poziomu ryzyka.

blokowanie użycia nieautoryzowanych pośredników i prywatnych bram API,
monitorowanie ruchu wychodzącego do usług AI i dostawców VPS,
klasyfikowanie danych dopuszczonych do przesyłania w promptach,
wdrażanie polityk DLP dla integracji z modelami generatywnymi,
audyt rozszerzeń, wrapperów i narzędzi automatyzujących dostęp do LLM.

Zespoły SOC i threat intelligence powinny uwzględnić relaye AI w katalogu obserwowanych zagrożeń. Oznacza to analizę ruchu do nietypowych endpointów, identyfikację nieznanych brokerów dostępu oraz sprawdzanie, czy aktywność użytkowników nie wskazuje na obchodzenie zatwierdzonych kanałów korzystania z modeli.

Podsumowanie

Wykrycie dziesiątek tysięcy serwerów relay pośredniczących w dostępie do czołowych modeli AI pokazuje, że bezpieczeństwo generatywnej sztucznej inteligencji nie kończy się na samym modelu i filtrach treści. Coraz większe znaczenie ma kontrola warstwy dostępowej, integralność telemetrii oraz możliwość wiarygodnego przypisania aktywności do rzeczywistych użytkowników.

Dla rynku to sygnał wejścia w nową fazę rywalizacji pomiędzy dostawcami zaawansowanych modeli a podmiotami próbującymi ukryć źródło ruchu, obejść ograniczenia i wykorzystać wyniki modeli do dalszego trenowania. Relaye AI stają się tym samym problemem z pogranicza bezpieczeństwa aplikacyjnego, nadużyć API, ochrony własności intelektualnej i zarządzania ryzykiem w łańcuchu dostępu do usług AI.

Źródła

https://www.darkreading.com/cyber-risk/relays-masking-chinese-access-frontier-ai-models
https://www.team-cymru.com/
https://www.techtarget.com/