Ransomware jest jedynym rodzajem zagrożenia, o którym rozmawia się w kategoriach kosztu odtworzenia, a nie kosztu incydentu. Powód jest prosty: skutek jest natychmiastowy, mierzalny i widoczny dla całej organizacji.
W tej części cyklu patrzę na to, jak Sophos Endpoint podchodzi do tej klasy ataków — i dlaczego kluczowa decyzja projektowa brzmi: obserwuj zmianę zawartości pliku, nie proces.
1. Problem z rozpoznawaniem „złego”
Klasyczne podejście do ransomware sprowadza się do rozpoznania narzędzia: sygnatura, reputacja pliku, model wytrenowany na znanych rodzinach, reguła behawioralna opisująca konkretny sposób działania. Wszystkie te metody mają wspólną cechę — wymagają jakiejś wcześniejszej wiedzy o zagrożeniu.
Tymczasem szyfrowanie ma pewną wygodną właściwość: wygląda tak samo niezależnie od tego, kto je uruchomił. Zmiana zawartości pliku na dane o wysokiej entropii, wykonywana masowo, w krótkim czasie, na wielu plikach różnego typu — to sygnał, który da się zdefiniować bez znajomości narzędzia.
Na tym opiera się CryptoGuard. Mechanizm nie pyta „czy znam ten proces”, tylko „czy zawartość tych plików właśnie jest szyfrowana”. Konsekwencje są dwie: działa wobec wariantów, których nikt wcześniej nie widział, i nie zależy od łączności z chmurą w momencie ataku.
Rollback jako element mechanizmu, nie dodatek
Sama detekcja nie wystarczy, bo zanim proces zostanie zatrzymany, część plików jest już zmieniona. Dlatego wykrycie jest sprzężone z przywróceniem: pliki zmodyfikowane przez zatrzymany proces wracają do stanu sprzed szyfrowania, niezależnie od rozmiaru i typu.
Tu potrzebne jest zastrzeżenie, o którym warto mówić wprost. Rollback nie jest kopią zapasową. Dotyczy zmian wykonanych przez proces, który został rozpoznany i zatrzymany, i nie zastępuje planu odtworzenia środowiska. Jest mechanizmem ograniczania skutku, a nie strategią backupu.
2. Remote ransomware, czyli atak spoza zasięgu
To scenariusz, który zmienił statystyki w ostatnich latach i który wciąż bywa pomijany w rozmowach o ochronie stacji.
Przebieg jest następujący. Atakujący przejmuje kontrolę nad urządzeniem, które nie ma zainstalowanego agenta — starym serwerem, systemem sterowania, urządzeniem sieciowym, prywatnym laptopem. Uruchamia na nim proces szyfrujący. Proces ten nie atakuje jednak lokalnego dysku, tylko udziały sieciowe na innych maszynach.
Z perspektywy chronionego serwera plików nie dzieje się nic podejrzanego w sensie procesowym: nie pojawił się nowy plik wykonywalny, nic się nie uruchomiło, nie ma czego skanować. Są tylko operacje zapisu przychodzące przez protokół udostępniania plików.
Ochrona, która szuka złośliwego procesu na chronionym urządzeniu, w tym scenariuszu nie ma czego znaleźć. Ochrona, która obserwuje zawartość plików, widzi dokładnie to samo co przy ataku lokalnym.
Skala zjawiska nie jest marginalna. W raporcie Microsoft Digital Defense Report za 2024 rok zdalne szyfrowanie pojawiło się w około 70% udanych ataków ransomware, przy czym zdecydowana większość pochodziła z urządzeń niezarządzanych, obecnych w tej samej sieci. To dobrze pokazuje, gdzie leży realna luka: nie w jakości ochrony na stacjach objętych polityką, tylko w urządzeniach, które w ogóle nie mają agenta.
Wniosek praktyczny dla audytu
Jeśli w środowisku są udziały sieciowe — a są prawie zawsze — warto zadać dwa pytania: które urządzenia mają do nich dostęp zapisu i które z nich nie są objęte ochroną. Odpowiedź na drugie pytanie zwykle jest ciekawsza, niż zakłada dokumentacja.
3. Ransomware jako łańcuch, a nie zdarzenie
Skupienie na samym momencie szyfrowania zniekształca obraz. Szyfrowanie jest ostatnim krokiem — i najdroższym do naprawienia. Wcześniej dzieje się kilka rzeczy, z których każda jest osobną okazją do zatrzymania ataku.
- Wejście. Najczęściej wykorzystanie podatności w usłudze wystawionej na zewnątrz albo dostarczenie ładunku pocztą. Tu działają mitygacje exploitów i ochrona ruchu WWW opisane w części pierwszej.
- Ładunek. Uruchomienie pliku lub skryptu — obszar modeli uczenia głębokiego i skanowania skryptów przez AMSI.
- Przygotowanie. Wyłączanie ochrony, usuwanie kopii woluminów, rozpoznanie środowiska. Warstwa behawioralna i ochrona samego agenta.
- Szyfrowanie. Właściwy skutek — CryptoGuard i rollback.
- Unieruchomienie. Nadpisanie rekordu rozruchowego, żeby utrudnić odtworzenie. Osobny mechanizm ochrony MBR obejmuje również nowoczesne nośniki NVMe.
Ten ostatni punkt bywa lekceważony, a jest istotny operacyjnie: różnica między „odtwarzamy dane” a „najpierw musimy postawić system, żeby móc odtwarzać dane” to zwykle kilkanaście godzin przestoju.
4. Krok, który dzieje się tuż przed szyfrowaniem
Grupy prowadzące ataki ransomware od dawna traktują ochronę stacji jako przeszkodę do usunięcia, a nie jako coś, co trzeba ominąć po cichu. Stąd popularność techniki określanej jako BYOVD — bring your own vulnerable driver.
Sekwencja jest przewidywalna: atakujący ma już uprawnienia administratora, wgrywa legalny, podpisany, ale podatny sterownik, przez jego podatność uzyskuje operacje na poziomie jądra i z tego poziomu kończy procesy ochrony. Dopiero potem uruchamia właściwy ładunek, na urządzeniu, które przestało być chronione.
Odpowiedzią jest Tamper Protection — ochrona agenta przed manipulacją, realizowana również na poziomie jądra. Obejmuje ona kilka elementów:
- obronę własnych procesów, usług i plików agenta przed zatrzymaniem i modyfikacją,
- traktowanie próby załadowania znanego podatnego sterownika jako sygnału ataku,
- wymóg uwierzytelnienia w konsoli do wyłączenia ochrony — samo posiadanie uprawnień lokalnych nie wystarcza,
- przekazanie sygnału do warstwy adaptacyjnej, która podnosi poziom ochrony na całym hoście (temat części czwartej).
Znaczenie tej warstwy jest proporcjonalne do jej pozycji w łańcuchu. Jeśli agent przetrwa próbę wyłączenia, atak dochodzi do warstwy CryptoGuard. Jeśli nie przetrwa — nie dochodzi do niej nic.
5. Serwery i systemy, których nie da się wymienić
W kontekście ransomware osobnej uwagi wymagają dwie kategorie maszyn, bo to na nich skutek jest najdotkliwszy.
Pierwsza to serwery plików i obciążenia serwerowe. Ten sam agent obsługuje Windows i Linux, także w wariantach serwerowych i kontenerowych, więc ochrona przed szyfrowaniem nie kończy się na stacjach roboczych. To istotne właśnie ze względu na scenariusz zdalny opisany wyżej: udział sieciowy jest celem, a nie źródłem ataku, i to on musi być chroniony.
Druga to systemy poza wsparciem producenta. Prawie w każdym środowisku istnieje maszyna, której nie da się zaktualizować, bo działa na niej aplikacja sterująca czymś, czego nie da się zatrzymać, albo sprzęt, do którego nie ma nowszych sterowników. Standardowa odpowiedź „trzeba to wymienić” jest poprawna i zwykle niewykonalna w horyzoncie, w którym trwa rozmowa.
Praktyczne podejście składa się z trzech elementów: objęcia takiej maszyny ochroną w wersji przewidzianej dla systemów dziedziczonych, odseparowania jej sieciowo od reszty środowiska oraz — co najważniejsze operacyjnie — ograniczenia jej uprawnień zapisu do udziałów sieciowych. Ten ostatni punkt wynika wprost z mechaniki zdalnego szyfrowania: przejęta maszyna szkodzi dokładnie tak bardzo, jak szeroki ma dostęp zapisu.
6. Trzy pytania, które warto zadać dowolnemu rozwiązaniu
Niezależnie od producenta, te pytania dobrze różnicują deklaracje od faktycznych możliwości:
- Czy ochrona przed ransomware działa bez wcześniejszej wiedzy o wariancie? Czy opiera się na sygnaturach, modelach i wskaźnikach, czy na obserwacji samego szyfrowania?
- Czy obejmuje zdalne szyfrowanie? Czyli sytuację, w której złośliwy proces nigdy nie pojawia się na chronionym urządzeniu.
- Czy przywracanie plików jest częścią mechanizmu? Czy działa dla plików dowolnego rozmiaru i typu, czy tylko dla wybranych lokalizacji?
Do tego dwa pytania o kontekst systemowy: czy ochrona rekordu rozruchowego jest częścią produktu i czy sam agent jest chroniony przed wyłączeniem z poziomu systemu.
7. Czego to nie zastępuje
Ta sama uwaga co w części pierwszej, tylko ostrzejsza. Ochrona przed ransomware zmniejsza prawdopodobieństwo, że będziemy odtwarzać środowisko. Nie zmniejsza konsekwencji tego, że nie mamy z czego go odtworzyć.
Kopie zapasowe odseparowane od domeny, przetestowana procedura odtworzenia, segmentacja sieci i ograniczenie uprawnień zapisu do udziałów pozostają niezbędne. Warstwa ochrony na stacji i ta lista to dwa niezależne filary — brak jednego nie da się nadrobić drugim.
Źródła
- Sophos News — CryptoGuard: an asymmetric approach to the ransomware battle
- Sophos News — protection against remote ransomware attacks
- Sophos — The State of Ransomware (raport roczny)
- Microsoft Security Insider — Digital Defense Report
- Sophos Central — dokumentacja administratora
Podstawą merytoryczną są publiczne materiały produktowe Sophos (solution brief, solution brochure, buyer’s guide) oraz dokumentacja Sophos Central. Informacje zależne od wersji agenta, poziomu licencji i konfiguracji wymagają ponownej weryfikacji przed publikacją.