Helpful Navigation Toolbar

Tuesday, April 22, 2014

You don't know where that device has been...

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 ( 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!) 

Wednesday, April 16, 2014

Updates to the Windows Live Response tool collection

Good news everyone!! I found some time during the early part of this week to make a couple of updates to the Windows version of the Live Response tool collection. 

The first update is Pinpoint Version 0.2.0 (which was actually released back in February) from Kahu Security. The tool is great for helping to identify possible malicious content on a webpage. The following description of the tool is taken directly from website:

"Fetches a webpage and then enumerates and analyzes its components to help identify any infected files. Pinpoint gives you various options when making an HTTP request including spoofing the user-agent string and referer. Pinpoint will not render any of the content."

The second update is PEStudio, from Marc Ochsenmeier, who has been EXTREMELY busy pushing out updates to his amazing tool. The most recent update to PEStudio has "extended blacklist and Features detection as well as fixing a bug when handling 64-bit images". Marc has also set up a Paypal donation option on his website, if you have used PEStudio to help with any of your analysis and/or research I encourage you to consider donating as a way of saying "Thank you Marc!" for all of the time, effort, and work he has put into PEStudio. I would gladly pay for a tool like PEStudio, but am very grateful that Marc offers it for free!

The third update comes as a result of using the Live Response collection in a real-world response case. After being alerted to some possible files of interest that were identified by the other tools in the script, I wished that I had the hashes of some of those files to perform some additional research to attempt to determine if those files were legitimate Windows files or if they were malicious but attempting to "look" like Windows files. If run with Administrative privileges, the script will now compute the md5 and SHA256 of Windows PE files in the "%WINDIR%\system32" folder and "%SystemDrive%/Temp" folder (if it exists). It will also compute the md5 and SHA256 of all of the files in the "%TEMP%" folder of the currently logged on user. (COMMENT: I am working on doing this for each user of a system, I need to do some more testing in an effort to perform this in the most efficient (least system intensive) way possible).

I hope that you find the update(s) useful and as always, if you come across anything to help make the collection better or if there is a feature or option you would like to add or see, please let me know! - download here 

MD5: 7bc32091c1e7d773162fbdc9455f6432
SHA256: 2c32984adf2b5b584761f61bd58b61dfc0c62b27b117be40617fa260596d9c63
Updated: September 5, 2019

Wednesday, April 2, 2014

Brief Windows Live Response Tool Collection Walkthrough

As many long time readers of this blog know, one of my goals has been to put together a Live Response tool collection that helps IT professionals/Incident Responders/GeekSquad employees/etc. be able to quickly perform some volatile data collection in an automated fashion. The topic of today's post is to create a small walk-through guide of how to accomplish this collection from start to finish on a Windows system.

The first step is to ensure that you have downloaded the latest copy of the Live Response zip file. I updated the zip file today (2 April 2014) with PEStudio 8.17 ( in order to perform some malware information gathering on-site if needed. (Marc has put a TON of work into his tool and if you are performing any type of malware analysis and you are not using it, you should add it to your toolset collection immediately!) - download here 

MD5: 7bc32091c1e7d773162fbdc9455f6432
SHA256: 2c32984adf2b5b584761f61bd58b61dfc0c62b27b117be40617fa260596d9c63
Updated: September 5, 2019

Once you have the zip file downloaded, you should extract it to either the system you want to gather the information from or (my preference) an external USB device. Once you have extracted the file, navigate to the Windows_Live_Response folder. Inside this folder you will see a bunch of folders that contain the tools that we are going to leverage, as well as the file "Windows_Live_Response.bat". 

Contents of Windows Live Response folder

You have two options with this, you can either click the batch script which will run it with "normal" privileges (on Windows Vista and newer, this means not as an Administrator, on XP it runs with Admin privileges). You can also right click on the batch script and choose the "Run as Administrator" option.

Choosing to run script with Admin privileges on Windows 8 Pro device

If the script is run with the elevated privileges, a memory dump will automatically be created using the Belkasoft Ram Capture tool, Prefetch files will be copied, Last Activity View will run, netstat -anb will run, and an nmap scan of your default gateway will occur. If the script does not run with the elevated privileges, those items will not run (the script determines if it has elevated privileges or not).

The script will automatically create a folder within the "Windows_Live_Collection" folder that contains the computer name and the time that the collection occurred. This is to help users establish baseline activity as well as if you run the script multiple times on the same system.

Computer name and date are the name of the automatically created folder!

Once the script is complete, you are prompted to press any key to continue. 

Waiting to continue...

This helps ensure that the script has actually completed, rather than not displaying everything and potentially having the drive moved during the middle of the collection. The files are saved in the following folder structure:

Folder structure of Windows Live Response collection

"ForensicImages" -- This folder contains the memory dump (if made) which is stored in the "Memory" folder, and a "DiskImage" folder for storing the disk image if you so desire.

Contents of "ForensicImages" folder

"LiveResponseData" -- This folder stores the output of the tools and script, under the sub-folders:

  • "BasicInfo" - Information about the system
  • "NetworkInfo" - Information about the network
  • "PersistenceMechanisms" - Things that are set to run on the system (possible hiding location(s) of some malware
  • "Prefetch" - Prefetch information (for more on this, please read my earlier blog post HERE)
  • "UserInfo" - Information about the user(s) 

Contents of "LiveResponseData" folder

Lastly, there is a file named "Processing_Details_and_Hashes.txt". This file lists the md5 and SHA256 hashes each of the files in the LiveResponseData as well as the entire memory capture (if created). The script saves most of the results as text files, so you can import them into whatever tool you desire to view the results. You can also just use notepad and open up the files as well, the methodology of analysis is completely up to you.

Partial list of hashes in "Processing_Details_and_Hashes.txt" file created by Windows Live Response collection

Hopefully this small walk-through helps guide you through the steps that I take in order to leverage the Live Response tools on engagements. If during the usage of the tool you notice something is amiss or would like a feature(s) added, please let me know. I don't want to include anything in here that a user has to pay for, so please make sure the tool is completely free. If it is a commercially available tool, perhaps we can come up with a solution to produce something similar with a built-in command or another freely available solution.