Defeating Windows MAC Randomization: How I Learned to Stop Worrying and Become the NSA

Hello everyone. I'm Angela Biddinski. I'm a security engineer at Security Innovation. And today I'm going to do four things. Uh I'm going to start by telling you guys a story. Uh then we're going to analyze the NSA real quick. Uh after we're done analyzing the NSA, we're going to become the NSA. And finally, I'm going to have a call to action. So, let's get right into it. First, a story. The year is 2013. Uh the Edward Snowden leaks have just published millions of internal government files uh from the NSA as well as many other uh uh intelligence agencies both in the US and abroad. Uh these disclosures have shocked the world uh revealing for the

first time the real extent of uh the modern age of of digital surveillance. However, uh among these documents, uh while many of them make a major splash in the uh in the public consciousness, quite a few of them fall through, right? Obviously, there's millions of documents that the public is not going to pay attention to every single one of them. Uh and one of these that kind of slips through the cracks a little bit is this right here. Uh there was an internal CSEC which is the like Canadian NSA basically uh presentation where it was revealed that they were using uh MAC addresses which they were uh obtaining through airports Wi-Fi connections uh in order to track Canadian travelers and

they were doing this as part of a trial run for the NSA. I'm going to be using like I'm going to attribut be attributing a lot of this to the NSA throughout this talk just because it's punchier. Uh this was a CSCC and NSA joint effort so kind of keep that in mind going forward. Um, this internal slide deck uh has some pretty concerning stuff. This is a slide from that. You see it's labeled top secret. Don't worry about that. Um, so you can see that across uh two they said they swept a modestized city and in just two hightraic uh locations they over two weeks they were able to surveil 300,000 unique devices. That is terrifying,

right? That is a test pilot for their program. Um, and you know, this doesn't, like I said, doesn't make a much of a splash uh in the public consciousness, but it kind of makes a couple of uh waves in security circles. There's a few blog posts about it, a couple of articles. Um, and eventually people realize, yeah, this is a very legitimate privacy concern. Um, and so, um, Apple initially develops a uh defense measure called macronization. Uh, they deploy it in iOS 8 in 2014, so like a year or half a year after these, uh disclosures. Uh Microsoft and Google followed suit in 2015 with Windows 10 and Android 6 and this fixed everything. Uh we all lived

happily ever after. Great great end to the story. Well, I mean, okay, I would like for this to be the case, but I mean I guess I can end the presentation here. Um I have another like 22 minutes or something. We might as well look at what the NSA was actually doing, right? So let's analyze the NSA. Let's suppose that we are the NSA and we want to track a random civilian, right? you know, for for good reasons, I'm sure. What does every single random civilian carry with them? Uh, well, they carry the smartphone. Yeah, I heard that somewhere. Nice. Uh, what is every single smartphone doing at all times? Well, it's like communicating with cell

towers, for example. And that is a way that people that the feds are surveilling people like they will uh get data from uh from telecommunications providers and then triangulate people's positions based on like the signal strength to to each tele to each cell tower like around them. Uh but that requires like going with a warrant somewhere and like maybe even like a gag order to make sure that the telecom communications company doesn't like tattle on you. It's a real pain in the ass. So what if we instead look at how phones scan for Wi-Fi networks? They're just doing that passively. uh how does that process look like? Well, let's find out. Uh is specified in

what is called E 802.11. Uh this is the Wi-Fi protocol specification, you know, introduced back in the '90s. And the way it works is devices are sending out 802.11 frames whenever they are interacting with Wi-Fi. Uh so these frames, here's an oversimplified format. So they have a source MAC address. MAC stands for medium access control. It has nothing to do with like Macintoshes. Uh you have a destination MAC address and a frame type. and then some other data depending on one frame what frame type you're sending. Um let's look at MAC addresses specifically uh because we have both source and destination MAC addresses. Uh these are six byt addresses which are assigned to a network interface controller or an NIC.

Uh they are usually set in the firmware for the NIC. NIC is just like the Wi-Fi card in your in your device or you know if you're using this for Ethernet or Bluetooth or whatever it's whatever chip is interacting with the network. uh it's usually set in the firmware by the manufacturer and like I said it's used for Ethernet, Wi-Fi, Bluetooth, bunch of other stuff in the like general 802 family of technologies. Um and it is used to distinguish devices which are in the same physical area. So unlike an IP address where you're going to be using that for like on a global level like to communicate across the entire internet, MAC addresses are for communicating with

other devices or which are basically like in the same room with you or close to that. uh the and the operating operating system can usually change the MAC address. Um here we have some examples on the right. This is just some that I sniffed in Wireshark. Uh you can see that there are six octets like separated by these colons for readability. Uh let's take a look at 802.11 frames. Here are some common frame types. There are probe requests. This is how you actually scan for Wi-Fi. When your device wants to know what Wi-Fi networks are nearby, it sends out a probe request saying, "Hey, I'm device X. uh every access point so like Wi-Fi router or

whatever in the area please announce your presence and then all Wi-Fi networks around you will send a probe response saying hey I'm the access point with MAC address X and name XYZ feel free to connect to me and then if your device wants to connect it will send an association request saying hey I'd like to connect connect to this specific access point uh obviously there are many other frame types these are the ones which are going to be relevant for what we're doing today here's the crux of the problem that the NSA is going to exploit every single time a device scans for Wi-Fi networks, it has to broadcast its MAC address in the clear. This is by design,

right? If in order to be able to interact with it 802.11, you need to send out your MAC address and you say, "Hi, hey, I'm identifying myself as this device." Um, in the same way that if you want to send any like uh internet traffic anywhere, you're going to they're going to see your IP address. So, let's do surveillance NSA style. Uh, here is step one. We are going to set up a bunch of probe request sniffers across a uh an area. So here we have these little doggos or they represent our sniffers. Uh the sniffers are just going to be like little chips that are just listening on 2.4 GHz and 5 GHz. Uh so

like the uh uh frequencies for Wi-Fi. Uh and they're going to be paying attention to uh all of the probe requests which are being sent in a specific area. So like in literally like a radius I don't know 100 150 ft. Uh so you put you know one in Cap Hill, you put one in International District, you put one near the Space Needle etc. one in the UDub Udub area and then you compile this giant database of when each MAC address was seen at which location. So here we see for example that MAC address I've highlighted in blue. It was seen at Cap Hill at 7:00 and then at U District at 7:45. So who whoever owns that device

moved from Cap Hill to UD district in that time. And congratulations, you can now just passively track millions of devices. You don't need any warrants. You don't need any gag orders. You don't need any any zero days. You're good. Um because this is the crux of the talk, I would like to reiterate what the attack is here. So basically the NSA is putting a bunch of uh devices across just scattering them across a city having them uh log all MAC addresses that they see in their vicinity and then after that uh because those MAC addresses are unique and persistent identifiers uh every time one of those sniffers picks up one of those MAC addresses, they know that whoever

owns that device is in that area right now. So, how do we fix this? Well, let's formulate the problem. Uh, like I said, the problem is that our devices are constantly broadcasting a static unique identifier everywhere. And to fix this, we have to make our MAC address no longer static. It has to be unique just because otherwise it wouldn't work as an address. But we can make it no longer static. And that is what macronization is. It's the process of just periodically changing your uh MAC address to just something completely random. Here's a typical implementation as you might see in a modern operating system. We are going to use a random address on every probe request, every time we send

out a probe request. Uh we are also going to use a random address every time we connect to a network. Uh this takes two forms in practice. Usually devices will randomize the first time they are connecting to a network and then after that they will use that same uh randomized MAC address going forward every time they connect to that specific network. Uh I'll talk about a bit later about why that is. Um sometimes uh the device will actually rerandomize a new MAC address every single time it connects to a network but that can be annoying for usability. It is better for privacy but uh it is not the default because it causes usability problems. Uh here are some common failures with

macronization uh which can allow surveillance to be conducted anyways. Sometimes pro requests just aren't randomized and at that point like you're not really doing doing anything. Uh sometimes association requests like when you're trying to connect to a network will not be randomized. uh you might have cryptographically insecure randomization. This one is thankfully quite uncommon. I have not seen it in a while uh because you know it should not be difficult to generate a random number. Um sometimes the device will just randomly default to a hardware address like as a treat for no reason. Uh and you might have timing attacks and fingerprinting attacks which we'll talk about later in more detail. Here are some specific failure examples

which all of these are from a paper by written by fence uh and others uh in 2021. It was published in the uh pet symposium. uh this is a very seminal work like a lot of this talk would not have been possible without this paper. So huge shout out to them. Um there are sometimes different failures among devices even when they are using the same operating system. Uh so for example Motorola devices which obviously use Android have different failures than other Android devices where they will leak hardware addresses when they are active. So they're when they're actively using a Wi-Fi network but when they're passive they will like randomize everything totally normally. Um, some older Apple devices uh don't

randomize what are called sequence numbers in 802.11 uh which allows for like kind of better uh like fingerprinting. It's it's a little bit of metadata that you can use to uh uh to deanonymize like a randomized address. Uh and yeah, fingerprinting. What I mean by fingerprinting is using other metadata in an 802.11 frame in order to uh like construct a unique identity for a device based on other stuff like for example uh what what the length of the frame that it's sending is like how how long it takes to send that what it's rate what the radio capabilities of the device are, what radio channel it's using. um you can use all that to try to

construct like a a partially unique uh like set of identifiers for a device even if it's randomizing its MAC address completely correctly. So I specifically have been looking at macronization on Windows because it is a heavily underresarched area. Uh almost all research on macronization is about mobile devices which makes sense because it is considered to be a higher impact scenario for phones right like everyone is carrying their phone around with them everywhere. Not everyone is carrying a Windows device everywhere. But I think that it is still relevant because there are laptops obviously which many people in this room I'm sure are every day carrying a laptop. There are Windows-based handhelds uh increasingly like there's an ROG Ally kind of like

gaming handheld thing which uses Windows. Uh these are becoming increasingly popular. Uh there's a rumored future of Xbox handheld which whatever I won't say too much about I guess because we're in Microsoft. Uh uh which will probably be Windowsbased. Uh don't don't kill me Microsoft people. Um uh so if we actually look at how uh the randomization works on Windows, there is very little documentation. Uh in fact almost all of uh the stuff I got from a presentation that uh someone who just worked on the feature uh gave in 2015 uh and if not for this present like if not for the slides for this presentation being archived online, it would have been a total pain to figure anything out

about this subject. Here are the important details. Randomization is off by default. Uh, great. Thanks. Uh, probe requests, however, are randomized. So, okay, thank you. I don't kick me out of the Microsoft yet. Um, and randomization is cryptographically secure. So, they take a shot to fix hash of a client secret, which is stored on the machine. Uh, the SSID of the network if you're connected to it, uh, and a connection ID and then they truncate that whole thing. So, it's whatever. It's just it's functionally random. You're not going to be cracking this. Uh, the client secret is stored in the registry somewhere somewhere. But now that we know how uh the implementation works, uh let's see how we can break it.

Let's become the NSA. Uh this is also known as a findings section for normal people. Uh first of all, hotspots do not have their MAC address randomized. Uh when you turn on a hotspot on a Windows device, the MAC address of that hotspot is just your hardware MAC address, but with the locally administered bit flipped to a one. Um locally administered is like a a bit in the MAC address which specifies whether your MAC address has been changed by the operating system or not. And so they just flip that bit and call it a day. This is maybe not a bug. The severity of this is very low overall because like if the feds want to track you and you're

walking around with a hot spot all the time, they can just track the name of your hotspot. It's whatever. This is uh relatively low impact. Uh this is however higher impact. All probe requests will use the same randomized MAC address up until you reset the NIC. Uh so that happens if you reboot your computer, if you toggle your Wi-Fi on and off, uh other stuff like that, or if you connect to or disconnect from a network. So if a target is walking around just uh like from point A to point B and they don't connect to any Wi-Fi networks along the way, which is a pretty reasonable like scenario in the in day-to-day life, it is trivial to

track them. They are going to be sending out probe requests with the exact same MAC address throughout their entire journey. Uh moreover, uh what if they do connect to a Wi-Fi network? Like what if they pass by a Starbucks and they autoconnect to the Starbucks. They leave the range and they disconnect from the Starbucks. Well, let's take a look at what our sniffers will see. Uh at some point, address X is sending probe requests and then suddenly just stops. It stops sending any traffic whatsoever. Then immediately at that point, address Y connects to some network. Then at some point later, address Y disconnects and then immediately address Z starts sending probe requests. Well, the attacker can be pretty confident that X,

Y, and Z are all belonging to the same per or all of the same device. So tracking is still viable in this scenario. Um let's talk about timing and fingerprinting. Uh probe requests on Windows are sent almost exactly every 60 seconds. Uh it's like 60.0015 or something like that. Um and so if you have a persistent view of the target, so you have sniffers which all like at any point in time along the uh person's journey, you always have a sniffer which is uh which has uh which is picking up their probe requests. Uh you can correlate their MAC addresses. Uh this is finicky. It requires obviously a very high density of sniffers. That's not

really a problem if you're the NSA. It's a problem if you're a researcher like me. Uh but it's made more viable if you like fingerprints based off of hardware capabilities and other stuff like that. So, here's like a wire shark screenshot showing like uh stuff that you could fingerprint based off of. So, like hardware capabilities and other stuff like that. But all of this is made kind of mooted by an undocumented quote unquote feature. Uh I use the term feature derogatorily here. Uh because I think that it should be considered a bug. As far as I can tell, it is intentional. Uh when you turn on randomization systemwide on Windows, it remains off for any known networks. Any network that

you were already connected to before this point, randomization will not be turned on for unless you turn it on manually. And this behavior is never made apparent to the end user. Uh there is no easy one-click fix. You literally have to go into every single one of those networks, click on the network and settings, turn on randomization, click on the other network, turn on randomization, do that. Uh, and this is especially bad because like on Windows 11 at least, you have to connect to a Wi-Fi network in order to set up your device. You can't you physically cannot turn on macronization before connecting to a Wi-Fi network on Windows 11 without like doing a you know whatever the

command line bypass but nobody's doing that um with exception of people here. Uh so this allows us to do essentially a variant of an evil twin attack where if a device is leaking its hardware MAC address, right? So if macronization is turned off for all of those networks, the device will leak its hardware MAC address every times it every time it tries to connect to one of those specific networks. We can just pretend to be one of those networks. We can send a spoofed probe response uh with like guesses at common SSIDs. So like we say, hey, I'm Starbucks Wi-Fi. I'm Centry Link, bunch of numbers. I'm Exfinity Wi-Fi. I'm University of Washington Wi-Fi. If we

want to, you know, surveil activists on college campuses or whatever, um, and then if a user has connected to any of these networks before they turned on randomization, bam, their device automatically just tries to connect and leaks this hardware address. Notably, the device doesn't even have to successfully connect to your network. It just has to start trying to connect to it. As soon as it starts trying, as soon as it sends that association request, it is sending its hardware MAC address. And it is trivial to detect when you've successfully gotten someone to leak their hardware uh address because you just look at the locally administered bit. Um we can extend this to other operating systems. Uh so Android,

Windows and iOS uh implementations of macronization actually all by default have the behavior of reusing one MAC address for uh for a network every single time you connect to it uh after you initially connect to it. So it will randomize once and then reuse that forever. Uh this is so that you don't have problems with like captive gateways. is like if you go to a hotel and you connect to the Wi-Fi and you like pay for one device, you don't want to have a the hotel thinking that you're connecting a new device every time you reconnect. Uh this is called persistent randomization. Um and and the our evil twin attack will always get the device

to leak the same address uh even with MAC randomization implemented and turned on as intended. So, uh, when we set up our evil twin, uh, if a, uh, a device has connected to that network in the past before, every single time it will send an association request with the same MAC address, it will be a quote unquote randomized address, but it will be static. It will be unchanging. Every single time we do this, uh, it will, the device will send the exact same address. Uh, so the attack complexity doesn't actually meaningfully increase from the NSA's perspective. Uh, from macronization, as it currently, uh, exists on all operating systems. sniffers just need to passively send out

like fake Starbucks Wi-Fi probe requests. Uh, and with this knowledge, we can finally become the NSA. So, we set up a bunch of Wi-Fi sniffers across a large area. Uh, we have those sniffers pretend to be some common network name like Starbucks Wi-Fi. Uh, we note down which MAC addresses attempts to connect to that network. And then when a specific device is near any of our sniffers, it will always attempt to connect with the same unique identifier. And then we just do surveillance the exact same way as we were doing previously. So, you know, this is an NSA grade attack, so it clearly requires some NSA grade hardware. We are going to use a thousand ESP32s.

Uh, and that's it. That's kind of just all you need. Uh, you can buy these things for a dollar and you can cover an entire city center with like a thousand of these pretty easily. Uh, this is a very lowcost attack. It is viable for me to do, you know, it is viable for any of you to do. Uh, please do not use this for stalking. It would be very bad. Uh this is solved by something called non-persistent randomization as opposed to persistent. Uh where iOS and Windows both have the option to randomize addresses every 24 hours. Uh Android has a developer option to rerandomize on each connection to a specific network. Uh but the average user is very unlikely

to ever turn these on. Uh because these options are nested layers deep in the network settings. Nobody knows what they do. Uh on iOS and Windows, you have to change them individually per network. And so like these security features don't do anything if nobody is going to turn them on. Uh that is kind of the takeaway from this talk is uh where does this leave us? Across all three major operating systems, MAC address tracking is still very viable. Uh so this technique that was revealed in leaks that the NS that the CSCC and NSA were already test piloting in 2012, it is 2025 now. It is still viable to do. So that brings us to

the call to action. We need more eyes on this problem. uh mac address tracking is heavily underresarched. Uh it is uh researched almost exclusively in academic circles and then probably like a couple of uh people at like Google and Apple and Microsoft like internally researching it. Uh this talk I've given has barely scratched the surface. Uh here are some further areas. Feel free to poke at these if you are interested. Uh Bluetooth. Bluetooth uses MAC addresses. Your everything uses Bluetooth. Your car has Bluetooth. Does your car randomizes its Bluetooth MAC addresses? Probably not. Is that bad? Hm. Probably. uh air tags, they also use Bluetooth. There's an interesting kind of uh uh conundrum there where if you randomize

those addresses too often, it makes it too easy to use air tags for stalking. So, they have like a a whole system for how often they randomize. And then we need to develop better defensive measures because the current ones are insufficient. Uh this is more critical now than ever. Domestic surveillance is especially harmful under oppressive regimes. And who boy, it's not looking good out there. Uh there is already precedent for surveillance of student activists. So that's why I mentioned University of Washington Wi-Fi. Uh people seeking abortions etc. Uh things will get worse in the coming years and so this isn't just a cool technical problem that I get to yap about. It is something which directly affects at risk

individuals. Uh so with that said acknowledgements. Special thanks to the authors of the paper I mentioned earlier. It is a really good paper. I highly recommend reading it. Uh security innovation my employer for facilitating this research. Uh Montias Fontanini who created this uh cool uh command line presentation tool that I've been using. Uh, and Batman's Kitchen for enduring me yapping about MAC addresses for 2 years. Thank you guys. Uh, [Applause] you can find me on various locations. Uh, if you're cool on Signal, the other two I don't really check that often, but feel free to reach out. [Applause]