Wprowadzenie do problemu / definicja
Nowe ustalenia dotyczące aktywności klastra JADEPUFFER pokazują, że tożsamości aplikacyjne w chmurze stają się pełnoprawnym celem operacji destrukcyjnych. W analizowanym incydencie napastnicy powiązani z grupą śledzoną jako Storm-3168 wykorzystali skompromitowane service principals w środowisku Microsoft Azure do rozpoznania zasobów, prób pozyskania poświadczeń oraz usuwania kluczowych elementów infrastruktury.
To istotna zmiana perspektywy dla obrońców. Service principal, często traktowany jako techniczny komponent integracji między aplikacjami i usługami, w praktyce może mieć uprawnienia pozwalające na masowe operacje administracyjne. Jeśli takie konto zostanie przejęte, atakujący może działać bez potrzeby uzyskiwania interaktywnego dostępu do stacji roboczych czy serwerów.
W skrócie
Według opisu incydentu atak trwał około 18 godzin i obejmował użycie dwóch skompromitowanych service principals w ramach jednego tenanta Azure. Jeden z nich służył głównie do rekonesansu i enumeracji zasobów, a drugi do działań destrukcyjnych oraz prób pozyskiwania danych uwierzytelniających.
- napastnicy wykonali setki operacji odczytu w celu mapowania środowiska,
- w krótkim czasie przeprowadzili ponad 100 prób usunięcia kont Azure Storage,
- celem były także między innymi Key Vault, Function Apps, App Services oraz bazy Azure SQL,
- część zabezpieczeń ograniczyła skuteczność ataku, ale nie zapobiegła wszystkim usunięciom,
- charakter operacji wskazuje na scenariusz zbliżony do ransomware wymierzonego w warstwę zarządzania chmurą.
Kontekst / historia
JADEPUFFER był już wcześniej łączony z kampaniami określanymi jako agentic ransomware, czyli zautomatyzowanymi operacjami, w których kolejne etapy ataku są sekwencjonowane z użyciem narzędzi wspierających podejmowanie działań ofensywnych. W poprzednich analizach grupa była opisywana w kontekście uzyskiwania dostępu początkowego, kradzieży poświadczeń, ruchu lateralnego oraz niszczenia danych.
Obecny przypadek rozwija ten model o warstwę chmury publicznej. Zamiast klasycznego wdrażania szyfratora na wielu hostach końcowych, atakujący skupili się na płaszczyźnie zarządzania Azure. To podejście pozwala szybciej wywołać efekt operacyjny, ponieważ kompromitacja jednej uprzywilejowanej tożsamości maszynowej może otworzyć drogę do szerokiego zasięgu działań w wielu usługach jednocześnie.
Analiza techniczna
Kluczowym elementem incydentu była kompromitacja poświadczeń service principal. Z ustaleń wynika, że client ID, client secret i tenant ID miały zostać wcześniej ujawnione publicznie w zgłoszeniu na GitHub. Nawet po usunięciu sekretu z widocznej treści nadal pozostawał on dostępny w historii zmian, co stworzyło realną ścieżkę przejęcia tożsamości.
Po uzyskaniu dostępu napastnicy rozdzielili zadania pomiędzy dwa service principals. Pierwszy odpowiadał za długotrwałą enumerację zasobów, obejmującą między innymi maszyny wirtualne, subskrypcje, grupy zasobów i inne elementy tenanta. W tej fazie wykonano ponad 300 operacji odczytu, co wskazuje na metodyczne przygotowanie przed przejściem do właściwego ataku.
Drugi principal został wykorzystany do dodatkowego rozpoznania, a następnie do działań o wysokim wpływie. Po około 16 godzinach aktywności atakujący analizowali konfiguracje App Service, prawdopodobnie w poszukiwaniu zapisanych sekretów i poświadczeń aplikacyjnych. Następnie w ciągu około 35 minut wykonali ponad 150 operacji związanych z destrukcją środowiska lub pozyskiwaniem danych uwierzytelniających.
Najbardziej intensywna faza trwała około siedmiu minut i obejmowała ponad 100 prób usunięcia Azure Storage Accounts. Atak objął również Azure Key Vault, Function App, App Service Plan oraz wiele baz Azure SQL. Próby usuwania części baz nie powiodły się z przyczyny technicznej, ponieważ wykorzystano nieobsługiwaną wersję API dla danego typu zasobu. To pokazuje, że nawet przy szerokich uprawnieniach skuteczność operacji w chmurze zależy od poprawności wywołań wobec interfejsów zarządzania.
Po fazie destrukcyjnej zaobserwowano także udane operacje pobierania kluczy dostępowych do kont magazynu. Sugeruje to, że kampania mogła łączyć sabotaż z próbami uzyskania dalszego dostępu do danych. Dodatkowo wzorce czasowe i podział zadań między kilka tożsamości wskazują, że aktywność była w znacznym stopniu zautomatyzowana lub oparta na skryptach.
Konsekwencje / ryzyko
Największe zagrożenie w tego typu incydencie wynika z połączenia uprzywilejowanej tożsamości maszynowej, natywnego dostępu do funkcji zarządzania chmurą oraz bardzo szybkiego tempa wykonywania operacji. Jeśli service principal ma szerokie uprawnienia, napastnik może usuwać magazyny danych, usługi aplikacyjne, sekrety, blokady ochronne i elementy odpowiedzialne za odtwarzanie środowiska.
Z biznesowego punktu widzenia oznacza to ryzyko poważnych przestojów, utraty integralności środowiska oraz wydłużonego czasu przywracania usług. Szczególnie groźny jest scenariusz, w którym atakujący celowo niszczy mechanizmy backupu i recovery, ponieważ utrudnia to odbudowę bez ponoszenia wysokich kosztów i bez długiego okresu niedostępności.
Incydent ten podkreśla również wagę problemu wycieków sekretów w publicznych repozytoriach, systemach zgłoszeń i historiach edycji. Nawet krótkotrwałe ujawnienie client secret może wystarczyć do pełnej kompromitacji tożsamości aplikacyjnej, a konsekwencje takiego błędu mogą być porównywalne z przejęciem konta uprzywilejowanego administratora.
Rekomendacje
Organizacje korzystające z Azure powinny potraktować service principals jak zasoby krytyczne i uprzywilejowane. Pierwszym krokiem powinien być przegląd wszystkich tożsamości aplikacyjnych, ich uprawnień oraz sposobów uwierzytelniania.
- ograniczyć role zgodnie z zasadą najmniejszych uprawnień,
- zastępować sekrety mechanizmami managed identity lub certyfikatami tam, gdzie to możliwe,
- wdrożyć ciągłe skanowanie repozytoriów, ticketów, wiki i pipeline’ów pod kątem wycieków sekretów,
- po każdym ujawnieniu natychmiast rotować client secrets i analizować logi użycia,
- monitorować anomalie w aktywności service principals, zwłaszcza masową enumerację i sekwencje operacji usuwania,
- utrzymywać resource locks, soft delete, purge protection oraz niezależne kopie zapasowe,
- opracować procedury reagowania specyficzne dla tożsamości maszynowych, obejmujące szybkie wyłączenie principal, przegląd RBAC i walidację integralności środowiska.
W praktyce szczególnie ważne jest monitorowanie działań dotyczących Key Vault, pobierania kluczy dostępowych, usuwania storage accounts oraz prób modyfikacji mechanizmów ochronnych. To właśnie takie sygnały mogą wskazywać, że atakujący przeszedł z fazy rozpoznania do fazy destrukcyjnej.
Podsumowanie
Aktywność Storm-3168 pokazuje wyraźną zmianę w charakterze ataków na środowiska chmurowe. Zamiast koncentrować się wyłącznie na hostach końcowych, napastnicy coraz częściej przejmują tożsamości aplikacyjne i wykorzystują natywne mechanizmy zarządzania platformą do niszczenia zasobów na dużą skalę.
Dla zespołów bezpieczeństwa najważniejszy wniosek jest jednoznaczny: ochrona service principals nie może być traktowana jako zadanie drugorzędne. Ograniczanie uprawnień, eliminowanie wycieków sekretów, wzmacnianie zabezpieczeń niezależnych od tożsamości oraz budowa detekcji ukierunkowanej na anomalie w aktywności kont maszynowych stają się dziś jednym z kluczowych elementów bezpieczeństwa chmury.
Źródła
- The Hacker News — https://thehackernews.com/2026/09/jadepuffer-linked-attackers-used.html
- Microsoft Security Blog: Storm-3168: Agentic-driven cloud attacks using compromised service principals — https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/
- Microsoft Security Blog — https://www.microsoft.com/en-us/security/blog/