The topic of this blog post, device geolocation, is one of the areas that I enjoy researching but, unfortunately, it is one that I do not have to use very often. Specifically, we are going to delve into the data contained within the Windows Event Log "System.evtx" file that is present on Windows Vista and later systems.
(COMMENT: I did this on my own live system, but the exact same method applies while digging into your traditional "dead-box" system).
First of all, we are going to use the Windows Event Viewer to open up our System Event log. Once you have the Event Viewer program open, navigate to the "System" event log. What you see should look very similar to what is pictured below:
|Windows Event Viewer|
Once it is open, the easiest way is to search for the Event ID "6100" (Diagnostics-Networking). You can double click on the Event ID tab and it will sort for you. The default size limit of the Event Logs is capped at 20MB, so it may take a few seconds to sort it. Once it is sorted, you can navigate down to the 6100 events. The one that we are interested in starts with "Details about wireless connectivity diagnosis". The 6100 events have different data, but we want the one that starts with that line and contains a listing of all of the visible networks the device can see. It should look something like this:
|System.evtx Event ID 6100|
Now that we have the MAC addresses and network names associated with the device at the timestamp of the 6100 event, we can attempt to geolocate the MAC address of the BSSID(s) in question to try to determine where the device was. The SSID name will probably not always be as straight-forward as "Ripley's at Inner Harbor Baltimore Maryland", so we have to dig around a bit in order to find this data. I've used both the Google API and the Skyhook API in the past for this correlation, but for this example I used WiGLE (https://wigle.net/). You may have a "go to" source for geolocation that could be different and/or better, but once again, the methodology that we are going to follow is the same.
I took the list of BSSID MAC addresses that were listed in the 6100 event and searched WiGLE for each one of them. I only got two results, one on the SSID "WYHP4" and one on the SSID "4ZNNF".
|WiGLE results for "WYHP4"|
|Google Maps search for coordinates provided in WiGLE search for "WYHP4"|
|WiGLE results for "4ZNNF"|
|Google Maps search for coordinates provided by WiGLE search for "4ZNNF"|
Based off those results, on 11 March 2014 at 19:48:06, my device was located somewhere in that area determined by plotting those two locations. My actual location was is the small suitcase icon in the middle of the photos, but it is definitely close enough to determine, roughly, where a device was. With better tools and methods (in my experience, Skyhook is REALLY good but it is not as easy to demonstrate as WiGLE) it is possible to refine the location even more accurately!
Hopefully there are many, many more hits for the networks that you can see while performing your search, but this method can prove to be very helpful when you have evidence that a device is connected to a network, but have no location data on that network. If you can find other networks the device could see but did not connect to during that same time, it increases the chances of being able to roughly figure out where a device was as a particular time. The same methodology can be (and is) used with mobile devices and cell tower data. There are PLENTY of articles about cell tower locational mapping, if you would like to read more about that I recommend looking up that information via your search engine of choice!
A couple more thoughts to consider as well:
- Within the event log itself, you can search for the term "BSSID". That seems to be a constant in every language, so if your system was set to Arabic for example, the Event ID should be the same, but you can just use your evtx parser of choice and search for Event ID 6100 and BSSID for a listing of the networks (I prefer the EVTX Parser by Andreas Schuster for this purpose, just look for "/<EventID>6100<\/EventID>/" and "/BSSID\t\t/" (Perl regular expression matching))
- The events themselves seem to be generated when there is a connection issue of some sort, so you need "something" to have occurred in order to generate the event data (in other words, you have to be lucky enough to have it happen during the time-frame that you are looking for. The wireless network information is probably available in a memory dump too, I haven't had the time to dig through that as much as I would like yet. I have a hunch that it is in there somewhere, just not sure exactly where it is!)