--- title: "Storm-3168 niszczył zasoby Azure i zbierał klucze dostępu" description: "Microsoft przeanalizował aktywność Storm-3168 w Azure, obejmującą rozpoznanie środowiska, usuwanie zasobów i pobieranie kluczy dostępu. Atak pokazuje, dlaczego organizacje powinny chronić tożsamości usług, ograniczać uprawnienia i zabezpieczać mechanizmy odzyskiwania." publisher: "Najnowsze Informacje" language: "pl-PL" canonical_url: "https://najnowsze-informacje.pl/cyberbezpieczenstwo/storm-3168-niszczyl-zasoby-azure-i-zbieral-klucze-dostepu" markdown_url: "https://najnowsze-informacje.pl/cyberbezpieczenstwo/storm-3168-niszczyl-zasoby-azure-i-zbieral-klucze-dostepu/index.md" date_published: "2026-09-25T18:38:05.869Z" date_modified: "2026-09-25T20:14:02.288Z" author: "Redakcja" category: "Cyberbezpieczeństwo" tags: - "cyberbezpieczeństwo" - "azure" - "ataki w chmurze" - "ransomware" - "storm-3168" source_url: "https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/" source_name: "Microsoft Security Blog" image_url: "https://najnowsze-informacje.pl/api/media/file/cyberbezpieczenstwo-unsplash-1790359320394.jpeg" image_alt: "A blue glass cloud icon with data layers above a silver padlock" image_credit: "© Growtika / Unsplash" image_credit_url: "https://unsplash.com/@growtika" --- # Storm-3168 niszczył zasoby Azure i zbierał klucze dostępu > Microsoft opisał atak Storm-3168 na środowisko Azure, w którym przejęte tożsamości usług usuwały zasoby i pobierały klucze dostępu. ## Kluczowe informacje - Dwie przejęte tożsamości usług działały w tym samym dzierżawcy Azure. - Napastnicy próbowali usuwać konta Storage, Key Vault, Function App i inne zasoby. - Część operacji zablokowały blokady zasobów oraz ochrona przed usunięciem. - Nie potwierdzono skutecznej eksfiltracji danych ani znalezienia notatki z żądaniem okupu. 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. ## Nowe dane o aktywności JADEPUFFER 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. ## Rozpoznanie środowiska poprzedziło destrukcję 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. - Około 90 minut po rozpoczęciu pierwszego rozpoznania drugi service principal wyliczył maszyny wirtualne i grupy zasobów w dwóch subskrypcjach w ciągu pięciu sekund. - Obie tożsamości korzystały z infrastruktury powiązanej ze Storm-3168, tego samego odcisku sieciowego oraz klienta python-requests/2.34.2. - Szesnaście godzin później druga tożsamość sprawdzała magazyny konfiguracji App Service, prawdopodobnie w poszukiwaniu ujawnionych poświadczeń. - Nieudana próba wyszukania zasobów Azure OpenSearch oraz późniejsze żądanie ListKey wobec nieistniejącego konta Storage poprzedziły operacje niszczące. 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. ## Usuwanie zasobów i próby osłabienia odzyskiwania 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. - Wykonano ponad 100 prób usunięcia kont Azure Storage, z których większość zakończyła się powodzeniem. - Usunięto Azure Key Vault, Function App i plan App Service należące do jednej grupy zasobów. - Próby usunięcia baz Azure SQL zakończyły się niepowodzeniem z powodu nieobsługiwanej wersji API. - Blokady zasobów oraz zabezpieczenia przed usunięciem ocaliły część kont Storage. - Podejmowano próby ingerencji w blokady związane z Azure Site Recovery i Azure Backup. ## Po destrukcji przyszła kolej na klucze dostępu 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. ## Co wynika z analizy Microsoftu 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. ## Znaczenie automatyzacji dla obrony chmury 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. ## Zalecenia dla administratorów 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ń. ## Wyjaśnienie pojęć ### [blokada zasobu](https://najnowsze-informacje.pl/definicje/blokada-zasobu) 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. ### [service principal](https://najnowsze-informacje.pl/definicje/service-principal) 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. ### [token uwierzytelniający](https://najnowsze-informacje.pl/definicje/token-uwierzytelniajacy) 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 najmniejszych uprawnień](https://najnowsze-informacje.pl/definicje/zasada-najmniejszych-uprawnien) Zasada bezpieczeństwa polegająca na przyznawaniu użytkownikowi, programowi lub usłudze wyłącznie uprawnień niezbędnych do wykonania określonych zadań. ## Źródło pierwotne [Microsoft Security Blog](https://www.microsoft.com/en-us/security/blog/2026/09/25/storm-3168-agentic-driven-cloud-attacks-using-compromised-service-principals/) --- ## Informacje do cytowania - **Autor:** Redakcja - **Data publikacji:** 2026-09-25T18:38:05.869Z - **Ostatnia aktualizacja:** 2026-09-25T20:14:02.288Z - **Kategoria:** Cyberbezpieczeństwo - **Adres kanoniczny:** [https://najnowsze-informacje.pl/cyberbezpieczenstwo/storm-3168-niszczyl-zasoby-azure-i-zbieral-klucze-dostepu](https://najnowsze-informacje.pl/cyberbezpieczenstwo/storm-3168-niszczyl-zasoby-azure-i-zbieral-klucze-dostepu) - **Wersja Markdown:** [https://najnowsze-informacje.pl/cyberbezpieczenstwo/storm-3168-niszczyl-zasoby-azure-i-zbieral-klucze-dostepu/index.md](https://najnowsze-informacje.pl/cyberbezpieczenstwo/storm-3168-niszczyl-zasoby-azure-i-zbieral-klucze-dostepu/index.md) **Sugerowane cytowanie:** > Najnowsze Informacje, „Storm-3168 niszczył zasoby Azure i zbierał klucze dostępu”, 2026-09-25, https://najnowsze-informacje.pl/cyberbezpieczenstwo/storm-3168-niszczyl-zasoby-azure-i-zbieral-klucze-dostepu