OPSEC considerations when using wifi

Here is a list of stuff with wifi that leads to deanonymization and some other trivia on information leaks with this technology. No wifi hacking tho.

All of those attacks only work if your adversary is in range of your wifi. It can be extended with directional antennas, LNAs and all of this is applying to management packets. Those are modulated differently to allow for more range at the cost of bandwidth compared to normal data packets.

Mac Addresses

Your wifi card has a permanent hardware serial number that is used as its address on OSI layer 2, the MAC address. It is send unencrypted with every packet and can be read by anyone in range.
This number is of the following format: “FF:FF:FF:AA:AA:AA”,
where the first 3x2 hex digits are the manufacturers prefix, and the last part the unique identifier within that address space.

Here is a list of all manufacturer prefixes.

If you see a MAC address that is for example 00:20:91:AB:0C:13 you can figure out that this wifi card was build by the National Security Agency.

Everybody in range can passively log MAC addresses with minimal ($2) hardware.


Turn on MAC randomization and hostname randomization. I wrote a setup script if somebody wants to copy my (very simple and auditable) bashcode into dom0.

Caveat! Some wifi firmwares are shitty. You can change your MAC address in software, but some chipsets will answer to packets that are addressed at their real MAC address, enabling an adversary to perform an active confirmation attack.

Wifi probes

Wifi probes are a bitch, so you probably want to mitigate those.

The APs (the thing that makes your wifi network) does send out beacon frames periodically, basically saying “Hi, i am network_a!”. This is enough for your devices to connect to it, but to speed up this process and to aid in roaming wifi probes are used.

Those are unencrypted packets send out by your devices whenever wifi is enabled to interrogate every known APs.

You wifi cards constantly sends out “hey home network, are you there? Hey network of my mate, are you there?” for every network you where connected at one time, resulting in a pretty unique used AP list that leaks astonishing metadata like where you where on vacation in some scenarios (“trump hotel guest wifi”) and so on… More a threat to smartphones, but of course also applies to laptops.

Wifi probe fingerprinters are in active deployment by corpos to track if customers return to their store and measure engagement by deploying one on billboards and one in the store… Those things are cheap ($2).


Only activate wifi if you really need it.
Delete old networks you won’t use anymore.
In qubes you could create one sys-wifi-networkname that is used as the netvm for sys-net for every network you connect and only start the one you want, or selectively only expose the configuration of needed networks to your sys-net dynamically.

Hardware imperfections

If your adversary is technically a bit more skilled, ones wifi card can be uniquely finerprinted by its hardware imperfections. Despite the fanciness of thid attack the needed hardware has gotten quite cheap (~20$). I am not aware of ready to go open source solutions for this attack If you are: Please send me a link!



As you cannot mitigate your hardware imperfections in software, the only way to stay “anonymous” is to simply buy more hardware.

Assume that every wifi device can be uniquely identified by an skilled and motivated adversary.

You can compartmentalize with hardware, like use only one physical wifi device for one single network, this would at least make your adversary unable to link together different networks you use.

You adversary will still be able to recognize that the same device is connected to the same network again, but there is nothing one can do about that that would scale good enough to be practical, but to not use wifi.

Other stuff

There is much wrong with wifi, i will not go into the attacks on the crypto here.

But even without attacking the crypto an passive adversary can monitor network traffic metadata (timings, size of packets) and leverage that knowledge with other deanonymization techniques.

Oh and you can look through walls with wifi. Pretty neat. LE has this in active deployment for years now.

Threat model is everything

This all may sound scary, and arguably it is. Assuming the most powerful adversary is a common mistake new ppl make in OPSEC so carefully evaluate what attacks your specific adversary is capable of/willing to execute.

Here is my assesment:
Mac address deanonymication: Active deployment, cheap easy. Everybody can do this and corpos do this already.

Wifi probe deanonymization: Active deployment, cheap, easy. Everybody can do this and corpos do this already.

Hardware imperfections: No known deployment in an industrial setting. I would say this is more private investigator and higher adversary stuff.

Looking through walls:
Batshit sci-fi crazy. LE stuff. If you have an open source project you know of, pls let me know!

Closing notes

If you have more ideas/info on how to deanonymize or fingerprint with wifi, please let me know!
More fun trivia about wifi welcome!
Did i miss something important or made a mistake? Pls tell me!


Fantastic post.

I had never heard about Wifi probes, but this makes total sense as a massive leak of metadata. Thank you for bringing this to my attention.

1 Like

To disable wifi by default on boot, one option is to add a command to rc.local to disable it.

Run in sys-net terminal the following:
sudo gedit /rw/config/rc.local

If sys-net is disposable, then run the command in the Disposable Template (the underlying template for sys-net). If gedit is not installed, use another editor such as nano.

Then add the following text to rc.local and save:

sudo nmcli radio wifi off

This will disable the wifi on boot. It can be enabled easily via the Network Manager (check box).


Randomizing your hostname is also a nice feature, not just for wifi:


With the edits to disp-vm which serves your disp-sys-net:

Do we need to create a new template and edit that to preserve the original state of our original disp-vm of choice?

If we apply Mac randomizations and/or hostname witholding/randomizations to the same disp-vm which creates all of our disp-app-vms, will there be any sudden networking issues between disp-app-vms and disp-net-vms?

If not, why isn’t this an issue? Is there some policy or address translation or whatever that I should get my headaround to understand the qube sinfrastructure better?

Keywords, homework, things to read, please

1 Like

It you want, i did that.

I don’t think so, but have not tried this.

This would change the mac addresses of your virtual network interfaces and the hostname. Neither of those are really important for the netvm to deliver networking (i think).

1 Like

So my goal is to create a new service qube, specifically ‘sys-net-disp-random’.

‘sys-net-disp-random’ will always randomize MAC address and host names. This will replace sys-net in most instances, but i’d like to maintain sys-net for rare use cases.

For these randomisations to always happen in ‘sys-net-disp-random’, they need to be spawned from template ‘sys-net-random-template’ which has the required scripts.

Have successfully created both the above mentioned: ‘sys-net-disp-random’ & ‘sys-net-random-template’.

But I cannot change template vm of ‘sys-net-disp-random’ to ‘sys-net-random-template’.

‘Sys-net-disp-random’ is still bound to ‘debian-11-dvm’.

What do now?

(I tried creating a new topic but i’ve hit my limit for a new user, I still think it’s related to wifi OPSEC: I can’t implement the policies if I can’t make the new template/service qubes work)

1 Like

These are good questions which will get lost in this thread.
Open TWO new threads, one for each question.

1 Like

Permission Issues when creating .conf file

I appreciate this isn’t a qubes specific question, but i’m sure people reading here could benefit from it.

Action: Write the settings to a new file in the /etc/NetworkManager/conf.d/ directory, such as 00-macrandomize.conf.

Issue: ‘Permission Denied’

Question: Why am I having permissions issues in a templatevm with passwordless root? Isn’t that sorta the point of passwordless root? Do I need to set about creating a user in my template just to work around this and assign permissions to that user?

Posted above question to new topic

1 Like

Iam happy to help you with this problem, but please create another topic for this.

This topic is about OPSEC considerations when using wifi.

1 Like