Ostatnio dyskutowano o tym, że w przypadku zainstalowania naszego produktu, szkodnik ExPetr nie zapisze specjalnego szkodliwego kodu, który szyfruje MFT, do rekordu MBR. Niektórzy wietrzyli tu nawet konspirację. Inni wykazywali, że to nonsens. Jak zwykle, Vesselin Bontchev, legenda w dziedzinie bezpieczeństwa IT, który znany jest z tego, że zwykle potrafi trafić w sedno, wyraził to najlepiej:
[Bzdura. To powoduje dokładnie to samo co w przypadku wystąpienia błędu podczas próby zainfekowania rekordu MBR. Widzicie ten fragment po „or („II”)” w ostatnim warunku (if).]
O co tu chodzi? Jak powiedział kiedyś ktoś mądry „kod nie kłamie”, przeanalizujmy więc szczegółowo kod infekcji dysku MBR/czyszczenia ExPetra.
W skrócie, szkodnik wykonuje następujące działania:
Główna funkcja szkodliwego oprogramowania
Funkcja „sprawdź uprawnienia”
Ciekawostką jest to, że szkodnik próbuje znaleźć kilka uruchomionych procesów (oblicza skrót hash z nazw uruchomionych procesów i porównuje go z kilkoma zakodowanymi na sztywno wartościami).
Wyliczanie uruchomionych procesów
Najciekawsza część kodu znajduje się poniżej:
Po tym warunku wykonane mogą zostać dwie szkodliwe funkcje:
Opiszmy szczegółowo ten warunek:
Oto, co się wydarzy po początkowej infekcji:
Graficzne zobrazowanie warunku
Bardzo ważne uzupełnienia:
Ogólnie, wydaje się, że ugrupowanie stojące za szkodnikiem ExPetr zbudowało tzw. „stone soup”. Jest to mieszanka starego kodu, nowego kodu, sztuczek hakerskich, kontroli testowych oraz fragmentów nietypowego kodu. Na przykład, występuje specjalny blok warunku, w którym szyfrowanie pliku AES w ogóle nie działa, jednak warunek ten jest zawszy fałszywy. Pod wieloma względami kod ten wygląda na coś, co zostało wypuszczone naprędce, zanim zdążono to dopracować.
Skąd ten pośpiech? Tego nie wiemy, ale przyczyn może być kilka. Jedną z nich może być to, że twórcy tego kodu bardzo starali się złapać „pociąg” EternalBlue/EternalRomance. Po incydencie WannaCry, wiele organizacji zaczęło łatać swoje instalacje Windowsa, aby usunąć istniejące luki w zabezpieczeniach, skutecznie zmniejszając tzw. okno możliwości. Być może autorzy szkodnika ExPetr chcieli zainfekować możliwie najwięcej systemów, zanim dziury te zostaną w większości załatane.
Mimo pośpiechu osoby atakujące wyraźnie orientowały się w naszych technologiach (oraz technologiach innych firm), takich jak Kontrola systemu, która jest niezwykle skuteczna jeśli chodzi o zwalczanie oprogramowania ransomware. Działanie Kontroli systemu polega na gromadzeniu informacji dotyczących podejrzanych działań uruchomionych programów i tworzeniu wskaźnika. Na przykład, gdy program odczytuje pełny plik w pamięci, następnie zapisuje inny plik o podobnym rozmiarze, ale w innym formacie i usuwa oryginał, wskaźnik rośnie. Inne podobne, złe zachowanie powoduje wzrost wskaźnika, natomiast dobre – spadek. Jeśli wiele szkodliwych działań zdarzy się kilkakrotnie, i będą się powtarzały, wskaźnik może osiągnąć próg, który wyraźnie wskazuje, że coś jest nie tak. W takiej sytuacji, Kontrola systemu ostrzega użytkownika i proponuje zakończenie „problematycznego” procesu i przywrócenie danych.
Aby przeciwdziałać tej technologii, autorzy ExPetra zastosowali kilka „środków zaradczych”. Jednym z nich jest unikanie zapisywania kodu modułu szyfrującego GoldenEye w rekordzie MBR, jeśli w systemie działa nasz produkt. W ten sposób autorzy szkodnika zapobiegają wzrostowi wskaźnika podejrzanych działań i zbyt wczesnego zakończenia swojego procesu. Wydaje się, że włożyli mnóstwo energii w próby obejścia naszych produktów oraz atakowania naszych użytkowników, co oznacza, że poważnie martwili się tym, że zostaną powstrzymani. Jednak ich wysiłki nie dały oczekiwanych rezultatów, co potwierdza teorię, że mamy tu do czynienia ze zbiorem złożonych naprędce sztuczek hakerskich. Komponent Kontrola systemu i tak uruchamia się i powstrzymuje szyfrowanie plików, kończąc proces i odwracając zmiany.
Konkludując, nasi użytkownicy byli bezpieczni mimo środków zastosowanych w szkodniku ExPetr, wymierzonych przeciwko nim.
Dlaczego zdecydowaliśmy się napisać to dłuższe wyjaśnienie? Wobec złożonego kodu szkodliwego oprogramowania oraz wbudowanych mechanizmów służących do obejścia produktów antywirusowych, zrozumienie całej funkcjonalności dzisiejszego szkodliwego oprogramowania jest trudne. Łatwo można dać się zwieść i sądzić, że niektóre przypadki sprawdzania kodu mogą oznaczać „taryfę ulgową” dla użytkowników produktów Kaspersky Lab. W rzeczywistości jednak, ich celem było obejście technologii Kontrola systemu. Ostatecznie, nie zadziałało. Nasi użytkownicy nie potrzebują „taryfy ulgowej” od szkodnika ExPetr, ponieważ są chronieni przez naszą technologię Kontrola systemu.
Analizy
Blog