I’ve been a happy Qubes OS user for years. The short pitch is that VMs are heavily used to make compartmentalizing different activities easier, and VMs can easily have their network and hardware access restricted. Your security and privacy baseline just got much higher. I’ll leave the feature list to the official site and just say it’s impressive and I recommend giving it a try. But it’s not without a learning curve, and one hurdle is that the OSes you run in VMs need the extra software to support the integrations that make Qubes especially useful. I recently decided to add a Kali VM to my setup to take a look at some Hack The Box target machines, and it was enough of a detour that I decided to write up what it took. I did this in December 2025, but only now got around to writing about it.

The Community Options#

Do some searching and you’ll probably turn up two things: the kali-core template in the qubes-templates-community-testing repo, and the forum thread about making your own Kali template from a Debian template. I tried both and ultimately went with the latter because the kali-core template was old and needed manual modifying anyways. Unfortunately some things have changed since the guide was originally writtern, so we have to do some things slightly differently.

I recommend reading the full thread, and I’ll try to put things into abbreviated instructions for “doing this in 2025/2026”.

Creating the Kali Template#

Latest Debian Template#

Qubes comes with Debian templates, but you should make sure you have the latest one and that it’s up to date. qvm-template in dom0 is a CLI tool for managing templates, but you can also use the “Qubes Template Manager” GUI tool. It can be found in the Qubes menu (blue Qubes logo) under the gear icon, and then “Qubes Tools”. At time of writing, debian-13 is the latest Debian template.

Once you have the latest Debian template, make sure it’s up to date with either the Qubes updater, or manually in a terminal in that template with apt, and then shut it down.

GPG Key#

We need to get the Kali GPG signing key to add the Kali repo later, but that’s changed since 2023. Fetching the new key is described here. When I accessed the page in February 2026, it simply said to download the key from https://archive.kali.org/archive-keyring.gpg, check that file’s sha1 digest matched 603374c107a90a69d983dbcb4d31e0d6eedfc325, and that it contained the new signing key ED65462EC8D5E4C5. If everything checks out, hold on to this file, we’ll add it to our template later.

Clone and Modify Debian Template#

Using either the “Qube Manager” GUI tool or the qvm-clone CLI tool in dom0, clone our latest Debian template to something like “kali-rolling”. We’ll essentially be turning this new Debian template into a Kali system.

Start up the new “kali-rolling” template, and get ready for lots of modifications. First we change the Qubes repo list at /etc/apt/sources.list.d/qubes-r4.list to testing, if possible. Right now Debian stable is codename “trixie” and testing is codename “forky”. However, looking at the Qubes debian repo at https://deb.qubes-os.org/r4.2/vm/dists/, we only have up to “trixie”, and no “forky”. Oh well, let’s leave it at “trixie”.

We also uncomment the lines in qubes-r4.list to enable the “trixie-testing” and “trixie-securitytesting” repositories.

Next we add the Kali GPG key from earlier by copying it into our template and placing the .gpg file in /etc/apt/trusted.gpg.d/. Now that we have the keys in place, we can overwrite /etc/apt/sources.list and replace the standard Debian repo with the Kali repo.

#from https://www.kali.org/docs/general-use/kali-linux-sources-list-repositories/
deb https://http.kali.org/kali kali-rolling main non-free contrib

The forum thread mentions that this is where you may see a number of broken packages you have to manually fix. This wasn’t the case for me, I just apt update/upgraded to essentially a very minimal Kali system. Like mentioned in the thread, now is a good time to verify you can launch applications by running qvm-run -a kali-rolling gnome-terminal.

Almost there, but, we don’t even have kali-linux-default! The whole point of Kali is that we get a lot of useful things bundled together without having to hunt down and install it all ourself! Before we install that, we’ll need to increase our template’s size, since kali-linux-default adds so much. I used the “Qube Manager” GUI tool to increase the template’s System storage max size to 30GB and that worked.

Finally, there’s the PulseAudio fix so that audio input/output will work. I just used the recommended rm command:

rm /usr/lib/systemd/user/pulseaudio.service.d/kali_pulseaudio.conf /usr/lib/systemd/user/pulseaudio.socket.d/kali_pulseaudio.socket.conf

Firewall Rules#

The only Qubes-related change left here would be fixing some firewall rules, but I haven’t done that myself yet. A common trick is to force a targeted host to connect back to your machine so you can serve it malicious files, get a reverse-shell, etc. But Qubes adds some default firewall rules (nftables, not iptables) to default deny incoming connections.

The “qubes-core-agent-networking” package provides default firewall rules in “.nft” files under /etc/qubes/ which are loaded via the qubes-iptables.service systemd unit. I haven’t learned enough about nftables syntax to recommend changes to these files/this package, but that would be a useful change to do in the template.

Until then, manually dropping firewall rules when you boot any AppVMs based on this template will be necessary to allow reverse shells: sudo nft flush ruleset

Finished!#

All done, you should now have a Kali template to base AppVMs off of! We can start taking advantage of Qubes features now, like creating multiple AppVMs based on this template so that we have cleanly separated Kali machines for different purposes, and giving them different network connectivity like forcing all traffic over Tor, or allowing only specific IPs. Updating this template will keep all the AppVMs based on it updated.

My Experience#

Fresh Kali template in hand, I made an AppVM, set up my HTB account, and went through all the freely available machines in their “Starting Point” collection. Besides a few hiccups, things went smoothly. Once I discovered the firewall issue the challenges involving receiving connections worked fine, and the only real issue I had was trying to run hashcat with only 4GB of RAM and a measly CPU (it simply didn’t run).

More about Hack The Box. I liked the Starting Point VMs as a nice entrypoint to this style of CTF. They stepped the user up through the basic pentest-style ctf workflow, with an official writeup available to consult if the player ever got stuck. This is wonderful since in my opinion the worst part of this style of CTF is working on it alone, then getting stuck and not even having a clue what to start researching. That competition style can be pretty demoralizing for someone just trying to learn. However, it was annoying to have so many machines paywalled behind VIP+. For a “just getting started” collection, having nearly half the VMs locked behind a payment made me worried what else was paywalled, and $20/mo for VIP+ is a big ask for just getting started on the site.

Conclusions#

Qubes is pretty cool, but not something I would reach for to do pentesting with Kali if I were starting from scratch. Running Kali in a VM on top of some other host OS is probably fine for most use-cases, and certainly easier. Maybe you use Kali and also want the features Qubes has (disposable VMs, device access control, etc.), in which case yes, you can run Kali under Qubes. It just requires some manual effort and may also have some limitations, like a memory limit. But if you’re doing something that requires lots of memory anyways, you may want dedicated or specialized hardware with something running bare-metal anyways, rather than a VM.

If you’re already a Qubes user, yes indeed you can (with some work) run Kali under Qubes. However the overhead may force you to turn to other machines if you have to do something that requires more horsepower, like cracking.