Menu

Funkcjonariusz: platforma open source do szybkiej eksfiltracji danych z komputerów, serwerów, telefonów, tabletów, aparatów cyfrowych i innych urządzeń USB.

kontakt@funkcjonariusz.com

Funkcjonariusz potrafi rekurencyjnie eksfiltrować maszyny wirtualne na serwerach VMware i Hyper-V.

Dlaczego potrzebny jest osobny tryb eksfiltracji maszyn wirtualnych?

Z punktu widzenia eksfiltracji danych, głównym problemem z serwerami wirtualnymi jest rezerwacja przestrzeni dyskowej. Każda maszyna wirtualna ma swój dysk twardy, którego tylko niewielką część zajmują dane warte eksfiltracji. Cała reszta to:

  • wolna przestrzeń - tak jak w każdym innym komputerze, tylko pomnożona przez ilość osobnych maszyn wirtualnych i ich dysków
  • dane, które i tak zostałyby pominięte dzięki regułom wykluczającym

Przykładowa maszyna wirtualna z Windows 10 może mieć dysk 300 GB, na którym:

  • 55 GB jest zajęte przez pliki systemu Windows (w tym wielki katalog WinSxS ze sterownikami)
  • 10 GB jest zajęte przez pliki tymczasowe takie jak pagefile.sys
  • zaledwie 18 GB jest zajęte przez pliki choć trochę warte eksfiltracji
  • ponad 200 GB to wolna przestrzeń

Funkcjonariusz w standardowej konfiguracji widzi tylko pliki z obrazami dysków wirtualnych i musi je kopiować w całości, co w oczywisty sposób marnuje miejsce na Twoim urządzeniu.

Podczas eksfiltracji serwerów Windows, które poza klasycznymi usługami typu bazy danych, obsługują dodatkowo np. 1-5 maszyn wirtualnych, najczęściej nie jest to problemem. Ale eksfiltrując duże, specjalizowane serwery wirtualizacyjne z setkami maszyn wirtualnych, bez zaglądania do środka tych maszyn szybko skończyłoby się miejsce na każdym, nawet największym dostępnym na rynku dysku.

Jak to działa?

  1. Po starcie komputera, Funkcjonariusz rozpoznaje podłączone dyski twarde i partycje na nich.
  2. Każda partycja po kolei jest montowana i eksfiltrowana - a przed samą eksfiltracją, przetwarzana przez hooki.
  3. hook-virtual skanuje partycję w poszukiwaniu plików z obrazami dysków wirtualnych (*.vmdk dla VMware, *.vhd i *.vhdx dla Hyper-V).
  4. Wszystkie znalezione obrazy są rekurencyjnie montowane jako partycje i eksfiltrowane.
  5. Jeśli eksfiltracja danego dysku wirtualnego się nie powiedzie (bo np. system plików w środku jest uszkodzony i wymaga ręcznej naprawy), dysk taki jest kopiowany w całości (i kompresowany w tle), aby można było go na spokojnie obrobić ręcznie.
  6. Reguły wykluczające z zestawu exclude-virtual wykluczają obrazy dysków wirtualnych z eksfiltracji w normalnym trybie.

Jakie oszczędności to daje w praktyce?

Artykuł Cayman National: studium przypadku eksfiltracji infrastruktury Hyper-V przedstawia szczegółową analizę wydajności procesu eksfiltracji danych z dużej części realnej infrastruktury bankowej, opartej na Hyper-V.

Instalacja

Tutaj znajdziesz instrukcję, jak instalować dodatkowe hooki i repozytoria konfiguracyjne. Cała konfiguracja specjalnego trybu obsługi serwerów wirtualnych sprowadza się do doinstalowania 2 repozytoriów opcjonalnych, a następnie - również opcjonalnie - konfiguracji kilku opisanych niżej ustawień szczegółowych (głównie jeśli znasz już konfigurację serwerów ofiary i chcesz szczegółowo dostosować do nich zachowanie Funkcjonariusza).

git clone https://github.com/drivebadger/exclude-virtual /opt/drivebadger/config/exclude-virtual
git clone https://github.com/drivebadger/hook-virtual /opt/drivebadger/hooks/hook-virtual

Obsługiwane hiperwizory

VMware

  • wszystkie produkty używające VMFS w wersji 6 (ESXi 6.5 lub nowszy)
  • wszystkie produkty typu "hosted virtualization" (działające na bazie normalnego systemu operacyjnego, głównie Windows)

Hyper-V

Ograniczenia

Ograniczenia związane z VMware

  • system plików VMFS w wersji starszej niż 6 nie jest obsługiwany
  • zagnieżdżona wirtualizacja z użyciem VMFS nie jest obsługiwana

Ograniczenia związane z Hyper-V

  • obrazy różnicowe AVHD/AVHDX nie są obsługiwane
  • wszystkie zmiany od ostatniego snapshota, zawarte w obrazach różnicowych AVHD/AVHDX, będą pominięte (a dane utracone)
  • system plików ReFS nie jest obsługiwany
  • Cluster Shared Volumes nie są obsługiwane
  • tryb parawirtualizacji Hyper-V w VirtualBox z użyciem dysków VDI nie jest obsługiwany

Szyfrowanie dysków twardych

Konfiguracja szczegółowa

Obsługa wirtualizacji zagnieżdżonej (nested virtualization)

Przeszukiwanie kontenerów VHD/VHDX/VMDK pod kątem kolejnych (zagnieżdżonych) kontenerów VHD/VHDX/VMDK działa bardzo, bardzo powoli - dlatego też standardowo jest wyłączone (co prowadzi do potencjalnej utraty danych, jeśli ofiara używa zagnieżdżonych maszyn wirtualnych VMware/Hyper-V - co na szczęście jest bardzo rzadkie, gdyż w takich przypadkach raczej używa się innego oprogramowania i innych rozszerzeń plików z obrazami dysków twardych).

Jeśli jednak chcesz włączyć przeszukiwanie maszyn wirtualnych VMware/Hyper-V pod kątem wirtualizacji zagnieżdżonej, musisz utworzyć na urządzeniu z Funkcjonariuszem 3 pliki (osobno dla każdego typu kontenera):

  • /opt/drivebadger/config/.allow-nested-vhd
  • /opt/drivebadger/config/.allow-nested-vhdx
  • /opt/drivebadger/config/.allow-nested-vmdk

Task spooler i Qemu: wydajność czy niezawodność?

hook-virtual używa prostego mechanizmu kolejkowania zadań task-spooler, aby kolejkować zadania eksfiltracji kolejnych kontenerów VHD/VHDX/VMDK. Domyślnie wykonywanie jest tylko 1 zadanie jednocześnie (nie licząc zadań kopiowania kontenerów w całości, które są realizowane w tle niezależnie).

Aby przyspieszyć proces eksfiltracji, możesz włączyć w task spoolerze wykonywanie 2 (lub więcej) zadań jednocześnie, wykonując z konsoli następujące polecenie:

tsp -S 2

Niestety eksfiltracja (i w ogóle montowanie) kontenerów VHD/VHDX/VMDK jest oparta na Qemu, który jest bardzo wrażliwy na wszelkiego rodzaju problemy dotyczące dysków wirtualnych i ich zawartości. Do tego obsługa błędów Qemu działającego w wielu instancjach działa nie do końca przewidywalnie, przez co uruchamianie wielu zadań jednocześnie może prowadzić do losowych problemów przerywających kopiowanie plików przez program rsync, a w najgorszym przypadku do trwałego zablokowania całego procesu eksfiltracji.

Uruchamianie więcej niż 3 jednoczesnych zadań na kontenerach Hyper-V (VHD/VHDX), albo więcej niż 4 na kontenerach VMware (VMDK), prawie zawsze prowadzi do utraty danych.

Metody kompresji

Gdy z jakiegoś powodu kontener VHD/VHDX/VMDK nie może zostać zamontowany i prawidłowo eksfiltrowany:

  • nie da się wylistować zawartych w nim partycji (nieobsługiwany układ partycji, uszkodzenie itp.)
  • eksfiltracja którejkolwiek partycji zakończy się niepowodzeniem (np. procesy rsync lub Qemu zostaną zabite)

wówczas taki kontener jest traktowany jako zwykły plik i kopiowany w całości na dysk docelowy. Jako że został on już wyłączony ze standardowej eksfiltracji przez reguły wykluczające, jest on kopiowany osobno - robi to skrypt copy-compress.sh, który przy okazji w locie go kompresuje, aby zaoszczędzić miejsce na dysku.

Dostępnych jest kilka różnych metod (i poziomów) kompresji:

  • lz4 - najszybsza, najmniejszy narzut pamięci RAM, nadal bardzo dobry współczynnik kompresji
  • gzip - najbardziej kompatybilna i uniwersalna metoda kompresji, dość szybka
  • pigz - wersja gzip dla procesorów wielordzeniowych (najlepsza wydajność kompresji kilku obrazów dysków jednocześnie na dużych procesorach, poza tym raczej problematyczna)
  • xz - najlepszy możliwy współczynnik kompresji, za to bardzo powolna (w większości przypadków niepraktyczna)
  • bzip2 - bardzo dobry współczynnik kompresji (gorszy niż xz/LZMA2), nadal bardzo powolna

Dobór najwłaściwszej metody kompresji:

  • w większości przypadków, zwłaszcza jeśli nie znasz dokładnej charakterystyki danych na eksfiltrowanych dyskach wirtualnych, wybierz po prostu lz4 lub gzip
  • pigz może się lepiej sprawdzić na dużych procesorach (np. Ryzen) i dość niewielkiej liczbie dysków wirtualnych, za to dużych
  • xz może się lepiej sprawdzić na dużych procesorach, dużej ilości RAM, przy wielu małych dyskach
  • bzip2 będzie się dobrze sprawdzał w podobnych scenariuszach do xz, ale ale przy dużo mniejszych wymaganiach dot. RAM
Wydajność

Porównanie wydajności kompresji dysku wirtualnego 80 GB ze świeżo zainstalowanym Solarisem 11, kopiowanego na Core i7-3770:

  • lz4 -1 - 12 minut
  • gzip -6 - 31 minut
  • różnica rozmiaru po kompresji: ~0.8GB (1%)
Konfiguracja domyślna

Domyślnie metoda i poziom kompresji ustawione są na lz4 -1, czyli kompresję możliwie najlżejszą, działającą wydajnie również na bardzo starych procesorach. Możesz to zmienić na kilka sposobów:

  • forkując to repozytorium i modyfikując ten skrypt - a następnie instalując na urządzeniach z Funkcjonariuszem swoją wersję zamiast oryginalnej
  • modyfikując ten skrypt lokalnie na wybranych urządzeniach - to jest najlepsze podejście, gdy widziałeś już wstępnie serwery ofiary i wiesz, jak najlepiej dostosować zachowanie Funkcjonariusza do każdego z nich, aby maksymalnie przyspieszyć ich eksfiltrację

Rozwiązywanie problemów z obrazami dysków

Hyper-V i nieprawidłowo zamknięte systemy

Najczęstszym (przynajmniej dla systemów Windows) powodem, dla którego obraz dysku nie daje się otworzyć i eksfiltrować, jest nieprawidłowe zamknięcie systemu operacyjnego (albo po prostu brak zamknięcia). System plików NTFS jest wówczas oznaczony jako "unclean" i wymaga sprawdzenia (a najczęściej także naprawy, sprowadzającej się do ponowienia zmian z journala) przed otwarciem.

Jeśli masz taki uszkodzony obraz, który został eksfiltrowany jako osobny plik, rozpakuj go (ale trzymaj kopię zapasową!) i wykonaj na nim następującą operację:

LIBGUESTFS_BACKEND=direct LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 virt-filesystems -a CN-FS01_C.vhdx

Najprawdopodobniej zobaczysz mniej więcej taki komunikat:

qemu-img: Could not open '/test/CN-FS01_C.vhdx': VHDX image file '/test/CN-FS01_C.vhdx' opened read-only, but contains a log that needs to be replayed
To replay the log, run:
qemu-img check -r all '/test/CN-FS01_C.vhdx'

Wykonaj to ostatnie polecenie - powinieneś zobaczyć coś takiego:

# qemu-img check -r all '/test/CN-FS01_C.vhdx'
The following inconsistencies were found and repaired:

    0 leaked clusters
    1 corruptions

Double checking the fixed image now...
No errors were found on the image.

Ale uwaga: w pewnych (na szczęście bardzo rzadkich) przypadkach, próba ponowienia journala przez QEMU może jeszcze bardziej uszkodzić system plików - dlatego zawsze trzymaj oryginalny plik ze skompresowaną kopią zapasową, aby móc go w razie potrzeby rozpakować kolejny raz i spróbować innego podejścia. To jest również powód, dla którego Funkcjonariusz nigdy nie próbuje naprawiać takich obrazów bezpośrednio w eksfiltrowanym systemie, tylko po prostu kopiuje je osobno do ręcznej obróbki.

podejście generyczne

Jeśli qemu-img check nie jest w stanie naprawić systemu plików, a jesteś pewien, że problem dotyczy właśnie systemu plików, a nie samego kontenera, możesz spróbować skonwertować ten kontener na obraz dysku RAW:

qemu-img convert -f vhdx -O raw broken.vhdx broken.raw
qemu-img convert -f vmdk -O raw broken.vmdk broken.raw

Obraz w takim formacie będziesz mógł dalej analizować w dowolnym narzędziu do odzyskiwania danych, a nie tylko w QEMU.

jeszcze bardziej generyczne podejście

Popularny archiwizator 7-Zip potrafi rozpakowywać obrazy dysków jak archiwa, wypakowując z nich pliki z pojedynczymi partycjami. Jeśli qemu-img convert nie zadziała, możesz spróbować właśnie tego podejścia:

7z x -o/destination/directory CN-FS01_C.vhdx

7-Zip jest mniej wrażliwy na różne problemy z kontenerem od QEMU. Większość kontenerów VHDX może być rozpakowana przez standardowy p7zip 16.02 (wersja zawarta w Kali Linux) - natomiast niektóre rodzaje problemów mogą być prawidłowo obsłużone dopiero przez wersję 7-Zip 21.07 lub nowszą (którą musisz sobie zainstalować osobno - są dostępne dla Linuxa i Windows).