Atak Solorigate – co wiemy o jednym z największych cyberataków 2020 r.

Atak Solorigate bez wątpienia na długo zapisze się w pamięci całej branży ze względu na techniki użyte przez napastników oraz ich skuteczność. Przeczytajcie, jakich narzędzi można użyć, by chronić się przed podobnymi atakami w przyszłości.

Autorem artykułu jest Paweł Łakomski, Technicial Specialist, Security & Compliance, MCSE, CISSP, CEH, OSCP.

13 grudnia 2020 roku Microsoft zamieścił informację o konieczności poczynienia przez organizacje określonych kroków w celu ochrony przed nowym, wyrafinowanym cyberatakiem, który wkrótce ochrzczono nazwą Solorigate. Ujawnione w grudniu 2020 roku informacje o sposobie przeprowadzenia ataku i umieszczenia złośliwego kodu w pliku binarnym SolarWinds Orion, platformy szeroko wykorzystywanej do monitorowania środowisk przez wiele organizacji na całym świecie, okazały się czubkiem góry lodowej. W niniejszym artykule przyjrzymy się, co nastąpiło potem. Celem jest próba określenia, w jaki sposób i w jakim zakresie jesteśmy w stanie chronić się przed tym atakiem i mu podobnymi oraz czego do tego potrzebujemy.

Solorigate to przykład ataku typu „cross-domain”, którego etapy można zauważyć na poziomie wielu elementów infrastruktury. W związku z tym najistotniejsze w przypadku Solorigate zdaje się być coś, co możemy określić mianem „wglądu” czy „widoczności” (ang. visibility). Wymaga to jednak jak największej liczby sygnałów, a korelacja jest jasna – im więcej sygnałów, tym lepszy wgląd w środowisko i tym samym większa szansa zauważenia nieprawidłowości.

Powyższy wykres przedstawia wysokopoziomowo przebieg ataku Solorigate. Opisy w branżowych artykułach i prezentacjach skupiają się najczęściej na pierwszym etapie (ataku na łańcuch dostaw), jako najbardziej efektownym i medialnym, oraz na drugim, czyli przeprowadzanej przez złośliwy kod analizie środowiska i początku raportowania do C2. W tym artykule chciałbym pochylić się także nad dalszymi etapami oraz pokazać, jak na tych wszystkich etapach zdefiniowana wcześniej „widoczność” może nam pomóc. Celem jest zatrzymanie ataku na jak najwcześniejszym etapie, ale i na samym końcu nie wszystko jest jeszcze stracone. Umieszczeniu w środowisku organizacji podatnego pliku DLL (konkretnie SolarWinds.Orion.Core.BusinessLayer.dll) to dla atakującego jedynie początek. Aby skutecznie zaatakować organizacje, musi przejść do kolejnych, wcale nie łatwiejszych etapów, na których działania da się zauważyć przy wykorzystaniu istniejących już rozwiązań. Tradycyjnie atakujący musi zadbać o eskalację uprawnień w środowisku, która często będzie wymagała poprzecznych ruchów i dotknięcia innych urządzeń. Zagwarantowanie sobie trwałości dostępu (ang. persistence) także jest działaniem, które możemy zauważyć, jeśli tylko mamy do tego odpowiednie narzędzia.

Zanim przejdziemy do szczegółów, należy poczynić jednak pewne zastrzeżenie – niniejszy artykuł opiera się na stanie wiedzy o ataku z połowy lutego 2021 r. Jak widać z doniesień, sprawa jest rozwojowa, co jakiś czas nowe organizacje informują o dotknięciu atakiem ich środowisk, stąd nasza wiedza o sposobach lateralnego poruszania się atakujących, eskalacji uprawnień czy w końcu o celu ataków jest siłą rzeczy niekompletna. Mimo to będziemy starać się opierać na tym, co wiemy, aby nakreślić sposoby wykrywania i zapobiegania atakowi na podstawie aktualnie istniejącego threat intelligence.

Patrząc na etapy omawianego ataku, widać wyraźnie, że obserwacją należy objąć wiele elementów infrastruktury organizacji – zarówno stacje robocze i serwery, jak i usługi chmurowe czy tożsamość użytkowników. Stąd określenie tego ataku mianem „międzydomenowego”. Dobrym rozwiązaniem zatem jest produkt klasy eXtended Detection and Response (XDR), ponieważ ze swojej natury gromadzi informacje i obejmuje swoją ochroną całe środowisko organizacji. Pozwala to na zebranie sygnałów z większej liczby systemów i obszarów, wcześniejsze wykrycie ataku oraz daje bogate możliwości proaktywnego wyszukiwania zagrożeń (ang. hunting). W niniejszym artykule zobaczymy, jak Microsoft 365 Defender realizuje wszystkie te cele.

Gdy tylko informacje o ataku Solorigate podano do informacji publicznej, Microsoft stworzył w Microsoft 365 Defender dwa raporty w sekcji poświęconej analityce zagrożeń (ang. threat analytics).

Część ta zawiera nie tylko informacje o samym ataku, znanych IoC czy celach ataku, ale przede wszystkich koreluje je z informacjami zebranymi z naszego środowiska. Rezultat stanowi raport analityczny, w którym na pierwszy rzut oka zobaczymy, które zdarzenia i zachowania skutkowały otwarciem alertu połączonego z Solorigate oraz które urządzenia wymagają dodatkowej konfiguracji pod kątem ochrony przed tym atakiem. Krótko mówiąc, raport ten stanowi świetne miejsce rozpoczęcia dochodzenia w zakresie Solorigate w organizacji. Niezależnie od tego, czy chcemy znaleźć informacje o tym, czy złośliwy plik DLL jest obecny na jakimś urządzeniu, czy też sprawdzamy, czy któryś z aktywnych alertów dotyczy Solorigate – informacje te z łatwością znajdziemy w tym miejscu. Nie oznacza to, że jest to jedyny raport tego typu – przeciwnie, od czasu Solorigate Microsoft stworzył (na połowę lutego) już osiem innych raportów threat analytics, dotyczących innych aktywnych kampanii i szeroko wykorzystywanych zagrożeń. Informacje, które widzimy w tych raportach pochodzą z różnorakich źródeł, którym przyjrzymy się w dalszej części artykułu, ponieważ to one stanowią o sile rozwiązania Microsoft 365 Defender.

Skąd właściwie Microsoft 365 Defender „wie”, że na urządzeniu znajduje się podatna wersja SolarWinds Orion? Za to odpowiada komponent Threat & Vulnerability Management (z ang. zarządzanie zagrożeniami i podatnościami, TVM), który pobiera z każdego urządzenia listę zainstalowanego oprogramowania, a następnie dla każdego z nich posiadającego kod CPE nakłada bazę podatności MITRE CVE.

W związku z tym oprogramowanie nie musi być wykrywane przez antywirusa ani nawet nie musi wykonać żadnego podejrzanego ruchu, aby zostać oflagowane, a zalecenie aktualizacji pojawiło się w konsoli. SolarWinds Orion jest świetnym przykładem tego, że podatności w oprogramowaniu mogą być bardzo poważne i o ile w tym przypadku trudno było się o sytuacji nie dowiedzieć (np. z artykułu, który obecnie czytacie), to w innym przypadku ewentualną podatność łatwo przeoczyć. TVM stanowi dobrą alternatywę dla tradycyjnych sieciowych skanerów podatności, które mogą mieć kłopoty z przeskanowaniem urządzenia w przypadku pracy z domu bez VPN czy braku podłączenia do domeny – coraz częstszych w czasach COVID-19. W przypadku TVM wystarczy połączenie do usługi, a baza podatności jest aktualizowana na bieżąco.

Póki co nadal znajdujemy się na pierwszym etapie ataku i skupiamy się na wykrywaniu podatnego pliku, który może zostać odnaleziony przez rozwiązanie antywirusowe Microsoft Defender AV, ale także może zostać oznaczony jako komponent oprogramowania, którego dotyczy podatność. W przypadku zatrzymania pliku binarnego przez antywirusa, zaraportuje on o tym fakcie do Microsoft 365 Defender, aby ten mógł automatycznie rozpocząć szeroko zakrojone dochodzenie. Jednym z elementów tych działań będzie otwarcie alertu i – po skorelowaniu z innymi alertami – złożenie ich razem w incydent. Ponieważ zazwyczaj jeden atak czy zagrożenie nie oznacza po prostu jednego alertu, ponieważ każde zdarzenie możemy prawdopodobnie zauważyć na kilku etapach, alerty konsolidowane są w elementy wyższego poziomu – incydenty. Dodatkowo redukuje to tzw. zmęczenie alertami (ang. alert fatigue), przez które można przeoczyć ważne zdarzenia.

Incydenty dotyczące Solorigate mogą odnosić się zarówno do wykrycia podatnego pliku, jak również do późniejszych działań atakującego, na kolejnych etapach ataku, takich jak komunikacja złośliwego kodu z C2 w domenach powiązanych z tą kampanią:

próby eskalacji uprawnień przez wyciąganie uprawnień z procesu LSASS.exe czy też kradzież klucza prywatnego z usługi Active Directory Federation Services (AD FS):

Każde z tych działań samo w sobie jest podejrzane i zostaje zmapowane na techniki matrycy MITRE frameworku ATT&CK, a w kontekście Microsoft 365 Defendera skutkuje otwarciem incydentu, w którym na pierwszy rzut oka widać wyraźnie wszystkie szczegóły określonych zdarzeń. Należy także zwrócić uwagę, że niektóre incydenty mogą być oznaczone ikoną Microsoft Threat Experts. W przypadku organizacji, które zdecydowały się skorzystać z doświadczenia analityków firmy Microsoft, takie incydenty powstają w przypadku odnalezienia przez ich zapytania huntingowe określonych informacji.

Do tej pory mówiliśmy o podejściu reaktywnym, które w odpowiedzi na wykryte zachowanie czy znalezione elementy otwiera incydent i rozpoczyna automatyczny proces przywracania urządzenia do zdrowia (ang. remediation). Drugim sposobem jest proaktywne wyszukiwanie informacji, które mogą wskazywać na podejrzane działania. Natura rozwiązań XDR polega na zbieraniu sygnałów z dużej liczby miejsc, stąd zapytania huntingowe w module Advanced Hunting będą mogły dotyczyć zarówno urządzeń, jak i aplikacji chmurowych, czy też tożsamości użytkownika. Skoro wiemy, że jedną z technik wykorzystywanych w ataku Solorigate jest wykradzenie klucza AD FS służącego do podpisywania tokenów SAML lub dodanie nowego (albo modyfikacja istniejącego) federacyjnego stosunku zaufania do dzierżawy Azure Active Directory – możemy skupić się na poszukiwaniu informacji związanych z tymi technikami. Zapytania Advanced Hunting obejmujące te i inne techniki, do wykorzystania w Microsoft 365 Defenderze znajdują się na GitHubie oznaczone sufiksem [Solorigate].

Ważne jest również to, że poszczególne zapytania huntingowe można z łatwością zamienić w reguły wykrywania oraz przypisać im działania do automatycznego wykonania po znalezieniu rezultatów.

Podsumowanie

W przypadku tak wyrafinowanych ataków wiedza to nie wszystko. Równie ważna jest liczba sygnałów, które tę wiedzę budują, przede wszystkim możliwość interpretacji zdarzeń w kontekście posiadanego threat intelligence. To wszystko i wiele więcej oferuje rozwiązanie klasy XDR – Microsoft 365 Defender. Możecie przetestować Microsoft Defendera w praktyce dzięki bezpłatnej wersji próbnej, do pobrania pod adresem https://aka.ms/DefenderWersjaProbna.

Macie pytania do artykułu? Już w najbliższą niedzielę o godzinie 21 gościem Rozmowy Kontrolowanej będzie Marcin Kozakiewicz z Microsoftu, który chętnie na nie odpowie.

Dla pełnej przejrzystości – za publikację powyższego artykułu otrzymujemy wynagrodzenie.