DRAKVUF Sandbox¶

DRAKVUF Sandbox to otwartoźródłowy system służący do analizy behawioralnej złośliwych plików wykonywalnych. Jego kod jest udostępniany przez CERT Polska na licencji GPL w repozytorium CERT-Polska/drakvuf-sandbox. Jest to jedno z głównych rozwiązań wykorzystywanych przez serwis mwdb.cert.pl do analizy złośliwych plików na platformę Windows.

Sercem systemu jest silnik DRAKVUF autorstwa Tamasa Lengyela, który umożliwia monitorowanie aktywności procesów systemu operacyjnego działającego w maszynie wirtualnej.

W odróżnieniu od typowych rozwiązań typu sandbox, DRAKVUF nie wymaga instalacji tzw. agenta na monitorowanym systemie. Dzięki wykorzystaniu VMI (Virtual Machine Introspection) monitorowanie przeprowadzane jest z poziomu Dom0, czyli uprzywilejowanej domeny zarządzającej maszynami wirtualnymi. Pozwala to w nieinwazyjny sposób monitorować całą aktywność w zainfekowanym systemie, włącznie z operacjami wykonywanymi w trybie jądra. Ponieważ VMI nie wymaga uruchamiania dodatkowych programów czy sterowników na poziomie systemu gościa, fakt monitorowania jest trudniejszy do wykrycia niż w przypadku podejścia agentowego.

Jak działają sandboksy?¶

Metody analizy złośliwego oprogramowania można podzielić na dwie kategorie:

• analiza statyczna, która umożliwia pozyskanie informacji bezpośrednio z próbki oprogramowania, bez konieczności jej wykonywania,
• analiza dynamiczna, która polega na uruchomieniu programu i monitorowaniu jego zachowania, a następnie analizie skutków jego działania.

W praktyce obie metody łączy się, wykonując wpierw analizę dynamiczną i pozwalając programowi na dokonanie instalacji w systemie, a następnie statycznie analizując uzyskany w ten sposób ruch sieciowy, zrzuty pamięci i zawartość pobranych plików.

Analiza dynamiczna wymaga przygotowania specjalnego środowiska, które z jednej strony będzie możliwie jak najbardziej przypominać typowy komputer użytkownika, a z drugiej będzie umożliwiało obserwowanie zachowania i uzyskiwanie powtarzalnych rezultatów bez względu na rodzaj złośliwego oprogramowania. Takie środowisko musi być również odpowiednio odizolowane, aby uruchomienie złośliwego kodu nie zagrażało samemu środowisku i innym urządzeniom w tej samej sieci.

Aby spełnić te wymagania, najczęściej w tym celu stosuje się maszyny wirtualne, odpowiednio przygotowany snapshot z zainstalowanym docelowym systemem (np. Windows) i wyłączonymi zabezpieczeniami, które mogłyby utrudnić wykonanie złośliwego pliku. Na tak przygotowanym środowisku uruchamia się szereg rozwiązań, które pozwalają na monitorowanie i analizowanie zachowania programu np.:

• monitory, pozwalające przechwytywać interakcje z API systemu operacyjnego przez programy działające w systemie (np. Process Monitor, Sysmon, instrumentacja za pomocą Frida, w praktyce sandboksy stosują dedykowane rozwiązania)
• sniffery, czyli programy służące do przechwytywania ruchu sieciowego (np. tcpdump)
• narzędzia analityczne takie jak reguły YARA, Sigma czy capa, które pozwalają dopasować znane wzorce do uzyskanych logów z monitorowania, aby zidentyfikować rodzinę złośliwego oprogramowania, rozpoznać charakterystyczne zachowania i wskazać najważniejsze aktywności.

W praktyce środowiska służące do analizy dynamicznej są wysoce zautomatyzowane i z perspektywy analityka - analiza polega na załadowaniu pliku wykonywalnego, odczekaniu odpowiedniego czasu, a następnie uzyskaniu szczegółowego raportu.

Analiza agentowa, a bezagentowa¶

W klasycznym (agentowym) podejściu, monitor stanowi narzędzie, które jest uruchamiane na systemie gościa i monitoruje aktywność procesów poprzez wykorzystywanie odpowiednich mechanizmów systemu operacyjnego. Takimi mechanizmami mogą być:

• funkcje umożliwiające modyfikowanie pamięci innych procesów i wstrzykiwanie do nich własnego kodu
• funkcje debugowania, które pozwalają zatrzymać wykonanie programu w konkretnym miejscu i zmienić jego parametry
• funkcje przechwytywania operacji na poziomie jądra systemu operacyjnego (np. Process Monitor wykorzystuje do tego celu API dla sterowników minifilter)

Oznacza to, że programy monitorujące działają na tym samym systemie co monitorowany program i ściśle integrują się z systemem operacyjnym, przechwytując i zapisując zdarzenia. Przykładem popularnego rozwiązania stosującego podejście agentowe jest CAPE Sandbox.

Natomiast podejście bezagentowe wykorzystuje do monitorowania mechanizmy wirtualizacji sprzętowej i nie wymaga interakcji z systemem operacyjnym, który działa w maszynie wirtualnej. Jest to możliwe dzięki różnym mechanizmom zaimplementowanym w procesorach architektury x86-64, które umożliwiają przechwytywanie operacji wykonywanych przez wirtualną maszynę:

• VM-exit: Wirtualizacja niesie za sobą konieczność współdzielenia urządzeń między maszynami wirtualnymi, a systemem gościa, co wymaga przechwytywania różnych operacji w sposób transparentny dla wirtualizowanego systemu operacyjnego. W związku z tym, niektóre operacje generują tzw. VM-exit, czyli przerwanie wykonywania kodu w maszynie wirtualnej i przekazanie kontroli do hypervisora. Po obsłużeniu zdarzenia, mechanizm pozwala wrócić do pierwotnie wykonywanego kodu, bez wiedzy wirtualizowanego systemu operacyjnego;
• EPT (Extended Page Tables): Wirtualizacja niesie również za sobą konieczność współdzielenia pamięci. W związku z tym, dostępy do pamięci wykonywane przez wirtualną maszynę przechodzą przez dodatkowy mechanizm translacji, który pozwala wyznaczyć osobne regiony pamięci fizycznej przeznaczone dla maszyny wirtualnej, w sposób transparentny dla wirtualizowanego systemu operacyjnego. Dodatkowa warstwa translacji wiąże się też z dodatkową warstwą sprawdzania uprawnień dostępu do pamięci, co w efekcie pozwala odebrać np. prawa do odczytu danego obszaru pamięci na poziomie hypervisora i tym samym zanotyfikować hypervisor jeśli maszyna wirtualna spróbuje dany obszar odczytać.

DRAKVUF wykorzystuje wspomniane mechanizmy wirtualizacji za pośrednictwem biblioteki LibVMI. Biblioteka umożliwia dostęp do pamięci maszyny wirtualnej i wykorzystuje wspomniane mechanizmy do notyfikowania o zdarzeniach. Ponieważ mechanizmy te działają na niższej warstwie niż system operacyjny, monitorowanie bezagentowe niesie za sobą istotny problem określany jako semantic gap. Monitor działający na poziomie hypervisora musi znać dokładne rozmieszczenie struktur monitorowanego systemu operacyjnego w pamięci, a także wiedzieć jak interpretować stan wirtualnego procesora. Jest to realizowane poprzez przygotowywanie profilu VMI dla danego snapshota, który dostarcza informacji na temat położenia najważniejszych struktur w pamięci, co tym samym umożliwia introspekcję pamięci.

Ponieważ analiza bezagentowa jest realizowana za pomocą niskopoziomowych mechanizmów, rozwiązania oparte na VMI nie są uniwersalne i są ściśle związane z konkretną implementacją hypervisora (Xen), konkretnym rodzajem systemu operacyjnego (określone wersje systemów Windows i Linux) i konkretną architekturą procesora (procesory Intel x86-64). W związku z tym jest to podejście znacznie trudniejsze od agentowego, ale dające pełniejszy obraz tego, co dzieje się w ramach monitorowanego systemu.

Aby umożliwić praktyczne wykorzystanie silnika DRAKVUF do automatycznych analiz malware, stworzyliśmy system DRAKVUF Sandbox.

Czym jest DRAKVUF Sandbox?¶

DRAKVUF Sandbox stanowi uzupełnienie silnika DRAKVUF o elementy potrzebne do wykonywania zautomatyzowanych analiz malware m.in.:

• zestaw narzędzi ułatwiających tworzenie i zarządzanie maszynami wirtualnymi Xen, wraz z profilem VMI.
• aplikację webową, która umożliwia dodawanie próbek do analizy i interakcję z maszyną wirtualną podczas analizy
• analizowanie danych wyjściowych z DRAKVUFa pod kątem modyfikowanych plików, wykonywanych requestów HTTP, dopasowania do reguł CAPA itp.
• automatyczne tworzenie screenshotów, przechwytywanie ruchu sieciowego
• sporządzanie końcowego raportu w sposób czytelny dla analityka

Sam DRAKVUF stanowi narzędzie CLI, które po podaniu odpowiednich parametrów wypisuje na standardowe wyjście strumień zdarzeń, których rodzaj zależy od użytych pluginów monitorujących. Przykładowo polecenie:

drakvuf -o json -F -k 0x1aa002 -r /var/lib/drakrun/profiles/kernel.json -d vm-1 --json-ntdll /var/lib/drakrun/profiles/native_ntdll_profile.json -a procmon -a apimon --dll-hooks-list /etc/drakrun/hooks.txt

uruchamia monitorowanie wirtualnej maszyny vm-1 z wykorzystaniem zadanego profilu i pluginów procmon (monitorowanie uruchamianych procesów) i apimon (monitorowanie wybranych wywołań funkcji WinAPI z zadanej listy hooks.txt). Wcześniej jednak należy przygotować profil wirtualnej maszyny, uruchomić ją z wykorzystaniem odpowiedniego snapshota, a także załadować analizowany plik na dysk wirtualnej maszyny. Automatyzacja tych czynności jest główną motywacją dla której powstał DRAKVUF Sandbox.

DRAKVUF Sandbox umożliwia przeanalizowanie pliku za pomocą następującego formularza:

Aplikacja automatycznie dobiera parametry wykonania w zależności od typu analizowanego pliku, jednakże parametry mogą być wprowadzone również przez analityka. Pozwala również wrzucić całe archiwum do rozpakowania po stronie wirtualnej maszyny np. w przypadku złośliwych programów składających się z wielu plików, które muszą być umieszczone w tym samym katalogu.

Bardzo istotnym elementem są pluginy, których dobór pozwala wpłynąć na szczegółowość monitorowania. Do najważniejszych należą:

• apimon - monitorujący wywołania WinAPI według odpowiednio dobranej listy hooków, możliwej do zmodyfikowania w konfiguracji
• filetracer - monitorujący operacje na plikach
• memdump - dokonujący zrzutów pamięci w obszarach, które mogą zawierać złośliwy kod
• procmon - monitorujący operacje na procesach
• socketmon - monitorujący zapytania DNS i połączenia TCP/UDP
• tlsmon - dokonujący zrzutu kluczy TLS, które mogą być później wykorzystane do odszyfrowania przechwyconego ruchu
• hidsim - stanowiący moduł HID simulation symulujący aktywność myszy i umożliwiający autonomiczne klikanie w interaktywne elementy (np. okna dialogowe wyświetlane przez malware)
• regmon - monitorujący operacje na Rejestrze systemu Windows
• syscalls - monitorujący wywołania funkcji na poziomie jądra

Wykorzystanie większej liczby pluginów podnosi dokładność monitorowania, ale znacząco obniża wydajność i zwiększa objętość generowanych informacji. W skrajnym przypadku, złośliwe oprogramowanie może nie zdążyć się w pełni uruchomić, dlatego ważne, aby zachować balans między dokładnością, a wydajnością.

Analizy mogą być zlecane zarówno manualnie poprzez UI, jak i za pośrednictwem REST API.

Architektura i sposób użycia¶

Proces analizy w środowisku DRAKVUF Sandbox można podzielić na następujące etapy:

1. Użytkownik przesyła plik przez aplikację webową lub REST API, a zlecenie trafia do kolejki.
2. Worker pobiera zlecenie z kolejki i uruchamia maszynę wirtualną (np. vm-1) na podstawie szablonu vm-0.
3. Injector (z wykorzystaniem drakshella) umieszcza plik na dysku maszyny wirtualnej i uruchamia go z odpowiednimi parametrami.
4. Silnik DRAKVUF rozpoczyna monitorowanie aktywności maszyny wirtualnej za pomocą wybranych pluginów, a tcpdump przechwytuje ruch sieciowy. W trakcie analizy aplikacja webowa udostępnia analitykowi podgląd maszyny i możliwość interakcji przez noVNC.
5. Po zakończeniu monitorowania, moduł postprocessing przetwarza zebrane dane (logi, zrzuty, ruch sieciowy, screenshoty) i sporządza raport.
6. Raport jest udostępniany analitykowi przez aplikację webową, a w przypadku integracji z mwdb.cert.pl - wyniki są przekazywane do dalszej analizy z pomocą systemu Karton.

Poniżej znajduje się szczegółowy opis poszczególnych komponentów.

Maszyny wirtualne (vm-0, vm-1, ..., vm-n)¶

System DRAKVUF Sandbox przeprowadza analizy na maszynach wirtualnych z zainstalowanym systemem Windows. Przygotowanie maszyny wirtualnej jest jednym z najważniejszych etapów przygotowywania środowiska analitycznego i stanowi punkt odniesienia dla rezultatów wykonania złośliwego programu.

Najważniejszą maszyną wirtualną jest vm-0 - szablon, który służy jako bazowy obraz dla maszyn wykonujących analizy. Jest to tzw. snapshot, stanowiący pełny zapis stanu wirtualnej maszyny. Na podstawie tego stanu generowany jest profil VMI opisujący rozmieszczenie struktur systemu operacyjnego w pamięci.

Maszyna vm-0 instalowana jest za pomocą polecenia drakrun install, które pozwala na instalację obrazu maszyny wirtualnej z zadanego pliku ISO.

# drakrun install --help

Usage: drakrun install [OPTIONS] ISO_PATH

  Install guest Virtual Machine

Options:
  --vcpus INTEGER                 Number of vCPUs per single VM  [default: 2]
  --memory INTEGER                Memory per single VM (in MB)  [default:
                                  4096]
  --storage-backend [qcow2|zfs|lvm]
                                  Storage backend type  [default: qcow2]
  --disk-size TEXT                Disk size  [default: 100G]
  --zfs-tank-name TEXT            Tank name (only for ZFS storage backend)
  --lvm-volume-group TEXT         Volume group (only for lvm storage backend)
  --help                          Show this message and exit.

Zawartość dysku maszyny wirtualnej może być przechowywana zarówno w pliku qcow2, jak i w ramach woluminu LVM czy ZFS. Po uruchomieniu polecenia, użytkownik może przeprowadzić instalację systemu za pośrednictwem interfejsu VNC na porcie 5900, który jest zabezpieczony losowo wygenerowanym hasłem.

Podczas konfigurowania systemu Windows, warto zadbać o:

• upewnienie się, że są zainstalowane podstawowe aktualizacje np. brak aktualnej listy certyfikatów Root CA, może uniemożliwić poprawne nawiązywanie połączeń TLS,
• wyłączenie zabezpieczeń przed wykonaniem: UAC (User Account Control), Windows Defender,
• zainstalowanie dodatkowych zależności, których może wymagać złośliwe oprogramowanie np. różne wersje środowiska .NET, biblioteki Visual C++ Redistributable, pakiet Microsoft Office
• instalację dodatkowych przeglądarek np. Google Chrome, Firefox,
• wyłączenie automatycznych aktualizacji i telemetrii, aby zredukować szum w wynikach analizy i nie zaśmiecać przechwytywanego ruchu sieciowego komunikacją z serwerami aktualizacji,
• personalizację środowiska, aby przypominało standardowy komputer użytkownika, a nie zautomatyzowaną maszynę analityczną.

Po instalacji systemu Windows i wstępnej konfiguracji, należy uruchomić polecenie drakrun postinstall, które przygotowuje maszynę wirtualną do działania w systemie DRAKVUF Sandbox, wykonuje referencyjny snapshot i generuje profil VMI.

Tak utworzony szablon wykorzystywany jest do uruchamiania maszyn analitycznych. DRAKVUF Sandbox umożliwia uruchamianie wielu analiz jednocześnie, stąd wykorzystywane maszyny mają kolejne numery vm-1, vm-2 itd. Maszyny można uruchomić manualnie za pomocą poleceń drakrun vm-start i drakrun vm-stop.

Szablon musi być regularnie utrzymywany, aby środowisko w którym wykonywany jest malware było aktualne, zawierało potrzebne zależności i umożliwiało poprawne uruchomienie. W związku z tym DRAKVUF Sandbox dostarcza polecenie drakrun modify-vm0, które w sposób transakcyjny umożliwia modyfikację vm-0, a następnie naniesienie zmian wraz z wygenerowaniem nowego profilu. Polecenie drakrun modify-vm0 begin uruchamia kopię maszyny wirtualnej vm-0. Następnie, dokonane zmiany można nanieść na oryginalny snapshot za pomocą polecenia drakrun modify-vm0 commit lub wycofać poleceniem drakrun modify-vm0 rollback.

Injector i drakshell¶

Aby wykonać złośliwy program na maszynie wirtualnej, potrzebne jest wykonanie następujących czynności:

• rekonfiguracja przywróconego stanu maszyny wirtualnej (pobranie aktualnego adresu IP, synchronizacja zegara)
• umieszczenie plików programu na dysku maszyny wirtualnej
• uruchomienie programu z odpowiednimi parametrami

W systemach agentowych, czynności te wykonywane są za pośrednictwem agenta, który oprócz monitorowania asystuje również przy czynnościach konfiguracyjnych. DRAKVUF do tego celu wykorzystuje komponent o nazwie Injector. Komponent ten wykorzystuje VMI do przechwycenia dowolnego, istniejącego procesu w systemie, a następnie zmodyfikowanie go w taki sposób, aby wykonać za jego pomocą dowolną operację np. wczytanie pliku czy uruchomienie nowego procesu. Jest to wykonywane w sposób podobny do metody wstrzykiwania kodu określanej jako Thread Execution Hijacking - modyfikowany jest stos i kontekst procesora dla danego wątku, aby wykonał konkretną operację. Wątek po operacji przywracany jest do pierwotnego stanu.

Injector jest rozwiązaniem bardzo skutecznym, ale niestety dość niestabilnym. Wątek będący celem operacji może nie być obudzony wystarczająco szybko, bo np. oczekuje na jakieś zdarzenie. Tym samym operacja, którą próbujemy wykonać w ramach takiego wątku może się nie wykonać poprawnie.

Ze względu na niestabilność Injectora, w DRAKVUF Sandbox wprowadziliśmy dodatkowy komponent o nazwie drakshell. Jest to tzw. shellcode napisany w języku C, który po wstrzyknięciu do procesu za pomocą Injectora uruchamia własny wątek i nasłuchuje na polecenia na porcie szeregowym. Wątek intencjonalnie unika długiego oczekiwania na operacje i wykonuje się w pętli, aby być łatwym i przewidywalnym celem dla operacji Injectora. Jednocześnie drakshell umożliwia wykonywanie bardziej złożonych operacji np. interaktywne wykonywanie komend z przechwyceniem wejścia/wyjścia. Drakshell wstrzykiwany jest w momencie wykonywania komendy drakrun postinstall, a więc podczas przygotowywania referencyjnego snapshota vm-0.

Drakshell można również wywołać ręcznie, za pośrednictwem polecenia drakrun drakshell.

# drakrun drakshell -- powershell.exe
[2026-08-25 15:26:03,393][INFO] Drakshell active on: {'pid': 1680, 'tid': 5628}
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

PS C:\Windows\system32> 

Z możliwości Injectora można natomiast skorzystać za pomocą polecenia drakrun injector np. do skopiowania plików między dyskiem maszyny wirtualnej a systemem plików Dom0. Injector wywołany w ten sposób automatycznie skorzysta z wątku komponentu drakshell.

Usage: drakrun injector [OPTIONS] COMMAND [ARGS]...

  Copy files and execute commands on VM using injector

Options:
  --help  Show this message and exit.

Commands:
  copy  Copy files between VM and host
  exec  Execute commands on VM using injector (non-interactive)

Pomimo wykorzystania drakshella, sam proces analizy nadal pozostaje bezagentowy. W momencie rozpoczęcia analizy, drakshell po otrzymaniu odpowiedniego sygnału zamyka swój główny wątek i usuwa się z pamięci procesu do którego został wstrzyknięty.

Postprocessing¶

W toku analizy zbierany jest strumień danych, składający się z następujących elementów:

• zdarzeń przechwyconych przez pluginy DRAKVUF, które monitorują aktywność procesów w maszynie wirtualnej
• zrzuconych plików i wykonanych zrzutów pamięci, również przez pluginy systemu DRAKVUF.
• przechwyconego ruchu sieciowego przez tcpdump
• wykonanych zrzutów ekranu za pośrednictwem VNC

Przechwycone dane są surowe i muszą być wstępnie przetworzone i zinterpretowane, aby można było z nich sporządzić przejrzysty raport. Odpowiada za to moduł postprocessing, który uruchamia się po zakończeniu monitorowania. Na podstawie zgromadzonych informacji:

• budowane jest drzewo procesów wraz z oznaczeniem ich czasu aktywności;
• indeksowane są logi z analizy co umożliwia ich filtrowanie i przeszukiwanie;
• na podstawie przechwyconych wywołań funkcji API zbierane są informacje na temat wykonywanych żądań HTTP, wykonywanych połączeń TCP/UDP oraz zmodyfikowanych lub usuniętych plików;
• dopasowywane są reguły CAPA, aby wyodrębnić TTP² i oznaczyć charakterystyczne zachowania złośliwego oprogramowania;

Z tak zagregowanych i przetworzonych informacji, sporządzany jest raport, który jest wyświetlany analitykowi. W przypadku integracji z mwdb.cert.pl wyniki analizy trafiają również do systemu Karton. Wewnętrznie wykorzystujemy go m.in. do analizy zrzutów pamięci wykonywanych przez Drakvuf pod kątem dopasowania do reguł YARA i możliwości ekstrakcji statycznej konfiguracji.

drakrun worker i drakrun web¶

System DRAKVUF Sandbox dostarcza również interfejs użytkownika, dostępny za pośrednictwem aplikacji webowej i REST API. Umożliwia zlecanie analiz do kolejki i wykonywanie ich w sposób równoległy na wielu maszynach wirtualnych jednocześnie.

Do tego celu wykorzystywany jest prosty system kolejkowy oparty na bibliotece rq (Redis Queue) i bazie danych Redis. Aplikacja webowa wykorzystuje frameworki webowe Flask (backend, Python) i React (frontend, JavaScript).

Komponent drakrun web umożliwia:

• przesyłanie plików i zlecanie analiz
• interakcję z systemem Windows w trakcie analizy wykorzystując protokół noVNC (VNC po protokole Websocket)
• śledzenie statusu i pobranie szczegółowego raportu z analizy

Analizy mogą być przechowywane na lokalnym systemie plików Drakvuf Sandbox, ale również na serwerze S3

Co można znaleźć w raporcie z DRAKVUF Sandbox?¶

Raport z analizy ma za zadanie przedstawić analitykowi przejrzysty obraz zachowania analizowanego pliku. Poniższy zrzut prezentuje przykładowy widok raportu:

Raport zawiera m.in.:

• Drzewo procesów obrazujące relacje między procesami uruchomionymi w trakcie analizy.

Procesy kodowane są kolorami: - szare działały już przed rozpoczęciem monitorowania (w tym sama próbka, ponieważ DRAKVUF rozpoczyna obserwację krótko po uruchomieniu procesu) - czarne powstały i zakończone w trakcie monitorowania - niebieskie zostały uruchomione w trakcie analizy, ale wciąż działały po jej zakończeniu. Najechanie na proces wyświetla pełną linię poleceń, z jaką został uruchomiony.

• Podsumowanie analizy ze wskazaniem utworzonego procesu (i jego kodu wyjścia, jeśli zakończył się w trakcie analizy), zapytań DNS, wykonywanych żądań HTTP, parsowanych adresów URL (przez funkcje takie jak InternetCrackUrl), nawiązanych połączeń TCP/UDP, zmodyfikowanych i usuniętych plików oraz dopasowanych reguł CAPA, wyodrębniających TTP² i wskazujących charakterystyczne zachowania złośliwego oprogramowania.

• Logi z monitorowania (zakładka General logs) z indeksowaniem, co umożliwia ich filtrowanie i przeszukiwanie, z możliwością podglądu poszczególnych zdarzeń w formacie JSON. Oddzielna zakładka Process info pozwala na filtrowanie logów dla wybranego procesu, w tym zawężenie do konkretnych wywołań funkcji (np. RegSetValueExA, RegOpenKeyExA).

• Screenshoty wykonywane w regularnych odstępach w trakcie analizy, które mogą ujawnić m.in. interaktywne elementy wyświetlane przez malware (np. okna dialogowe, z którymi plugin hidsim automatycznie interaguje).

• Artefakty do pobrania - przechwycony ruch sieciowy w postaci pliku PCAP, klucze TLS pozyskane przez plugin tlsmon (umożliwiające odszyfrowanie przechwyconego ruchu) oraz zrzuty pamięci wykonane przez plugin memdump. Istnieje również możliwość pobrania surowych plików analizy w postaci archiwum ZIP.

FAQ¶

Czy mogę uruchomić własną instancję DRAKVUF Sandbox?¶

Tak. System jest oprogramowaniem otwartoźródłowym udostępnianym na licencji GPL. Kod źródłowy i instrukcję instalacji znajdziesz w repozytorium CERT-Polska/drakvuf-sandbox. Wymagania sprzętowe i programowe (m.in. procesor Intel z VT-x i EPT, Xen jako hypervisor) opisane są w dokumentacji w serwisie ReadTheDocs.

Warto jednak pamiętać, że utrzymanie własnego sandboxa opartego na VMI jest zadaniem wymagającym - w przeciwieństwie do rozwiązań agentowych, błędy mogą być specyficzne dla danej konfiguracji i wymagać samodzielnej diagnostyki. W niektórych konfiguracjach sprzętowych DRAKVUF może nie zadziałać poprawnie. W takim wypadku może być potrzebna szczegółowa wiedza odnośnie debugowania problemów w środowisku Xen, aby stwierdzić czy problem wynika z nieprawidłowej konfiguracji, błędów w systemie czy z niekompatybilności z danym sprzętem.

Czy DRAKVUF Sandbox wspiera systemy inne niż Windows?¶

Silnik DRAKVUF wspiera wybrane wersje systemów Windows i Linux, jednak DRAKVUF Sandbox jest rozwijany przede wszystkim z myślą o analizie malware na platformę Windows.

Czy DRAKVUF Sandbox można uruchomić w chmurze?¶

Ze względu na wykorzystanie niskopoziomowych funkcji procesora (VT-x, EPT), rozwiązania chmurowe mogą nie być w stanie uruchomić DRAKVUF-a. Mechanizmy wirtualizacji są zazwyczaj mocno niestandardowe w takich rozwiązaniach i mogą okazać się niekompatybilne. Dodatkowym utrudnieniem jest fakt, że Xen jest hypervisorem typu 1, co oznacza, że działa bezpośrednio na sprzęcie bez pośrednictwa systemu operacyjnego.

Drakvuf Sandbox może zadziałać na serwerach dedykowanych i rozwiązaniach typu bare metal.

Czy mogę użyć procesora AMD?¶

Nie. DRAKVUF jest ściśle powiązany z funkcją altp2m¹ implementowaną wyłącznie dla procesorów Intel. Wymagany jest procesor Intel z obsługą VT-x i EPT. Wymagania sprzętowe i programowe (m.in. wersja Xen) opisane są w dokumentacji.

Jak zgłosić błąd lub pomysł do systemu?¶

Zgłoszenia dotyczące oprogramowania DRAKVUF Sandbox można kierować bezpośrednio w sekcji Issues w repozytorium CERT-Polska/drakvuf-sandbox. W sprawach dotyczących serwisu mwdb.cert.pl lub analiz przeprowadzanych przez CERT Polska prosimy o kontakt pod adresem info@cert.pl.

Dokumentacja¶

Pełne informacje na temat instalacji i konfiguracji DRAKVUF Sandbox znajdują się w dokumentacji ReadTheDocs, w szczególności w przewodniku Getting started. Kod źródłowy dostępny jest w repozytorium CERT-Polska/drakvuf-sandbox.

W przypadku pytań ogólnych można kontaktować się z nami pod adresem info@cert.pl.

Ostatnia aktualizacja artykułu: 2026-09-02.