Recovering WIFI SSIDs From Chromium's Network Persistent State File

• Thu, Feb 3, 2022
• 3-minute read

As part of my master’s thesis at Abertay University, I’d spent most of the semester sifting through the artifacts generated by Chromium-Esque applications like Microsoft Teams. One notable file (from a forensic perspective) that I found is Chromium’s Network Persistent State file. In this quick post, I’ll be explaining how this file can be used to recover the SSIDs a suspect has previously been connected with.

File Location

The Network Persistent State file can be located within the root folder of the Electron or Chromium-based application under AppData. For Google Chrome on Windows, for example, the full path would typically be C:\Users<username>\AppData\Local\Google\Chrome\Network Persistent State. Note that this file does not have a file extension.

For popular Chromium-based browsers and applications, the locations would be as follows:

1
2
3
4
5
6
7
8

📝 Chrome Windows: C:\Users\<username>\AppData\Local\Google\Chrome\Network Persistent State
📝 Chrome Mac OS X: ~/Library/Application Support/Google/Chrome/Network Persistent State
📝 Chrome Linux: ~/.config/google-chrome/Network Persistent State
📝 WhatsApp Desktop Windows: C:\Users\<username>\AppData\Roaming\WhatsApp\Network Persistent State
📝 WhatsApp Desktop Mac OS X: ~/Library/Application Support/WhatsApp/Network Persistent State
📝 Microsoft Teams Windows: C:\Users\<username>\AppData\Roaming\Microsoft\Teams\Network Persistent State
📝 Microsoft Teams Mac OS X: ~/Library/Application Support/Microsoft/Teams/Network Persistent State
📝 Microsoft Teams Linux: ~/.config/Microsoft/Microsoft Teams/Network Persistent State

Content of the Network Persistent State File

The Network Persistent State file contains a list of servers and an indicator of whether the webservers support SPDY. SPDY was an experimental communication protocol developed by Google that was designed for transporting web content over HTTP with lower latencies while improving security through improved integration of TLS.

Besides, these server addresses include the file a dictionary with the key network_qualities that contains key-value pairs of the networks a client has been connected to and their qualities. This file, which is part of Chromium’s network quality estimator, stores the Service Set IDentifier (SSID) of wireless networks the client was connected to, as well as an estimator of the connection speed. The following figure shows the decoded entry of a client that has previously been connected to the university eduroam wireless network. In the following screenshot, the Base64 encoded keys have been decoded using GCHQ’s CyberChef.

The maximum number of entries for both wired and wireless networks saved in the Network Persistent State file is restricted to 20 entries. However, forensic examiners might even locate older entries as the eviction of entries does not follow the first-in-first-out principle but occurs based on a random selection of a previous network ID ¹. This circumstance could mean that entries of a crime-related Wireless Local Area Network (WLAN) SSID might still be present, even if a suspect has connected to more than 20 networks, in the meantime.

Word of Caution

I have noticed that the SSIDs did not get populated on some occasions even though the connection occurred over a wireless connection. I am still in the process of finding out what triggers the population of the SSID. Once I come around to do that, I will update the post accordingly. Nevertheless, I think the Network Persistent State file is something that every forensic investigator should have in their back pocket when analyzing modern Chromium-based applications.