Szczepionka na ransomware. Jak działa Raccine?

Oprogramowanie klasy ransomware, choć niebezpieczne (i przy tym niezwykle dochodowe), opierają swoje działanie na szeregu dość przewidywalnych, masowo powtarzanych operacji. Intuicja podpowiada, że przy takiej charakterystyce powinny być łatwym celem dla antywirusów, zdolnych do odnalezienia kodu wykonującego prostą, złośliwą operację na masową skalę. A jednak ransomware panoszy się bardzo mocno i kolejne wersje payloadu przez wiele dni od powstania unikają wykrycia. Dlaczego?

Niska skuteczność antywirusów bierze się z niezwykłej różnorodności metod aktywacji. To już nie jest "wirus.exe", a dziesiątki wariantów różnorako uruchamianego wirusa, zazwyczaj w ramach kaskady procesów. Złośliwy kod jest ponadto tworzony tak, by odpowiednio dużą część swojej pracy wykonywać cudzymi rękami. Zamiast samemu uruchamiać jakiś plik DLL, prosi o to aplikacje systemowe. Zamiast usuwać jakiś plik, rejestruje go jako tymczasowy, a następnie woła Oczyszczanie Dysku. I tak dalej.

Oznacza to, że o wiele lepszą definicją antywirusową byłaby tu definicja behawioralna, ponieważ opisy próbek i definicje heurystyczne są niewystarczające. Zagrożenia występują od początku w wielu wariantach i stosują różnorakie ścieżki wykonawcze. Innymi słowy, objawy infekcji nie są jednoznaczne… aż do zaszyfrowania dysku i wyświetlenia żądania okupu.

Podejście antywirusowe okazuje się więc nieskuteczne. Trafniejsze okazują się metody bazujące na pomysłach z IDS (systemów wykrywania włamań). Nie próbujemy w takiej sytuacji zgadywać czy program jest szkodliwy. Zamiast tego sprawdzamy, w jakich okolicznościach wykonuje on operacje systemowe, które powinny być bardzo rzadkie.

W ten sposób działa Raccine, narzędzie nieformalnie nazwane "szczepionką na ransomware". Jego autorem jest Florian Roth. "Szczepionka" przechwytuje żądania do narzędzia VSS Admin, czyli programu zarządzającego kopią zapasową w tle. Ponieważ operacje VSS Admin bardzo rzadko znajdują uzasadnienie na stacjach roboczych (co innego na serwerze!), można się im "przyglądać".

Odbywa się to poprzez zezwolenie w systemie na podłączenie debuggera do procesów i zarejestrowanie takowego dla vssadmin.exe. Gdy narzędzie VSS zostanie uruchomione (w domyśle: przez ransomware) celem usunięcia historii plików/kopii zapasowych, niby-debugger przechwyci żądanie, nie dopuści do niego i ubije procesy macierzyste odpowiedzialne za wysłanie go.

Ponieważ operacje VSS są jedną z pierwszych czynności wywoływanych przez ransomware, ubicie procesu źródłowego może wręcz skutecznie powstrzymać infekcję i zapobiec jakimkolwiek stratom. Nie powstrzymaliśmy systemu przez otrzymaniem trojana i nie zapobiegliśmy rozpoczęciu jego wykonania, ale jedna z kluczowych operacji została uniemożliwiona. Jest to w pewien sposób poddanie walki, ale w praktyce oznacza to zaprzestanie wiary w bajkę, że użytkowników da się wyedukować, a antywirusy – uczynić przydatnymi.

Problem bierze się, w przypadku VSS, z tego że Microsoft nie wprowadził granulacji dostępu i zaawansowanej kontroli do narzędzia vssadmin.exe. Istotnie, przystawki i zasady dla Windows Server Backup są niezwykle rozbudowane i narzędzia kopii woluminów oraz historii plików do potężne wynalazki. Ale zaprojektowano je, jak zresztą wiele innych składników Windows, bez zastanowienia, czy na pewno stacje klienckie potrzebują takiego samego zbioru operacji, co Windows Server Backup. Czy nie warto na przykład objąć takich operacji audytem. Albo zakazać na klientach.

Dzisiejszy Microsoft już rzadziej popełnia takie błędy. Popełnia za to inne: mnóstwo programów i bibliotek systemowych da się skłonić do wykonania kodu. Co prawda na tych samych prawach, ale zawsze łatwiej ukryć się w logach jako Panel Sterowania, niż jako tr6EyAAh.exe. Problem ten nie zostanie naprawiony. Podobnie zresztą, jak ten z vssadmin. Może chociaż Defender nauczy się go wykrywać…?