Spirals: od web shella do szyfrowania w niecałą dobę

Zespół Threat Hunter firmy Symantec opisał nową rodzinę ransomware o nazwie Spirals, użytą przeciwko firmie świadczącej usługi IT w Azji Południowej. Liczba, która robi największe wrażenie: od włamania do zaszyfrowania całej sieci minęło mniej niż 24 godziny.

Ta oś czasu jest ważniejsza niż sam malware. Napisany w Ruście ładunek jest solidny, ale nie rewolucyjny. Rewolucyjne — a właściwie: konsekwentnie doskonalone od lat — jest tempo operacji. Jeszcze niedawno mediana czasu przebywania napastnika w sieci przed uderzeniem liczona była w tygodniach. Tutaj cały cykl zamknął się w jednej dobie, co ma bezpośrednie przełożenie na to, jak musi wyglądać obrona.

Poniżej rekonstruujemy przebieg ataku krok po kroku i — co ważniejsze — wskazujemy konkretne momenty, w których dało się go zatrzymać.

Oś czasu: doba, która zakończyła się szyfrowaniem

16 czerwca, 22:21 — wejście

Atak zaczyna się od kompromitacji serwera IIS wystawionego do internetu i wgrania web shella ASP.NET. Godzina nie jest przypadkowa: późny wieczór to standardowy wybór, bo redukuje szansę, że ktoś zauważy anomalię w czasie rzeczywistym.

Web shell to niewielki plik umieszczony w katalogu serwowanym przez serwer WWW, dający napastnikowi możliwość wykonywania poleceń przez zwykłe żądania HTTP. Jego zaletą z perspektywy atakującego jest to, że nie wymaga instalowania niczego — działa w kontekście istniejącego, zaufanego procesu serwera.

W ciągu minut — trzy niezależne tunele

Zaraz po uzyskaniu dostępu napastnicy wdrażają trzy osobne narzędzia tunelujące, w tym Chisel podszywający się pod chrome.exe oraz klienta tuneli Cloudflare. Do tego dochodzi narzędzie do podszywania się pod tokeny (token impersonation), prawdopodobnie użyte do eskalacji uprawnień.

Ta redundancja jest świadomą decyzją operacyjną. Trzy niezależne kanały komunikacji oznaczają, że odcięcie jednego nie kończy operacji. Jeśli obrońca zauważy i zablokuje jeden tunel, dwa pozostałe działają dalej — a napastnik dowiaduje się, że został wykryty.

Warto zwrócić uwagę na dobór narzędzi. Chisel to legalne, otwartoźródłowe oprogramowanie do tunelowania. Klient Cloudflare to komponent powszechnie używanej usługi. Oba wtapiają się w normalny ruch i nie są klasycznym malware’em, więc detekcja oparta na sygnaturach ma z nimi trudność. Nazwanie binarki chrome.exe to dodatkowa warstwa maskowania, licząca na to, że nikt nie sprawdzi, skąd uruchamiana jest przeglądarka.

23:33 — ruch boczny przez WMI

Nieco ponad godzinę po wejściu napastnicy przechodzą do ruchu bocznego z wykorzystaniem WMI, w ciągu kilku minut sięgając po kilkanaście maszyn. Używają przy tym przejętych poświadczeń administratora domeny.

To najważniejszy moment całej operacji i wart osobnego podkreślenia: od web shella na serwerze WWW do poświadczeń administratora domeny minęła około godzina. Raport nie precyzuje, w jaki sposób te poświadczenia zdobyto, ale typowe ścieżki są dobrze znane: wydobycie z pamięci procesu po eskalacji uprawnień, konto usługowe o nadmiarowych uprawnieniach albo poświadczenia zapisane w konfiguracji aplikacji.

WMI (Windows Management Instrumentation) to wbudowany mechanizm zarządzania Windows. Jego użycie do ruchu bocznego jest przykładem techniki living off the land — napastnik nie wnosi własnych narzędzi, tylko wykorzystuje to, co system oferuje natywnie i co administratorzy wykorzystują na co dzień. Dlatego samo „użycie WMI” nie jest alarmem; alarmem jest kto, skąd i do ilu maszyn go używa.

17 czerwca — masowe wdrożenie przez PsExec

Następnego dnia operacja przechodzi w fazę skalowania. Głównym narzędziem staje się PsExec: pojedynczy przejęty host rozsyła identyczny ładunek PowerShell zakodowany w base64 do kolejnych celów w sieci — co kilka sekund, przez około 30 minut.

Ten wzorzec jest z perspektywy detekcji wręcz krzyczący. Jedna maszyna nawiązująca połączenia administracyjne do dziesiątek innych, w równych, kilkusekundowych odstępach, z identycznym ładunkiem — to zachowanie, które nie ma żadnego odpowiednika w normalnej pracy. Jeśli jakikolwiek moment tej operacji miał być wykryty automatycznie, to właśnie ten.

Finał — szyfrowanie

Ładunek Spirals to pełnowymiarowy ransomware napisany w Ruście, z funkcjami obejmującymi omijanie zabezpieczeń, szyfrowanie, ruch boczny, zabijanie procesów, obfuskację i eskalację uprawnień. Przed szyfrowaniem operacja wyłącza usługi bezpieczeństwa i zakłóca kopie zapasowe — standardowy element współczesnych kampanii, wymierzony w zdolność ofiary do odtworzenia się bez płacenia.

Symantec zauważa, że ładunek wygląda na całkowicie nowy albo przygotowany specjalnie pod ten jeden atak, a sprawca pozostaje niezidentyfikowany.

Dlaczego Rust i dlaczego to ma znaczenie

Wybór języka nie jest przypadkowy i wpisuje się w wyraźny trend ostatnich lat.

Trudniejsza analiza. Binaria kompilowane z Rusta są dla analityków wsteczna trudniejsze niż odpowiedniki w C. Agresywne optymalizacje, wplecione mechanizmy obsługi błędów i sposób generowania kodu sprawiają, że rekonstrukcja logiki zajmuje więcej czasu — a czas analityka to realny koszt po stronie obrony.

Słabsze pokrycie sygnaturami. Narzędzia detekcyjne mają dekady doświadczeń z malware’em pisanym w C i C++. Nowsze języki oznaczają mniejszą bazę reguł i heurystyk.

Łatwa wieloplatformowość. Ten sam kod można skompilować na Windowsa i Linuksa niewielkim nakładem, co upraszcza atakowanie środowisk mieszanych.

Wydajność. Szyfrowanie dużych wolumenów danych jest zadaniem obliczeniowo intensywnym; język bez narzutu maszyny wirtualnej po prostu robi to szybciej, skracając okno na reakcję.

Praktyczny wniosek dla obrońcy: detekcja oparta na sygnaturach plików będzie coraz mniej skuteczna. Skoro ładunek bywa pisany pod jedną kampanię i kompilowany w języku o słabszym pokryciu, obrona musi opierać się na zachowaniu: kto uruchamia procesy zdalnie, kto masowo modyfikuje pliki, kto wyłącza usługi bezpieczeństwa.

Gdzie dało się to przerwać

To najważniejsza część analizy. Atak miał kilka wyraźnych punktów, w których automatyczna reakcja zatrzymałaby operację przed szyfrowaniem.

Moment	Sygnał	Możliwa reakcja
22:21	Nowy plik `.aspx` w katalogu IIS	Alarm na zmiany w katalogach serwowanych; blokada zapisu
minuty później	Serwer WWW uruchamia procesy potomne	Alarm — `w3wp.exe` nie powinien uruchamiać powłoki
minuty później	Nowe binaria w katalogach tymczasowych; `chrome.exe` poza standardową ścieżką	Kontrola aplikacji (allowlisting); alarm na nietypową lokalizację
minuty później	Trwałe połączenia wychodzące do usług tunelowania	Kontrola egressu; allowlista domen
23:33	Zdalne wykonanie przez WMI do kilkunastu hostów w kilka minut	Alarm progowy; automatyczna izolacja hosta źródłowego
17.06	PsExec rozsyłający identyczny ładunek co kilka sekund	Alarm o wysokim priorytecie; natychmiastowa izolacja
przed szyfrowaniem	Zatrzymywanie usług bezpieczeństwa, kasowanie kopii	Ochrona przed manipulacją (tamper protection); niezmienne kopie

Zwróć uwagę, że żaden z tych sygnałów nie wymaga wykrycia samego ransomware’u. Wszystkie dotyczą etapów poprzedzających — a więc momentów, w których szkoda jest jeszcze odwracalna. Właśnie dlatego inżynieria detekcji nastawiona na techniki, a nie na próbki, jest dziś skuteczniejsza niż kolejny skaner.

Wnioski praktyczne

Serwery wystawione do internetu to nadal wejście numer jeden

Wszystko zaczęło się od serwera IIS osiągalnego z sieci. Podstawy pozostają niezmienne: aktualizacje w krótkim cyklu, minimalna liczba wystawionych usług, WAF przed aplikacjami webowymi oraz — najważniejsze — monitorowanie katalogów serwowanych pod kątem nowych plików wykonywalnych. Web shell musi gdzieś wylądować; wykrycie zapisu w katalogu aplikacji jest prostą i skuteczną regułą.

Godzina od web shella do administratora domeny to problem tożsamości

Jeśli napastnik przechodzi z serwera WWW do poświadczeń administratora domeny w godzinę, znaczy to, że te poświadczenia były w zasięgu. Kierunki naprawcze:

brak logowania kontami administratora domeny na zwykłych serwerach (model warstw/tieringu),
osobne konta administracyjne dla stacji, serwerów i domeny,
ochrona poświadczeń w pamięci (Credential Guard i pokrewne),
konta usługowe o minimalnych uprawnieniach zamiast „na wszelki wypadek administrator”,
monitorowanie użycia kont uprzywilejowanych z nietypowych hostów.

Szerzej omawiamy to przy bezpieczeństwie Active Directory i atakach relay w AD.

Segmentacja kupuje czas, którego brakuje najbardziej

W płaskiej sieci ruch boczny przez WMI i PsExec jest trywialny. Segmentacja nie zapobiega włamaniu, ale spowalnia jego rozprzestrzenianie — a przy operacji zamkniętej w 24 godzinach każde spowolnienie realnie zwiększa szansę na reakcję. Praktycznie: ogranicz ruch administracyjny (SMB, WMI, RPC) między stacjami i serwerami do wyznaczonych hostów zarządzających (testy segmentacji).

Kopie muszą przetrwać napastnika, nie tylko awarię

Operacja celowo zakłóciła kopie zapasowe przed szyfrowaniem. Kopia dostępna z tej samej domeny, na tych samych poświadczeniach, jest w takim scenariuszu bezużyteczna. Wymagania minimum: kopie niezmienne lub offline, poza domeną produkcyjną, oraz regularnie testowane odtworzenie całego środowiska (strategia 3-2-1).

Detekcja musi działać w nocy

Atak zaczął się o 22:21, a kluczowa faza ruchu bocznego nastąpiła o 23:33. Model „SOC w godzinach pracy” nie ma tu zastosowania. Jeśli nie stać Cię na całodobowy zespół, alternatywą jest automatyczna reakcja: izolacja hosta przy spełnieniu twardych warunków, bez czekania na decyzję człowieka. Lepiej odłączyć jedną maszynę niepotrzebnie niż odtwarzać całą sieć — o kompromisach piszemy przy monitoringu bezpieczeństwa dla MŚP.

Trzy liczby, które warto znać dla własnej sieci

Analiza cudzego incydentu ma sens tylko wtedy, gdy zamienia się w pytania o własne środowisko. Przy tym scenariuszu warto znać trzy konkretne wielkości.

Czas od zapisu pliku w katalogu WWW do alarmu. Web shell jest pierwszym artefaktem całej operacji. Jeśli nie masz monitorowania integralności katalogów serwowanych, ta liczba wynosi w praktyce „nigdy”. Jeśli masz — sprawdź, czy alarm faktycznie dociera do kogoś o 22:21, czy tylko ląduje w kolejce do przejrzenia rano.

Czas od zwykłego konta do administratora domeny. To jedyna liczba, która realnie opisuje odporność Twojej sieci wewnętrznej. W opisanym ataku wyniosła około godziny. Nie da się jej ustalić inaczej niż testem — i właśnie dlatego wewnętrzne testy penetracyjne startujące z założenia „napastnik ma przyczółek” są wartościowsze niż skanowanie z zewnątrz.

Czas do odtworzenia usług krytycznych z kopii. Nie „czy mamy backup”, tylko ile godzin zajmie przywrócenie działania, przy założeniu, że domena jest skompromitowana, a kopie dostępne przez konta domenowe są bezużyteczne. Jeżeli tej liczby nikt nie zna, plan ciągłości istnieje wyłącznie na papierze.

Warto te trzy wartości zmierzyć raz, zapisać i traktować jako punkt odniesienia. Poprawa którejkolwiek z nich przekłada się bezpośrednio na skutki realnego incydentu — w przeciwieństwie do większości metryk raportowanych w narzędziach bezpieczeństwa.

Najczęstsze pytania (FAQ)

Czy 24 godziny to nowy standard? To wyraźny kierunek. Jeszcze kilka lat temu napastnicy spędzali w sieci tygodnie, prowadząc rozpoznanie. Dziś część operacji jest mocno zautomatyzowana i domyka cykl w dobę lub szybciej. Planując reakcję, przyjmij, że masz godziny, nie dni — a przy operacjach wspieranych automatyzacją nawet mniej.

Jesteśmy małą firmą — czy dotyczy nas atak na firmę IT? Tak, z dwóch powodów. Po pierwsze, technika jest uniwersalna i tania. Po drugie, dostawcy usług IT są celem ze względu na dostęp do klientów — kompromitacja jednego partnera potrafi otworzyć drzwi do wielu firm, co opisujemy przy ryzyku dostawców.

Czy antywirus wykryłby Spirals? Ładunek wygląda na przygotowany pod jedną kampanię, więc sygnatury nie miały prawa go znać w momencie ataku. Wykrywalne były natomiast zachowania: web shell, tunele, zdalne wykonanie przez WMI i PsExec, zatrzymywanie usług bezpieczeństwa. Obrona oparta wyłącznie na sygnaturach jest w takim scenariuszu spóźniona.

Od czego zacząć, jeśli mamy ograniczony budżet? Od czterech rzeczy o najlepszym stosunku efektu do kosztu: monitorowania zapisu plików w katalogach serwerów WWW, alarmu na procesy potomne serwera aplikacyjnego, ograniczenia ruchu administracyjnego między stacjami oraz testowanej kopii offline. To wykrywa lub blokuje większość kroków opisanej operacji.

Jak sprawdzić, czy nasza sieć wytrzymałaby taki scenariusz? Kontrolowany test wewnętrzny startujący z założenia „napastnik ma web shell na serwerze WWW” pokazuje realną drogę do administratora domeny i czas, w jakim da się ją przejść. Odezwij się, jeśli chcesz to zweryfikować.

Podsumowanie

Spirals nie jest ciekawy dlatego, że jest napisany w Ruście — choć to utrudnia analizę. Jest ciekawy dlatego, że pokazuje skalę kompresji czasu: web shell o 22:21, poświadczenia administratora domeny i ruch boczny o 23:33, masowe wdrożenie następnego dnia, szyfrowanie przed upływem doby.

Wnioski są przyziemne i wykonalne. Napastnik wszedł przez wystawiony serwer, awansował do administratora domeny w godzinę, poruszał się natywnymi narzędziami Windows i zadbał o zniszczenie kopii, zanim zaszyfrował dane. Każdy z tych kroków zostawia sygnał, który da się wykryć bez znajomości konkretnego malware’u. Pytanie brzmi nie „czy mamy antywirusa”, tylko „czy o 23:33 ktokolwiek — lub cokolwiek — zareaguje”. Jeśli chcesz sprawdzić, jak wygląda ta odpowiedź w Twojej organizacji — przetestujmy to razem.

Źródła i dalsza lektura: Symantec Threat Hunter Team, Help Net Security, CISA — StopRansomware, MITRE ATT&CK.