Zdjęcie: © Growtika / Unsplash
Źródło: unsplash.com/photos/8zB4P0eafrs
Microsoft Security Research opisał aktywność przypisaną JADEPUFFER, grupie śledzonej przez Microsoft jako Storm-3168. Atakujący uzyskali dostęp do dwóch service principals w tym samym dzierżawcy Azure, a następnie wykorzystali je do rozpoznania środowiska, niszczenia zasobów oraz pozyskiwania kluczy dostępu. Operacje objęły między innymi konta Azure Storage, bazy SQL, magazyny Key Vault, aplikacje Function App, maszyny wirtualne i App Services.
JADEPUFFER został odkryty przez firmę Sysdig w lipcu 2026 roku i był opisywany jako pierwsza udokumentowana operacja ransomware wykorzystująca podejście agentic. Najnowsza analiza Microsoftu poszerza publicznie dostępny obraz tej działalności o szczegółowy opis operacji w Azure. Badacze podkreślają, że nie chodziło wyłącznie o pojedyncze usunięcie zasobu, lecz o szeroki ciąg działań obejmujący rozpoznanie, destrukcję i próby uzyskania poświadczeń umożliwiających dostęp do danych.
W badanym środowisku jedna z przejętych tożsamości usług służyła przede wszystkim do rozpoznania. Druga wykonywała rozpoznanie, operacje niszczące i pobieranie kluczy. Service principal nie jest zwykłym kontem pracownika, lecz tożsamością używaną przez aplikację, usługę lub automatyzację. Jeśli taka tożsamość ma szerokie uprawnienia, jej przejęcie może pozwolić na wykonywanie zmian w wielu zasobach bez konieczności logowania się do każdego z nich osobno.
Słownik artykułu
Krótkie objaśnienia terminów występujących w tekście. Każde hasło prowadzi do szerszej definicji i przykładów użycia.
Dodatkowe zabezpieczenie zasobu chmurowego przed określonymi zmianami, w tym przed usunięciem. Może pozostać skuteczne nawet wtedy, gdy przejęta tożsamość ma szerokie uprawnienia administracyjne.
Tożsamość używana przez aplikację, usługę lub automatyzację do wykonywania operacji w chmurze. Jej uprawnienia i poświadczenia mogą pozwalać na dostęp do zasobów bez udziału człowieka.
Ciąg danych potwierdzający tożsamość użytkownika lub jego uprawnienie do dostępu do usługi. Może zastępować hasło albo działać jako dodatkowy element uwierzytelniania.
Zasada bezpieczeństwa polegająca na przyznawaniu użytkownikowi, programowi lub usłudze wyłącznie uprawnień niezbędnych do wykonania określonych zadań.
Aktywność rozpoczęła się na początku czerwca 2026 roku. Pierwszy przejęty service principal przez około 15 godzin i 30 minut wyliczał maszyny wirtualne, subskrypcje, grupy zasobów i inne elementy środowiska Azure. W tym czasie wykonał ponad 300 udanych operacji odczytu. Tak szeroki zakres rozpoznania dawał napastnikom obraz organizacji, jej podziału na subskrypcje i grupy zasobów oraz rozmieszczenia usług.
Microsoft odnotował, że mniej niż sekundę po nieudanym żądaniu ListKey druga przejęta tożsamość rozpoczęła działania destrukcyjne. W ciągu 35 minut wykonała ponad 150 operacji związanych z usuwaniem zasobów lub pozyskiwaniem poświadczeń. Sama sekwencja destrukcyjna trwała około siedmiu minut. Tak krótki odstęp pomiędzy rozpoznaniem a zmianami w środowisku wskazuje na automatyzację działań i wcześniejsze przygotowanie kolejnych operacji.
Największą część operacji stanowiły próby usunięcia kont Azure Storage. Napastnicy wykonali ponad 100 takich żądań, a większość wskazanych kont została skutecznie usunięta. Niektóre próby zablokowały blokady zasobów oraz ochrona przed usunięciem ustawiona na poziomie kont Storage. To istotny element analizy, ponieważ niezależne zabezpieczenia pozostały skuteczne nawet wtedy, gdy przejęta tożsamość dysponowała szerokimi uprawnieniami administracyjnymi.
Usunięto także magazyn Azure Key Vault, aplikację Function App oraz plan App Service. Wszystkie te elementy należały do tej samej grupy zasobów i wyglądały na powiązane z aplikacją Function App. Równolegle druga tożsamość próbowała usuwać bazy Azure SQL. Żadna z tych prób się nie powiodła, ponieważ użyto nieobsługiwanej wersji interfejsu API dla tego typu zasobu.
Atakujący podejmowali również nieudane próby usunięcia blokad Azure Site Recovery i Azure Backup, które chroniły konta Storage. Wśród celów znalazły się zasoby o nazwach kojarzących się z tworzeniem kopii zapasowych i mechanizmami odzyskiwania. Microsoft wskazuje, że może to oznaczać próbę ograniczenia zdolności organizacji do odtworzenia środowiska po usunięciu danych. Jednoczesne kierowanie działań przeciwko kontom Storage i bazom SQL sugeruje zamiar rozszerzenia skutków na różne usługi danych.
Około 30 minut po ostatniej operacji destrukcyjnej ta sama przejęta tożsamość ponownie zinwentaryzowała konta Azure Storage, a następnie wykonała ponad 30 udanych żądań ListKeys. Operacja polegała na pobraniu kluczy dostępu do poszczególnych kont. Wśród sprawdzanych zasobów znajdowały się także konta powiązane z Azure Site Recovery. Posiadanie takich kluczy może umożliwić dostęp do danych przechowywanych w danym zasobie, dlatego ich pobieranie po serii usunięć było szczególnie istotne z punktu widzenia obrony.
Microsoft zaobserwował pięć unikatowych tokenów wydanych dla tożsamości odpowiedzialnej za usuwanie i pobieranie kluczy. Cztery tokeny obsługiwały operacje usuwania, a piąty służył do inwentaryzacji Storage i pobierania kluczy. Dwa tokeny wykorzystywane do usuwania były aktywne w tym samym 70-sekundowym okresie. Jeden koncentrował się na kontach Storage, a drugi łączył operacje dotyczące Storage i SQL. Podział zadań, nakładanie się tokenów oraz bardzo krótkie odstępy między żądaniami wskazują na skryptowe lub zautomatyzowane wykonanie sekwencji.
Analiza uprawnień pokazała, że działania mieściły się w zakresie istniejących ról Azure. Grupowo przyznana rola Storage Account Contributor umożliwiała operacje destrukcyjne na kontach Storage. Bezpośredni dostęp Contributor pozwolił na usunięcie trzech zasobów aplikacyjnych oraz na jedno dodatkowe udane pobranie klucza. Bezpośrednia rola SQL DB Contributor umożliwiała próby usunięcia baz SQL, choć w tym przypadku nie doszło do skutecznej destrukcji z powodu błędnej wersji API.
W jednym przypadku podobnie nazwane konto Storage w tej samej grupie zasobów nie zostało usunięte razem z powiązanymi zasobami aplikacyjnymi. Później ta sama przejęta tożsamość skutecznie wykonała wobec niego operację ListKeys. Ten szczegół pokazuje, że celem nie było wyłącznie masowe usuwanie, lecz także selektywne zachowanie dostępu do zasobów, które mogły zawierać dane lub przydatne poświadczenia.
Zestawienie usuwania zasobów, prób ingerencji w mechanizmy kopii zapasowych i odzyskiwania oraz pobierania kluczy jest zgodne z taktykami, które mogą wspierać ransomware i szantaż. Microsoft nie zaobserwował jednak notatki z żądaniem okupu i nie potwierdził skutecznej eksfiltracji danych w opisanej aktywności. Z tego powodu analiza pokazuje potwierdzone działania napastników, ale nie przesądza, czy doszło do pełnego scenariusza wymuszenia.
Microsoft przedstawia Storm-3168 jako przykład szerszego przesunięcia w stronę ataków koordynowanych z użyciem automatyzacji i narzędzi AI. W badanym przypadku o automatycznym charakterze świadczą przede wszystkim chronologia żądań, podział pracy między dwie tożsamości, równoległe wykorzystanie tokenów oraz tempo operacji. Taki model pozwala szybko przejść od rozpoznania do zmian w dużej liczbie zasobów, co utrudnia ręczne analizowanie każdego pojedynczego zdarzenia przez zespoły bezpieczeństwa.
Wśród podstawowych zaleceń Microsoft wymienia ochronę tożsamości obciążeń i ich sekretów, stosowanie zasady najmniejszych uprawnień oraz zabezpieczanie zasobów używanych do odzyskiwania. Organizacje powinny szczególnie sprawdzać, czy service principals mają dostęp do usuwania wielu typów zasobów, czy role są przyznawane grupowo bez wyraźnej potrzeby oraz czy klucze i inne poświadczenia mogą być pobierane przez automatyzację. Warto także monitorować nietypowe sekwencje obejmujące masową inwentaryzację, usuwanie zasobów i żądania ListKeys.
Jeżeli poświadczenia zostały ujawnione, samo usunięcie miejsca, w którym je opublikowano, nie wystarcza. Pozostają użyteczne do czasu ich odwołania lub rotacji, dlatego konieczne jest unieważnienie i zastąpienie takich danych. Niezależne blokady zasobów oraz ochrona kont i usług związanych z kopiami zapasowymi mogą ograniczyć skutki przejęcia szeroko uprzywilejowanej tożsamości. Microsoft wskazuje również na wykorzystanie narzędzi Defender do wykrywania i analizy oraz na wsparcie AI przy badaniu dużej liczby zdarzeń.
Brak komentarzy. Bądź pierwszy!