SANS Digital Forensics and Incident Response Blog

Big Brother Forensics: Device Tracking Using Browser-Based Artifacts (Part 1)

[Author's Note: Geo-location artifacts have been a frequent focus of my research, and I am amazed at how quickly they are permeating operating systems, applications and file formats. In the fall of 2011 I had the pleasure of writing an article for Digital Forensics Magazine focused on browser-based geo artifacts, where much of this series was originally published.]

One of the more revolutionary forensic artifacts to emerge in recent years is geo-location data. Geo-location gives us an accurate means to identify the physical location of an item on Earth. It is now possible to determine where in the world a laptop or mobile phone has been, solely using host-based forensics. In a world of increasingly mobile devices, geo-artifacts can provide a crucial extra dimension to our investigations. With it, we now have the potential to answer who, what, when, why, and where.

The trend towards mobile computing is unmistakable, with laptop computers outselling desktops for several years. Forrester Research estimates tablets, netbooks, and laptops to be 73% of computer sales in 2011. While an increasing number of smartphones contain Global Positioning System (GPS) radios, the technology has been slower to be adapted to mobile computers. However, devices can be geo-located and store location artifacts even if they do not contain a GPS capability. In fact, in urban locales and particularly indoors, GPS can be highly unreliable. Technologies like WiFi network positioning and cell tower triangulation often augment or replace GPS. If a device is connected to the Internet and has access to GPS, a cellular modem, or a wireless network card, geo-location data in some form is likely already being generated and stored. This capability has sparked a creative gold rush, with an ever-increasing number of software applications racing to become "location aware". At stake is a slice of the $billion mobile marketing industry. Envision walking by a restaurant and being alerted to a half price lunch special via your mobile device; or arriving at a conference and immediately pinpointing the bars and restaurants where your contacts are located. These applications exist and digital forensic examiners can use the data generated to pinpoint the location of a device at a specific time.

An Inside Look at a Geo-location Service

Google Latitude

Google Latitude is a free, popular geo-location service. The host device first collects environmental information about itself, including IP address and any GPS, cell tower, and WiFi information available. This information is sent to Google via a Javascript Object Notation (JSON) file. The accuracy of the location estimate depends on how much distinct data is provided.

Example Google Latitude HTTPS POST Request:

{ "version":"1.1.0", "request_address":true, "wifi_towers":
[ {"mac_address":"00-15-e9-35-8e-3d",
"ssid":"JOHN HOME", signal_strength":-70 },
"ssid":"DAY-SEC","signal_strength":-83} ] }

The initial POST request includes data collected from the host: the SSID and MAC address for two wireless access points along with their relative signal strengths. Google Latitude will perform database lookups using the provided data and return an approximate location. Notice that coordinates, a street address and estimated accuracy (in meters) are returned.

Example Google Latitude JSON Response:

{"country":"United States",
"region": "Utah",
county": "Summit",
"city":"Park City",
"street":"Deer Valley Drive N",
"accuracy":72.0} }

These requests can certainly be captured in transit, though keep in mind they are SSL encrypted by default. A more realistic approach is to look for evidence of these JSON files on the host. Unfortunately files transferred via HTTPS are not cached, so our best chance of recovery is via unallocated space. Luckily, several of the tags present in the JSON files make excellent search terms. While I have had good success finding remnants of these geo-location communications, there are much easier places to discover geo artifacts. Specifically, the applications requesting location data almost invariably leave an easy to follow trail.

Introducing HTML5 Geo-Location

To see the future of geo-location artifacts, we need only to review the new HTML5 standard for web development. While the specification is not yet final, the Internet is moving rapidly towards HTML5 adoption. The World Wide Web Consortium (W3C) presciently included a geo-location application-programming interface (API) within HTML5, providing scripted access to geo-location information via the host system browser. With every major browser now supporting HTML5, there is instantly a common language for Internet applications to request and utilize the location of a given device. The HTML5 geo-location API can facilitate device location lookups using WiFi positioning, cell tower triangulation, GPS data, and in the worst case, simple IP address geo-location. Real-time location updates can be requested via the watchPosition() function, creating a breadcrumb trail of a device's whereabouts. From a forensic perspective, the HTML5 API is the best possible scenario. Standardized methods lead to dependable forensic artifacts, and interactions take place using the web browser, which is well understood by forensic examiners. With web browsers available on nearly every mobile device, we should expect consistent cross-platform artifacts on laptops, tablets, netbooks, and even smartphones.

How HTML5 Location Sharing Works

How HTML5 Location Sharing Works

In order to identify the forensic artifacts left behind by geo-location, we need to understand how location aware applications interact with the web browser, and ultimately the host system. When an application requests the current location, the following steps occur:

  1. The browser notifies the user of the location data request. If the user previously shared location information with the application, this step may be skipped.
  2. Assuming the user gives permission, the browser queries the host device using javascript and the getCurrentPosition() function.
  3. The host device returns available data, including IP address, GPS data, nearby cell towers, WiFi access points, and signal strengths.
  4. Information collected is sent to a geo-location service for database lookups. In this example, the Firefox browser defaults to Google Latitude. Latitude employs Secure Socket Layer (SSL) by default.
  5. The geo-location service returns an approximate longitude and latitude, which is stored in the browser document object model (DOM) as position.coords.longitude and position.coords.latitude and made available to the requesting application.

Next up in part 2: Identifying browser artifacts and parsing Google Maps data


Chad Tilbury, GCFA, has spent over twelve years conducting computer crime investigations ranging from hacking to espionage to multi-million dollar fraud cases. He teaches FOR408 Windows Forensics and FOR508 Advanced Computer Forensic Analysis and Incident Response for the SANS Institute. Find him on Twitter @chadtilbury or at