Piątek przed 21:00. Firma kończy pracę tuż przed długim weekendem. Pracuje już tylko magazyn, który przygotowuje ostatnie przesyłki do nadania klientom. Nagle aplikacje jedna po drugiej zgłaszają dziwne błędy. Próba wylistowania zamówień kończy się błędem aplikacji. Po kilku minutach wszystkie wystąpienia aplikacji „padają”. Nie można już uruchomić aplikacji na żadnej stacji. Magazyn zgłasza sprawę do działu IT, który w sumie jest już na długim weekendzie….
Dlaczego monitoring jest tak ważny?
Na miejscu pojawia się szef IT. Szybka decyzja o wyłączeniu wszystkich serwerów. Dla bezpieczeństwa odcięcie dostępu do sieci organizacji. Nie wiadomo do końca, co się dzieje. Żadne alerty nie zostały uruchomione, logowania na serwerach tylko ze znanych kont. Narada z centralą potwierdza, że jeszcze kilka oddziałów zgłasza podobne problemy. Pilna informacja do oddziałów, które nie pracują, aby nie uruchamiały infrastruktury, na ile będzie to możliwe. Jest jednak za późno.
Antywirusy z opóźnieniem zaczęły działać; użytkownicy, którzy pracowali zdalnie, nagle otrzymali powiadomienia o podejrzanych plikach; mechanizmy obronne zaczęły odcinać dostęp do zasobów organizacji z powiadomieniami do centrali. Jednak to nie wystarczyło.
Jakie straty?
Sobota rano, stawia się cały zespół IT, aby ocenić straty i spróbować przywrócić działanie infrastruktury. Logowania na serwery w trybie offline, na konta awaryjne. Wszystko wygląda normalnie. Serwery uruchomiły się poprawnie, jednak po zalogowaniu logi zgłaszają błędy uruchomienia usług takich jak MSSQL oraz aplikacji, które współpracują z instancjami baz danych. W miejscach przechowywania plików baz danych pojawiła się lista plików, które wyglądały dziwnie. Okazało się, że pliki zostały zaszyfrowane. Przy próbie otwarcia pojawiła się jedynie informacja o adresie, na który należy wysłać okup w postaci określonej kwoty w BTC.
Sytuacja wygląda poważnie. Cała infrastruktura padła. Biznes zaczyna liczyć straty, brak produkcji, brak realizacji zamówień = brak przychodów.
Stan po ataku
W związku z długim weekendem jest szansa, że uda się przywrócić główne usługi, aby firma mogła zostać przywrócona operacyjnie. Na szczęście wcześniej zostały podjęte kroki, aby podnieść bezpieczeństwo danych. Serwery plików zostały zmigrowane do chmury (Sharepoint), przygotowane zostały procedury backupu oraz jego odzyskania. Pytanie, czy to wystarczy w godzinie próby? Zaszyfrowane pliki zaczęły synchronizować się z chmurą. Na szczęście jest historia wersji.
Ważne jest również to, że sieć produkcyjna została wcześniej odseparowana od sieci biurowej. Żadna maszyna nie ucierpiała, produkcję można wznowić.
Co z maszynami wirtualnymi, plikami baz danych, kopiami bare metal serwerów fizycznych? Logowanie do serwera backupu (głównego). Pliki są jednak zaszyfrowane. Powód? Backup oparty na Windows Server w domenie. Pobrany skrypt również tam zajrzał.
W serwerowni stoi mały biały NAS, dwa dyski w RAID 1, czy kopie są bezpieczne?
Przywracanie
Logowanie na NAS. Szybki przegląd plików, również zaszyfrowanych, ale jedynie te, które zostały synchronizowane z głównego backupu. Straty w plikach baz danych około 15 minut, główny plik nienaruszony. Pliki aplikacji (instalatory) są bezpieczne. Można podmienić po instalacji te, które na serwerach nie zostały zaszyfrowane. Pliki pakietu Office (jeden działa na lokalnym serwerze), wyglądają również dobrze; brak strat ze względu na to, że ostatnie zapisy miały miejsce przed atakiem i zdążyły się synchronizować na NAS. Skrzynki mailowe są bezpieczne, poczta w Office 365, więc wystarczy synchronizacja na stacje.
Dlaczego NAS przetrwał? Odpowiedź jest bardzo prosta. Urządzenie oparte na GNU/Linuxie, brak domeny, więc złośliwy skrypt nie miał jak się zalogować i tylko to uratowało organizację przed totalną katastrofą.
Zespół rozpoczyna przywracanie. Przegląd rozpoczyna się od serwerów krytycznych. Kopiuje zaszyfrowane pliki, przegląda konfiguracje, montowanie dysków i inne konfiguracje, które są niezbędne do odzyskania działania.
Formatowanie dysków, instalacja świeżej kopii systemu, instalacja aplikacji, baz danych oraz pozostałej konfiguracji.
I tutaj zaczynają się schody, odzyskiwanie backupu. Kopiowanie plików trwa bardzo długo, pod koniec tego procesu błąd odczytu. Dyski gorące, powtórka procesu, ten sam błąd. Sprawdzenie dysków, na jednym z dysków bad sectory. Szybka decyzja, odłączenie uszkodzonego dysku. Firma w tamtym momencie „wisi” na jednym dysku. Jeżeli nie uda się skopiować plików, sytuacja stanie się dramatyczna. NAS przeniesiony do serwerowni, aby temperatura była jak najniższa. Pliki kopiują się szybciej, główna baza danych oraz ostatnie kopie różnicowe w końcu zostały odzyskane. Wielka chwila, odzyskanie konfiguracji oraz skopiowanie odzyskanych plików bazy danych. Pliki zamontowane na konkretnych partycjach z poprawnymi literkami. Usługi MSSQL uruchomiły się poprawnie. Wejście przez Management Studio, baza jest, listuje tabele, dane są. Odzyskujemy kolejne kopie różnicowe, aby oddzyskać jak najwięcej. Ostatecznie straty na głównej maszynie, niewielkie, około 15 minut, dotyczą jedynie zleceń przeznaczonych do wysyłki.
Instalacja aplikacji biznesowej, podpięcie do bazy, uruchomienie aplikacji. Dane wyglądają dobrze: historia zamówień, konfiguracje klientów itd.
Kolejne kroki to przygotowanie najważniejszych stacji roboczych, aby uruchomić produkcję. Zapowiada się mnóstwo pracy. Jednak małymi krokami przywracane są kolejne elementy produkcji. Praca po 14–16 h przez kolejne 4 dni.
Na szczęście straty wśród końcówek nie są duże. Znaczna część urządzeń była wyłączona zarówno w biurze, jak i zdalnie. Z ponad 200 stacji jedynie około 30 wymagało ponownego przeinstalowania.
Pracownicy otrzymali instrukcje, czego nie mogą robić. Po długim weekendzie mieli pojawić się w biurze w celu przywrócenia sprawności swoich urządzeń, skanowania dysków, instalacji kolejnych aplikacji antywirusowych oraz zbierania danych śledczych, aby zidentyfikować sprawcę.
Każda stacja otrzymała dodatkowe oprogramowanie antywirusowe, które szukało konkretnego pliku na dysku. Zainfekowane końcówki zostały sformatowane oraz skonfigurowane do nowa.
Po 4 dniach i w sumie ponad 60 godzinach pracy każdego członka zespołu firma odzyskała możliwości produkcyjne. Pozostałe mniej istotne usługi zostały przywrócone kilka dni później w normalnym 8-godzinnym trybie pracy.
Jedyne straty to konieczność pracy w nadgodzinach. Produkcja oraz dostawy nie ucierpiały.
Przyczyna
Analiza przez specjalistów od cyberbezpieczeństwa z centrali wykazała, że do infrastruktury w sposób nieautoryzowany dostał się intruz. Doszło do przejęcia konta Administratora Przedsiębiorstwa. Następnie atakujący dodaje mały skrypt, który rozsyła poprzez GPO kopie w celu uruchomienia. Co robi skrypt? Po przesłaniu na lokalne maszyny zaczyna skanować dyski, wyszukuje konkretne pliki: .mdf, .sdf, .exe, .doc, docx, .xsl, .xslx itd., aby je zaszyfrować. Nie rusza jedynie plików systemowych, aby maszyna nadal była w stanie się uruchomić i pokazać informacje o wymuszeniu okupu.
Wprowadzone zmiany
Po takim incydencie zostały wdrożone zmiany w organizacji.
Na początek wzmocnienie kont użytkowników:
- Każde konto obligatoryjnie musi wykonać zmianę hasła.
- Hasła zostały zmienione również na kontach serwisowych, które uruchamiały procesy.
- Dodatkowo hasło musi mieć długość min. 14 znaków.
- Historia starych haseł ostatnie 12. Zmiana co 3 miesiące.
- Dodatkowo dostęp do aplikacji krytycznych wymaga podwójnego uwierzytelniania poprzez MFA.
- Logowanie do każdej aplikacji wewnętrznej również wymusza utrzymywanie hasła (wcześniej różnie z tym bywało).
- Wdrożenie aplikacji do utrzymywania aktualizacji wszelkich aplikacji, nie tylko poprawek do systemu operacyjnego czy pakietu Office.
- Aktualizacje w trybie ciągłym. Każda nowa poprawka musi trafić do systemu jak najszybciej.
- Upgrade systemów operacyjnych do najnowszych wersji.
- Dodatkowe wzmocnienie ochrony antywirusowej poprzez centralizację zarządzania Windows Defenderem.
- Szkolenia dla użytkowników 2 razy do roku poprzez platformę online.
- Wzmocnienie ochrony na urządzeniach brzegowych: routery.
Podsumowanie
Wygląda jak fajna opowieść. Jest tylko jeden problem. Powyższy opis zdarzył się naprawdę. Pomimo lokalnych wdrożeń, pilnowania infrastruktury, uświadamiania użytkowników, atak przyszedł z wewnątrz lokalizacji, ponieważ ktoś w centrali popełnił błąd. Co z tego wynika dla Ciebie? Nadzór nad środowiskiem, poświęcanie czasu na aktualizacje, monitoring. Wymiany sprzętu, szkolenia użytkowników są bardzo istotne. Jednak wiemy, w jaki sposób wygląda codzienność. Ważniejsze jest odbieranie telefonów od użytkowników, bo znów skończył się toner lub padła myszka. Czasu na rzeczy istotne jest mniej niż trzeba. Takie sytuacje nie zdarzają się tylko w urzędach, w których ciągle nie ma środków czy zespołów z prawdziwego zdarzenia. Zdarzają się w dużych organizacjach, w których pieniądze na inwestycje są wystarczające.
Dziękuję Ci, za poświęcony czas na przeczytanie tego artykułu. Jeśli był on dla Ciebie przydatny, to gorąco zachęcam Cię do zapisania się na mój newsletter, jeżeli jeszcze Cię tam nie ma. Proszę Cię także o “polubienie” mojego bloga na Facebooku oraz kanału na YouTube – pomoże mi to dotrzeć do nowych odbiorców. Raz w tygodniu (niedziela punkt 17.00) otrzymasz powiadomienia o nowych artykułach / projektach zanim staną się publiczne. Możesz również pozostawić całkowicie anonimowy pomysł na wpis/nagranie.
Link do formularza tutaj: https://beitadmin.pl/pomysly
Pozostaw również komentarz lub napisz do mnie wiadomość odpisuję na każdą, jeżeli Masz jakieś pytania:).
