Drive Badger is able to recursively exfiltrate virtual machines on VMware and Hyper-V virtualization servers.
The problem with virtualization servers is about drive space reservation: they contain several virtual drive image files, where only a small degree of reserved space is occupied by valuable files, while all the rest space:
For example, a particular Windows 10 virtual machine can have a 300 GB drive, where:
pagefile.sysand other temporary files
In standard configuration, Drive Badger sees only these virtual drive image files and needs to copy them as a whole, which wastes a lot of space on Drive Badger device.
When exfiltrating normal Windows servers, that additionally host eg. 1-5 virtual machines, this is usually not a problem. But if you want to exfiltrate big, specialized virtualization servers with hundreds of virtual machines, you would run out of space without this special mode.
hook-virtualsearches this partition for virtual drive image files (
exclude-virtualexclude these virtual drive image files from being exfiltrated as ordinary files.
Cayman National: Hyper-V exfiltration case study brings the detailed performance analysis of exfiltration of big part of Cayman National's IT infrastructure (based on Hyper-V).
Here you will find instructions, how to install additional hooks, configuration repositories etc. All you need to do, is install these 2 repositories (either before of after arming the device), and then optionally proceed with some fine tuning (mostly when you have already seen the victim's servers and want to adjust the exact behavior of each Drive Badger device to each virtualization server).
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
Searching for VHD/VHDX/VMDK containers inside another VHD/VHDX/VMDK container is very, very slow, and therefore disabled by default (which may lead to data loss, if victim uses nested VMware/Hyper-V virtualization - which fortunately is very unusual, at least using VHD/VHDX/VMDK containers).
To avoid data loss on servers with nested VMware/Hyper-V virtualization, you need to create these 3 files (separately for each image type):
To speed up the exfiltration process, you can set task spooler to execute 2 (or more) simultaneous tasks, by executing the following command on console:
tsp -S 2
However, exfiltration of VHD/VHDX/VMDK container relies on Qemu, which is very susceptible to all sorts of problems with these containers, or filesystems inside them. And error handling of Qemu running in multiple instances is very unreliable, so running multiple tasks simultaneously can cause random rsync failures, and in the worst scenario can even lock the whole exfiltration process.
Also, running more than 3 simultaneous tasks for Hyper-V, or more than 4 for VMware will almost certainly cause data loss.
When VHD/VHDX/VMDK container cannot be fully exfiltrated for some reason:
then such container is copied to your target drive as a file. Since it was already excluded by rules from
exclude-virtual, it needs to be copied separately - this is done by
copy-compress.sh script, which compresses copied images on-the-fly.
There are many possible compression methods and levels available:
lz4- the fastest one, minimal memory footprint, still achieves very good compression ratio
gzip- the most compatible and universal, quite fast
pigz- multi-core alternative to
gzip(best performance when compressing small number of images on big CPUs, but problematic otherwise)
xz- the best compression, but very slow (impractical in most cases)
bzip2- very good compression (worse than
xz/LZMA2), still very slow
What you should choose and when:
pigzmight be better for big CPUs and small number of virtual machines, but with large virtual drives
xzmight be better for big CPUs, lots of RAM and big number of virtual machines, having small virtual drives
bzip2is better than
xzfor big CPUs but small RAM
Performance comparison for fresh installed 80GB Solaris 11 drive image, compressed on Core i7-3770:
lz4 -1- 12 minutes
gzip -6- 31 minutes
The current default is
lz4 -1. You can change it:
The #1 reason (at least for Windows-based guests), why virtual drive image file can't be properly opened and exfiltrated, is that underlying filesystems weren't properly shut down, and need to be recovered (which usually only means, that journal needs to be replayed).
If you have a broken image, which was exfiltrated as raw file, unpack it (but keep a backup!) and execute the following command in its directory:
LIBGUESTFS_BACKEND=direct LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1 virt-filesystems -a CN-FS01_C.vhdx
You will probably see something like this:
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'
Now run the suggested command - and you should see:
# 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.
Beware that in some (fortunately rare) cases, this might further break the filesystem - so always keep a backup (original compressed file), to be able to start over. This is also the reason, why Drive Badger never attempts to do it on original images during exfiltration.
If the underlying filesystem can't be recovered by
qemu-img check, but the problem is still related to filesystem(s), and not the container itself, you can try to convert it to raw drive image:
qemu-img convert -f vhdx -O raw broken.vhdx broken.raw qemu-img convert -f vmdk -O raw broken.vmdk broken.raw
7-Zip popular file compression software can open most existing drive image containers as archives, and unpack individual partitions from them. You can try it, if
qemu-img convert command fails:
7z x -o/destination/directory CN-FS01_C.vhdx
Also, 7-Zip is a bit less sensitive to various problems with the container itself, than QEMU. Most VHDX containers can be unpacked using p7zip 16.02 (version included in Kali Linux) - while some specific failure types can be handled only by the 7-Zip 21.07 or newer, that needs to be installed separately (for Linux or Windows, also with graphical file manager).