Atakujący w 31 sekund: co pierwszy autonomiczny atak ransomware oznacza dla odtwarzania

Kiedy atakujący przestał potrzebować człowieka

1 lipca 2026 roku zespół Sysdig Threat Research Team opublikował analizę operacji ransomware, której nadał nazwę JADEPUFFER. Według Sysdig jest to „what we assess to be the first documented case of agentic ransomware: a complete extortion operation driven end-to-end by a large language model (LLM)” (w naszym tłumaczeniu: ich zdaniem pierwszy udokumentowany przypadek agentowego ransomware, czyli kompletna operacja wymuszenia prowadzona od początku do końca przez duży model językowy).

To nie jest kolejna historia o phishingowych e-mailach pisanych przez AI ani o podrobionych głosach w rozmowach telefonicznych. W payloadach przechwyconych przez Sysdig agent wykorzystał podatność aplikacji wystawionej do internetu, zebrał poświadczenia, przeszedł na drugi serwer, przejął jego usługę konfiguracyjną, zaszyfrował i usunął dane, a na koniec zostawił żądanie okupu. Gdy któryś krok się nie powiódł, sam diagnozował przyczynę i próbował ponownie, nie czekając na instrukcje.

W BackupSec uważamy, że JADEPUFFER jest ważny nie tyle jako pojedynczy incydent, ile jako zapowiedź. To wczesny punkt danych dla pytania, na które każda architektura kopii zapasowych i odtwarzania prędzej czy później będzie musiała odpowiedzieć: co się dzieje, gdy pętla decyzyjna po drugiej stronie skraca się z godzin do sekund?

Łańcuch ataku JADEPUFFER od środka

W ogólnym zarysie to łańcuch ataku, przed którym zespoły bezpieczeństwa bronią się od lat. Sysdig mówi to wprost: „None of the individual techniques were novel or sophisticated” (żadna z poszczególnych technik nie była nowa ani wyrafinowana). Nowe było to, co je wykonało. Poniższa sekwencja opiera się na opisie Sysdig:

1. Dostęp początkowy. Agent wykorzystał CVE-2025-3248 w Langflow, otwartoźródłowym frameworku do budowy aplikacji LLM. NVD opisuje ją jako wstrzyknięcie kodu w endpoincie /api/v1/validate/code, które pozwala, by „a remote and unauthenticated attacker” (zdalny, nieuwierzytelniony atakujący) wykonał dowolny kod, i ocenia ją na CVSS 9,8. Poprawka trafiła do Langflow 1.3.0 31 marca 2025 roku, a CISA dodała tę lukę do katalogu Known Exploited Vulnerabilities 5 maja 2025 roku. Poprawka istniała, ale nie została wdrożona.
2. Zbieranie poświadczeń. Na hoście Langflow agent zinwentaryzował system i przeszukał środowisko pod kątem kluczy API dostawców LLM, poświadczeń chmurowych, portfeli kryptowalut i poświadczeń baz danych, a następnie zrzucił własną bazę Postgres Langflow. Znalazł osiągalny z hosta magazyn obiektowy MinIO, zalogował się do niego domyślnymi poświadczeniami MinIO (minioadmin:minioadmin) i wylistował buckety, które według Sysdig obejmowały „application data, backups, ML artifacts, and a terraform-state bucket” (dane aplikacji, kopie zapasowe, artefakty ML oraz bucket ze stanem Terraform). Z jednego z nich pobrał plik credentials.json zawierający parę klucz dostępu/sekret.
3. Utrwalenie dostępu. Na hoście Langflow zainstalował wpis w crontabie, który co 30 minut łączy się z infrastrukturą atakującego.
4. Przejście do właściwego celu. Według Sysdig prawdziwym celem operacji był osobny, wystawiony do internetu serwer produkcyjny z MySQL i usługą konfiguracyjną Alibaba Nacos. Agent połączył się z otwartym portem MySQL jako root. Sysdig nie zaobserwował, skąd pochodziły te poświadczenia roota: „Their origin is unknown” (ich pochodzenie jest nieznane).
5. Przejęcie Nacos. Agent atakował Nacos kilkoma ścieżkami jednocześnie: rodziną obejść uwierzytelniania CVE-2021-29441 (według NVD w Nacos przed wersją 1.4.1 filtr uwierzytelniania można pominąć sfałszowanym nagłówkiem user-agent), tokenem JSON Web Token podpisanym publicznie udokumentowanym domyślnym kluczem Nacos oraz kontem administratora-backdoorem zapisanym bezpośrednio w bazie Nacos dzięki dostępowi roota. Ścieżka JWT nie zadziałała („custom secret in use”, czyli używany był własny sekret) i została porzucona. Konto-backdoor zadziałało po 31-sekundowej korekcie opisanej niżej.
6. Skutki. Agent zaszyfrował wszystkie 1342 elementy konfiguracji Nacos funkcją MySQL AES_ENCRYPT(), usunął oryginalne tabele konfiguracji i historii, a potem usuwał całe schematy baz danych. Notatka z żądaniem okupu twierdzi, że użyto AES-256. Sysdig zwraca uwagę, że AES_ENCRYPT() domyślnie używa AES-128-ECB, chyba że serwer skonfigurowano inaczej. Szczegół ważniejszy dla odtwarzania: klucz został wypisany raz i nigdy nie był przechowywany ani wysłany, więc, jak pisze Sysdig, „The victim cannot recover the encrypted configurations even with payment” (ofiara nie odzyska zaszyfrowanych konfiguracji nawet po zapłacie). Te dane mogła przywrócić wyłącznie kopia wykonana przed atakiem i przechowywana poza zasięgiem atakującego.
7. Wymuszenie. Agent utworzył tabelę README_RANSOM z żądaniem, adresem Bitcoin i kontaktem w Proton Mail.

Uczciwe zastrzeżenie

Chcemy precyzyjnie określić, co oznacza tu „autonomiczny”, bo przesada podważyłaby argument, który zaraz przedstawimy.

Sysdig wymienia dwie rzeczy, których nie widzi. Nie zaobserwował, w jaki sposób agent uzyskał poświadczenia roota MySQL, których użył w kroku czwartym. Ma też „no visibility into JADEPUFFER's system prompt or agent configuration” (brak wglądu w prompt systemowy i konfigurację agenta JADEPUFFER), więc nie potrafi powiedzieć, jaki cel lub jakie zasoby człowiek przekazał agentowi przed uruchomieniem. Ktoś go zbudował, skonfigurował i uruchomił.

Sysdig dokumentuje natomiast zachowanie w przechwyconych sesjach: ponad 600 różnych payloadów, kod komentujący własne rozumowanie oraz błędy diagnozowane i poprawiane w ciągu sekund. Na tej podstawie wnioskuje, że „the evidence points to an autonomous agent driving the operation rather than a human operator or a fixed toolkit” (dowody wskazują na autonomicznego agenta prowadzącego operację, a nie na ludzkiego operatora czy stały zestaw narzędzi).

To rozróżnienie ma znaczenie i naszym zdaniem wzmacnia argument, zamiast go osłabiać. Nawet łańcuch, w którym człowiek wyznacza cel, a agent zajmuje się wykonaniem, usuwa największe źródło opóźnień w tradycyjnej operacji ransomware: czas, jaki ludzki operator poświęca na myślenie, konsultacje z nadzorcą i decyzję, co wypróbować dalej.

Dlaczego 31 sekund znaczy więcej, niż się wydaje

31 sekund to nie jest całkowity czas trwania ataku. Sysdig nie publikuje czasu trwania całego łańcucha i celowo nie będziemy go wymyślać. Publikuje natomiast sekwencję ze znacznikami czasu z przejęcia Nacos. Agent dodał konto administratora-backdoora, o 19:34:36 UTC spróbował się zalogować i mu się nie udało. Równolegle sprawdził dwie możliwe przyczyny, a o 19:35:07 wysłał 15-wierszowy payload korygujący, który poprawnie odbudował konto. Logowanie powiodło się o 19:35:18. Słowami Sysdig: „The window between the failed login and the correct multi-step fix is 31 seconds” (okno między nieudanym logowaniem a poprawną wieloetapową naprawą wynosi 31 sekund). Sysdig opisuje ten sam wzorzec w innych miejscach sesji. Gdy żądanie zwróciło XML zamiast JSON, kolejny payload parsował XML. Gdy DROP DATABASE nie powiodło się z powodu ograniczenia klucza obcego, następny najpierw wyłączał to sprawdzanie.

Porównajmy to z zachowaniem ludzkiego operatora po nieudanym kroku. Robi przerwę. Ponownie ocenia sytuację. W zorganizowanej operacji ransomware-as-a-service może napisać do nadzorcy i czekać na wskazówki. Próbuje ponownie w skali minut lub godzin, czasem dopiero po przekazaniu zmiany. To opóźnienie, czyli luka między niepowodzeniem a kolejną próbą, zawsze było jednym z nielicznych czynników działających na korzyść obrońców. To dzięki niemu alert z 2:00 w nocy może jeszcze zostać przeanalizowany przez człowieka o 8:00 rano, a incydent w międzyczasie niekoniecznie drastycznie się pogorszy.

Agent, który zamyka tę lukę do 31 sekund, nie tylko działa szybciej. Usuwa założenie wpisane w niemal każdy runbook reagowania na incydenty: że między pierwszą nieudaną próbą atakującego a kolejną istnieje okno na ludzką skalę i że proces wykrywania i reagowania działający w podobnej, ludzkiej skali czasu może rozsądnie liczyć na interwencję w tym oknie.

Liczby, które były prawdziwe, zanim pojawiła się AI

Infrastruktura kopii zapasowych nie stała się celem z powodu agentowej AI. Była nim już wcześniej, a dane na ten temat wyprzedzają JADEPUFFER o dwa lata.

• 2024 Ransomware Trends Report firmy Veeam, ankieta wśród 1200 respondentów z organizacji, które w 2023 roku padły ofiarą co najmniej jednego ataku ransomware, wykazał, że „backup repositories are targeted in 96% of attacks, with bad actors successfully affecting the backup repositories in 76% of cases” (repozytoria kopii zapasowych są celem w 96% ataków, a przestępcom udaje się na nie skutecznie wpłynąć w 76% przypadków). Veeam powtarza wartość 96% na własnym blogu.
• Badanie Sophos z 2024 roku dotyczące skompromitowanych kopii zapasowych, oparte na odpowiedziach 2974 specjalistów IT i cyberbezpieczeństwa z organizacji dotkniętych ransomware w poprzednim roku, wykazało, że „The median overall ransomware recovery costs for organizations whose backups were compromised ($3M) came in eight times higher than that of organizations whose backups were not impacted ($375K)” (mediana całkowitych kosztów odtwarzania po ransomware w organizacjach ze skompromitowanymi kopiami zapasowymi, 3 mln USD, była ośmiokrotnie wyższa niż w organizacjach, których kopie nie zostały naruszone, 375 tys. USD).

Te liczby opisują świat ludzkich atakujących, którzy już rozumieli, że zniszczenie lub zaszyfrowanie warstwy kopii zapasowych to ruch o największej dźwigni, jaki mają do dyspozycji po uzyskaniu przyczółka. Agentowa AI w żaden sposób nie zmienia tego rachunku. Zmienia to, kto lub co może go realizować na dużą skalę, przez całą dobę, bez potrzeby snu, przerwy między zmianami czy czekania na zgodę nadzorcy przed wypróbowaniem kolejnego poświadczenia.

IBM 2026 X-Force Threat Intelligence Index dopełnia obraz trendu. IBM X-Force odnotował wzrost o 44% liczby ataków rozpoczynających się od wykorzystania podatności aplikacji publicznie dostępnych, czyli dokładnie tego wektora wejścia, którego użył JADEPUFFER, a liczba aktywnych grup ransomware i wymuszeń wzrosła o 49% rok do roku. Powierzchnia ataku rosła, zanim ktokolwiek potrzebował do tego autonomicznego operatora.

Od okien wykrywania do pewności odtworzenia

Wykorzystanie znanej podatności to już najczęstsza droga wejścia. Ten sam raport IBM stwierdza, że wykorzystywanie podatności „became the leading cause of attacks, accounting for 40% of incidents observed by X-Force in 2025” (stało się główną przyczyną ataków i odpowiadało za 40% incydentów zaobserwowanych przez X-Force w 2025 roku). Luka między podatnościami znanymi a załatanymi jest zbyt duża i zbyt stale uzupełniana, by doskonała prewencja była realistyczna. JADEPUFFER pasuje do tego wzorca: Sysdig zauważa, że atak na właściwy cel „leaned on years-old issues, a 2021 Nacos auth-bypass and an unchanged default signing key” (opierał się na kilkuletnich problemach, obejściu uwierzytelniania Nacos z 2021 roku i niezmienionym domyślnym kluczu podpisującym). JADEPUFFER nie zmienia tego argumentu. Wyostrza go.

Jeśli roboczym założeniem branży było to, że proces wykrywania i reagowania działający w ludzkim tempie może rozsądnie liczyć na wychwycenie włamania gdzieś między dostępem początkowym a nieodwracalnymi skutkami, to agent korygujący się w 31 sekund bezpośrednio podważa to założenie. Odpowiedzią nie może być „wykrywaj i reaguj szybciej niż maszyna”, bo to nie jest wyścig, który obrońcy mogą wygrywać w nieskończoność. Odpowiedź musi być architektoniczna: sprawić, by skutki szybkiego, adaptacyjnego włamania dało się przetrwać bez względu na to, o ile szybszy stanie się atakujący.

Konkretnie: właściwości, które mają znaczenie dla infrastruktury kopii zapasowych i odtwarzania, nie zmieniają się dlatego, że atakującym jest agent AI, a nie człowiek. Przestają być aspiracją i stają się warunkiem koniecznym:

• Separacja poświadczeń i tożsamości, która nie zależy od tego, czy człowiek na czas zauważy nietypową aktywność. Jeśli poświadczenia dające dostęp do środowiska kopii zapasowych są tymi samymi, które agent może w kilka sekund zebrać ze skompromitowanego hosta, izolacja musi być strukturalna, a nie proceduralna.
• Niezmienność, która jest weryfikowana, a nie tylko skonfigurowana. Blokada retencji, którą wystarczająco uprzywilejowane poświadczenie może po cichu wyłączyć, to mechanizm zakładający, że ludzki atakujący się zawaha. Agent się nie zawaha.
• Testy odtwarzania zakładające, że atakujący już zna Twoje środowisko. Agent JADEPUFFER dostosowywał się do nieudanych kroków w czasie rzeczywistym. Plan odtwarzania, który testowano wyłącznie pod kątem jednego, oczekiwanego scenariusza awarii, jest planem zbudowanym na wolniejszego, bardziej przewidywalnego przeciwnika niż ten, który, jak widać, jest już możliwy.

Co to oznacza dla osób odpowiedzialnych za ryzyko w przedsiębiorstwie

JADEPUFFER to jedna udokumentowana kampania, a nie dowód, że każda operacja ransomware jest teraz autonomiczna. Jeśli jednak ocena Sysdig się utrzyma, zaobserwowano coś, co wcześniej było teorią: agenta LLM prowadzącego prawdziwy łańcuch ataku na prawdziwy cel, z pętlą samokorekty liczoną w sekundach.

Dla osób odpowiedzialnych za ryzyko praktyczne pytanie nie brzmi już, czy agentowe ransomware stanie się powszechniejsze. Sysdig pisze, że obrońcy „should expect the volume and breadth of such campaigns to rise as agentic tooling matures” (powinni spodziewać się wzrostu liczby i zasięgu takich kampanii w miarę dojrzewania narzędzi agentowych), a IBM X-Force „expects adversaries to automate complex tasks like reconnaissance and advanced ransomware attacks” (spodziewa się, że przeciwnicy zautomatyzują złożone zadania, takie jak rozpoznanie i zaawansowane ataki ransomware). Praktyczne pytanie brzmi: czy założenia Twojej architektury odtwarzania powstały z myślą o przeciwniku działającym w ludzkim tempie, czy o takim, który już tego nie potrzebuje.

Gdzie pojawia się BackupSec

W BackupSec zbudowaliśmy nasze podejście wokół założenia, które JADEPUFFER czyni pilniejszym: prewencja zawiedzie, a o wyniku decyduje warstwa zbudowana tak, by przetrwać tę porażkę, niezależnie od tego, jak szybko działało to, co ją spowodowało.

• ZeroMON monitoruje Veeam Backup & Replication. Wdrażany jest lokalnie jako OVA, łączy się za pomocą konta tylko do odczytu i niczego nie wysyła do BackupSec ani do żadnej strony trzeciej. Śledzi kondycję zadań kopii zapasowych, rejestruje zmiany konfiguracji w Veeam (kto co zmienił i kiedy), pokazuje status niezmienności tak, jak raportują go ustawienia repozytorium w samym Veeam, i utrzymuje w zasięgu wzroku listę kontrolną Security Analyzer z Veeam. Jego reguły alertów obejmują ruchy po stronie Veeam, jakie intruz wykonuje przeciwko kopiom zapasowym, takie jak zmiany poświadczeń, edycje retencji i harmonogramów, wyłączone zadania i sesje usuwania. Alerty są wysyłane e-mailem i jako powiadomienia w aplikacji. ZeroMON obserwuje Veeam: nie widzi zbierania poświadczeń na innych hostach i odczytuje ustawienia niezmienności z Veeam, zamiast sprawdzać blokady na samym magazynie danych.
• ZeroTAM zapewnia Twojemu zespołowi dedykowanego doradcę ds. bezpieczeństwa kopii zapasowych: przegląd architektury, planowanie odtwarzania po ransomware, planowanie pojemności i priorytetowe wsparcie w kryzysie. To miejsce, w którym można sprawdzić pod presją, czy separacja tożsamości, niezmienność i izolacja zostały zaprojektowane z myślą o atakującym działającym w ludzkim tempie.
• ZeroPEN to test penetracyjny ukierunkowany na zagrożenia, obejmujący Veeam Backup & Replication, Veeam ONE i Enterprise Manager. Symuluje łańcuch ataku ransomware w ośmiu etapach zmapowanych na MITRE ATT&CK, od dostępu początkowego i nadużycia poświadczeń, przez dostęp do repozytorium i neutralizację kopii zapasowych, aż po dowód zdolności do szyfrowania. Usługa obejmuje weryfikację integralności przywracania i niezmienności, dostarcza dowody gotowe do audytu i ponowny test dla krytycznych ustaleń. Jest niedestrukcyjna: ZeroPEN „never deletes real backups, performs real encryption, or stops production or backup services” (nigdy nie usuwa prawdziwych kopii zapasowych, nie wykonuje prawdziwego szyfrowania ani nie zatrzymuje usług produkcyjnych czy usług kopii zapasowych).

Pytanie, które stawia JADEPUFFER, nie brzmi, czy Twoja obrona jest szybka. Brzmi, czy Twoja architektura odtwarzania została zbudowana tak, by nie zależała od tego, czy obrona jest szybka.

Porozmawiaj z BackupSec o weryfikacji swojej architektury odtwarzania →

Ta analiza opiera się na badaniu Sysdig dotyczącym JADEPUFFER z lipca 2026 roku, raporcie IBM 2026 X-Force Threat Intelligence Index, raporcie Veeam 2024 Ransomware Trends Report oraz badaniu Sophos z 2024 roku dotyczącym skompromitowanych kopii zapasowych, a szczegóły podatności pochodzą z NVD i CISA. Przedstawiona tu interpretacja i ramy są autorstwa BackupSec. Aby omówić, jak ta analiza odnosi się do Twojego środowiska, skontaktuj się z naszym zespołem →