JadePuffer/Storm-3168: agentyczny aktor usuwa magazyn dzierżawcy Azure w 7-minutowym niszczycielskim zrywie

Microsoft Security Research poinformował 25 września 2026 r., że podmiot wykorzystujący dwie przejęte jednostki usługi (service principals) działał wewnątrz nienazwanego dzierżawcy Azure na początku czerwca 2026 r.; najpierw przez ponad 15 godzin prowadził rozpoznanie, a następnie w ciągu około siedmiu minut próbował usunąć ponad 100 kont magazynu, co udało mu się w przypadku większości z nich, oraz usunął Azure Key Vault, Function App i plan App Service. Microsoft przypisuje tę intruzję aktorowi, którego śledzi jako Storm-3168, którego firma zajmująca się bezpieczeństwem Sysdig nazywa JADEPUFFER i udokumentowała w lipcu 2026 r. jako pierwszą operację ransomware przeprowadzoną od początku do końca przez duży model językowy. Microsoft podał, że nie znalazł żadnej notatki okupowej i nie potwierdził, że jakiekolwiek dane zostały wyeksfiltrowane. Archiwum zapisuje tę kampanię jako incydent o wysokiej wadze z potwierdzonym udziałem AI i rzeczywistymi szkodami, a pełny wpis w Orca AI Incident Archive zawiera źródła, ocenę wagi i ocenę pewności.

Nazwa ofiary nie została podana. Raport Microsoftu opisuje pojedynczą dzierżawę Azure, należące do niej dwie przejęte jednostki usługi oraz podział pracy między nimi: jedna jednostka usługi zajmowała się rekonesansem przez około 15 godzin i 30 minut i wykonała ponad 300 udanych operacji odczytu, wyliczając maszyny wirtualne, subskrypcje, grupy zasobów i zasoby; druga przeprowadziła odkrywanie, operacje niszczące i zbieranie poświadczeń. Microsoft nie podał, ile organizacji zostało dotkniętych, i nie mógł ustalić, w jaki sposób jednostki usługi zostały po raz pierwszy przejęte.

Co pokazuje telemetria, po kolei

Drugi podmiot rozpoczął około 90 minut po rozpoczęciu działania pierwszego i w ciągu około pięciu sekund wyliczył maszyny wirtualne i grupy zasobów w dwóch subskrypcjach, według Microsoftu. Obie tożsamości korzystały z infrastruktury, którą Microsoft powiązał z Storm-3168, miały ten sam odcisk sieciowy i przedstawiały ten sam agent użytkownika, python-requests/2.34.2. Microsoft stwierdził, że czas i podział pracy „wyraźnie wskazują na wykonanie zautomatyzowane lub skryptowe”.

Około 16 godzin później drugi podmiot zabezpieczeń sprawdził magazyny konfiguracji Azure App Service pod kątem ujawnionych poświadczeń i bezskutecznie szukał Azure OpenSearch. Siedemdziesiąt sekund później spróbował wykonać operację ListKey na koncie magazynu, które nie istniało. Niecałą sekundę po tym nieudanym wywołaniu rozpoczęło się niszczenie. W ciągu następnych 35 minut Microsoft naliczył ponad 150 operacji niszczących lub zbierających poświadczenia; główna faza niszczenia trwała około siedmiu minut.

Siedem minut i kontrole, które się utrzymały

Microsoft podaje, że większość kont magazynu, które były celem aktora, została pomyślnie usunięta. Aktor usunął również Azure Key Vault, aplikację Function App i plan App Service, które znajdowały się w tej samej grupie zasobów i wydawały się obsługiwać Function App. Obieranie celów nie ograniczało się do magazynu: Microsoft odnotował wiele prób usunięcia blokad Azure Site Recovery i blokad ochrony Azure Backup oraz poinformował, że próby te zakończyły się niepowodzeniem.

Microsoft twierdzi, że nie wszystkie usunięcia się powiodły, a przyczyny różnią się w sposób istotny dla obrońców. Kilka kont magazynu przetrwało, ponieważ blokady zasobów Azure i ochrona przed usunięciem na poziomie konta magazynu zablokowały operację. Równoległe próby usunięcia baz danych Azure SQL nie powiodły się z innego powodu: każda z nich używała nieobsługiwanej wersji interfejsu API. Cloud Security Alliance określiła to jako błąd operacyjny, a nie zablokowaną akcję. Microsoft podsumował połączenie usuwania zasobów, prób ingerencji w proces odzyskiwania i gromadzenia poświadczeń jako „spójne z taktykami, które mogą wspierać operacje ransomware i wymuszania”.

Opis Microsoftu przedstawia zwykłe przypisania ról Azure, a nie wykorzystanie luk w samym Azure. Stwierdzono w nim, że przyznana grupie Storage Account Contributor rola umożliwiła zniszczenie zasobów magazynu, bezpośrednia rola Contributor umożliwiła usunięcie trzech zasobów aplikacji i kolejne pobranie klucza, a bezpośrednia rola SQL DB Contributor umożliwiła nieudane próby SQL. Microsoft zaobserwował pięć unikatowych tokenów wydanych dla drugiej jednostki usługi: cztery umożliwiały usuwanie, a piąty obsługiwał inwentaryzację magazynu i pobieranie kluczy. Dwa z tokenów do usuwania były aktywne w tym samym 70-sekundowym okresie. W raporcie zauważono również, że konta magazynu, których nazwy nawiązują do terraform i backup, znalazły się wśród celów, potencjalnie w celu utrudnienia odzyskiwania.

Zwrot kluczy do przechowalni

Około 30 minut po zakończeniu niszczenia wrócił ten sam podmiot. Zinwentaryzował konta magazynu i wykonał ponad 30 udanych żądań ListKeys, w tym wobec magazynu powiązanego z Site Recovery. Konto magazynu o podobnej nazwie w tej samej grupie zasobów zostało oszczędzone podczas fazy usuwania, a następnie pomyślnie wyświetlono dla niego klucze. Microsoft nie zaobserwował notatki z żądaniem okupu i nie potwierdził udanej eksfiltracji danych, ale stwierdził, że zebrane klucze mogą umożliwić przyszłą eksfiltrację.

Ta sekwencja zmienia znaczenie odzyskiwania, zdaniem Rossa Filipeka, dyrektora ds. bezpieczeństwa informacji w Corsica Technologies, który opowiedział o incydencie serwisowi CSO Online. Odbudowa usuniętych zasobów nie wystarczy, powiedział, ponieważ późniejsze żądania kluczy do magazynu mogą utworzyć kolejną ścieżkę do danych; zespoły reagujące muszą ustalić, których tożsamości i kluczy dotknięto, i przejrzeć ich użycie, zanim zaufają przywróconym usługom. „Gdy atakujący zdobędą tożsamość aplikacji, ich działania mogą wyglądać jak zwykłe administrowanie chmurą” — powiedział Filipek serwisowi CSO Online.

Jak wypłynęły dane uwierzytelniające

Microsoft nie był w stanie potwierdzić wektora początkowego dostępu. Ustalił natomiast ekspozycję: identyfikator klienta, klucz tajny klienta i identyfikator dzierżawy jednej z jednostek usługi pojawiły się w postaci jawnej w publicznym zgłoszeniu na GitHubie, opublikowanym przez pracownika dotkniętej organizacji. Zgłoszenie zostało później zmienione, ale Microsoft podał, że klucz tajny pozostał dostępny w publicznej historii edycji zgłoszenia. W raporcie wprost stwierdzono, że Microsoft nie mógł potwierdzić, czy użyto właśnie tego klucza tajnego.

Ostrzeżenie dołączone do tego ustalenia to praktyczna część. Microsoft twierdzi, że publicznie ujawnione dane uwierzytelniające należy traktować jako skompromitowane, natychmiast je unieważnić lub wymienić oraz zbadać pod kątem wcześniejszego wykorzystania; usunięcie lub zredagowanie ujawnionego sekretu nie unieważnia go, a publicznie ujawnione dane uwierzytelniające pozostają użyteczne, dopóki nie zostaną unieważnione lub wymienione.

Microsoft opisał również szersze sondowanie prowadzone przez infrastrukturę powiązaną ze Storm-3168 od początku 2026 r. wobec usług Azure App Services w zakresie administracji WordPress, PHP-CGI, punktu końcowego Langflow /api/v1/validate/code oraz ścieżek przypominających webshelle. Te cele nie pokrywały się z subskrypcjami ofiary, a Microsoft nie znalazł żadnej ścieżki z App Service do poświadczeń Azure Resource Manager. W raporcie wymieniono trzy wskaźniki: 45.131.66[.]106 w przypadku sondowania i złośliwych żądań ARM oraz 34.153.223[.]102 i 64.20.53[.]230 w przypadku sondowania App Service.

Ten sam podmiot, inna operacja

Raport Sysdig z 1 lipca 2026 r. jest powodem, dla którego słowo „agentic” w ogóle odnosi się do tego aktora. Sysdig opisał JADEPUFFER jako pierwszy udokumentowany przypadek ransomware opartego na agentach — „kompletną operację wymuszenia przeprowadzoną od początku do końca przez duży model językowy” — i stwierdził, że jego możliwości pochodziły od agenta AI, a nie od zestawu narzędzi obsługiwanego przez człowieka. W tym włamaniu aktor wykorzystał CVE-2025-3248 w wystawionej do internetu instancji Langflow, zaszyfrował 1342 elementy konfiguracji Nacos przy użyciu wbudowanej w MySQL AES_ENCRYPT() funkcji, usunął oryginalne tabele i pozostawił README_RANSOM tabelę z adresem Bitcoin i kontaktem Proton Mail. Sysdig zgłosił ponad 600 różnych ładunków, samonarrujący się kod oraz korygujący wieloetapowy ładunek, który pojawił się w ciągu 31 sekund po nieudanym logowaniu do Nacos. Sysdig stwierdził również, że nie miał wglądu w prompt systemowy ani konfigurację agenta.

Kampania Azure to odrębna operacja tego samego aktora, a nie powtórka lipcowej intruzji: chodziło o usuwanie i gromadzenie kluczy, a nie szyfrowanie, i Microsoft nie znalazł żadnej notatki z żądaniem okupu. Związek między oboma opiera się częściowo na infrastrukturze. Cloud Security Alliance zauważyła w notatce badawczej z 28 września, że dwa z adresów IP wymienionych przez Microsoft, 45.131.66[.]106 i 34.153.223[.]102, pojawiły się w lipcowych raportach Sysdig. Ta sama notatka ostrzegała, że samo ponowne użycie adresów IP nie pozwala wykluczyć współdzielonego hostingu osób trzecich.

Ustalony, oceniony i wciąż otwarty

Mechanika włamania do Azure jest dobrze udokumentowana. Autonomia nie jest udokumentowana według tego samego standardu, a ta różnica jest najważniejszym zastrzeżeniem w tym zapisie.

Ustalono na podstawie telemetrii Microsoftu: dwa przejęte podmioty usługi w jednej dzierżawie; ponad 300 udanych operacji odczytu w ciągu około 15 i pół godziny; ponad 100 prób usunięcia konta magazynu, z których większość zakończyła się sukcesem; usunięcie magazynu kluczy, aplikacji funkcyjnej i planu usługi App Service; usunięcia baz danych SQL, które wszystkie nie powiodły się z powodu nieobsługiwanej wersji interfejsu API; konta magazynu ocalone dzięki blokadom zasobów i ochronie przed usunięciem; ponad 30 udanych żądań ListKeys po dokonaniu zniszczeń; poświadczenia podmiotu usługi w postaci zwykłego tekstu w publicznym zgłoszeniu w GitHubie i jego historii edycji; nie zaobserwowano żadnej notatki z żądaniem okupu; i żadnego potwierdzonego wycieku danych.

Ocenione przez Microsoft: że działalność należy do Storm-3168; że połączenie usuwania, zakłócania odzyskiwania i zbierania kluczy jest spójne z ransomware i wymuszeniem; że wykonanie było prawdopodobnie zautomatyzowane lub skryptowe; oraz że zebrane klucze mogłyby wspierać przyszłą eksfiltrację. Publiczny raport Microsoft nie opisuje autonomicznego agenta, który przeprowadza rozumowanie przez kroki specyficzne dla Azure.

Otwarte: w jaki sposób jednostki usługi zostały po raz pierwszy przejęte; tożsamość ofiary i liczba dotkniętych organizacji; czy jakiekolwiek dane opuściły tenanta; oraz czy samymi operacjami Azure kierował agent AI, a nie skrypt.

Cloud Security Alliance dokładnie wskazało lukę dowodową w swojej notatce z 28 września: stwierdziło, że określenie „agentic” opiera się obecnie „na precyzji, tempie i podziale pracy między tożsamościami”, a nie na przechwyconych śladach rozumowania agenta. Dowody, których Sysdig użył w lipcu — samoopisujące się payloady i szybki cykl diagnozy i korekty — nie występują w publicznym zapisie kampanii Azure. Nick Tausek z firmy bezpieczeństwa Swimlane powiedział CSO Online, że dowody z Azure pokazują „skoordynowaną automatyzację, a nie dowód, że AI kierowała każdym krokiem”.

Relacje o ujawnieniu stosowały mocniejsze ujęcie. Nagłówek BleepingComputer opisywał „ataki agentowej AI” na Azure, a nagłówek Dark Reading opisywał „aktora AI” przełamującego dzierżawę Azure; raport samego Microsoftu stwierdza, że czas i podział pracy „zdecydowanie wskazują na wykonanie zautomatyzowane lub skryptowe”, i nie przypisuje poszczególnych kroków w Azure agentowi.

Archiwum ocenia ten rekord na poziom pewności A i nie oznacza go jako spornego. Etykieta „potwierdzonego” udziału AI w tym rekordzie opiera się na przypisaniu do JADEPUFFER — aktora, którego Sysdig udokumentował jako kierowanego przez LLM; nie jest to twierdzenie, że Microsoft przechwycił rozumowanie agenta podczas usunięć w Azure. Szkoda jest ustalona, automatyzacja jest ustalona, a autonomia jest wywnioskowana.

Co według Microsoftu powinno się zmienić

Zalecenia firmy Microsoft mają charakter operacyjny i wynikają bezpośrednio ze sposobu, w jaki doszło do tego wtargnięcia. Wzywają obrońców do włączenia odpowiednich planów Microsoft Defender for Cloud dla usług Resource Manager, Storage, Key Vault, App Service i Databases; do nieprzechowywania poświadczeń jednostki usługi, kluczy magazynu, ciągów połączeń i innych wpisów tajnych w kodzie źródłowym, konfiguracji, repozytoriach i zgłoszeniach; do używania Microsoft Entra Workload ID zamiast długotrwałych wpisów tajnych; do stosowania zasady najmniejszych uprawnień i przeglądania przypisań Azure RBAC dla tożsamości obciążeń; oraz do ograniczania i monitorowania zasobów kopii zapasowych i odzyskiwania, w tym prób zmiany ich mechanizmów ochrony.

Publiczny raport firmy Microsoft nie mówi, czy dzierżawca przywrócił swoje dane, czy ofiara została powiadomiona ani czy którekolwiek z zebranych kluczy zostały później wykorzystane. Tych wyników nie ma w materiale. Materiał zawiera jednak wymierny kontrast: blokady zasobów i ochrona przed usunięciem zablokowały niektóre operacje usuwania nawet w przypadku szeroko uprzywilejowanych tożsamości, podczas gdy bazy danych SQL ocalały z powodu błędu w wersji interfejsu API, a nie decyzji obrońcy. Relacja firmy Microsoft nie mówi, co dzierżawca zrobił następnie. Mówi natomiast, że sprawca spędził ponad 15 godzin na czytaniu, zanim poświęcił siedem minut na usuwanie.