top of page

Unveiling An Invisible Threat: WIFI Perils of Digital Tracking

We live in a hyper connected world where radio frequencies seamlessly intertwine alongside us with every step we take. If you were to check out your WIFI setting on your phone right now, there are probably 5-10 different networks you could connect to, with even more options on your laptop. With the barrage of signals bouncing around us, we find solace in the convenience that autoconnect offers. As we move from location to location, our devices effortlessly latch onto familiar networks, granting us instant internet access without any manual intervention. However, under all of this convenience lies a hidden danger, and a vulnerability that can expose us to digital tracking and surveillance.


Today we delve into the murky waters of WIFI auto-connect, shedding light on the potential risk it poses and providing mitigation strategies against this form of espionage. The boundaries of privacy, convenience, and expansion of the Internet of Things are all intertwined. It has become imperative to understand the inner workings of this technology and take protective measures to protect your privacy.


Tracking you by your device all starts with “Probe Requests.” When your device is not connected to WIFI, it periodically broadcasts Probe Requests with the hope that it receives a “Probe Response” and exchange Information Elements (IE’s) with a known WIFI access point (an access point is a wireless device connecting other devices to the internet without cables, such as a router) to establish a connection. TLDR: a Probe Packet reaches out without user input to nearby access points, looking for access points you have previously connected to in order to reconnect automatically for internet access. As mentioned before, these Probe Requests are broadcasted. Therefore, any device capable of listening for this type of wireless traffic can capture and store it. The threat of tracking is within the data that is broadcasted and stored inside of these Probe Requests.


MAC address tracking explained


A Probe Request contains a load of information, but we're only going to focus on some of the data you could use to identify/fingerprint a device. To start, a Probe Request contains a MAC address. A MAC address is a unique identifier of a network interface card (a network interface card is computer hardware that connects a computer to an access point/network), assigned and programmed into the card during the manufacturing process. No two MAC addresses are the same (unless an attacker is spoofing one, but that is another topic). Once connected to an access point, a MAC address serves as a unique identifier for each device connected to said access point, allowing devices to recognize and address one another. Think of the MAC address as a name your computer goes by.


A MAC address can easily be used to track someone. For example, say a set of Monitoring Systems (MS’s) are set up along your regular path to work. If these MS’s were configured to receive Probe Requests and create an alert when a specific MAC address was received, in theory, your location would be tracked as you were on the way to work. Luckily, many technology companies have recognized this threat and implemented Address Space Layout Randomization (ASLR) which will randomize your MAC address whenever it sends out Probe Requests. However, this does not mean you’re completely safe, there is other data stored within the Probe Requests that can be used to identify your device.


Information Elements (IE’s)


As expressed previously, a goal of a Probe Request is to exchange Information Elements (IE’s) with a known access point. IE’s also known as parameters/tags, are used to advertise the functionalities of the device. Simply put, some devices have more WIFI capabilities than others. The Probe Request communicates the device's capabilities to the access point, making these Probe Packets tailored to the specific device. Not only that, but each Information Element has subcategories containing more information about your personal device. Therefore, if there are two identical models of an iPhone with the same WIFI capabilities, a researched observer could look at the subcategories of the IE’s to separate the devices and determine which is which.


Below is a list of these IE elements:

  1. SSID IE: carries the name of the network (Service Set Identifier) the device is trying to join.

  2. Supported Rates IE: lists the data rates supported by the device for communication.

  3. Extended Supported Rates IE: similar to Supported Rates, this element lists additional data rates supported by the device.

  4. HT Capabilities IE: for devices using 802.11n or higher standards, this element indicates the High Throughput (HT) capabilities of the device.

  5. HT Information IE: another IE related to 802.11n and higher standards, providing additional HT-related information.

  6. VHT Capabilities IE: for devices using 802.11ac or higher standards, this element indicates the Very High Throughput (VHT) capabilities of the device.

  7. VHT Operation IE: related to 802.11ac or higher standards, this IE provides VHT operational details.

  8. WPS IE: the Wi-Fi Protected Setup IE, which may be present if the device supports WPS.

  9. RSN (Robust Security Network) IE: this element indicates the security protocols supported by the device.

  10. Vendor-Specific IE: additional information specific to a particular vendor or manufacturer.


How you can be tracked through IE elements


Briefly, I would like to discuss methods used to track a person through IE elements.


WPS IE

Not all devices have WPS capabilities, but if one does, a WPS IE could be included in a Probe Request. WPS is a little button you may recognize even if you don’t know what it does.



Two network routers are displayed, with hands pointing to the WPS button on each one.
Examples of where to locate WPS buttons.

WPS button example

Many access points have a WPS button. If you click the WPS button on your home router and then click it on your personal device as well, you can automatically connect to your WIFI without entering a password/PSK.


In specific, there is a subfield within a WPS IE known as the Universally Unique Identifier (UUID) of the device. Following the guidance of the Wi-Fi Alliance, it is advisable to generate the UUID according to RFC 4122 standards, a widely adopted protocol adhered to by the majority of devices. The UUID is obtained through the truncation of the digest obtained from a cryptographic hashing of the MAC address. TLDR: It has been shown that a UUID can be reverse engineered through brute forcing, leaking the real MAC address of the device, bypassing Address Space Layout Randomization (ASLR). Remember, if someone obtains your MAC address, they can then track your location.


This is made even more easy if one knows the brand of the device due to the Organizationally Unique Identifier (OUI). The OUI is the first half of a MAC address and uniquely identifies the manufacturer or vendor of a network interface card. This means you only truly have to brute force the last half of an MAC address and can supply a dictionary of known OUI’s for a specific brand on the first half. Below is a visual representation of the OUI within a MAC address.




HT capabilities IE

High Throughput (HT) IE provides essential information about the functions of a WIFI client. Below is a list of subcategories within HT capabilities IE.

  1. Supported Channel Widths: indicate the channel width options supported by the client device for data transmission. Common options are 20 MHz, 40 MHz, or 20/40 MHz coexistence.

  2. Supported MIMO Configurations: specify the Multiple-Input Multiple-Output (MIMO) configurations supported by the client device. This information indicates the number of spatial streams supported, such as 1x1, 2x2, 3x3, or 4x4.

  3. Greenfield Support: indicates whether the client device supports the use of Greenfield format for transmitting data. Greenfield format is a more efficient method used in 802.11n and later standards.

  4. Short Guard Interval (SGI) Support: specifies whether the client device supports Short Guard Interval, a technique to reduce the guard interval time between symbols, thereby increasing data throughput.

  5. HT-STBC Support: indicates whether the client device supports Space-Time Block Coding (STBC), which is a method to improve signal reception in challenging environments.

  6. HT-Delayed Block Acknowledgment Support: indicates whether the client device supports the use of Delayed Block Acknowledgment, which improves efficiency in certain scenarios.

HT capabilities are very useful due to the amount of subcategories there are and the subcategories within those subcategories. The values within these subfields vary from device to device, making it one of the most useful IE’s for tracking.



The screen displays an example of Wireshark code.

HT capabilities IE/tag captured in wireshark


SSID IE

The SSID IE carries the SSID or name of the access point you are attempting to connect to. Every access point you connect to is saved onto a list and stored on your device. During each iteration of your device broadcasting Probe Requests, it will send a burst of requests for every SSID in that list. This practice has been abandoned for regular Probe Requests for security reasons; however, it is still triggered by specific events dependent on your device. Some iPads have been proven to burst out SSID IE’s when waking up from sleep mode and if a network is “hidden” (meaning you have to know and manually input an SSID to connect), the iPad may broadcast its SSID no matter what. This has many use cases; for instance, if an attacker (or snooper) knows the SSID of your router at home, they could sniff for that specific SSID, identifying your device. Below is some python code we made just to show how easy this process is.


Custom SSID detection code credit to Zach Hutton, Anthony Cruz and Sebastian Bowman

The code allows a user to specify a Network Interface card (NIC) with monitoring mode capabilities and has monitoring mode enabled, then allows the user to select a .txt list of known SSID’s that could be broadcast from a target device. It will then capture Probe Packets and output if a SSID in your list was broadcast to our device. Below are some screenshots of the code in action:



Final Notes about IE tracking + Sequence Number Tracking


As you can imagine, the power of IE tracking comes when you use multiple IE’s to build a fingerprint of a device. Not all devices have the same WIFI capabilities leading to some of the IE’s not being included in Probe Requests. So while it does require some work and research, one can tailor what specific IE’s a device will broadcast. This will give you a cluster of devices that are the same, which you can then utilize “sequence numbers” to further identify the device.


A sequence number is a unique set of 12 bits inside the header of our Probe Request and is used to detect retransmission and reconstructing of packets. The sequence number is generated by the combination of the MAC address of the device and a counter. This counter starts at 0 and increments with each new network request transmitted.


For example, let's say your device broadcasts a Probe Request, the sequence number is 56, and the access point receives said Probe Request. If your personal device does not receive a response from a nearby access point, it will resend the same Probe Request and the counter will stay at 56 for said request. The access point can do two things at this point; first, it can use the sequence number in the Probe Request retransmissions to confirm it is a repeat and continue ignoring it. Secondly, in some cases, Probe Requests may be fragmented due to network conditions or interference. The sequence number helps in reconstructing the fragmented packets correctly and then decides whether to respond or not. Therefore, the access point is uniquely identifying your device, this process can be reverse engineered to further identify a device by us humans.



Sequence Number captured from wireshark

Some of these methods to create fingerprints from databases of captured network traffic have already been automated on github, and algorithms to identify devices from sequence numbers have been researched extensively. I have not fully tested any of these myself.


Mitigation


Luckily, the solution to stop this type of tracking is simple. Disable WIFI and bluetooth if you're not using it and reset/wipe your phone. Reset/wiping will cause your counter number to reset and start again at 0. Not only will turning off your WIFI and bluetooth give you a longer battery life for the device you're using, but you also will “disappear” off from the map. This obviously is a hassle for many people, but if this type of privacy is important to you, it is a very simple fix.


Conclusion

In conclusion, the threat of being tracked through Probe Requests is a significant concern in today’s digitally-connected world. Technology is a terrifying and powerful tool, but as with everything in life, it is a double-edged sword. We tend to enjoy harnessing the benefits of technology while ignoring the safeguarding of our personal information. This is just ONE tracking method of the many that come with carrying devices that communicate with the whole world without us knowing, all should work together to create a safe and more secure future.



Sources (Could never do it without some google fu and these amazing studies/posts):

  1. Attacking Pixels. "Tracking Mobile Devices Through 802.11 Probe Request Frames - Part 1." [Online] Available: https://attackingpixels.com/Tracking-Mobile-Devices-Through-802.11-Probe-Request-Frames-Part-1/

  2. Mathy Vanhoef. "The Next Step in WiFi Probe Request Tracking." In Proceedings of the 11th ACM on Asia Conference on Computer and Communications Security (ASIA CCS'16), pp. 231-236. [Online] Available: https://papers.mathyvanhoef.com/asiaccs2016.pdf

  3. Karim, Md Abdul, et al. "An Analysis of Wi-Fi Probe Requests for User Tracking." Security and Communication Networks 2017 (2017). [Online] Available: https://www.hindawi.com/journals/scn/2017/6235484/

  4. Security Affairs. "WiFi Probe Requests Can Be Used to Track Users." [Online] Available: https://securityaffairs.com/132193/mobile-2/wifi-probe-requests-track-users.html

  5. Leach, Paul, et al. "A Universally Unique Identifier (UUID) URN Namespace." RFC 4122. [Online] Available: https://datatracker.ietf.org/doc/html/rfc4122

  6. Rpp0. "WiFi MAC Tracking." GitHub Repository. [Online] Available: https://github.com/rpp0/wifi-mac-tracking

  7. Oracle. "What Is IoT (Internet of Things)?" [Online] Available: https://www.oracle.com/internet-of-things/what-is-iot/

  8. Wi-Fi Alliance. "Wi-Fi Alliance." Wikipedia. [Online] Available: https://en.wikipedia.org/wiki/Wi-Fi_Alliance#:~:text=The%20Wi%2DFi%20Alliance%20is%20a%20nonprofit%20organization%20that%20promotes%20Wi%2DFi%20technology%20and%20certifies%20Wi%2DFi%20products%20if%20they%20comply%20with%20certain%20standards%20of%20interoperability.%20It%20is%20based%20in%20Austin%2C%20Texas.

  9. TechSlang. "What is ASLR (Address Space Layout Randomization)?" [Online] Available: https://www.techslang.com/definition/what-is-aslr/

  10. Wikipedia. "Organizationally Unique Identifier (OUI)." [Online] Available: https://en.wikipedia.org/wiki/Organizationally_unique_identifier


Sebastian Bowman is a Security Engineer at StandardUser Cybersecurity and enjoys teaching others what he is learning.


We at StandardUser Cybersecurity are on a mission to share cybersecurity and cyber safety education with everyone, to make our world a better place. Are you with us? How can we help? Let us know today.


Whatever your cybersecurity challenge, we can help you keep your business running. We are a defensive and offensive cybersecurity company, using over 30 years of experience with active commercial and government work and proven security methodologies. We also educate teams and professionals who want to build on their skills. Occasionally we communicate with cybersecurity memes.


We set the standard for cybersecurity excellence.

97 views0 comments
bottom of page