JadePuffer: ransomware, którego atak wykonał agent AI (od włamania po okup)
1 lipca 2026 r. zespół Sysdig Threat Research Team opisał incydent, który nazwał pierwszym udokumentowanym przypadkiem agentowego ransomware. Chodzi o kompletną operację wymuszenia okupu, w której całą techniczną robotę - od włamania po notatkę z żądaniem - poprowadził duży model językowy (LLM) działający jako agent. Aktora oznaczono jako JadePuffer. Motyw był czysto finansowy, bez śladów powiązania ze znanymi grupami ransomware czy z którymkolwiek państwem. Cel był konkretny: bazy danych i sekrety.
Kontekst i legalność. To materiał edukacyjny. Opisujemy publicznie udokumentowany atak (Sysdig TRT) oraz wykorzystane w nim, znane i załatane podatności. Testowanie cudzych systemów jest legalne wyłącznie za pisemną zgodą właściciela. Wyjaśniamy mechanizm i obronę - nie udostępniamy gotowego exploita. Jedno zastrzeżenie od razu: „agentowy" nie znaczy „bez człowieka". Wracamy do tego niżej.
Co dokładnie się wydarzyło
Atak miał dwa serwery na celowniku. Pierwszy to wystawiona do internetu instancja Langflow - narzędzia typu low-code do budowania przepływów i agentów na modelach LLM. Drugi, właściwy cel, to serwer produkcyjny z bazą MySQL i usługą konfiguracyjną Alibaba Nacos. Agent wszedł przez pierwszy, a zniszczenie i okup wykonał na drugim.
Sysdig naliczył ponad 600 osobnych ładunków dostarczonych w krótkim oknie czasowym, każdy jako zakodowany w base64 kod Pythona wykonany przez końcówkę RCE Langflow. To nie była pojedyncza próbka złośliwego oprogramowania, tylko strumień poleceń generowanych i korygowanych na bieżąco.
Etap 1 - wejście i sekrety (Langflow, CVE-2025-3248)
Punkt wejścia to stara znajoma: CVE-2025-3248, brak uwierzytelnienia na końcówce walidującej kod w Langflow. Nieuwierzytelniony atakujący może wykonać dowolny kod Pythona na hoście. Tę samą powierzchnię ataku rozbieraliśmy wcześniej przy okazji łańcucha Langflow; tu posłużyła jako otwarte drzwi.
Po wejściu agent zachował się jak metodyczny operator. Rozpoznał hosta zwykłymi poleceniami (id, uname -a, hostname), a potem przeczesał środowisko pod kątem sekretów:
- klucze API do dostawców modeli: OpenAI, Anthropic, DeepSeek i Gemini, a także poświadczenia chmurowe (z uwzględnieniem dostawców chińskich),
- zrzut bazy Postgres stojącej pod Langflow (poświadczenia, klucze, konta użytkowników),
- skan wewnętrznej sieci i usług, w tym magazynu obiektowego MinIO pod
127.0.0.1:9000, do którego zalogował się domyślnymminioadmin:minioadmini wyciągnął z kubełkaterraform-stateplikcredentials.json.
Na koniec zapewnił sobie trwałość: wpis w crontabie odzywający się do infrastruktury atakującego co 30 minut.
Etap 2 - pivot na Nacos i błąd naprawiony w 31 sekund
Na serwerze produkcyjnym agent uderzył w Nacos, wykorzystując CVE-2021-29441 - obejście uwierzytelnienia sprzed czterech lat. Sfałszował poprawny token JWT, korzystając z powszechnie znanego, domyślnego klucza podpisującego Nacos, i wstrzyknął konto administratora prosto do bazy usługi.
I tu pojawia się fragment, który najlepiej pokazuje różnicę między skryptem a agentem. Wstawienie konta nie zadziałało za pierwszym razem, a model sam się z tego wygrzebał:
19:34:24 wstawia konto xadmin (hash bcrypt) przez subprocess
19:34:36 próba logowania nieudana (12 s później)
19:35:07 diagnoza: zła ścieżka PATH w subprocess
→ przełącza się na bezpośredni import bcrypt,
kasuje wadliwy wiersz, wstawia poprawny hash
19:35:18 logowanie udane
Cała pętla „zauważ błąd, zmień metodę, ponów" zamknęła się w 31 sekundach. Agent nie miał zaszytej obsługi tego konkretnego błędu. Odczytał komunikat, wywnioskował przyczynę i wybrał inne podejście - szybciej, niż zrobiłby to człowiek przy klawiaturze.
Etap 3 - zniszczenie i okup
Mając dostęp, agent zaszyfrował wszystkie 1 342 pozycje konfiguracyjne Nacos funkcją AES_ENCRYPT() wbudowaną w MySQL, usunął oryginalną tabelę config_info wraz z historią i utworzył tabelę README_RANSOM z żądaniem okupu. Kilka baz danych po prostu skasował poleceniem DROP, zostawiając w kodzie komentarz w stylu „bazy o wysokim zwrocie do skasowania, dane już skopiowane na 64.20.53.230".
Notatka obiecywała ofierze odszyfrowanie po zapłacie w bitcoinie i deklarowała szyfrowanie „AES-256". Problem w tym, że klucz AES agent wygenerował jako base64(uuid4().bytes + uuid4().bytes), wypisał go na standardowe wyjście i nigdy nigdzie nie zapisał ani nie wysłał. Innymi słowy: nawet po zapłacie okupu nie było czym odszyfrować danych. Do tego adres bitcoin w notatce to kanoniczny przykład z dokumentacji Bitcoina, a nie realny portfel operatora. Skuteczne zniszczenie, nieskuteczne wymuszenie - tyle że dla ofiary liczy się to pierwsze.
Dlaczego to jest nowe
Zacznijmy od uczciwego kubła zimnej wody, bo należy się ofensywnej rzetelności. Żadna pojedyncza technika w tym ataku nie jest nowa. Wystawiona usługa, kradzież poświadczeń, ruch boczny, nadużycie domyślnych haseł, kasowanie baz - to katalog znany od lat. Johan Edholm z Detectify podsumował to trzeźwo: „więcej ewolucji niż wynalazku". Nowe jest coś innego: spięcie całego łańcucha bez człowieka na każdym kroku.
Cztery rzeczy odróżniają JadePuffer od zwykłej automatyzacji:
Po pierwsze, autonomiczna koordynacja. Klasyczny malware wykonuje z góry zapisany scenariusz. Tu model łączył rozpoznanie, kradzież kluczy, pivot, trwałość i zniszczenie, dobierając kolejne kroki na podstawie tego, co zobaczył. Operator nie musiał być ekspertem od żadnego z tych etapów.
Po drugie, kod, który opisuje własny zamiar. Ładunki JadePuffer zawierały komentarze w naturalnym języku: rozumowanie, priorytety, uzasadnienie każdego ruchu. Człowiek rzadko tak pisze pod presją, model robi to odruchowo. To jednocześnie najmocniejszy dowód, że za sterami był LLM, i - o czym za chwilę - prezent dla obrońców.
Po trzecie, reakcja w czasie rzeczywistym. Wspomniane 31 sekund to nie wyjątek. Agent dostosowywał się też, gdy dostał zły format danych czy natrafił na ograniczenie bazy. To zachowanie typu „planuj, działaj, obserwuj, popraw", a nie sztywny skrypt z blokiem try/except.
Po czwarte, stare podatności na skalę. Agent wykorzystał lukę Nacos z 2021 roku. Dla modelu przeczesanie całego historycznego katalogu CVE jest praktycznie darmowe. Michael Clark z Sysdig ujął sedno jednym zdaniem: próg wejścia do prowadzenia operacji ransomware spadł do „tego, ile kosztuje uruchomienie agenta".
A teraz obiecane zastrzeżenie. JadePuffer nie był w pełni bezobsługowy. Człowiek wybrał ofiarę, postawił infrastrukturę (serwer C2 i serwer do wykradanych danych) i dostarczył agentowi rootowe poświadczenia do MySQL zdobyte we wcześniejszym włamaniu. Model wykonał atak, ale to ludzie go nacelowali i uzbroili. Do tego widać niedoróbki: podstawiony adres bitcoin i bezpowrotnie utracony klucz zdradzają operację wczesną i niedopracowaną. Właściwe podsumowanie brzmi więc: autonomiczne wykonanie, ludzkie nacelowanie. To i tak wystarczy, by zmienić ekonomię tych ataków, bo najdroższa część - godziny pracy wykwalifikowanego operatora - właśnie staniała.
Jak się bronić
W kolejności priorytetów:
- Zamknij wejście. Załataj Langflow (CVE-2025-3248) i nie wystawiaj do internetu końcówek wykonujących kod. Dostęp administracyjny tylko przez VPN lub bramę tożsamości.
- Odetnij sekrety od agenta. Nie trzymaj kluczy do chmury i modeli na hoście, na którym działa narzędzie agentowe. Sekrety w dedykowanym magazynie, wstrzykiwane w trakcie działania; po ekspozycji rotacja wszystkich kluczy.
- Utwardź usługi wewnętrzne. Załataj Nacos (CVE-2021-29441) i zmień domyślny klucz podpisujący JWT. Pozbądź się domyślnych haseł typu
minioadmin:minioadmin. To właśnie po nich agent poruszał się dalej. - Kontroluj ruch wychodzący i patrz w czasie działania. Filtruj egress: zablokowanie beaconu C2 co 30 minut czy wysyłki danych na serwer staging przerywa łańcuch. Kwartalny audyt to za mało, skoro agent przechodzi od rozpoznania do skutku w minuty. Potrzebny jest ciągły wgląd w to, co dzieje się na hostach.
- Wykorzystaj czytelny zamiar. Ładunki agenta same opisują cel w komentarzach. Klasyczne malware tego nie robi. Ten „narracyjny" tekst to sygnał, który można wychwycić w detekcji.
Co z tego wynika dla organizacji
JadePuffer to studium przypadku szerszego zjawiska: infrastruktura AI jest nową powierzchnią ataku, a narzędzia agentowe obniżają próg wejścia dla napastników. Na razie to pojedynczy, miejscami niechlujny incydent. Ale gdy tooling się upowszechni i „opakuje" w gotowe zestawy, dostaną go operatorzy o niższych kompetencjach, a wolumen i zasięg takich kampanii wzrosną. Sysdig mówi wprost o zmianie sposobu, w jaki prowadzi się wymuszenia.
To wprost tematyka NIS2/KSC: zarządzanie podatnościami, bezpieczeństwo łańcucha dostaw, kontrola dostępu i wykrywanie incydentów. Szczegóły wymogów opisaliśmy na stronie NIS2 / KSC. Jeśli budujesz lub hostujesz agentów AI i chcesz sprawdzić ich odporność - od prompt injection, przez nadużycie kluczy, po wyciek sekretów - to dokładnie nasza specjalizacja: AI / LLM red teaming. Umów konsultację, jeśli chcesz zweryfikować własną powierzchnię ataku, zanim zrobi to za ciebie czyjś agent.
Źródła: Sysdig (raport pierwotny) · CyberScoop · TechCrunch · Dark Reading · BleepingComputer