Archiwa: AI - Security Bez Tabu

Microsoft ostrzega przed wzrostem ataków z użyciem ACR Stealer

Wprowadzenie do problemu

ACR Stealer to złośliwe oprogramowanie typu infostealer, zaprojektowane do wykradania danych z urządzeń końcowych. Jego głównym celem są zapisane w przeglądarkach hasła, tokeny uwierzytelniające, ciasteczka sesyjne oraz dokumenty użytkowników, które mogą posłużyć do dalszych ataków na organizację.

Najnowsze obserwacje wskazują na wyraźny wzrost aktywności tej rodziny malware w środowiskach firmowych. Atakujący łączą socjotechnikę z wykorzystaniem natywnych narzędzi systemu Windows, co utrudnia wykrycie i zwiększa skuteczność kampanii.

W skrócie

Microsoft poinformował o nasileniu kampanii wykorzystujących ACR Stealer przeciwko klientom korporacyjnym. Aktywność była obserwowana od końca kwietnia do połowy czerwca 2026 roku i opierała się głównie na dwóch łańcuchach infekcji.

W obu wariantach ważną rolę odgrywała technika ClickFix, a także wykorzystanie WebDAV lub narzędzia MSHTA do uruchamiania silnie zaciemnionych skryptów PowerShell. Głównym celem operatorów pozostaje kradzież danych z przeglądarek, dokumentów biznesowych oraz plików z lokalnych i zsynchronizowanych katalogów użytkowników.

Kontekst i historia

ACR Stealer jest opisywany jako usługa malware-as-a-service, co oznacza, że jego twórcy mogą oferować narzędzie innym cyberprzestępcom w modelu abonamentowym lub partnerskim. Według dostępnych analiz istnieją przesłanki, że jest to rebranding wcześniej znanej rodziny Amatera Stealer.

Tego typu zmiany nazwy i infrastruktury są typowe dla współczesnego ekosystemu cyberprzestępczego. Utrudniają one korelację incydentów, spowalniają reakcję zespołów bezpieczeństwa i pozwalają operatorom malware szybciej odbudować działalność po ujawnieniu kampanii.

Kampanie powiązane z ACR Stealer wpisują się także w szerszy trend nadużywania legalnych komponentów systemowych. Zamiast klasycznych loaderów atakujący coraz częściej wykorzystują wbudowane narzędzia administracyjne i uruchamianie kodu w pamięci, aby ograniczyć liczbę artefaktów na dysku.

Analiza techniczna

Microsoft wskazał dwa najczęściej obserwowane łańcuchy dostarczenia ACR Stealer. Pierwszy rozpoczyna się od przynęty ClickFix, w której użytkownik jest nakłaniany do wykonania polecenia mającego rzekomo rozwiązać problem techniczny lub potwierdzić, że nie jest botem.

W praktyce takie działanie uruchamia zdalną bibliotekę DLL pobieraną z udziału WebDAV przy użyciu rundll32.exe. Atakujący konstruują ścieżki WebDAV tak, aby przypominały legalne zasoby, wykorzystując między innymi struktury katalogów oparte na identyfikatorach GUID.

Po nawiązaniu łączności z infrastrukturą kontrolowaną przez napastników wykonywany jest silnie zaciemniony skrypt PowerShell. Jego zadaniem jest uruchomienie instalatora malware, ustanowienie trwałości oraz przygotowanie środowiska do działania końcowego ładunku.

Mechanizmy persistence obejmują między innymi instalację dołączonego loadera w Pythonie, utworzenie zaplanowanego zadania podszywającego się pod aktualizację oprogramowania, manipulację znacznikami czasu oraz czyszczenie historii PowerShell. Ostatecznie ładunek jest wstrzykiwany do procesu systemowego i uruchamiany w pamięci.

Drugi łańcuch infekcji również wykorzystuje ClickFix, ale prowadzi do uruchomienia MSHTA, które pobiera złośliwą zawartość z serwera atakującego. Następnie wykonywany jest kolejny zaciemniony downloader PowerShell, a zaszyfrowany payload może zostać ukryty w publicznie hostowanym obrazie JPEG z użyciem steganografii.

Z punktu widzenia funkcjonalności ACR Stealer koncentruje się na przejęciu danych o wysokiej wartości:

haseł, cookies, tokenów i danych sesyjnych z przeglądarek,
danych chronionych przez DPAPI,
baz danych przeglądarek opartych na Chromium, takich jak Chrome i Edge,
dokumentów PDF oraz plików Microsoft 365,
plików z katalogów Pulpit i Pobrane,
danych z katalogów synchronizowanych z OneDrive i SharePoint.

Dodatkowo niektóre warianty wykorzystują publiczne usługi blockchain jako mechanizm dead-drop resolver do pobierania aktualnych lokalizacji payloadów lub adresów infrastruktury C2. Takie podejście zwiększa odporność zaplecza atakujących na blokowanie i utrudnia analizę ruchu.

Konsekwencje i ryzyko

Ryzyko związane z ACR Stealer wykracza daleko poza samą kradzież haseł. Pozyskane tokeny sesyjne, cookies i dane uwierzytelniające mogą umożliwić przejęcie aktywnych sesji bez konieczności ponownego logowania, a w niektórych scenariuszach także obejście części zabezpieczeń MFA.

Dla organizacji oznacza to możliwość szybkiej eskalacji incydentu od infekcji pojedynczej stacji roboczej do naruszenia usług chmurowych, repozytoriów dokumentów i zasobów współdzielonych. Szczególnie niebezpieczne jest ukierunkowanie na lokalnie zsynchronizowane katalogi OneDrive i SharePoint.

W praktyce może to prowadzić do wycieku dokumentacji projektowej, danych finansowych, materiałów HR, umów oraz informacji handlowych. Infostealer tego typu często stanowi etap wstępny przed sprzedażą dostępu, phishingiem wewnętrznym, oszustwami BEC lub wdrożeniem ransomware.

Dodatkowym problemem jest wykorzystanie legalnych narzędzi administracyjnych, takich jak PowerShell, MSHTA czy rundll32.exe. Bez dojrzałych mechanizmów detekcji behawioralnej odróżnienie aktywności złośliwej od administracyjnej może być bardzo trudne.

Rekomendacje

Organizacje powinny zacząć od ograniczenia skuteczności wektorów socjotechnicznych. Kluczowe jest szkolenie użytkowników, aby nie kopiowali i nie uruchamiali poleceń wyświetlanych przez fałszywe komunikaty, wyskakujące okna czy strony podszywające się pod mechanizmy weryfikacji.

Od strony technicznej warto wdrożyć następujące środki ochrony:

blokowanie lub ograniczanie uruchamiania mshta.exe, rundll32.exe, powershell.exe oraz interpreterów Python w kontekstach użytkownika, jeśli nie są niezbędne biznesowo,
stosowanie reguł Application Control oraz polityk WDAC lub AppLocker dla ścieżek zapisywalnych przez użytkownika i zasobów zdalnych,
filtrowanie ruchu do nowych, niskoreputacyjnych i nieuzasadnionych biznesowo domen,
monitorowanie dostępu do udziałów WebDAV oraz nietypowego pobierania bibliotek DLL z lokalizacji zdalnych,
wykrywanie tworzenia zaplanowanych zadań podszywających się pod aktualizacje,
analizę pamięci i telemetrii EDR pod kątem wstrzykiwania kodu do procesów systemowych,
audyt dostępu do danych przeglądarek Chromium i operacji na DPAPI,
wzmocnienie ochrony tożsamości, w tym skrócenie czasu życia sesji, wdrożenie odpornych na phishing metod MFA oraz monitorowanie tokenów.

Po wykryciu potencjalnej infekcji incydent należy traktować jako kompromitację danych uwierzytelniających, a nie wyłącznie obecność malware na urządzeniu. Oznacza to konieczność unieważnienia sesji, resetu haseł, przeglądu kont uprzywilejowanych oraz analizy możliwej eksfiltracji danych z usług Microsoft 365, OneDrive i SharePoint.

Podsumowanie

Wzrost aktywności ACR Stealer pokazuje, że infostealery pozostają jednymi z najbardziej opłacalnych i niebezpiecznych narzędzi cyberprzestępców. Skuteczność tej kampanii wynika z połączenia socjotechniki, nadużycia natywnych komponentów Windows, uruchamiania ładunku w pamięci oraz precyzyjnego wyboru danych o wysokiej wartości.

Dla zespołów bezpieczeństwa oznacza to konieczność jednoczesnego wzmacniania świadomości użytkowników, kontroli uruchamiania aplikacji, monitoringu behawioralnego oraz ochrony tożsamości i danych chmurowych. Organizacje, które zlekceważą zagrożenie ze strony infostealerów, ryzykują szybkie przejście od pojedynczej infekcji do pełnoskalowego incydentu naruszenia danych.

Źródła

Microsoft warns of surge in ACR Stealer attacks on customers — https://www.bleepingcomputer.com/news/security/microsoft-warns-of-surge-in-acr-stealer-attacks-on-customers/
Microsoft Security Blog — https://www.microsoft.com/en-us/security/blog/
Scaling cybercrime disruption through innovation and AI — https://blogs.microsoft.com/on-the-issues/2026/06/24/scaling-cybercrime-disruption-through-innovation-and-ai/

NadMesh atakuje publiczne usługi AI i kradnie klucze chmurowe oraz tokeny Kubernetes

Wprowadzenie do problemu / definicja

NadMesh to nowo wykryty botnet napisany w języku Go, który koncentruje się nie tylko na przejęciu zainfekowanego hosta, ale przede wszystkim na pozyskiwaniu poświadczeń, sekretów i tokenów umożliwiających dalszą kompromitację środowisk chmurowych oraz kontenerowych. Jego operatorzy aktywnie wyszukują publicznie wystawione usługi AI, narzędzia automatyzacji i interfejsy administracyjne, które mogą stanowić szybki punkt wejścia do cenniejszych zasobów.

To podejście pokazuje istotną zmianę w krajobrazie zagrożeń. Coraz częściej celem cyberprzestępców nie jest sama moc obliczeniowa maszyny, lecz dostęp do tożsamości infrastrukturalnej zapisanej w plikach konfiguracyjnych, zmiennych środowiskowych i tokenach serwisowych.

W skrócie

NadMesh skanuje internet w poszukiwaniu publicznie dostępnych usług AI i komponentów cloud-native.
Na celowniku znajdują się m.in. ComfyUI, Ollama, Open WebUI, Langflow, Gradio i n8n.
Malware zbiera sekrety z plików konfiguracyjnych, danych środowiskowych oraz konfiguracji AWS, Dockera i SSH.
Botnet wykorzystuje także otwarte Docker API, Jenkins Script Console, Redis, Telnet i SSH.
Największe ryzyko dotyczy organizacji, które nie segmentują środowisk i przechowują poświadczenia bez odpowiedniej ochrony.

Kontekst / historia

Aktywność NadMesh została zaobserwowana na początku lipca 2026 roku. Badacze opisali infrastrukturę operatora, która obejmuje własny panel zarządzania pokazujący liczbę infekcji, wdrożeń oraz pozyskanych poświadczeń. Choć dostępne dane telemetryczne nie są całkowicie spójne, wskazują na szeroko zakrojoną kampanię ukierunkowaną na środowiska AI i infrastrukturę cloud-native.

W odróżnieniu od wcześniejszych kampanii wymierzonych w publiczne narzędzia AI, NadMesh nie koncentruje się głównie na kopaniu kryptowalut czy wykorzystywaniu hostów jako proxy. Kluczową wartością są tutaj dane uwierzytelniające, które pozwalają przestępcom przenieść się z jednego serwera do chmury, klastra Kubernetes, rejestru kontenerów albo systemów CI/CD.

Analiza techniczna

Mechanizm działania NadMesh obejmuje kilka etapów: rekonesans, eksploatację, wdrożenie agenta, utrzymanie trwałości oraz eksfiltrację danych. Botnet dynamicznie priorytetyzuje adresy i podsieci, które wcześniej odpowiadały na zapytania, co oznacza, że raz wykryta ekspozycja może być ponownie testowana w krótkich odstępach czasu.

Szczególne zainteresowanie wzbudzają publicznie dostępne usługi AI wystawione bez właściwego uwierzytelnienia. Dotyczy to zarówno interfejsów webowych, jak i narzędzi zdalnego wykonywania funkcji. W analizach pojawia się również wątek ekosystemu MCP, gdzie błędnie skonfigurowane wdrożenia mogą zwiększać powierzchnię ataku i umożliwiać wykonywanie poleceń za pośrednictwem narzędzi zdalnych.

NadMesh nie opiera się na jednym wektorze ataku. W obserwowanej aktywności pojawiają się próby wykorzystania otwartego Docker API, konsoli skryptowej Jenkinsa, nieautoryzowanego Redis, słabych haseł Telnet i SSH oraz wybranych podatności w usługach wystawionych do internetu. W praktyce daje to operatorom dużą elastyczność i pozwala atakować zarówno środowiska eksperymentalne, jak i źle zabezpieczone systemy produkcyjne.

Po skutecznym dostępie malware przechodzi do etapu kradzieży poświadczeń. Na szczególną uwagę zasługują:

zmienne środowiskowe zawierające sekrety,
tokeny kont serwisowych Kubernetes,
pliki .env,
konfiguracje AWS,
dane logowania do rejestrów kontenerów,
pliki konfiguracyjne Dockera i SSH.

Opisane próbki stosują również wiele mechanizmów persistence jednocześnie. Oznacza to, że usunięcie pojedynczego komponentu nie musi prowadzić do pełnej eliminacji zagrożenia. Dodatkowo obfuskacja i pakowanie utrudniają wykrywanie oparte wyłącznie na hashach plików, przez co klasyczne wskaźniki IOC mogą mieć ograniczoną skuteczność.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem działania NadMesh jest możliwość przejścia z poziomu pojedynczego hosta do poziomu całego środowiska chmurowego lub klastra Kubernetes. Kradzież kluczy AWS może umożliwić tworzenie nowych zasobów, dostęp do magazynów danych, modyfikację konfiguracji i dalszą eskalację uprawnień. Przejęcie tokenów Kubernetes może otworzyć drogę do workloadów, sekretów, usług wewnętrznych i procesów CI/CD.

Ryzyko jest szczególnie wysokie w organizacjach, które:

udostępniają narzędzia AI bez warstwy uwierzytelnienia,
uruchamiają usługi deweloperskie bezpośrednio w internecie,
przechowują sekrety w plikach tekstowych i zmiennych środowiskowych,
nie oddzielają środowisk testowych od produkcyjnych,
nadają kontom serwisowym nadmiarowe uprawnienia.

Nawet jeśli zainfekowany host nie przetwarza danych krytycznych, może pełnić rolę pomostu do znacznie cenniejszych systemów. To klasyczny scenariusz kompromitacji pośredniej, w którym publicznie dostępne narzędzie AI staje się furtką do infrastruktury organizacji.

Rekomendacje

Podstawowym krokiem obronnym powinno być ograniczenie ekspozycji usług do internetu. Interfejsy takie jak ComfyUI, Ollama, Gradio, n8n, Docker API, Jenkins Script Console, Redis czy rclone RC nie powinny być publicznie osiągalne bez silnego uwierzytelnienia, filtrowania źródeł ruchu i odpowiedniej segmentacji sieciowej.

W praktyce warto wdrożyć następujące działania:

przeprowadzić inwentaryzację publicznie wystawionych usług AI i narzędzi administracyjnych,
wyłączyć bezpośrednią ekspozycję usług deweloperskich do internetu,
wymusić uwierzytelnienie i autoryzację dla wszystkich zdalnych interfejsów,
rotować oraz ograniczać zakres kluczy chmurowych i tokenów kont serwisowych,
usunąć sekrety z plików .env i przenieść je do menedżerów sekretów,
włączyć monitoring dostępu do plików konfiguracyjnych i katalogów użytkowników,
aktualizować podatne komponenty, w tym narzędzia AI i usługi pomocnicze,
monitorować nietypowe wywołania API chmurowych oraz działania w klastrach Kubernetes,
wdrożyć zasadę najmniejszych uprawnień dla kont serwisowych i workloadów.

W przypadku podejrzenia kompromitacji samo usunięcie pliku binarnego nie jest wystarczające. Należy odizolować host, zidentyfikować mechanizmy persistence, a następnie unieważnić wszystkie poświadczenia, do których system mógł mieć dostęp. Dopiero po pełnym oczyszczeniu środowiska należy wydawać nowe klucze i tokeny oraz przeanalizować historię ich użycia.

Dodatkowo warto aktywnie poszukiwać artefaktów kompromitacji, takich jak nieautoryzowane wpisy w authorized_keys, podejrzane zadania cron czy nietypowe pliki w katalogach tymczasowych i pamięci współdzielonej.

Podsumowanie

NadMesh pokazuje, że publicznie wystawione usługi AI stały się pełnoprawnym elementem współczesnej powierzchni ataku. W tym modelu działania najcenniejszym zasobem nie jest sam host, lecz zapisane na nim poświadczenia, tokeny i konfiguracje umożliwiające ruch boczny do chmury oraz środowisk kontenerowych.

Dla zespołów bezpieczeństwa oznacza to konieczność traktowania narzędzi AI, interfejsów automatyzacji i usług deweloperskich z taką samą rygorystyczną kontrolą jak systemów produkcyjnych. Największym zagrożeniem pozostaje bowiem nie pojedyncza podatność, lecz połączenie ekspozycji, słabego uwierzytelnienia i nadmiernych uprawnień.

Źródła

Ponad milion kampanii phishingowych wykorzystuje ukryty tekst do omijania filtrów AI

Wprowadzenie do problemu / definicja

Ukryty tekst w wiadomościach e-mail, określany często jako text salting, to technika polegająca na dodawaniu do treści wiadomości niewidocznych lub trudnych do zauważenia fragmentów tekstu, które mają zmylić mechanizmy analizy bezpieczeństwa. W praktyce atakujący modyfikują warstwę HTML i CSS wiadomości tak, aby silniki filtrowania — w tym systemy oparte na sztucznej inteligencji — interpretowały zawartość inaczej niż człowiek widzący finalny wygląd wiadomości w skrzynce odbiorczej.

W skrócie

Badacze zaobserwowali ponad milion phishingowych wiadomości stylizowanych na komunikację handlową, które od kwietnia wykorzystywały ukryty tekst do obchodzenia zabezpieczeń poczty. Kampanie bazowały na prostych przynętach, takich jak punkty lojalnościowe, nagrody czy karty podarunkowe, a ich skuteczność wynikała nie tyle z jakości socjotechniki, co z manipulacji treścią źródłową wiadomości. Problem dotyczy zarówno klasycznych bram bezpieczeństwa poczty, jak i nowszych mechanizmów analizy treści wspieranych przez modele językowe.

Kontekst / historia

Technika ukrywania lub „solenia” tekstu nie jest nowa. Przez lata była wykorzystywana do omijania filtrów antyspamowych opartych na prostych regułach i dopasowaniu słów kluczowych. Współcześnie wraca jednak w odświeżonej formie, ponieważ środowisko obronne zmieniło się szybciej niż same podstawy ataku.

Nowoczesne systemy ochrony poczty coraz częściej łączą klasyczne kontrole reputacyjne, analizę nagłówków, weryfikację domen nadawcy i mechanizmy uwierzytelniania z analizą semantyczną treści. To właśnie w tym obszarze pojawiła się nowa asymetria: napastnicy mogą automatycznie generować dużą liczbę wariantów wiadomości i modyfikacji kodu, podczas gdy systemy obronne nadal mają trudność z poprawnym odtworzeniem rzeczywistego znaczenia wiadomości ukrytego pod warstwą prezentacji.

W opisywanych kampaniach wykorzystywano wiadomości podszywające się pod znane marki detaliczne. Część z nich używała domen podobnych do legalnych, a część była wysyłana z przejętych, prawidłowo działających domen, co dodatkowo utrudniało detekcję na podstawie reputacji i sygnałów infrastrukturalnych.

Analiza techniczna

Sedno problemu polega na rozbieżności między tym, co widzi użytkownik, a tym, co analizuje system bezpieczeństwa. Bramy pocztowe i silniki klasyfikujące nie oceniają jedynie „obrazu” wiadomości. W pierwszej kolejności przetwarzają kod źródłowy, strukturę MIME, HTML, style oraz tekst możliwy do odczytu maszynowego.

Atakujący wstrzykują do wiadomości neutralne, nieszkodliwe fragmenty tekstu, które rozbijają wzorce charakterystyczne dla phishingu. Przykładowo słowa sugerujące presję czasową, nagrodę lub korzyść finansową mogą zostać przeplatane losowymi wyrazami albo dłuższymi, pozornie niegroźnymi akapitami. Dzięki temu model lub filtr oparty na analizie tekstu otrzymuje mniej jednoznaczny sygnał ryzyka.

Kluczowe jest jednak ukrycie tych fragmentów przed odbiorcą. W tym celu wykorzystywane są typowe techniki manipulacji warstwą prezentacji:

ustawienie rozmiaru czcionki na zero,
osadzenie tekstu w kontenerze o zerowej szerokości lub wysokości,
przesunięcie zawartości poza widoczny obszar ekranu,
ukrycie przewijania, aby użytkownik nie zauważył dodatkowej treści,
nakładanie kilku metod ukrywania jednocześnie, aby utrudnić ich automatyczne odtworzenie.

To właśnie wielowarstwowość techniki zwiększa jej skuteczność. Wiele narzędzi ochronnych potrafi wykrywać pojedyncze formy ukrytego tekstu, ale ma większy problem, gdy jedna wiadomość łączy kilka sposobów maskowania jednocześnie. Jeśli mechanizm „odwinie” tylko część treści, pozostałe elementy nadal mogą zaburzyć klasyfikację.

Dodatkowym czynnikiem wzmacniającym atak jest wykorzystanie modeli językowych przez przestępców. LLM-y pozwalają szybko generować warianty neutralnych wstawek tekstowych, modyfikować komunikaty phishingowe i automatycznie przygotowywać różne wersje kodu HTML. Oznacza to niższy koszt przygotowania kampanii i łatwiejsze testowanie, które kombinacje najlepiej przechodzą przez filtry.

Konsekwencje / ryzyko

Dla organizacji ryzyko jest wielowymiarowe. Po pierwsze, wzrasta prawdopodobieństwo dostarczenia phishingu bezpośrednio do skrzynki odbiorczej użytkownika, mimo wdrożonych zabezpieczeń pocztowych. Po drugie, kampanie tego typu obniżają skuteczność narzędzi, które zbyt mocno polegają na analizie semantycznej lub pojedynczych cechach wiadomości.

Najważniejsze konsekwencje praktyczne to:

wzrost skuteczności kampanii kradzieży danych uwierzytelniających,
większa ekspozycja użytkowników na fałszywe strony logowania i złośliwe linki,
ryzyko obejścia warstw detekcji opartych na AI,
trudniejsze dochodzenie i korelacja incydentów z powodu dużej zmienności treści wiadomości,
możliwość nadużycia legalnych lub przejętych domen, co osłabia wartość sygnałów reputacyjnych.

Szczególnie narażone są organizacje, które traktują wdrożenie „AI w ochronie poczty” jako zamiennik dla pełnej, wielowarstwowej architektury bezpieczeństwa. Sama obecność modeli analitycznych nie eliminuje problemu, jeśli system nie porównuje wersji widocznej dla użytkownika z pełną treścią techniczną wiadomości i nie analizuje relacji między nadawcą, linkami, zachowaniem oraz intencją wiadomości.

Rekomendacje

Z perspektywy operacyjnej obrona przed tego typu kampaniami wymaga podejścia wielowarstwowego.

Po stronie technologicznej warto:

wdrożyć analizę wiadomości opartą zarówno na renderowanej wersji treści, jak i na surowym HTML,
wykrywać anomalie związane z ukrytym tekstem, nietypowymi stylami CSS i elementami przesuwanymi poza ekran,
korelować analizę treści z reputacją domeny, historią nadawcy, autoryzacją wiadomości oraz oceną osadzonych linków,
uruchamiać sandboxing i dynamiczną analizę adresów URL z wiadomości o podwyższonym ryzyku,
monitorować nietypowy stosunek ilości tekstu ukrytego do tekstu widocznego.

Po stronie procesów bezpieczeństwa zalecane jest:

okresowe strojenie reguł SEG i silników detekcyjnych pod kątem technik text salting,
testowanie odporności środowiska za pomocą symulowanych kampanii phishingowych wykorzystujących ukryty tekst,
tworzenie detekcji w SIEM/XDR dla wiadomości zawierających podejrzane konstrukcje HTML i CSS,
uwzględnienie tej techniki w playbookach SOC oraz procedurach triage.

Po stronie użytkowników końcowych nadal istotne pozostają:

szkolenia rozpoznawania presji czasowej, obietnic nagród i nietypowych żądań kliknięcia,
promowanie zasady ograniczonego zaufania wobec wiadomości marketingowych i lojalnościowych,
zgłaszanie podejrzanych wiadomości nawet wtedy, gdy przeszły przez zabezpieczenia poczty.

Podsumowanie

Opisana kampania pokazuje, że skuteczne ataki phishingowe nie muszą być technicznie skomplikowane. Wystarczy umiejętne wykorzystanie różnicy między tym, co interpretuje system bezpieczeństwa, a tym, co widzi człowiek. Ukryty tekst pozostaje zaskakująco efektywnym sposobem omijania filtrów, także tych wspieranych przez sztuczną inteligencję.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że ochrona poczty nie może opierać się wyłącznie na słowach kluczowych, reputacji ani deklaratywnej „analizie AI”. Potrzebna jest pełna analiza kontekstu wiadomości, renderowania treści oraz intencji ataku. W przeciwnym razie nawet proste kampanie phishingowe będą nadal skutecznie trafiać do skrzynek odbiorczych.

Źródła

1M+ Emails Use Hidden Text to Dupe AI Security Filters — https://www.darkreading.com/threat-intelligence/1m-emails-hidden-text-dupe-ai-security-filters
Hidden text in emails: an old spam tactic that is now fooling AI-based detection — https://blog.barracuda.com/2026/07/15/hidden-text-in-emails-an-old-spam-tactic-that-is-now-fooling-ai-based-detection
Secure email gateway (SEG) — https://www.techtarget.com/searchsecurity/definition/secure-email-gateway
DomainKeys Identified Mail (DKIM) — https://www.techtarget.com/searchsecurity/definition/DomainKeys-Identified-Mail-DKIM

NadMesh: nowy botnet atakuje usługi AI, klucze chmurowe i tokeny Kubernetes

Wprowadzenie do problemu / definicja

NadMesh to nowo opisany botnet napisany w języku Go, którego operatorzy koncentrują się na przejmowaniu publicznie dostępnych usług AI, interfejsów administracyjnych oraz słabo zabezpieczonych elementów środowisk chmurowych i kontenerowych. W przeciwieństwie do klasycznych kampanii nastawionych głównie na DDoS lub cryptomining, NadMesh stawia na kradzież danych uwierzytelniających i sekretów infrastrukturalnych.

Najważniejszym celem atakujących są klucze dostępu do chmury, tokeny kont serwisowych Kubernetes, pliki konfiguracyjne oraz zmienne środowiskowe, które mogą otworzyć drogę do dalszej eskalacji uprawnień i poruszania się po infrastrukturze ofiary.

W skrócie

NadMesh aktywnie skanuje internet w poszukiwaniu eksponowanych usług AI i narzędzi DevOps.
Malware poluje na platformy takie jak ComfyUI, Ollama, n8n, Open WebUI, Langflow i Gradio.
Po uzyskaniu dostępu wykrada pliki .env, konfiguracje AWS i Dockera oraz tokeny Kubernetes.
Celem kampanii nie jest tylko przejęcie hosta, ale także uzyskanie dostępu do chmury, klastrów i procesów CI/CD.
Zagrożenie może prowadzić do trwałej kompromitacji środowiska i nadużyć finansowych.

Kontekst / historia

Botnet został opisany w lipcu 2026 roku, a jego nazwa pochodzi od identyfikatora widocznego w kodzie kontrolera. Dostępne analizy wskazują, że aktywność kampanii nasiliła się na początku lipca, kiedy zaobserwowano wzrost skanowania infrastruktury dostępnej z internetu oraz prób infekcji.

Kampania wpisuje się w rosnący trend ataków na szybko wdrażane narzędzia AI, środowiska eksperymentalne i komponenty DevOps, które trafiają do sieci bez odpowiedniego uwierzytelniania, segmentacji i kontroli dostępu. Problem dotyczy szczególnie usług uruchamianych tymczasowo, które z czasem zaczynają działać jak elementy produkcyjne.

Analiza techniczna

Mechanizm działania NadMesh opiera się na ciągłym skanowaniu internetu i zasilaniu kolejki celów informacjami o widocznych usługach. Botnet priorytetyzuje środowiska związane z AI, ale wykorzystuje również bardziej tradycyjne powierzchnie ataku, takie jak otwarty Docker API, Jenkins Script Console, niezabezpieczony Redis, słabe hasła do Telnetu i SSH oraz wybrane podatności umożliwiające zdalne wykonanie kodu.

Na szczególną uwagę zasługują wdrożenia oparte na MCP. W analizowanych przypadkach wskazano wykorzystanie wywołań typu tools/call do uruchamiania poleceń, co w nieprawidłowo zabezpieczonych środowiskach może prowadzić do wykonania kodu po stronie ofiary. To istotne ryzyko, ponieważ część serwerów MCP pozostaje publicznie dostępna i oferuje narzędzia zdolne do wykonywania komend systemowych.

Po skutecznym uzyskaniu dostępu malware koncentruje się na ekstrakcji materiału poświadczającego. Celem są między innymi:

klucze i profile AWS,
tokeny kont serwisowych Kubernetes,
sekrety zapisane w plikach .env,
dane logowania do rejestrów kontenerów,
konfiguracje Dockera,
dostęp do modeli i narzędzi wykonawczych powiązanych z usługami AI.

NadMesh wykazuje również cechy bardziej dojrzałego zaplecza operacyjnego. Obserwacje wskazują na adaptacyjne ponowne skanowanie podsieci, częstsze odpytywanie najbardziej obiecujących hostów, próby omijania potencjalnych honeypotów oraz równoległe utrzymywanie kilku wersji agenta. Dodatkowo próbki są zaciemniane i pakowane, co utrudnia ich wykrywanie wyłącznie na podstawie hashy.

W aktywności operatorów pojawiają się także próby wykorzystania podatności, w tym CVE-2026-39987 w Marimo, a także innych wektorów związanych z publicznie dostępnymi komponentami administracyjnymi. To pokazuje, że NadMesh nie jest prostym skanerem usług AI, lecz hybrydową platformą do kompromitacji hostów, wykradania sekretów i dalszej eksploatacji środowiska.

Konsekwencje / ryzyko

Największe zagrożenie związane z NadMesh wynika z faktu, że wartością dla atakującego nie jest sam serwer, lecz zasoby, do których ten serwer ma dostęp. Kradzież poświadczeń chmurowych i tokenów Kubernetes może umożliwić przejęcie znacznie szerszego fragmentu infrastruktury niż pojedynczy host.

przejęcie kont i zasobów w chmurze,
uruchamianie nowych workloadów przez atakującego,
dostęp do magazynów danych i sekretów,
pivoting do innych klastrów i środowisk,
kompromitację pipeline’ów CI/CD,
nadużycia finansowe związane z wykorzystaniem zasobów obliczeniowych ofiary.

W praktyce nawet pozornie niewielka ekspozycja usługi AI może stać się punktem wejścia do poważnego incydentu obejmującego konta chmurowe, środowiska kontenerowe i łańcuch dostaw oprogramowania. Co istotne, początkowa infekcja może być mniej zauważalna niż późniejsze użycie skradzionych poświadczeń.

Rekomendacje

Organizacje korzystające z narzędzi AI, platform orkiestracyjnych i rozwiązań DevOps powinny pilnie zweryfikować swoją ekspozycję na internet oraz sposób przechowywania sekretów. W przypadku NadMesh kluczowe znaczenie ma ograniczenie dostępności usług oraz szybka rotacja poświadczeń znajdujących się na narażonych hostach.

usunąć z publicznego internetu niezabezpieczone usługi ComfyUI, Ollama, Gradio, n8n, Open WebUI i podobne komponenty,
zablokować publiczny dostęp do Docker API, Jenkins Script Console, Redis oraz innych interfejsów administracyjnych bez silnego uwierzytelniania,
wymusić segmentację sieci oraz dostęp wyłącznie przez VPN, bastion host lub listy kontroli dostępu,
przeprowadzić inwentaryzację sekretów zapisanych w plikach .env, konfiguracjach AWS i Docker oraz tokenach serwisowych Kubernetes,
rotować i unieważniać wszystkie poświadczenia, które mogły znajdować się na potencjalnie naruszonych hostach,
sprawdzić mechanizmy persistence, zadania cron, katalogi tymczasowe i pliki authorized_keys,
wdrożyć monitoring aktywności w API chmurowych oraz działań kont serwisowych w Kubernetes,
rozszerzyć patch management o narzędzia AI, notebooki i usługi pomocnicze używane przez zespoły inżynierskie,
stosować zasadę najmniejszych uprawnień dla workloadów AI i usług wspierających,
ograniczyć możliwość wykonywania komend przez narzędzia MCP i wymusić pełne uwierzytelnianie oraz autoryzację.

Jeśli kompromitacja została potwierdzona, należy odizolować host, usunąć mechanizmy trwałości, unieważnić wszystkie poświadczenia dostępne z poziomu tego systemu, a następnie przeanalizować logi IAM, logi chmurowe i zdarzenia kontenerowe pod kątem dalszego wykorzystania skradzionych danych dostępowych.

Podsumowanie

NadMesh pokazuje wyraźną zmianę priorytetów po stronie operatorów botnetów. Coraz częściej nie chodzi już o samą moc obliczeniową przejętych urządzeń, lecz o dostęp do sekretów, tożsamości maszynowych i uprawnień chmurowych, które pozwalają przejmować kolejne warstwy infrastruktury.

Dla zespołów bezpieczeństwa to sygnał, że publicznie dostępne usługi AI, interfejsy administracyjne oraz komponenty orkiestracyjne należy traktować jak krytyczną powierzchnię ataku. Brak kontroli nad tym obszarem może prowadzić do incydentów o znacznie większej skali niż początkowa infekcja pojedynczego hosta.

Źródła

Fałszywe testy rekrutacyjne infekują programistów malware ukrytym w plikach SVG

Wprowadzenie do problemu / definicja

Kampanie wymierzone w programistów coraz częściej łączą zaawansowaną socjotechnikę z technikami ukrywania złośliwego kodu w pozornie nieszkodliwych zasobach aplikacji. W opisywanym przypadku atakujący wykorzystywali fałszywe procesy rekrutacyjne i zadania techniczne, aby skłonić ofiary do uruchomienia spreparowanych projektów zawierających malware osadzone w plikach SVG.

To szczególnie niebezpieczny model ataku, ponieważ złośliwy ładunek nie musi znajdować się w oczywistych miejscach kodu źródłowego. Zamiast tego zostaje ukryty w zasobach graficznych, co utrudnia jego wykrycie zarówno użytkownikom, jak i narzędziom bezpieczeństwa.

W skrócie

Badacze opisali kampanię przypisywaną podmiotom powiązanym z Koreą Północną, która wykorzystywała fikcyjne testy rekrutacyjne do infekowania deweloperów. Złośliwy kod był ukrywany w komentarzach HTML wewnątrz plików SVG przedstawiających flagi państw, a następnie składany przez skrypt JavaScript obecny w projekcie.

przynętą były realistyczne oferty pracy i zadania programistyczne,
ładunek ukryto w zakodowanych fragmentach osadzonych w obrazach SVG,
infekcja prowadziła do wdrożenia modułów kradnących dane i zdalnego dostępu,
celem były m.in. poświadczenia, portfele kryptowalutowe, pliki lokalne i dane ze schowka,
kampania wpisuje się w rosnący trend ataków na deweloperów i łańcuch dostaw oprogramowania.

Kontekst / historia

Opisana aktywność wiązana jest z kampanią znaną jako Contagious Interview, obserwowaną od co najmniej grudnia 2022 roku. Schemat działania pozostaje podobny: ofiara otrzymuje wiarygodnie wyglądającą ofertę pracy, przechodzi do rozmowy prywatnej, a następnie dostaje zadanie techniczne w formie repozytorium do uruchomienia lokalnie.

Skuteczność tej metody wynika z dopasowania przynęty do codziennej pracy programistów. Specjaliści IT regularnie analizują obcy kod, uruchamiają projekty testowe i budują zależności, dlatego dobrze przygotowany projekt oparty na popularnym stosie technologicznym może nie wzbudzić podejrzeń. To sprawia, że atakujący zyskują bardzo wiarygodny kanał wejścia do środowiska ofiary.

Analiza techniczna

Najbardziej charakterystycznym elementem kampanii było ukrycie fragmentów ładunku w plikach SVG znajdujących się w katalogu zasobów aplikacji. Napastnicy osadzali dane w komentarzach HTML, wykorzystując zakodowane ciągi, które nie rzucały się w oczy podczas pobieżnej analizy projektu.

Następnie specjalnie przygotowany skrypt JavaScript, wskazywany jako serverValidation.js, odczytywał rozproszone fragmenty i składał je w pełny payload. Po uruchomieniu mechanizmu infekcji malware mogło zapewniać sobie trwałość oraz wykonywać działania przy kolejnych restartach serwera lub aplikacji.

Badacze powiązali obserwowane komponenty z rodziną malware wykazującą zbieżność z OtterCookie. Oznacza to podejście modułowe, w którym poszczególne elementy odpowiadają za różne etapy kradzieży danych i utrzymania dostępu.

kradzież danych z przeglądarek oraz portfeli kryptowalutowych,
wykradanie plików o wybranych rozszerzeniach,
zdalne wykonywanie poleceń przez komponent oparty na Socket.IO,
przechwytywanie zawartości schowka,
dostarczanie dodatkowych plików wykonywalnych dla systemu Windows.

Na uwagę zasługuje także ukierunkowanie na artefakty związane z narzędziami AI używanymi przez programistów. Malware miało interesować się danymi powiązanymi z konfiguracjami i katalogami takimi jak .claude, .cursor, .gemini, .windsurf, .pearai czy .llama. To pokazuje, że operatorzy dostosowują techniki kradzieży do nowoczesnych środowisk developerskich, w których lokalne konteksty, tokeny i sekrety asystentów kodowania mają wysoką wartość.

Konsekwencje / ryzyko

Skutki takiego incydentu mogą być poważne zarówno dla pojedynczego programisty, jak i całej organizacji. Na poziomie użytkownika zagrożenie obejmuje utratę haseł zapisanych w przeglądarce, danych sesyjnych, plików projektowych, informacji ze schowka oraz danych dostępowych do usług i portfeli kryptowalutowych.

Znacznie większe ryzyko pojawia się jednak wtedy, gdy zainfekowana zostaje stacja robocza dewelopera pracującego nad komercyjnym oprogramowaniem. Przejęte sekrety, klucze API, tokeny CI/CD lub dostęp do repozytoriów mogą umożliwić dalszą infiltrację środowisk chmurowych, systemów budowania i pipeline’ów wdrożeniowych. W takim scenariuszu incydent może szybko przerodzić się w atak na łańcuch dostaw.

Dodatkowym problemem jest niska wykrywalność. Rozproszenie payloadu, ukrycie go w zasobach graficznych i obecność działającej aplikacji maskującej złośliwe funkcje znacząco utrudniają szybką identyfikację zagrożenia.

Rekomendacje

Organizacje i sami programiści powinni traktować każde zewnętrzne zadanie rekrutacyjne oraz niezweryfikowane repozytorium jako potencjalnie nieufne. Ochrona przed podobnymi kampaniami wymaga zarówno działań technicznych, jak i procedur operacyjnych.

uruchamiać obcy kod wyłącznie w odizolowanych środowiskach, najlepiej na jednorazowych maszynach wirtualnych lub w kontenerach,
nie przechowywać wrażliwych poświadczeń w przeglądarkach używanych do pracy developerskiej,
stosować osobne konta, profile przeglądarki i środowiska do testowania zewnętrznych projektów,
monitorować nietypowe użycie Node.js, skryptów startowych, mechanizmów persistence i połączeń wychodzących,
analizować repozytoria pod kątem ukrytych danych w SVG, komentarzach HTML i ciągach Base64,
ograniczać dostęp do kluczy API, portfeli oraz tokenów CI/CD zgodnie z zasadą najmniejszych uprawnień,
wdrożyć EDR lub XDR zdolne wykrywać kradzież poświadczeń, enumerację plików i nietypowe procesy potomne,
szkolić pracowników technicznych z rozpoznawania kampanii socjotechnicznych podszywających się pod rekrutację.

Z perspektywy DevSecOps warto również rozszerzyć reguły inspekcji o zasoby statyczne aplikacji. Pliki SVG, JSON i inne assety frontendowe nie powinny być automatycznie uznawane za bezpieczne, zwłaszcza jeśli pochodzą z niezweryfikowanych źródeł.

Podsumowanie

Fałszywe testy rekrutacyjne z malware ukrytym w plikach SVG pokazują, jak skutecznie napastnicy łączą socjotechnikę z nieoczywistymi technikami maskowania ładunku. Atak jest szczególnie groźny dla programistów, ponieważ wykorzystuje ich naturalne nawyki pracy z kodem i zewnętrznymi projektami.

Najważniejszy wniosek dla organizacji jest jednoznaczny: uruchamianie obcego kodu bez izolacji może prowadzić nie tylko do utraty danych pojedynczego użytkownika, ale również do kompromitacji środowiska deweloperskiego i incydentu obejmującego cały łańcuch dostaw oprogramowania.

Źródła

Luka w rozszerzeniu Claude dla Chrome umożliwia złośliwym dodatkom wywoływanie akcji AI

Wprowadzenie do problemu / definicja

Rozszerzenia przeglądarkowe wyposażone w funkcje agentowe AI coraz częściej uzyskują dostęp do poczty, dokumentów, kalendarzy i systemów CRM. W takim modelu nawet pojedynczy błąd w logice zaufania może sprawić, że narzędzie zaprojektowane do automatyzacji pracy stanie się wektorem nadużycia.

Właśnie taki problem wykryto w rozszerzeniu Claude dla Chrome. Luka pozwala innemu dodatkowi działającemu w kontekście strony usługi wyzwalać określone akcje AI poprzez symulowane kliknięcia, bez rzeczywistej intencji użytkownika.

W skrócie

Badacze bezpieczeństwa opisali podatność, która umożliwia złośliwemu rozszerzeniu uruchamianie predefiniowanych workflow AI w Claude dla Chrome. Problem wynika z braku skutecznej weryfikacji, czy zdarzenie kliknięcia pochodzi od użytkownika, czy zostało wygenerowane programowo.

Zakres ataku nie obejmuje dowolnych poleceń, lecz zestaw gotowych zadań przygotowanych przez producenta. Mimo tego potencjalne skutki są istotne, ponieważ chodzi o operacje wykonywane w usługach o wysokiej wrażliwości, takich jak Gmail, Google Docs, Kalendarz Google czy Salesforce.

odczyt wiadomości Gmail,
analiza komentarzy w Google Docs,
przeglądanie kalendarza i wolnych terminów,
modyfikacja rekordów w Salesforce.

Kontekst / historia

Nie jest to klasyczna luka prowadząca do zdalnego wykonania kodu ani pełnego przejęcia konta. Problem dotyczy przede wszystkim naruszenia granicy zaufania między rozszerzeniami przeglądarki oraz między interfejsem użytkownika a warstwą agentową AI.

Claude dla Chrome został zaprojektowany tak, aby wykonywać zestaw predefiniowanych działań zamiast przyjmować całkowicie dowolne instrukcje. Taki model z założenia ogranicza ryzyko, ale tylko wtedy, gdy uruchamianie tych działań jest ściśle powiązane z autentyczną interakcją człowieka.

Badacze z Manifold Security zgłosili producentowi dwa problemy w maju 2026 roku. Pierwszy dotyczył syntetycznych kliknięć wyzwalających workflow, a drugi parametru skipPermissions=true, który miał wpływać na sposób obsługi uprawnień w panelu rozszerzenia. Według opisu badaczy oba zachowania nadal można było odtworzyć jeszcze w lipcu 2026 roku.

Analiza techniczna

Rdzeń pierwszej podatności sprowadza się do obsługi zdarzeń DOM. Rozszerzenie nasłuchiwało kliknięć na elemencie odpowiedzialnym za uruchamianie określonych zadań AI, ale nie odróżniało w wystarczający sposób kliknięć prawdziwych od tych wygenerowanych przez skrypt.

W praktyce oznacza to, że inne rozszerzenie mogące wykonywać kod na stronie Claude mogło przygotować odpowiedni element, ustawić identyfikator zadania i wywołać syntetyczne kliknięcie. Jeśli logika aplikacyjna traktowała taki sygnał jako prawidłowy, dochodziło do uruchomienia jednego z dostępnych workflow.

wstrzyknięcie odpowiedniego elementu DOM,
ustawienie identyfikatora zadania,
wygenerowanie sztucznego kliknięcia,
wywołanie predefiniowanej akcji AI.

To klasyczny przykład błędu walidacji intencji użytkownika. Sama przeglądarka rozróżnia zdarzenia zaufane od niezaufanych, ale jeśli aplikacja nie wykorzysta tej informacji, warstwa ochronna przestaje działać w praktyce.

Drugi problem ma charakter bardziej architektoniczny. Wskazany parametr skipPermissions=true mógł według badaczy wpływać na tryb pracy panelu rozszerzenia i osłabiać część kontroli uprawnień. Sam w sobie nie musiał oznaczać pełnego wektora ataku, lecz mógł stanowić niebezpieczny element pomocniczy przy łączeniu z innymi lukami.

Konsekwencje / ryzyko

Najważniejsze znaczenie tej luki wynika z faktu, że złośliwe rozszerzenie może nadużyć zaufania wcześniej przyznanego agentowi AI. Z perspektywy ofiary działania są wykonywane z użyciem legalnie zalogowanej sesji i autoryzowanych integracji, co utrudnia wykrycie incydentu.

Poziom ryzyka zależy od konfiguracji środowiska oraz modelu potwierdzania działań. Jeśli użytkownik lub organizacja dopuszcza bardziej automatyczne wykonywanie akcji bez każdorazowej zgody, scenariusz staje się wyraźnie groźniejszy.

nieautoryzowany odczyt danych z usług Google,
manipulacja procesami i rekordami w narzędziach biznesowych,
wykonywanie operacji przez prawidłowo uwierzytelnioną sesję,
ograniczona widoczność incydentu w standardowych logach użytkownika.

Dla organizacji korzystających z agentów AI w przeglądarce to ważne ostrzeżenie. Nawet jeśli sam model działa wyłącznie w granicach określonych zadań, to warstwa integracyjna i mechanizmy autoryzacji pozostają kluczowym elementem powierzchni ataku.

Rekomendacje

Najlepszą odpowiedzią na tego typu ryzyko jest ograniczenie zaufania do rozszerzeń przeglądarkowych oraz traktowanie dodatków AI jako komponentów uprzywilejowanych, a nie zwykłych narzędzi zwiększających produktywność.

ograniczyć liczbę zainstalowanych rozszerzeń do niezbędnego minimum,
regularnie audytować uprawnienia dodatków i dostęp do konkretnych domen,
wyłączyć lub ograniczyć automatyczne wykonywanie akcji AI bez potwierdzenia,
monitorować nietypowe działania agentów AI w usługach SaaS,
wdrożyć polityki firmowe blokujące nieautoryzowane rozszerzenia,
testować dodatki agentowe pod kątem odporności na manipulację DOM i błędy walidacji zdarzeń.

Z perspektywy producentów oprogramowania kluczowe jest egzekwowanie wykonywania akcji wyłącznie po zaufanej interakcji użytkownika. Dodatkowo tryby podwyższonych uprawnień nie powinny być aktywowane przez parametry URL ani mechanizmy łatwe do odtworzenia poza właściwym przepływem działania.

Podsumowanie

Przypadek Claude dla Chrome pokazuje, że bezpieczeństwo agentów AI zależy nie tylko od modelu i treści poleceń, ale przede wszystkim od granic zaufania w interfejsie, integracjach i logice rozszerzenia. Choć opisana luka nie dawała pełnej dowolności atakującemu, umożliwiała uruchamianie realnych działań o wpływie na dane użytkownika i procesy biznesowe.

Dla zespołów bezpieczeństwa to kolejny sygnał, że rozszerzenia z funkcjami AI należy oceniać tak samo rygorystycznie jak inne komponenty mające szeroki dostęp do danych i usług firmowych.

Źródła

Claude Code i DeepSeek wykorzystane w kampanii cyberwywiadowczej powiązanej z Chinami

Wprowadzenie do problemu / definicja

Wykorzystanie dużych modeli językowych w działaniach ofensywnych przestaje być wyłącznie teoretycznym scenariuszem. Najnowsze ustalenia badaczy wskazują, że narzędzia oparte na AI mogą pełnić rolę aktywnego elementu łańcucha ataku, wspierając nie tylko analizę, ale również rozwój exploitów, adaptację technik obejścia zabezpieczeń oraz przygotowanie infrastruktury phishingowej.

To istotna zmiana w krajobrazie zagrożeń, ponieważ automatyzacja obejmuje dziś coraz więcej etapów operacji cyberwywiadowczych. W praktyce oznacza to skrócenie czasu potrzebnego na przygotowanie kampanii, zwiększenie jej elastyczności oraz łatwiejsze dostosowanie działań do konkretnej ofiary.

W skrócie

Badacze ujawnili kampanię cyberespionage wspieraną przez Claude Code oraz DeepSeek.
Atakujący korzystali z infrastruktury obejmującej serwery w Hongkongu, otwarte katalogi z artefaktami operacyjnymi, skrypty exploitów i klony stron logowania.
Celami były instytucje rządowe oraz organizacje z sektorów finansowego, telekomunikacyjnego, chemicznego, obronnego i łańcucha dostaw.
W części incydentów wykorzystano SQL injection, przejęto dane uwierzytelniające oraz uzyskano dostęp do zasobów chmurowych dzięki ujawnionym kluczom i tokenom.

Kontekst / historia

Kampania została powiązana z infrastrukturą znaną z wcześniejszych działań związanych z TencShell. Analiza rozpoczęła się od charakterystycznego fingerprintu nagłówka HTTP na porcie 1111, który doprowadził badaczy do klastra 13 serwerów. Na jednym z nich odkryto publicznie dostępny katalog zawierający tysiące plików i liczne podkatalogi powiązane z prowadzonymi operacjami.

Zgromadzone artefakty sugerują długotrwałą i wielowątkową aktywność wymierzoną w różne regiony oraz typy ofiar. Wśród odnalezionych materiałów znalazły się źródła aplikacji ofiar, notatki operacyjne zapisane uproszczonym chińskim, skrypty rozpoznawcze, narzędzia do klonowania stron logowania oraz komponenty malware dla różnych architektur systemowych.

Analiza techniczna

Najciekawszym elementem kampanii był podział ról między dwa modele AI. Claude Code miał odpowiadać za warstwę wykonawczą, w tym uruchamianie poleceń Bash, zarządzanie długotrwałymi sesjami, wykonywanie zadań równoległych oraz przygotowywanie infrastruktury phishingowej. DeepSeek pełnił natomiast funkcję warstwy planistycznej i decyzyjnej, generując skrypty, dobierając techniki ataku i proponując alternatywne metody obejścia zabezpieczeń.

Odzyskane pliki robocze wskazują, że operatorzy wykorzystywali AI do iteracyjnego rozwijania fałszywych stron logowania, ich testowania i ulepszania. W praktyce oznacza to skrócenie cyklu testowania i modyfikacji infrastruktury atakującej, co wcześniej wymagało większego zaangażowania analityków lub programistów.

W działaniach przeciwko celom rządowym wykorzystano podatności typu SQL injection do uzyskania dostępu administracyjnego do aplikacji webowych. Następnie wdrożono web shella ukrytego jako plik GIF, aby utrzymać trwały dostęp do środowiska. W innym przypadku skompromitowano aplikację opartą na Laravel 5.8.38, pozyskując kod źródłowy, poświadczenia do bazy danych, klucze szyfrujące oraz elementy obsługi poczty, a następnie przygotowano dedykowany exploit w Pythonie wymierzony w mechanizmy deserializacji frameworka.

W kampanii skierowanej przeciw organizacjom z Tajwanu operatorzy prowadzili rekonesans przy użyciu brute-force DNS, zapytań do rejestrów przejrzystości certyfikatów oraz fingerprintingu usług HTTP. Szczególnym zainteresowaniem cieszyły się bramy VPN, instancje GitLab i środowiska Jira. W jednym z przypadków kompromitacja była możliwa dzięki kluczom Supabase i tokenom Azure Logic Apps osadzonym na stałe w publicznie dostępnych plikach JavaScript.

Badacze opisali także wcześniej nieudokumentowaną infrastrukturę C2 określaną jako Gshell C2, częściowo pokrywającą się z wcześniejszym klastrem. Dodatkowo zabezpieczono próbki malware dla Linux/ARM 32-bit oraz Linux/x86. Wariant ARM komunikował się z serwerem przez WebSocket i potrafił wykradać dane uwierzytelniające z komunikatorów, tokeny platform firmowych oraz klucze dostępowe do usług chmurowych. Wersja x86 była zaciemniona przy użyciu narzędzia garble, lecz wspólny materiał kryptograficzny sugerował współdzieloną bazę kodu.

Konsekwencje / ryzyko

Najważniejszym wnioskiem z tej kampanii jest to, że modele AI mogą dziś działać jako realny akcelerator operacji cyberwywiadowczych. Nie chodzi już wyłącznie o generowanie kodu, ale o zwiększenie szybkości adaptacji ataku do konkretnego środowiska ofiary i bieżących warunków operacyjnych.

Dla sektora publicznego oznacza to ryzyko utraty danych obywateli, informacji administracyjnych, danych kadrowych oraz wglądu w procedury i systemy zgłoszeniowe. Dla przedsiębiorstw zagrożenie obejmuje przejęcie kont uprzywilejowanych, kompromitację środowisk chmurowych, kradzież kodu źródłowego oraz naruszenie łańcucha dostaw. Szczególnie groźne okazuje się połączenie klasycznych podatności aplikacyjnych z błędami operacyjnymi, takimi jak ujawnione sekrety, słaba segregacja uprawnień i brak monitorowania nietypowych działań administracyjnych.

Rekomendacje

Organizacje powinny potraktować tę kampanię jako wyraźny sygnał do rewizji modelu obrony przed atakami wspieranymi przez AI. Priorytetem powinno być rygorystyczne zarządzanie sekretami oraz usunięcie z publicznych repozytoriów i plików frontendowych wszystkich kluczy API, tokenów i danych dostępowych.

Niezbędne jest także regularne skanowanie aplikacji internetowych pod kątem SQL injection, błędów deserializacji oraz nadmiernej ekspozycji paneli administracyjnych. W obszarze monitoringu warto rozszerzyć detekcję o wzorce wskazujące na szybkie, iteracyjne zmiany w infrastrukturze phishingowej, użycie web shelli maskowanych jako pliki statyczne oraz komunikację WebSocket do nieznanych hostów.

wdrożyć rotację i pełną inwentaryzację kluczy oraz tokenów dostępowych,
przeprowadzić przegląd aplikacji pod kątem SQL injection i deserializacji,
ograniczyć ekspozycję paneli administracyjnych do sieci zaufanych lub przez ZTNA/VPN,
monitorować publiczne zasoby frontendowe pod kątem osadzonych sekretów,
rozwijać playbooki SOC uwzględniające ataki adaptacyjne wspierane przez AI,
analizować artefakty phishingowe i klony stron logowania pod kątem automatycznego generowania.

Podsumowanie

Opisana kampania pokazuje, że AI staje się pełnoprawnym komponentem nowoczesnych operacji cyberwywiadowczych. Integracja modeli językowych z narzędziami wykonawczymi skraca czas przygotowania ataku, zwiększa elastyczność operatorów i obniża koszt tworzenia spersonalizowanych technik kompromitacji.

Dla obrońców oznacza to konieczność równoczesnego wzmacniania bezpieczeństwa aplikacji, kontroli dostępu, ochrony sekretów oraz zdolności do wykrywania działań prowadzonych szybciej i bardziej adaptacyjnie niż w tradycyjnych kampaniach APT.

Źródła

Security Affairs — https://securityaffairs.com/195474/ai/claude-code-and-deepseek-powered-chinese-cyber-espionage-campaign.html
Hunt.io Report — https://hunt.io
Anthropic — Trust & Safety disclosures — https://www.anthropic.com