Application Specific Geo-location
Web applications can often leave their own geo-location clues similar to those found via the mapping services. While mapping artifacts are largely consistent, geo-artifacts created by applications are more haphazard. Thus the number of available artifacts can be as numerous as the applications using geo-location services. To illustrate this, we will analyze the artifacts left by two popular location-aware applications: Flickr and Twitter.
Mobile Flickr Geo-artifacts
Flickr is a photo sharing website and the mobile version has an interesting location-aware feature. A user can select the "Nearby" tab and see pictures that were geo-tagged in the general neighborhood. Of course, in order to do this, Flickr needs to know the user's current location, which it determines by sending device information to Yahoo! Geo Services. Evidence of this is recorded by the browser cache, as seen in Figure 1. The URL http://m.flickr.com/nearby/40.... clearly shows where Flickr believes the device to be located.
Figure 1: Flickr Location Artifact in Browser Cache
Notice that specific coordinates are found in the absence of an obvious location search, suggesting that actual geo-location may have taken place instead of the user simply typing a location. A review of the site on a test system indicates the Flicker Nearby feature will only function if the device is capable of geo-locating itself. This provides stronger evidence that this particular device was located at coordinates 40.760779,-111.891047 at the time the browser cache entry was created.
Geo-artifacts left by Twitter
Twitter uses geo-location to allow users to tag their posts (tweets) with a specific neighborhood, city, or exact location. It can use a HTML5 capable browser to request latitude and longitude and if that is unavailable will default to geo-location using the device's IP address. Interestingly, Twitter stores the last IP address for a device along with the time the IP was recorded within a cookie; even if geo-location was never authorized. Since an IP address can sometimes be geo-located, this can be a great artifact. A sample Twitter cookie, "firstname.lastname@example.org" might contain:
The IP address starts with the second character (22.214.171.124), and the timestamp immediately follows (1310063489493350). The timestamp is stored in PRTime, recording the number of microseconds since Jan 1, 1970 UTC. In this case, the value converts to July 7, 2011 18:31:29 UTC. Using an IP address geo-location database like Maxmind, we can determine the IP belongs to Charter Communications and appears to be located in Denton, Texas. Therefore, with some level of confidence we can say the device containing that cookie was in Texas on July 7, 2011. Of course geo-location by IP address can be wildly inaccurate, so we would prefer to have additional artifacts to help bolster that claim.
It turns out that Twitter allows requests using URL query string parameters similar to Google Map requests. You might find any of the following supporting information in the browser cache database:
If no evidence is found in the cache, our next step might be to review a memory dump or unallocated space. Similar to Google Maps, Twitter can transmit geo-location data via JSON and HTTP Post requests, circumventing our ability to spy data in the cache. Figure 2 shows a Twitter JSON fragment stored on the host when a tweet was posted with location tracking enabled. This fragment tells us that the device was geo-located by Twitter to a location near St Ann's Church in Salt Lake City, United States. If we are lucky enough to find the original JSON file metadata, the creation time will tell us when the device was at that location. In this example, we do not have any information on the data Twitter used for geo-location, and hence the accuracy is unknown.
I have had success in finding Twitter data using the following keyword search terms:
While we have covered only two applications, it should be clear that even simple location-aware implementations can reap very useful artifacts to the investigator. Since it would be infeasible to profile every possible location-aware application in advance, the following process can be used:
- Look for clues pointing to location-aware features
- Identify the potential application and perform offline testing
- Search for any useful artifacts discovered during testing
I hope you enjoyed this three part series! Our computing devices are becoming increasingly more mobile, and software applications are evolving to take advantage of this. As a result, geo-location artifacts are permeating operating systems, applications and file formats. Nowhere is this more obvious than in the latest web standard, HTML5, which includes native support for device geo-location. With the major browser's adoption of HTML5, nearly every Internet connected device on Earth can transmit its location. Taking advantage of the artifacts left behind will give forensic analysts tremendous new resources to track devices and build cases with stronger user attribution. This collection of posts represents just a sliver of the currently available geo-location artifacts. I look forward to continued discoveries and collaboration on this topic within the forensic community.
- Big Brother Forensics: Device Tracking Using Browser-Based Artifacts (Part 1)
- Big Brother Forensics: Device Tracking Using Browser-Based Artifacts (Part 2)
- Digital Forensics Magazine, Issue 9, November 2011
- Maxmind Geo-location Database
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 FOR500 Windows Forensics and FOR508 Advanced Computer Forensic Analysis and Incident Response for the SANS Institute. Find him on Twitter @chadtilbury or at http://forensicmethods.com.