Zamęczyć antywirusa: najnowsze usprawnienia w dostarczaniu trojanów

Być może trudno w to uwierzyć, ale kampanie mailowe z wirusami, choć niezmiennie mało kreatywne, pozostają poważnym zagrożeniem. Świadczą o tym rosnące zyski z ataków ransomware, skierowanych nawet w szpitale. Choć zjawisko ewoluuje od ponad dwudziestu lat, rozwija się nierównomiernie. Wektorem wejścia w dalszym ciągu jest nieostrożność lub naiwność użytkowników (kiepsko zabezpieczonych) stacji roboczych. Ale metody omijania antywirusów stają się coraz bardziej ambitne.

Zautomatyzowane wyłączanie Defendera przestało, wreszcie, być możliwe. Nic się jednak nie zmieniło w kwestii domyślnie dostępnych środowisk uruchomieniowych: kompilator .NET, Visual Basic for Applications (Office), PowerShell i Host Skryptów Windows. Domyślne ustawienia UAC także pozwalają na samo-podniesienie uprawnień (self-elevation) i to nie ma nawet szansy na zmianę, o co musimy zadbać samodzielnie.

Nowe szkodniki będą stosować te same API, co wcześniejsze, ale tym razem nie mogą wyłączyć antywirusa. Muszą go więc... zmęczyć. W ten sposób działają przedstawiciele nowej kampanii mailowej. Infekcja przebiega tak samo, jak wcześniej. Różni się zachowanie narzędzia pobierającego payload C2. Pracuje ono w pętli.

Działanie w pętli nie jest nowością: Danabot pobierał swój payload w pętli, by zmylić narzędzia do zautomatyzowanego wykrywania zagrożeń. skrypt prosił serwer o plik i w większości przypadków (a na pewno za pierwszym razem) otrzymywał w odpowiedzi HTTP krótki ciąg tekstowy. Dopiero po kilku minutach starań odpowiedzią stawał się ciąg base64 zawierający bibliotekę DLL z wirusem. W ten sposób analizatory bezpieczeństwa, sprawdzając serwer, nie flagowały go jako groźny, bo przecież "wysyła tylko cyferki", a efektem żądania nie był żaden plik.

Tym razem pobieranie pliku w pętli za każdym razem kończy się otrzymaniem wirusa. Jednak każda próba (są one oddalone od siebie o stałe 30 sekund) pobiera nieco innego wirusa. Nie jest jasne, czy są one kompilowane na żądanie czy należą po prostu do bardzo dużego zbioru, nie są jednak identyczne. To sposób na "przeczekanie" antywirusa. Gdy definicje nowego zagrożenia są niedojrzałe, początkowo dotyczą tylko literalnej jego kopii. Dopiero kolejne iteracje, dostarczane wraz z aktualizacjami, stają się odpowiednio uogólnione.

Zatem świeże, ale już znane silnikom antywirusowym zagrożenia, przez pierwsze godziny (dni?) swojego istnienia mogą uniknąć wykrycia, gdy ulegną tylko lekkiej zmianie. Pierwsze kilka mutacji zapewne "nie zniknie z radaru", ale te późniejsze mają na to większą szansę. Stąd też co pół minuty, złośliwy downloader pobiera kolejny plik, licząc na to, że w końcu któraś wersja nie zostanie wykryta i zablokowana.

Z perspektywy użytkownika, sprawa wygląda zabawnie: Defender co chwilę krzyczy o zablokowaniu wirusa. Ręczne sprawdzenie katalogu poddanego kwarantannie nie daje rezultatu, bo pliku już tam nie ma. Na liście procesów nie znajduje się ani wspomniany wirus, ani żadne narzędzie pobierające go. Mimo to, pół minuty później, w katalogu tymczasowym użytkownika pojawia się nowy złośliwy plik. Jak to możliwe?

Za cykliczne pobieranie odpowiedzialne jest zakamuflowane zadanie systemowego Harmonogramu Zadań. W katalogu "WindowsUpdate", poza dwoma systemowymi zadaniami, wirus umieszcza trzy inne. Pierwsze uruchamia składany w locie skrypt VBS uruchamiany przez WSCRIPT.EXE, drugi wykorzystuje MSHTA.EXE. oba wykonują się co minutę, z półminutowym przesunięciem czasowym. WSCRIPT jest stosowany na wypadek wykrycia MSHTA przez skaner behawioralny, a MSHTA – na wypadek zablokowania Hosta Skryptów przez Zasady Grupy. Harmonogram Zadań wykonuje swoje polecenia przez SVCHOST, a więc "zaufaną", systemową aplikację.

Zdecydowana większość zadań Harmonogramu nie powinna polegać na Hoście Skryptów ani interpreterze Aplikacji HTML. Dlatego z powodzeniem można założyć, że wszelkie wpisy, które ich używają, są złośliwe. Oto, jak je znaleźć, zatrzymać i wyłączyć:

Do założenia zadania Harmonogramu nie są potrzebne prawa administracyjne. Jest to wymagane dopiero wtedy, gdy chcemy przypisać mu wyższe uprawnienia i pozbawić możliwości łatwego usunięcia. Przesuwa to podział odpowiedzialności w łańcuchu infekcji: gdy "instalatorowi" uda się od razu założyć zadanie o podwyższonych prawach, pobierany przez nie wirus nie musi już zajmować się samo-podnoszeniem. Zbiór metod na podnoszenie praw jest zamknięty i łatwiej jest go heurystycznie wykryć niż np. metodę szyfrowania plików, co można robić na bardzo, bardzo wiele sposobów.

Instalatory zmieniają się częściej niż wirusy, bo łatwiej je napisać. Z kolei programy szyfrujące z ransomware to już większa sztuczka inżynieryjna i cenną jest możliwość usunięcia z nich składników do zdobywania uprawnień.

Pobierany trojan został zaklasyfikowany przez Defendera jako "Ransom:Win32/CryptInject!MSR". Sufiks "!MSR" w jego nazwie oznacza zapewne "Microsoft Reserved Partition" i wskazuje na to, że trojan zmienia sposób uruchamiania systemu. Zagrożenia tego typu dysponują obecnie bardzo dużym polem do usprawnień i bez wątpienia już wkrótce poznamy kolejne usprawnienia w owej dziedzinie. A w międzyczasie – suwak UAC na samą górę i wyłączmy Hosta Skryptów!