Case study: Odzyskiwanie porządku po ataku ransomware

Zgłosił się do nas klient, który padł ofiarą ataku ransomware, z prośbą o wykonanie analizy powłamaniowej i wprowadzenie niezbędnych zabezpieczeń, aby uniknąć podobnego scenariusza w przyszłości. Po krótkiej rozmowie dowiedzieliśmy się podstawowych informacji o przebiegu ataku. Scenariusz dość typowy – jeden z pracowników kliknął na podejrzany załącznik do wiadomości na poczcie firmowej. Następnie – na pierwszy rzut oka losowo - niektóre komputery w sieci zaszyfrował wirus. Przy próbie uzyskania dostępu do danych pojawiał się dość standardowy komunikat o konieczności wniesienia opłaty w jednej z popularnych kryptowalut, aby odzyskać dostęp. Firma zaakceptowała utratę danych, jednak zarząd, usilnie parł ku temu, aby poznać mechanizm ataku. Przede wszystkim, aby zastosować rozwiązania, które pozwoliłyby na uniknięcie podobnych zdarzeń w przyszłości. Co ciekawe, na każdej zainfekowanej stacji antywirus był aktywny i nawet zgłaszał problemy. Jednak najniższą opcję tego rozwiązania nie zintegrowano z centralną konsolą zarządzającą.

Po rozpoczęciu analizy ataku ransomware ciekawą kwestią okazało się znalezienie prawidłowości dotyczącej konfiguracji komputerów ofiar, bowiem przykładowo w jednym pomieszczeniu jeden lub 2 komputery wirus zaszyfrował, a 3 kolejne nie. Wskazywało to na pewną losowość w doborze ofiar. Jednakże wspólnym mianownikiem okazał się być aktywny na wszystkich zaszyfrowanych stacjach protokół SMB 1.0. Co prawda domyślnie jest nieaktywny na współczesnych wersjach systemu operacyjnego, to w tej firmie wyłączano go ze względu na funkcjonowanie skanerów sieciowych starszej generacji, niewspółpracujących z nowszymi wersjami protokołu SMB.

To dało nam sygnał, że ujawniony problem stanowi zaledwie wierzchołek góry lodowej, jeśli chodzi o podstawę względem cyberbezpieczeństwa w firmie. Lista problemów okazała się długa. Oto niektóre ze zidentyfikowanych nieprawidłowości:

- Praktycznie użytkownik każdej stacji roboczej miał na niej przydzielone uprawnienia lokalnego administratora, co samo w sobie niesie sporo ryzyk. Podyktowane było to głównie wygodą i tym, że użytkownicy mieli potrzebę instalować i aktualizować aplikacje. Jak się potem okazało, niektóre nieautoryzowane i nielicencjonowane w tej organizacji.

- Nadmiernie nadawano członkostwo w grupie Domain Admins. Każdy, kto kiedykolwiek miał zrobić jakieś zadanie na którymś z serwerów, będąc przydzielonym do tej krytycznej grupy zabezpieczeń, zostawał w niej na zawsze. Pracownicy działu IT korzystali z kont należących do tej grupy do wykonywania zadań codziennych na swojej stacji roboczej.

- Komputerom nie instalowano aktualnych poprawek, bowiem nikt nie zatwierdzał miesięcznych poprawek zbiorczych do instalacji na poziomie serwera WSUS, a nawet jeśli to było zrobione, to ustawienia stacji roboczych pozwalały na odkładanie instalacji w nieskończoność.

Dodatkowo, zgłoszono problem. Otóż w tej firmie, żadne spotkanie nie mogło rozpocząć się o czasie. Wszystkie zegarki synchronizujące czas ze źle skonfigurowanymi pod względem źródeł synchronizacji czasu kontrolerami domeny spóźniały się o kilka minut.

Po zebraniu wszystkich rzeczy stanowiących pole do poprawy konfiguracji przedstawiliśmy szczegółowy plan działania. Obejmował zakres i rozmieszczenie poszczególnych kroków w czasie.

W związku z tym, iż nie zdecydowano się na wymianę starych skanerów sieciowych, wydzielono mikro segment sieci z jednym serwerem plików Linux i podkatalogami udostępnionymi dla użytkowników korzystających ze skanerów sieciowych. Włączono analizę ruchu wschód-zachód, a na liście kontroli dostępu zezwolono tylko na ruch przychodzący na porcie TCP 445. Dla wygody użytkowników folder ten został podmapowany w ich lokalnej strukturze plików przy użyciu łącz symbolicznych. Natomiast SMB w wersji 1.0 zostało wyeliminowane na wszystkich stacjach roboczych i serwerach spod znaku Microsoft.

Członkostwo w grupach lokalnych administratorów na stacjach roboczych zostało uporządkowane za pomocą funkcjonalności Restricred Groups. Co więcej osobom, które realnie potrzebowały uprawnień administracyjnych przy dostępie do systemu kontroli dostępu czy monitoringu wizyjnego zostały utworzone dedykowane konta lokalne bez możliwości logowania interaktywnego. Dla lepszej ochrony poświadczeń wbudowanych kont lokalnych administratorów wdrożono zarządzanie hasłami w oparciu o darmowe rozwiązanie LAPS.

Dla środowiska Active Directory wdrożono trzystopniowy model Tieringu z oddzielną delegacją dla zarządzania serwerami związanymi z tożsamością, aplikacjami i stacjami roboczymi. Przy czym bardziej granularnie zaplanowano delegowanie uprawnień do zadań specyficznych, zakładając kontrolę dostępu opartą na rolach w organizacji (RBAC). Dla użytkowników, którym zdania wymagające podniesionych uprawnień administracyjnych delegowane są rzadko, wprowadziliśmy mechanizm ograniczonego czasowo członkostwa w grupach zabezpieczeń – Just in Time Administration.

Skorygowane zostały polityki dotyczące zarządzania poprawkami na stacjach roboczych jak i mocno zoptymalizowaliśmy działanie samego serwera WSUS. Nieregularne zatwierdzanie poprawek systemowych do instalacji nie wynikało bynajmniej z opieszałości działania administratorów serwera. Zwrócili oni uwagę, że konsola WSUS działa bardzo wolno. Sporo czasu zajmuje wyświetlenie odpowiednich widoków, a zanim to zostanie osiągnięte, konsola potrafi przestać odpowiadać nawet kilka razy. Nie wynika to z zaśmiecenia bazy czy partycji serwera starymi nieużywanymi poprawkami. Raczej takiego domyślnego funkcjonowania tej roli, co z pewnością odnotowali administratorzy konfigurujący WSUS od zera. Przeprowadziliśmy optymalizację, uruchamiając szereg skryptów optymalizujących konfigurację i samą bazę SQL, co doprowadziło do szybszego i stabilnego działania systemu.

Postawiliśmy też na automatyzację, czyli samozatwierdzanie poprawek na danych grupach WSUS do instalacji. Powszechnie wiadomo, że samo czasem lekarstwo może być gorsze od choroby. Niemniej jednak skonfigurowaliśmy funkcjonalność Windows Update for Business, czyli instalowanie poprawek w oparciu o kręgi. Mówiąc kolokwialnie, na pierwszy ogień idzie instalacja poprawek dla grupy komputerów mniej newralgicznych. Z pewnym opóźnieniem poprawki otrzymują wszystkie pozostałe systemy klienckie (drugi krąg). Chyba że po zainstalowaniu poprawek w pierwszym kręgu wystąpią problemy, to rezygnuje się z instalacji danej poprawki w drugim kręgu. Instalację poprawek na kluczowych serwerach firmy pozostawiono w formie ręcznej bez zmian. Pozostawiono adnotację, że należy tego pilnować i utrzymywania serwerów Windows nieaktualizowanych bez jasno określonego powodu.

Przeanalizowaliśmy sposób działania i przepływ informacji drogą elektroniczną w tej konkretnej jednostce. Pozwoliło to wdrożyć, zoptymalizować i dokonać fine tuningu polityk hardeningowych dostarczanych w darmowym pakiecie Microsoft Security Compliance Toolkit. Zawierają one w formie polis GPO zbiór dobrych praktyk stojących w sprzeczności z domyślną konfiguracją, w jakiej dostarczany jest Windows. Dobrze zaplanowane i przeprowadzone wdrożenie nie wywołało negatywnego wpływu na pracę użytkowników końcowych.

O konieczności aktualizacji systemu antywirusowego do wyższej wersji i konfiguracji konsoli zarządzającej z funkcją powiadamiania o wykrytych zagrożeniach zarządu nie trzeba było specjalnie przekonywać. Nikt nie chce, aby podobny atak ransomware znów się wydarzył.

Ustawiliśmy prawidłowe źródło czasu na PDC emulatorze. Odtąd czas na serwerach i komputerach należących do domeny reprezentował stan rzeczywisty.

Powyższe czynności, które mogą spokojnie mogą stanowić plan naprawczy, znacząco poprawiły postawę bezpieczeństwa w organizacji. Nie zapomnieliśmy również o części uświadamiająco-edukacyjnej tego projektu. Jak wiadomo, nie do końca świadomy zagrożeń użytkownik końcowy może stanowić najsłabsze ogniwo systemu zabezpieczeń. Poprzez zestaw mini szkoleń użytkowników nietechniczni uświadomiono w zakresie zagadnień dotyczących tego, jakich aktywności w sieci w przyszłości unikać. Nasze rekomendacje zakładały także inne aktywności. Chociażby wdrożenie systemu do identyfikacji i zarządzania podatnościami, jednak odłożono je na później ze względu na ograniczenia budżetowe. Aczkolwiek – jak mówi wiele metodologii zarządzania planami naprawczymi – działania należy zacząć od rzeczy najprostszych. Pomimo braku bezpośredniego benchmarku śmiało można stwierdzić, że na podstawie podjętych zmian punktacja secure score w firmie będącej przedmiotem niniejszego case study uległa znaczącej poprawie. Niestety tych działań nie uruchomiono już po przeprowadzonym skutecznie ataku ransomware. Nie da się, nie użyć frazesu, iż lepiej jest wcześniej zapobiegać niż później leczyć. Z drugiej strony lepiej późno niż wcale.