DRAKVUF Sandbox analyses malware from outside the guest OS

No agent on the guest, because the guest cannot be trusted

DRAKVUF Sandbox is described as an automated black-box malware analysis system with the DRAKVUF engine under the hood, and the phrase that matters in that sentence is that it does not require an agent on the guest operating system. The observation happens from the hypervisor, between the virtual machine and the hardware.

That design choice answers a problem that is hard to solve any other way. A sample running inside a Windows guest can look for instrumentation, detect a sandbox, and change its behaviour accordingly, so the report you get describes the sample's reaction to the analysis environment rather than the sample itself. With the observer outside the guest, there is nothing inside the machine for the sample to find, and no userland component that could be hooked or detected. It is also why the analysis is described as black-box, since the system watches behaviour rather than instrumenting instructions in a way the sample could perceive.

The system around the engine is the other half of the project. There is a friendly web interface for uploading suspicious files, and once the sandboxing job finishes you explore the analysis result through that interface to get an insight on whether the file is truly malicious. The documentation is hosted at drakvuf-sandbox.readthedocs.io, and the README links a getting started page there alongside the releases and the latest docs.

The project is not shy about the difficulty. The README opens with a warning that maintaining your own sandbox is a difficult task, that the project uses technology that is not user-friendly, and that you should be prepared to brush up on your debugging skills because bugs may be reproducible only on your configuration. The same block notes that it is not purely an R&D project and is used in production, and it points at the source code and issues on both the sandbox and the DRAKVUF engine as the best friends of anyone running it.

Intel VT-x and EPT rule out every cloud option

The hardware requirements are the first filter to apply, and they are strict. The processor must be an Intel processor with Intel Virtualization Technology, VT-x, and Extended Page Tables, EPT. The host system needs at least 2 core CPU and 5 GB RAM, running GRUB as bootloader, and must be one of Debian 12 Bookworm or Ubuntu 22.04 Jammy.

The guest system is one of Windows 10 build at least 2004 (x64), with 22H2 recommended, or Windows 7 (x64). Both are current and both are old, which tells you the analysis is aimed at malware families that target both.

The nested virtualization table is where most evaluations end. Xen works out of the box. KVM works and is often used for development purposes, with bugs to be reported if you hit them. VMware Workstation Player works, but only if you enable the Virtualize EPT option for the VM, and an Intel processor with EPT is still required.

And then the exclusions. AWS, GCP and Azure are not supported, due to lack of exposed CPU features, so hosting DRAKVUF Sandbox in the cloud is out, although the README allows that this might change in the future. Hyper-V does not work. VMware Fusion on Mac does not work.

That last list has a consequence worth stating plainly. The set of supported environments is Intel hardware, running GRUB, with a bare metal or nested virtualization stack that exposes EPT. There is no managed offering in the list, and the cloud providers are excluded for a hardware reason rather than a policy one, which means the requirement will not be solved by buying a bigger instance. Any evaluation has to start by confirming the hardware, and if you do not own such a machine, the project is not deployable for you today.

The drakrun CLI sits on top of Flask, a job queue and a screenshotter

The Python package is called drakvuf-sandbox on PyPI terms but installs a command named drakrun, and the setup.py registers a single console script.

entry_points={
    "console_scripts": [
        "drakrun = drakrun.cli:main",
    ]
},

The version is read out of drakrun/version.py at build time rather than hard coded, and it can be suffixed with a build tag from the DRAKRUN_VERSION_TAG environment variable, which the Makefile sets to the short git hash when building a wheel locally. Python 3.9 or newer is required.

The requirements list shows the shape of the system. The web interface is Flask 3.0.3 with flask-openapi3 for the Swagger documentation, and rq with rq-dashboard for a job queue, so analysis jobs are queued rather than run inline. The analysis itself leans on the DRAKVUF side with drakpdb 0.2.3 for the PDB handling that symbolising malware dumps needs, and on flare-capa 7.4.0 for capability detection, and pydantic 2.13.4 with pydantic-settings for configuration.

Screenshots are a separate subsystem. There is a Screenshotter dependencies block with asyncvnc 1.3.0 driving a VNC connection, Pillow 10.4.0 for image handling, and Perception 0.6.8 with opencv-contrib-python-headless 4.11.0.86 for the image processing, the latter being a headless build specifically so a server environment does not need a display server. The comment in the requirements file notes that opencv-contrib-python-headless is the missing peer dependency of Perception, and that msgpack is a peer of vivisect used directly.

Karton integration is handled by karton-core 5.9.0, and boto3 1.35.81 is present, which is how artifacts get into object storage. The requirements file labels karton-core a Karton integration dependency. The system is built to be one stage in a larger pipeline rather than a standalone tool.

The build compiles a C helper and a shell, then bundles a frontend

The Makefile is where the parts of the project that are not Python become visible, and there are two of them.

The first is get-explorer-pid, a C program compiled with gcc against VMI and glib-2.0.

drakrun/tools/get-explorer-pid: drakrun/tools/get-explorer-pid.c
	gcc $< -o $@ -lvmi `pkg-config --cflags --libs glib-2.0`

VMI is the library that talks to the hypervisor, which is why it is linked directly here rather than through the DRAKVUF Python bindings. The second is drakshell, built by recursing into its own directory with a separate Makefile, so the shell tool has its own build logic.

The frontend is a Node project living inside the Python package. The build target for it runs npm ci to install dependencies and npm run build through a vite.config.js, and the result lands in drakrun/web/frontend/dist, which is then packaged into the wheel along with the compiled binaries. The clean target removes the dist directory, the node_modules, the egg-info, and both compiled tools, and it also removes a compiled test-altp2m binary.

The wheel build itself is a plain python3 setup.py bdist_wheel invocation, with the version tag applied through the environment when DIST is not set, so a local build is identifiable by its git hash. The install target then does pip install of the built wheel.

The repository layout matches this structure, with a drakrun/ package directory, a drakvuf directory for the DRAKVUF related pieces, a dev/ directory, docs/, scripts/, test/, and a .readthedocs.yaml for building the documentation. The .gitmodules file indicates that at least one dependency is a git submodule, and pyproject.toml configures isort with the black profile, black itself with the data, tools and frontend directories excluded, and a lint-python configuration pointed at the drakrun source with mypy turned off.

An installer for beginners, and the escape hatch for experienced operators

The README makes a point of the fact that it is usually pretty hard to set up a malware sandbox, and responds with an installer app that guides you through the necessary steps and configures your system using settings recommended for beginners. Experienced users are told they can tweak some settings or even replace some infrastructure parts to better suit their needs.

That two-audience design is the practical shape of the project. The hardware requirements table, the distribution table and the getting started documentation exist for the first audience, while the source code, the issues and the ability to replace components exist for the second. The README's warning about debugging is aimed at the second audience, and it is the reason to read the issues before installing rather than after.

The licensing and the funding situation are worth reading too. The project listing marks the licence as a custom one that GitHub cannot classify, with a LICENSE file and a COPYING file at the top of the repository, so the terms themselves are in those files rather than in a standard header. The acknowledgements section names the Connecting Europe Facility of the European Union as a funder, The Honeynet Project as a contributor, and CERT Polska as the maintainer. The maintainer list is a group of named people from CERT Polska, with a general contact address at [email protected] described as the fastest response route, plus a Discord server.

The release history shows steady work rather than a hobby project. The tags are v0.19.0 on 2025-08-06, v0.20.0 on 2025-11-17 and v0.21.0 on 2026-08-19, and the last push to master was on 2026-10-16.

Where DRAKVUF Sandbox is the wrong tool

The first wrong case is hardware access. If your analysis machines are cloud instances, this project is unavailable, and the reason is a missing CPU feature rather than a licensing or configuration detail. The only recourse is to buy or reserve hardware, which changes the economics of a small team entirely. A team that wants to submit a handful of samples per week to a shared service is not going to get that from this repository.

The second wrong case is a team without hypervisor depth. The README says outright that the project uses technology that is not user-friendly, and that bugs may be reproducible only on your configuration. That is a statement about the operational cost of running it, not a transient complaint. A deployment that needs a second analyst to reproduce an issue on your specific setup, with the source code and the issues tracker as the primary diagnostic tool, is a commitment of people as much as of hardware.

The third wrong case is when you need something other than behavioural analysis of Windows executables. The guest options are Windows 10 and Windows 7, the analysis is black-box, and the artefacts are screenshots, process behaviour and capability reports. Questions about a Linux binary, about a document exploit in an email client, or about a browser exploit chain need a different environment, and the requirement of a single Windows guest image also means you are analysing the behaviour of a sample in a particular Windows build with its particular patch level and configuration.

The fourth wrong case is time to first result. There is no hosted trial and no one-command cloud deployment. The realistic path is dedicated hardware, a supported hypervisor, a Windows guest image, then a configuration pass that the documentation describes. If the question is whether a single file is malicious, a commercial multi-scanner feed is a faster answer, and this project is for the cases where you need the behaviour in a controlled environment yourself.

How it differs from an agent-based sandbox

The clearest comparison is with a sandbox that installs its own agent into the guest, which is the standard commercial shape. The agent approach is simpler to deploy because the observer runs at user level inside the virtual machine, so it inherits the operating system environment and can hook the API. It also has the disadvantage the sample can find and react to, and that is the trade DRAKVUF makes deliberately.

The second comparison is with a lightweight dynamic analysis system built on system call tracing, which reports the files, registry keys and network destinations a sample touches. That approach is far lighter, runs in a container or a small VM, and is much easier to run at volume. What it cannot do is observe anything the sample does before the trace begins, and it cannot give a picture of what the sample actually displayed, which is what the screenshotter subsystem in this project is for.

The third comparison is with a full system emulator. An emulator is the most faithful and the slowest, and it is what many researchers reach for when timing and system state matter. DRAKVUF sits between the two: it runs on a real hypervisor, so the timing and hardware behaviour are real, and it observes from outside, so the guest is unmodified by the observer.

The practical consequence of that position is that DRAKVUF gives you behaviour without instrumentation artefacts, at the cost of requiring the hardware and the expertise the README warns about. The pipeline framework integration, the Karton dependency, the job queue and the object storage client all point to the same intent, which is to be one stage in a larger analysis pipeline rather than a product you sit in front of.

Editorial conclusion

DRAKVUF Sandbox fits a CERT, a national CERT team or a security operations group that already owns Intel hardware with VT-x and EPT and wants malware triage performed outside the guest so the sample cannot detect the instrumentation. It does not fit a team looking for a cloud service, since the documentation rules out AWS, GCP and Azure for lack of exposed CPU features, and it does not fit a first time analyst who wants a quiet setup, since the project warns that maintaining an instance is difficult and that bugs may only reproduce on your configuration. Before deploying it, confirm your host is a supported Debian 12 or Ubuntu 22.04 machine running GRUB, decide whether you will keep the default Windows 10 22H2 guest or bring your own, and read the LICENSE file, since the project listing marks the licence as a custom one that GitHub cannot classify.

Frequently asked questions

Official sources

1. CERT-Polska/drakvuf-sandbox on GitHub
2. Issues
3. Project website
4. README
5. Releases