Skip to content

Cayman National – studium przypadku eksfiltracji infrastruktury Hyper–V

Jump to bottom
Tomasz Klim edited this page Jun 17, 2022 · 2 revisions

O banku Cayman National

Założony na Wyspie Man, Cayman National od 1985 roku oferuje cały szereg usług zarządzania majątkiem klientów, obejmujących usługi bankowe powiernicze. Bank jest częścią grupy Cayman National Corporation, z biurami zlokalizowanymi na Wyspie Man, Kajmanach i Dubaju.

Grupa Cayman National Corporation została założona w 1974 roku i zapewnia swoim klientom szeroki zakres krajowych i międzynarodowych usług finansowych. Jej portfolio klientów obejmuje osoby zamożne i ich rodziny, jak i przedsiębiorców, firmy inwestycyjne, pośredników finansowych i organizacje charytatywne.

O wycieku z 2019 roku

W 2019 roku popularny hacker znany jako Phineas Fisher opublikował około 2 terabajty danych skradzionych z Cayman National. Wyciek ten, poza samymi dokumentami, obejmował też katalog "October 2019" zawierający 11 archiwów 7-Zip, zawierających 25 plików z obrazami dysków wirtualnych w formacie Hyper-V (VHD i VHDX).

Jako że dane te są od 3 lat publicznie i bardzo łatwo dostępne (więc każdy może je pobrać i zweryfikować nasze wyniki), a zarazem są to prawdziwe dane prawdziwej firmy (w dodatku banku), a nie jakiś lepszy lub gorszy syntetyczny benchmark – postanowiliśmy oprzeć naszą analizę wydajności eksfiltracji danych z Hyper-V właśnie na nich.

Omówienie plików źródłowych

Tak naprawdę w wycieku dostępne są 2 katalogi z danymi, z kopiami zapasowymi tych samych systemów z czerwca i października 2019. My skupiliśmy się wyłącznie na tym drugim, o nazwie "October 2019", zawierającym łącznie 25 obrazów dysków wirtualnych:

  • 21 plików było kompletnych, spójnych i możliwych do eksfiltracji
  • 3 pliki były uszkodzone w taki sposób, że eksfiltracja systemów plików była niemożliwa, więc musiały być eksfiltrowane jako osobne pliki (do późniejszej naprawy manualnej)
  • 1 plik był uszkodzony w bardzo specyficzny sposób (patrz niżej)

Przyjrzyjmy się bliżej zawartości tych plików. Każdy obraz zawiera od 1 do 3 partycji NTFS - zawsze 1 partycję główną (widzianą w systemie jako litera dysku), a w niektórych przypadkach też dodatkowe partycje zarezerwowane i rozruchowe (bez danych, lub z minimalną ilością plików odpowiedzialnych za start systemu Windows). W poniższej tabeli dla uproszczenia dodaliśmy do siebie pliki i megabajty z partycji głównych i pozostałych.

powierzchnia [MB] zajętość [MB] zajętość [%] ilość plików
Athol_-_File_Application_Server/Virtual Hard Disks/Athol_C.vhd 71 680 61 522 85,83 301 381
Athol_-_File_Application_Server/Virtual Hard Disks/Athol_S.vhd 430 080 345 568 80,35 405 639
CN-AMLT/CN-AMLT_C.vhdx 51 204 24 351 47,56 167 501
CN-FS01/CN-FS01_C.vhdx 71 684 26 569 37,06 204 568
CN-PAMLT/CN-PAMLT_C.vhdx 51 204 26 015 50,81 169 695
CN-ProBank/CN-ProBanx_C.vhdx 102 404 98 662 96,35 317 480
CN-WEB/CN-WEB_C.vhdx 51 204 12 996 25,38 137 013
Hyper-V/Virtual Hard Disks/CaymanUAT_C.vhd 184 320 118 982 64,55 200 817
Hyper-V/Virtual Hard Disks/CN-AMLTS_C.vhdx 92 164 81 938 88,9 188 364
Hyper-V/Virtual Hard Disks/CN-BPM_C.vhdx 40 964 38 462 93,89 239 471
Hyper-V/Virtual Hard Disks/CN-Intranet_C.vhdx 40 964 25 609 62,52 224 476
Hyper-V/Virtual Hard Disks/CN-LFR_C.vhdx 61 444 45 628 74,26 200 967
Hyper-V/Virtual Hard Disks/CN-LFR_E.vhdx 409 604 291 757 71,23 6 467 670
Hyper-V/Virtual Hard Disks/CN-LFR_F.vhdx 204 804 90 480 44,18 2 206 860
Hyper-V/Virtual Hard Disks/CN-LFRT_C.vhdx 61 444 20 720 33,72 161 189
Hyper-V/Virtual Hard Disks/CN-SQL_C.vhdx 61 444 20 295 33,03 119 963
Hyper-V/Virtual Hard Disks/CN-SQL_E.vhdx 153 604 3 108 2,02 1 648
Primacy/Primacy_C.vhd 104 448 91 207 87,32 233 394
Primacy/Primacy_E.vhd 266 240 90 596 34,03 25 077
Primacy2016_SQL/SQL_C.vhdx 102 404 93 453 91,26 369 913
Primacy2016_SQL/SQL_D.vhdx 307 204 230 271 74,96 18 520
2 920 512 (razem MB) 1 838 189 (razem MB) 60,91 (średnio) 12 361 606 (razem plików)

Zastanawia nas bardzo wysoki stopień zajętości powierzchni wielu dysków, w ponad połowie przypadków przekraczający 60%, a w 6 przypadkach 85%. Może to świadczyć o problemach z bieżącą obsługą IT tych systemów. Problem ten został pokazany na poniższym wykresie:

Uszkodzone pliki

Jak już zostało wspomniane wyżej, 4 pliki były uszkodzone, na 3 różne sposoby:

  • plik CN-FS01_D.vhdx, z obrazem dysku z dokumentami od wewnętrznego serwera plików, był uszkodzony w bardzo nietypowy sposób: dysk dało się otworzyć przez qemu i zamontować, a nawet podejrzeć deklarowany stopień zajętości (148 GB), jednak z całej zawartości widocznych było tylko kilka pustych katalogów i popsutych linków symbolicznych
  • plik CN-DC1_C.vhdx, będący obrazem głównego dysku kontrolera domeny Active Directory, nie nadawał się do zamontowania przez qemu (w związku z czym został eksfiltrowany jako osobny plik), natomiast nadawał się do rozpakowania partycji programem 7-Zip (partycja główna była nadal uszkodzona, ale po wypakowaniu można było z nią dalej pracować w specjalistycznych programach do odzyskiwania danych)
  • pozostałe 2 pliki (dyski od serwera poczty Exchange 2013) również nie nadawały się do bezpośredniego zamontowania przez qemu (w związku z czym zostały eksfiltrowane jako osobne pliki) - natomiast wymagały jedynie ponowienia zmian z journala i oznaczenia jako poprawnie zamknięte

Poniższy wykres przedstawia współczynniki kompresji dla poszczególnych obrazów dysków:

Z naszych innych testów wynika, że ukazane wyżej współczynniki kompresji są dość reprezentatywne (dla metody kompresji lz4 -1):

  • dla systemów Windows i Windows Server, z co najmniej kilkoma miesiącami historii ściągania, rozpakowywania i instalowania aktualizacji, typowy współczynnik kompresji obrazu dysku C:\ to ok. 40-45%
  • dla świeżo zainstalowanych systemów Windows, gdzie wolna przestrzeń nie była jeszcze wykorzystywana i w większości jest wyzerowana, typowy współczynnik kompresji zależy od ilości tego wolnego miejsca - w przypadku dysków tworzonych "na styk", może on zejść nawet do 30% (chociaż bardziej typowe jest ok. 35%)
  • kontenery VHD mają wg naszych obserwacji skłonność do osiągania nieco lepszych wyników kompresji od VHDX - nie jesteśmy pewni, dlaczego tak się dzieje (oba formaty są bardzo podobne do siebie)
  • dyski o dynamicznym rozmiarze (gdzie kontener rośnie w miarę zapisywania nowych danych) mają generalnie dużo gorsze współczynniki kompresji od dysków statycznych - natomiast dla świeżo instalowanych systemów, po kompresji mogą one nadal mieć mniejszy rozmiar od tych drugich
  • kontenery z danymi wytworzonymi przez użytkownika (i to prawie dowolnymi: dokumenty, zdjęcia, filmy, bazy danych itd.) najczęściej osiągają dużo gorsze współczynniki kompresji od kontenerów z samym dyskiem C:\ (a więc głównie z plikami systemowymi, np. katalogi Windows czy Program Files) - szczegółowe wyniki zależą od typu danych użytkownika (niektóre typy plików są już wewnętrznie skompresowane, inne nie), oraz ilości wolnego miejsca, które nie było wcześniej używane (a więc nadal jest wyzerowane)

Jakiego rzędu oszczędności zapewnia Funkcjonariusz?

Jedną z głównych przewag Funkcjonariusza nad rozwiązaniami konkurencyjnymi, jak również nad skryptami tworzonymi ad-hoc, jest wydajność procesu eksfiltracji danych, rozumiana zarówno jako szybkość, jak i zmniejszenie ilości danych do skopiowania na dysk docelowy.

Przyjrzyjmy się, jak 2.92 TB oryginalnych danych (pomijając uszkodzone dyski) rozkłada się na dane skopiowane i pominięte:

  • 1.36 TB danych skopiowanych (czyli zaledwie 46.6% łącznego rozmiaru oryginalnych dysków)
  • 0.48 TB powierzchni dyskowej zaoszczędzonej dzięki wykluczeniu bezwartościowych danych za pomocą ponad 400 reguł wykluczających
  • 1.08 TB to wolne miejsce na oryginalnych dyskach (również zaoszczędzone dzięki kopiowaniu tylko plików, zamiast całych obrazów dysków)

Oczywiście, jak widać na powyższym wykresie, konkretna oszczędność jest zależna od specyfiki dysku i jest w każdym przypadku inna.

Generalnie, świeżo zainstalowany Windows, bez żadnych plików utworzonych przez użytkownika, ani zainstalowanych programów dodatkowych, po eksfiltracji zajmuje niecały 1 GB - ponieważ olbrzymia większość jego plików systemowych (a także plików związanych z typowymi programami, np. Adobe Reader, bazy programów antywirusowych itd.) jest wyłączana z eksfiltracji przez reguły wykluczające (żółte fragmenty na wykresie).

Natomiast ciemno-szare fragmenty wykresu to:

  • pliki wygenerowane (lub po prostu ściągnięte) przez użytkowników
  • nietypowe zainstalowane programy
  • bazy danych
  • kopie zapasowe
  • logi
  • wszystko inne, co było zbyt niepowtarzalne/nietrywialne i potencjalnie wartościowe, aby móc to bezpiecznie wykluczyć regułami

Konkretnie w przypadku danych Cayman National, większość powierzchni dyskowej zajmują:

  • bazy danych Microsoft SQL Server (zarówno "żywe" bazy, jak i ich liczne kopie zapasowe rozrzucone po różnych katalogach - głównie są to bazy związane z mechanizmami AML, oraz bazy robocze specjalizowanych aplikacji bankowych, stworzonych przez Primacy Corporation)
  • skany dokumentów - głównie z platformy do zarządzania elektronicznym obiegiem dokumentów Laserfiche DMS, ale też luźne pliki PDF
  • pliki PST od Outlooka (a ponad 300 GB kolejnej poczty w formacie Exchange 2013 znajduje się w popsutym pliku CN-EX01_S.vhdx, który jest kopiowany osobno i wymaga późniejszej ręcznej naprawy)

Porównanie wydajności: duże/małe pliki, dyski SSD/magnetyczne

Z wymienionych wyżej plików, bazy danych Microsoft SQL Server i pliki PST od Outlooka są bardzo duże - średnio po kilka gigabajtów na plik. Dla odmiany, skany dokumentów (w większości tworzone przez oprogramowanie Laserfiche) są bardzo małe, natomiast jest ich mnóstwo - stanowią 87.4% wszystkich eksfiltrowanych plików, bądź 70.2% wszystkich plików źródłowych.

Jak to wpływa na wydajność eksfiltracji danych?

  • kopiowanie dużej ilości małych plików z oczywistych względów trwa dłużej od kopiowania kilku dużych plików
  • złożone struktury katalogów (np. wolumeny danych Laserfiche DMS) również spowalniają kopiowanie, w porównaniu z taką samą ilością plików, ale ułożonych w płaską strukturę katalogów

Z drugiej strony, małe pliki mogą być odczytane za jednym podejściem (technicznie rzecz biorąc, za 3 wywołaniami systemowymi: stat, open i read), gdy większe pliki wymagają wielu dostępów do dysku. W niektórych sytuacjach, głównie przy eksfiltracji dysków magnetycznych, albo napędów podłączonych przez niewydolnie działające iSCSI, eksfiltracja dużych plików z wnętrza kontenerów VHDX może działać niewydolnie. Nasze eksperymenty pokazały, że większość chwilowych wahań wydajności (zarówno w górę jak i w dół), jak i innych anomalii wpływających na wydajność, jest powodowana przez samo oprogramowanie qemu, które jest bardzo wrażliwe na problemy z kontenerami VMDK/VHD/VHDX, jak również znajdującymi się w nich systemami plików - szczególnie jeśli urządzenie fizyczne pod spodem jest powolne albo wysycone wydajnościowo.

Generalnie rozkład wydajności procesu eksfiltracji wygląda podobnie do rozkładu wielkości plików na każdym z dysków - świetnie uwidacznia to poniższy wykres, pokazujący różnicę w wydajności eksfiltracji danych z dysków SSD i magnetycznych:

Kontenery VMDK/VHD/VHDX są montowane przy użyciu biblioteki FUSE i hiperwizora QEMU, który "pod spodem" uruchamia okrojoną instancję Linuxa. Całość jest niestety dość niestabilna i bardzo wrażliwa na wszelkiego rodzaju problemy z kontenerami i systemami plików. A do tego powolna - czy też, bardziej precyzyjnie, każda operacja dyskowa ma gigantyczny narzut wydajnościowy ze strony QEMU.

Jest to szczególnie widoczne właśnie przy eksfiltracji kontenerów leżących na dyskach magnetycznych (żółte fragmenty na powyższym wykresie), gdzie proces eksfiltracji jest średnio 11.7x mniej wydajny, niż w przypadku dysków SSD - a patrząc na same obrazy dysków C:\ od poszczególnych serwerów, wydajność ta potrafi spaść jeszcze bardziej (np. CN-SQL_C.vhdx czy CD-Intranet_C.vhdx)

Sprzęt testowy

Wszystkie opisane testy były prowadzone na następującym sprzęcie:

z systemem operacyjnym Kali Linux 2021.1 z jądrem 5.10.13-1kali1 (amd64) - tj. identycznym jak ten, na którym normalnie działa Funkcjonariusz.

Konfiguracja dysków i szyfrowania;

  • wszystkie dyski były podłączane do portów USB 3.0 na froncie obudowy
  • wszystkie dyski źródłowe miały po jednej partycji, sformatowanej jako ext4, bez jakiegokolwiek szyfrowania danych (programowego lub sprzętowego)
  • dysk docelowy - partycja z danymi sformatowana jako ext4 z szyfrowaniem LUKS, skonfigurowana jako partycja persistent dla Kali Linuxa
  • standardowa konfiguracja Funkcjonariusza + dodatki do eksfiltracji Hyper-V, całość skonfigurowana przy użyciu narzędzi z repozyorium deployment-scripts)

Dostępność surowych danych

Ten arkusz zawiera komplet surowych danych nt. plików źródłowych, jak i wydajności procesu eksfiltracji.

Jeśli chcesz porozmawiać nt. tych danych lub metodyki testów, albo doprecyzować elementy, które nie zostały dostatecznie jasno opisane, zapraszamy do kontaktu na adres email podany w stopce strony.

Oświadczenia prawne

  1. Pomimo tego, że pliki będące przedmiotem tego opracowania zostały opublikowane w Internecie w 2019 roku i są bardzo proste do znalezienia, ze względów prawnych nie możemy podać do nich bezpośrednich linków.

  2. Nie przetwarzaliśmy i nie zamierzamy przetwarzać danych ze wspomnianych plików w żadnym innym celu, niż testy techniczne i wydajnościowe procesu eksfiltracji danych przez Funkcjonariusza, oraz przygotowanie tego opracowania w celu opisanym w art. 269b § 1a Kodeksu karnego. W szczególności nie interesują nas żadne szczegóły biznesowe dotyczące działalności Cayman National, ani jego klientów.

  3. Nie jesteśmy w żaden sposób zaangażowani ani powiązani z oryginalnym wyciekiem. Po prostu pobraliśmy udostępnione przez kogoś pliki, tak jak może to w każdej chwili zrobić każda inna osoba.

© 2020-2022 Tomasz Klim Payload.pl, Wszelkie prawa zastrzeżone.

Clone this wiki locally