Edited: contained part of a reply to another post. Deleted unrelevant part, sorry about that.
What I would do there is install tcpdump in the netvm that is receiving the traffic prior of encrypting it (there is no point really into capturing network traffic that is going upstream encrypted). It would not make sense either to capture traffic into vault since that machine is not having netvm normally.
So running tcpdump into sys-firewall or sys-net directly, recording file locally would be a start. Then qvm-move that file to a disposable vm where you install wireshark and then inspect the packet trace from it. The only assumption we can do here is that the traffic is going out of sys-net, but it would most probably be encrypted, and if many other connections are happening at the same time, it won’t be so easy to isolate either. It requires some kind of flattening of what is normal to find what is abnormal here… There might be covert channels at play. If “lucky” there would be a stream that is continuous when data is exfiltrating. But that might also be screenshots, everything is possible here, really… Down to data being exfiltrated by speakers…
As said previously, my way of dealing with this is by comparing states. Ideally having a point in time where things were good and compare what state we are in now to isolate source of compromise.
This thread is convoluted. The assumptions are that something is grabbing vault’s screen content somehow, and that content is somewhat exfiltrated by network. If we consider that vault has no netvm associated to it (as it should) then its screen content needs to have greater system compromise to exfiltrate content, so we imply dom0 compromise as well.
But to go on simpler possibilities again, there is nothing under Qubes that would prevent, as in any other monolithic OS, to capture vault’s “desktop” and sends its screen content online if vault has a netvm associated. First thing first, we take for granted that its not the case here. Then, if vault’s screen content is to be exfiltrated somehow, then dom0/sys-gui needs to be compromised somehow. And for that content to be exfiltrated, it needs a way to exfiltrate it. If its on the network, then in the present case, we also know that Heads is at play, and if Heads maximized builds were flashed, there is no ME at play (but a 98kb BringUP+RUMP payload that keeps the laptop functionning without AMT etc). So AMT binaries cannot be used to exfiltrate content on the network either. So there needs to be either network traffic happening when the exfiltration happen, or the laptop screen itself is filmed somehow. the other replies in this thread are going into isolating if the behavior is localized to the house (house compromised), or if the laptop is compromised. This is an important step into isolating what is happening here.
Anyway. Without other AppVM running, we expect a minimal of sys-net, sys-firewall to be running. In such circumstances with sys-whonix being shutdown (qvm-shutdown --force --wait sys-whonix from dom0 terminal), we expect the network traffic going through sys-net to be pretty low and limited. We expect sys-net to do some NTP traffic to sync time, appvms to check for updates after 5 minutes of uptime, after which nothing should really happen on the network. Making sure vault has no netvm should be verified first.
sys-net assuming we are under Fedora based sys-net
sudo dnf install tcpdump
sudo ip addr #Get the name of your upstream interface, mine is wls7)
sudo tcpdump -nneti wls7 -w ~/packettrace.pcap #Ctrl-C when done
qvm-move ~/packettrace.pcap #send to a dispvm or trusted appvm
If using a disposable sys-net, I have nothing against installing wireshark there temporarily instead of tcpdump above, and running wireshark directly on the uplink interface instead, this will show the traffic as it happens which might be of interest to understand visually what is happening. Note that installing applications on appvms will only be available through that session and will vanish when the vm is shutdown.
In disposable vm/trustable appvm, install wireshark and open the file
sudo dnf install whireshark
wireshark
Open the pcap from ~/QubesIncoming/sys-net/packettrace.pcap
Hope this helps a little into investigating network traces.
I documented elsewhere how to get dom0 multiple snapshots, but that is useful only to compare prior/after compromise. It is also to note that it is totally possible to clone qubes/templates and compare states through volumes snapshots, where Qubes keeps 2 states by default (lvm snapshots named *-back where * is epoch time (number of seconds since 1970), which can be passed to disposable VMs in read only to be compared through basic tools like meld.
Edit: dom0 snapshots also discussed under Dom0 backup/snapshot?