VMDK Data Recovery After an Akira Ransomware Attack
Odzyskiwanie danych VMDK
Środowisko:
Infrastruktura VMware, której kopie zapasowe wykonuje Nakivo na 12-wnękowym urządzeniu Synology RS3621RPXs, RAID 5, BTRFS
Atak:
Ransomware Akira
Dane zagrożone:
Około 11 TB zaszyfrowanych kopii zapasowych maszyn wirtualnych, pozostałe dane usunięte
Komplikacja:
Około 15 TB zapisano na tym samym woluminie dzień po ataku
Wynik:
Odzyskano 99,91% na priorytetowym serwerze bazy danych
Wielolokalizacyjna organizacja przedsiębiorstwa padła ofiarą ataku ransomware Akira, który zakłócił dostęp do krytycznych systemów zwirtualizowanych i naraził na ryzyko znaczne części jej środowiska produkcyjnego. Około 11 TB kopii zapasowych maszyn wirtualnych przechowywanych w repozytorium Nakivo klienta zostało zaszyfrowanych. Pozostałe kopie zapasowe zostały usunięte.
Ten sam atak zaszyfrował produkcyjne maszyny wirtualne, pozbawiając organizację danych niezbędnych do przywrócenia działalności biznesowej.
W ciągu kilku dni organizacja zaangażowała swojego ubezpieczyciela cybernetycznego oraz firmę zajmującą się reagowaniem na incydenty. Konwencjonalne metody przywracania danych pozwoliły odzyskać część środowiska, jednak nie udało się przywrócić kilku priorytetowych maszyn wirtualnych. Firma zajmująca się reagowaniem na incydenty przekazała sprawę do DriveSavers Data Recovery, aby ustalić, czy z dotkniętej pamięci masowej można jeszcze odzyskać użyteczne dane oraz czy uszkodzone dyski maszyn wirtualnych da się zrekonstruować.
Zanim dyski dotarły do DriveSavers, szyfrowanie przez ransomware nie było już jedynym problemem.
Analiza techniczna przeprowadzona za pomocą naszego zastrzeżonego narzędzia do odzyskiwania dysków wirtualnych wykazała, że około 15 TB danych zostało zapisanych na woluminie dzień po ataku — już po tym, jak kopie zapasowe Nakivo zostały usunięte. Te zapisy okazały się mieć poważne konsekwencje.
Usunięcie pliku w systemie BTRFS nie usuwa jego zawartości. Systemy plików tego typu zazwyczaj oznaczają dotknięte bloki jako dostępne do ponownego użycia, podczas gdy same dane pozostają na miejscu, dopóki coś nie zostanie na nich zapisane. Zapisy wykonane po ataku zostały przydzielone do bloków, które wcześniej zajmowały usunięte kopie zapasowe.
Dalsza analiza techniczna wykazała, że znacznie większa część docelowych informacji, a potencjalnie nawet wszystkie, mogłaby zostać odzyskana, gdyby dotknięta pamięć masowa pozostała niezmieniona.
Wolumin, który dotarł do DriveSavers, zawierał zatem mieszankę oryginalnych, nienaruszonych danych, danych zaszyfrowanych przez ransomware, danych usuniętych i ponownie przydzielonych, nowo zapisanych informacji, uszkodzonych struktur systemu plików oraz częściowo nadpisanych bloków. Około 3600 plików o łącznej wielkości 16,1 TB pozostało aktywnych, z czego 99% stanowiły dyski wirtualne VMware i migawki z rozszerzeniami przepisanymi na .AKIRA.
Jedna cecha ataku poprawiła perspektywy. Algorytm szyfrowania użyty w tym incydencie nie szyfrował całych plików. Szyfrował około 15% każdego pliku w trzech pasmach, co w przypadku dużych plików VMDK objawiało się jako około 5-procentowe szyfrowanie na początku pliku. Znaczące obszary każdego dysku wirtualnego pozostały więc nienaruszone. Aby zidentyfikować te nienaruszone obszary, konieczna była analiza na poziomie bloków.
Zdalna ocena potwierdziła zakres projektu i posłużyła do ustalenia, czy odzyskiwanie danych może zostać przeprowadzone zdalnie, czy też będzie wymagać pracy w laboratorium. Odzyskanie tych danych oznaczało odczytanie wszystkich dwunastu dysków na poziomie sektorów, w tym obszarów, do których system plików już się nie odwoływał, a zdalny dostęp do działającego urządzenia NAS zazwyczaj sięga do woluminu logicznego, a nie do bazowego nośnika fizycznego. Zdalne odzyskiwanie danych nie było możliwe. Inżynier odebrał dyski na Międzynarodowym Lotnisku w San Francisco w kolejną niedzielę wieczorem.
Wszystkie dwanaście dysków zostało zobrazowanych w ciągu 24 godzin od dostarczenia, a każda kolejna operacja była wykonywana na tych obrazach. Oryginalne nośniki pozostały przez cały czas w stanie, w jakim zostały otrzymane, co pozwoliło zachować stan dowodowy podczas trwającej analizy.
Skanowanie około 120 TB pojedynczo, obraz po obrazie, nie byłoby wykonalne. Inżynierowie podzielili pracę na zakresy terabajtowe i uruchomili dziesięć skanów jednocześnie, co doprowadziło przepustowość do granic samego sprzętu. Następnie na drugim systemie zbudowano drugi zestaw obrazów, aby ekstrakcje mogły przebiegać równolegle na obu maszynach.
W miarę usuwania danych system BTRFS zaczął czyścić warstwę mapującą przechowywane dane do ich fizycznych lokalizacji. Dotyczyło to około 7 TB tej mapy, co powodowało bezużyteczne wyniki z nośnika, który w innym przypadku byłby odczytywalny. Inżynierowie ustalili, że dotknięte obszary zostały przydzielone w sposób ciągły przed usunięciem, co umożliwiło ręczną rekonstrukcję. Ręczne odbudowanie mapy przywróciło dostęp do około 5 TB danych kopii zapasowej, które system plików już wcześniej zwolnił.
Uszkodzony plik VMDK rzadko jest po prostu odczytywalny lub nieodczytywalny. Inżynierowie oddzielili nienaruszone obszary od tych, które zostały zaszyfrowane, uszkodzone, częściowo nadpisane lub strukturalnie uszkodzone. Trzy maszyny o najwyższym priorytecie miały po pięć lub sześć punktów przywracania każda, z których najnowszy wykonano krótko przed atakiem, co dało łącznie 35 plików VMDK. Uszkodzenie dotyczyło 3–5% każdego z tych plików. W przypadku jednej z trzech maszyn narzędzie szyfrujące w ogóle nie dotarło do plików dysku wirtualnego.
Tam, gdzie same dane kopii zapasowej nie obejmowały danego zbioru danych, inżynierowie dołączali niezaszyfrowane obszary produkcyjnych dysków wirtualnych. Podejście to było skuteczne, choć wymagało zachowania ostrożności. Dwie z trzech maszyn priorytetowych zawierały również pliki migawek, które nie mają relacji jeden do jednego z danymi, które reprezentują. Struktury mapujące pliki migawek na dane, które reprezentowały, znajdowały się w zaszyfrowanych obszarach. Wykorzystanie produkcyjnych dysków wirtualnych do wypełniania luk mogło zatem wprowadzić starsze dane i spowodować uszkodzenia, które byłyby trudne do wyśledzenia później. Inżynierowie oceniali ryzyko dla każdego zbioru danych indywidualnie, zamiast łączyć dane domyślnie.
DriveSavers współpracował z firmą reagowania na incydenty i klientem, aby z wyprzedzeniem ustalić, do jakiego środowiska dyski zostaną zaimportowane. Wyodrębnione dane na poziomie plików zwrócono najpierw przez sieć, dzięki czemu klient mógł uzyskać dostęp do konkretnych plików, podczas gdy pozostała część prac trwała nadal. Następnie dostarczono kompletne pliki VMDK nadające się do ponownego zaimportowania.
DriveSavers przeprowadził zlecenie w formie siedmiu osobno zdefiniowanych podprojektów, przy udziale wielu inżynierów pracujących równolegle, dzięki czemu systemy o najwyższym priorytecie mogły zostać opracowane i zwrócone przed pozostałą częścią środowiska.
DriveSavers przez cały czas informował firmę reagowania na incydenty oraz klienta, że nie można zagwarantować, iż zrekonstruowane pliki VMDK się uruchomią. Co najmniej jedna odzyskana maszyna wirtualna uruchomiła się poprawnie. Pozostałe zwrócono jako odzyskane dane oraz naprawione dyski.
Do każdego naprawionego dysku wirtualnego dołączono raport na poziomie bloków, wskazujący, które obszary dysku były nienaruszone, a które doznały nieodwracalnych uszkodzeń, wraz z liczbą obiektów, plików, katalogów i bajtów dla każdego z nich. Dla zespołów technicznych odbudowujących środowisko tego typu raportowanie dostarcza znacznie więcej informacji niż samo oznaczenie „odzyskano” lub „nie odzyskano”. Pozwala administratorom ocenić jakość odzyskanego obrazu oraz ustalić, czy potrzebne jest dodatkowe odzyskiwanie na poziomie aplikacji, wyodrębnianie plików lub odbudowa.
Gdy aplikacja do tworzenia kopii zapasowych nie może dokończyć przywracania danych, dane leżące u podstaw mogą nadal znajdować się w pamięci masowej. To repozytorium zostało zaszyfrowane, opróżnione,
Odzyskiwanie danych maszyn wirtualnych w takich warunkach wymaga specjalistycznej wiedzy, zastrzeżonych narzędzi oraz niestandardowego rozwoju dostosowanego do konkretnego zaangażowanego systemu plików. Gdy ransomware atakuje jednocześnie systemy produkcyjne i infrastrukturę kopii zapasowych, specjalistyczne odzyskiwanie danych po ransomware może zapewnić rozwiązanie techniczne, którego nie jest w stanie zaoferować konwencjonalne przywracanie danych.
Znajdujesz się w podobnej sytuacji? Skontaktuj się z DriveSavers pod numerem 1 (888) 282-2227.
English (United States) 
English (Australia) 
French (France) 
English (UK) 
French (Canada) 
English (Canada) 
Spanish (Mexico) 
German 
Dutch 
Italian 
Finnish 
Polish 
Norwegian 
Swedish 
Danish 
Spanish (Spain) 
Chinese 
Japanese 
German (Austria)