Defender: antywirus Windowsa. Jak skonfigurować reguły zmniejszania obszaru ataków

Jak dowodzą kampanie trojanów Ursnif, Danabot i Emotet, punktem wejścia dla popularnych wirusów często wcale nie są, regularnie łatane, dziury w systemie Windows i pakiecie Office. Przestępcy nie wykorzystują skomplikowanych podatności w oprogramowaniu, a zamiast tego inwestują w cudzą naiwność. Dlatego, co zdumiewające, dzisiejsze wirusy przychodzą do nas w postaci skryptów i dokumentów biurowych z załączonymi makrami, dokładnie tak, jak dwadzieścia lat temu.

Można, oczywiście, przypisać dużo odpowiedzialności za ten stan rzeczy Microsoftowi. Zwłaszcza kwestia automatycznego uruchamiania plików VBS jest zawstydzająca. Możliwość swobodnego uruchamiania procesów z poziomu edytora tekstów także sprawia, że podważa się kunszt inżynieryjny programistów z Redmond. Ale faktem jest, że mimo tych ewidentnych słabości, uruchamianie makr jest jednak domyślnie wyłączone. Aby uruchomić złośliwą zawartość, trzeba się zatem aktywnie postarać, zazwyczaj nabierając się na jakąś tanią sztuczkę.

Problem tworzą zatem ludzie, a nie technologia. W większości przypadków można co prawda wymusić posłuszeństwo użytkowników poprzez odebranie praw uruchomienia skryptów i makr. Niewątpliwie zmniejszyłoby to potencjał wielu obecnych kampanii malware'owych. Wciąż istnieją jednak takie miejsca, gdzie pliki VBS i makra są potrzebne do pracy (!), dlatego domyślne ich wyłączenie nie wchodzi w grę.

Kłopot z makrami polega na tym, że niezwykle łatwo je zaciemnić, a udostępniany model programowania zezwala niemal na wszystko. Innymi słowy, da się stworzyć niezwykle "niecharakterystyczny" kod i szerokich możliwościach, wyprowadzając w pole wszystkie antywirusy, dostarczając zarazem rozbudowany funkcjonalnie payload.

Z tego powodu, makrowirus nie będzie wykrywany statycznie, a detekcja heurystyczna też będzie utrudniona. Złośliwy kod makrowirusa działa bowiem w procesie WINWORD.EXE, wołając składniki MSVBVM, a to wszystko są "zaufane", "bezpieczne" komponenty wprost z Microsoftu. Makrowirusy zajmują się dziś głównie pobieraniem prawdziwego wirusa i to dopiero on sieje właściwe spustoszenie. Z perspektywy antywirusa, oprogramowany przez makro Office nie wykonuje żadnych podejrzanych czynności: jeżeli wolno mu uruchamiać makra, to znaczy że wolno mu robić to, co robi.

Odpadają więc detekcje statyczne, heurystyczne i behawioralne. Zresztą i tak aktywne środki zaradcze mogłyby doprowadzić jedynie do kwarantannowania… Worda, co jest raczej przeciwproduktywne. Aby chronić się przed zachowaniem potencjalnie prowadzącym do wykonania złośliwego kodu, musimy się opierać na innych mechanizmach ochrony. Zamiast liczyć na rozpoznanie zaciemnionego wirusa lub wysyłać Excela na kwarantannę, należy powstrzymywać niektóre procesy przed wykonywaniem konkretnych czynności.

Na przykład zakazać Office'owi tworzenia procesów potomnych. Innymi słowy, uniemożliwić makrowirusowi wywołanie PowerShella celem pobrania ransomware'u. Takie podejście jest trzecią drogą ochrony: nie wyłączamy obsługi makr, nie skanujemy dokumentów, ale powstrzymujemy działanie pewnych API w konkretnych okolicznościach. Aby osiągnąć taki cel, silnik antywirusowy musi mieć prawa zaglądania/debugowania/kontrolowania innych procesów. To nie przelewki: jeżeli jakiś AV to potrafi, to znaczy że pracuje na bardzo wysokich prawach, ma dostęp do wszystkiego i może kontrolować inne programy. Nie każdemu może się to podobać. Ale systemowy Defender umie takie rzeczy, acz domyślnie są one wyłączone.

Mowa o najbardziej chyba tajemniczej funkcji Defendera, jaką jest Zmniejszanie obszaru ataków. Powszechny brak jej znajomości wynika z kilku powodów: całkowitego ukrycia w opcjach konfiguracyjnych, fatalnego nazewnictwa, ograniczeń licencyjnych i dokumentacji Microsoftu, odpowiadającej jedynie na część pytań. Funkcjonalność redukowania powierzchni ataku, według dokumentów, wymaga licencji Enterprise i wdrożenia narzędzi centralnego zarządzania, jak Intune oraz ATP.

Z tym, że zapotrzebowanie to wynika głównie z funkcji analizowania wzorców w sieci oraz z tego, że "zaciągnąć" do Endpoint Managementu można wyłącznie Windowsy w wersjach Pro i Enterprise. Wszystkie funkcje działające całkowicie lokalnie nie wymagają żadnych enterprise'owych licencji. Możemy je włączyć samodzielnie.

Formalnie, na opisywaną funkcję składają się następujące komponenty: izolacja sprzętowa, ochrona przed eksploitami, kontrolowany dostęp do folderu, reguły redukcji, firewall i ochrona sieci lokalnej i dostępu do Web. Mechanizmy ochrony sieci stanowią kategorię typu "Pakiet Internet Security" i zajmiemy się nimi kiedy indziej. O pierwszych trzech składnikach już mówiliśmy, a firewall (podobnie jak SmartScreen) nie jest tak naprawdę częścią Defendera i pojawia się w opisach tylko ze względu na… zmianę nazwy.

Ale czym są "Reguły Zmniejszania Obszaru Ataków"? Krótko mówiąc, są przełącznikami zezwalającymi Defenderowi na interwencję w pracę innych procesów celem powstrzymania ich przed wykonaniem konkretnych czynności. W przeważającej większości dotyczą Office'a i skryptów, ale istnieje też reguła dla Adobe Readera (!). Nie każdy może się czuć komfortowo z antywirusem zdolnym do introspekcji i interwencji w działanie w programów, więc zbiór włączonych reguł jest domyślnie pusty. Lista dostępnych jest z kolei następująca: Zablokuj możliwość tworzenia procesów potomnych przez aplikacje Office Zablokuj możliwość tworzenia składników wykonywalnych przez aplikacje Office Zablokuj możliwość wstrzykiwania kodu do innych procesów przez aplikacje Office Zablokuj możliwość tworzenia procesów potomnych przez komunikatory Office Zablokuj wywołania WinAPI z poziomu makr Office Zablokuj uruchamianie plików wykonywalnych pobranych przez skrypty Visual Basic Zablokuj uruchamianie skryptów wyglądających na zaciemnioneBlokuj treść wykonywalną w programach pocztowych i stronach webmail Stosuj zaawansowaną ochronę przed ransomware Blokuj wydobywanie poświadczeń z procesu LSASS Blokuj tworzenie procesów, których potencjalnym rodzicem byłoby wywołanie PSExec lub instancja WMI Blokuj uruchamianie niepodpisanych programów z nośników USBBlokuj pliki wykonywalne niespełniające wytycznych popularności lub wieku Zablokuj możliwość tworzenia procesów potomnych przez Adobe Readera Blokuj próby uzyskania trwałej obecności w systemie poprzez rejestrację jako subskrybent zdarzeń WMIKtóre z nich powinniśmy włączyć? Cóż, nie jest to proste pytanie, odpowiedź zależy bowiem od naszej specyfiki pracy. Kilka reguł jest uniwersalnych i istnieje mało scenariuszy, w których ich włączenie okaże się szkodliwe. Mowa o obsłudze USB, mechanizmu WMI i LSASS. Chronią one jednak przed zagrożeniami, które mają sens w firmach, a które polegają na tzw. ruchach poziomych (lateral movement), czyli eksplorowaniu sieci w poszukiwaniu słabych punktów.

Na osobistych komputerach o wiele przydatniejsze jest włączenie zabezpieczeń dotyczących pakietu Office… o ile nie polegamy w pracy na makrach. Zdecydowana większość z nich po włączeniu zabezpieczeń dalej będzie działać, nie wyłączają one makr, ale jeżeli którekolwiek z nich wołało Win32 albo zewnętrzne EXE (a nie takie rzeczy wymyślano w ramach "tymczasowych rozwiązań"), Defender ubije je. Podobnie z Adobe Readerem. Jeśli używamy systemowej przeglądarki PDF, możemy włączyć reguły blokowania. Lecz gdy zdarza się nam korzystać z rozszerzonych PDFów i cudacznych wtyczek np. do autouzupełniania formularzy, blokada może to utrudnić.

Na szczęście, możliwy jest tryb audytu: wtedy Defender zamiast egzekwować blokadę, zapisze do dziennika wpis, jaka czynność zostałaby zablokowana, gdyby zabezpieczenia były w pełni aktywne. Pozwala to dokonać przeglądu, czy regularny dzień pracy skutkuje potencjalnymi blokadami. Jeżeli nie, można pokusić się o włączenie reguł redukcji powierzchni ataku. Wszystkich. Oto ich identyfikatory:

W Dzienniku Zdarzeń "Microsoft-Windows-Windows Defender/Operational" należy wtedy szukać zdarzeń o identyfikatorze 1122. Informuje on, że w systemie zaszło zdarzenie, które zostałoby zablokowane. Jeżeli normalna praca nie wywołuje żadnych takich zdarzeń przez rozsądny czas, można przełączyć tryb reguł z inspekcji na wymuszający. Niestety, interfejs który pozwala to łatwo zrobić, nie istnieje. A błędna komunikacja z owym obiektem nie poskutkuje żadnym przytomnym komunikatem błędu, ponieważ… nie zaimplementowano ich. Dlatego najlepiej usunąć wszystkie reguły i dodać je na nowo:

Można rozważyć, czy na pewno chce się włączać "01443614-cd74-433a-b99e-2ecdc07bfc25" i czy na pewno coś daje poza domeną. Ale oczywiście nie da się tego łatwo dowiedzieć. Wszak według dokumentacji Microsoftu, wdrożenie reguł w środowisku bez Intune/SCCM/Endpoint Managera jest "nieobsługiwane". Nie oznacza to, że reguły wtedy nie działają. Te bardziej skomplikowane mogą być jednak wtedy mniej skuteczne. Może wystarczy po prostu wyłączyć makra…?

W kolejnej części zajmiemy się funkcjami typu Internet Security.