Scenario: Case involves a Full File System extraction of an iPhone, acquired by law enforcement, that was turned over in discovery with a Cellebrite Reader Report and Call Detail Records (CDR). A Cellebrite Reader Report is commonly received by attorneys which contains the contents of phones and other mobile devices. In this case, our client had a witness provide screen shots of text messages between our client and the witness. There are myriad reasons why screenshots are problematic evidence (most egregiously they can be completely fabricated). The attorney knew these messages were real and they helped strengthen the alibi. But where are they in the reader report?
Forensic tools are not perfect. They are very useful in practice, but when you do not know where to manually look for the exculpatory evidence used to build a client’s alibi, then you are relying on imperfect and incomplete data to inform your case. In this scenario, the messages were present within the sms.db, the data base within the phone the stores these types of messages.
Where they were missing is more of the story, they were not presented in manner that is easily found in the Cellebrite Reader Report, especially to someone not trained in digital forensics or familiar with the use of Cellebrite’s Physical Analyzer. The attorney I was working with was completely unable to find these vital messages within the Cellebrite Reader Report and they did not have access to the tools needed to reprocess the extraction. Thankfully for the client, the attorney reached out to us and asked for help as we were able to find the messages and other artifacts to bolster our client’s defense. If you have similar issues, we can help, email us at email@example.com.
Cyber Agents has assisted in hundreds of military trials over the last 20 years. Sometimes it’s not necessary to take a case all the way to trial. We were contacted by a military attorney who requested our services to review a cell phone, computer, and a hard drive. The case involved contraband (CSAM) and the charges were possession. The case started when a service provider reported contraband to NCMEC (National center for Missing and Exploited Children). The images were found in the users cloud storage then reported to NCMEC.
We were provided reports of what the government found on the seized items. No images were found on the phone. Upon examination the primary hard drive which contained the OS (Operating System) and secondary hard drive contained a only few images of contraband. However when the government’s examiner carved the secondary external hard drive more than three million, mostly pornographic, images were returned. Carving is a way to recover deleted content from digital media. This is necessary when the reference to a file has been destroyed. Imagine a card catalogue at the library, the file reference is like the card in the index. If you loose that card the book doesn’t disappear from the shelf. Carving allows digital forensic examiners like us to find the book with no reference. Those references could have been recovered by the governments examiner, which would have revealed full file names and paths, but they didn’t use the correct tool. That is a discussion for another post.
Since I have worked a large number of contraband cases it was a strange there were so few images of contraband found on these items. On the main hard drive using our forensic software, I recovered internet history and link files. Internet history can show us where the user went online and link files can show file knowledge. Knowledge is a necessary component of proving someone knew a file existed and interacted with it. It is necessary in most situations and jurisdictions to prove a user knew a file was there to convict them of possession. In this case I was able to recover many internet artifacts and link files. From the internet history I was able to show the user didn’t search for CSAM. From the many recovered link files I was able to conclude that the user didn’t access the contraband or even the folder containing the images. The user also didn’t open any files with CSAM titles.
From this I concluded that the user probably had no idea there was even CSAM on the device. The user of this computer was also dual booting Ubuntu – KDE with grub, so I knew they were an advanced user. It looks like they used a script to download posts from porn forums and just happened to dump the wrong forum. I wrote a note about my findings for the defense attorney (TDS) to share with the government and the governments examiner. The government’s examiner agreed with my assessment and the case turned from a courts-martial to a Chapter 10.
Over the last 20+ years Cyber Agents has assisted in hundreds of cases some of which involve employee espionage. Today we’ll discuss a particular case where an employee was using company funds to purchase computer parts for their IT side business. Once we got involved we identified his phone and computers. We used Cellebrite’s Physical Analyzer to take an extraction of his iPhone and we used a hardware forensic imager to take forensic images (clones in a forensic format) of his computers hard drives. One mac mini, one standard dell desktop, and an iPhone. Unfortunately once he learned he was fired the employee reset their phone.
It is VERY important to secure company devices before you notify an employee they have been let go. Have them either tell you their pass code or enter the pass code for you in order to change the pass code to something known by management. Removing the pass code also removes access to shared items in the iOS keychain, which isn’t strictly necessary but it’s good forensic practice to change as little as possible on the device. (If they refuse to tell you the pass code we can crack it for you!) Then place the device into airplane mode and make sure to disable Bluetooth and WiFi in the settings menu and not in the control center pull down menu. Then give us a call at 859-523-9081 to have us preserve the devices. Even if you don’t intend to go after the person, preserving the data is important in case something comes up. Phone and laptop collections can be performed remotely so there is no need to ship the devices in most cases.
In this case, because the phone wasn’t secured we lost valuable information. It was fortunate that the suspect IT person backed up their phone to the company Mac mini. We were able to locate an older backup which had some of his personal business data on it. The suspect used a Newegg account to purchase the equipment. We were not able to access the account itself to get a list of parts. We were able to find emails with the purchased parts and we had the credit card bills showing Newegg purchases on the company card. The company declined to pursue the matter so the individual got away with the fraud. Will your employees get away with it?
Criminal cases in the field of digital forensics often bear morally-defunct charges, such as child pornography (CP) or child sexual exploitation (CSE). This type of content can be difficult for examiners – particularly the inexperienced. We are no stranger to these cases at Cyber Agents, as they often manifest as cyber crimes. But, how does law enforcement (LE) monitor for such crimes? How are these cases processed? How does this relate to digital forensic examiners (DFE’s)?
One of the most common ways we’ve seen LE track down potential predators is through the use of torrent-tracking software and passive peer-to-peer (P2P) network monitoring. BitTorrent and P2P networks are a great way of sharing massive amounts of data. So long as the files a user is looking for are available on the network, s/he will be able to download small fragments of it from multiple sources (on certain networks); this optimizes traffic across the network and allows people to download and upload several gigabytes (GB) in a small window. P2P networks rely on multiple people offering the same files for optimization, so when a user installs the client application the default settings will often be set so that a completed download will automatically start sharing to other users looking to download those files.
To fully understand how LE investigates CP and CSE distribution, it is necessary to understand how these different networks function. To explain that, we will need to look at the functional differences between BitTorrent and Traditional P2P networks, how LE handles their investigations of users on these networks, and how LE generally pursues suspects after they are identified.
BitTorrent is a P2P network protocol that allows a user to download blocks of a file while sharing blocks that s/he has already downloaded. Each torrent has a corresponding set of instructions known as a “[dot]torrent” file. Users download that set of instructions and feed them into their torrent client, or application. Users are then connected to trackers either on the DHT (distributed hash table) or hard coded into the torrent file, that advertise which peers have which blocks of a torrent available. Each peer connects to one or more peers on the network and downloads some of the available blocks from multiple seeding peers.
It is important to note that most Torrent clients do not offer the [dot]torrent file themselves. In order to obtain one, you must find a [dot]torrent repository and search. Some common repositories are “The Pirate Bay”, “Kickass Torrents”, “Demonoid”, “Torrentz”, and “ISOHunt”. Some common torrent clients are BitTorrent, uTorrent (MicroTorrent), Transmission, and Vuze.
LE will often use software that monitors the traffic on the network. On torrent networks, they identify known CP files by hash connect to the tracker or DHT and then connect to a single peer offering a completed download of that file within that torrent. A torrent download consists of blocks of a standard size specified when the torrent file is created. Between 16kiB and 16384kiB. Once a specific set of blocks is complete a user will have a complete copy of that file to download. A single block can contain multiple files. As soon as a block completes downloading the block is then made available, or seeded, to other downloaders, or leechers, of that same torrent. In layman’s terms they connect to a user making entire completed files available. With BitTorrent specifically, LE software will also track the peers, or the users downloading the available files, and LE will monitor when a peer finishes the file at issue and becomes a “seeder” of that file. LE possesses tools that allow them to leech files from a single seeder without offering the files themselves. This is important because LE should never share this content to other users. A leecher refers to a downloader that does not share content back to the network.
Traditional P2P Networks
Applications such as Limewire, Frostwire, EMule, and others are known as “traditional” P2P networks. They utilize concepts such as “Ultrapeers” and “leaf” to describe the structure of the network. For example searches for files within the network need a path to follow and the database of available files needs to be made available. In order for a peer to find a file, they send a search to their designated Ultrapeer (UP). That UP searches its connected peers or leafs, “x number of peers in my group have this file”. The UP then sends that search out to other UP’s who say, “x number of peers in our groups have this file, too”. With these types of networks, a file is generally not shared back to the other peers until the download has been completed. A user can alter settings within the application to allow this, but it is not a default setting for most applications. In addition, files are shared from beginning to end and in general are not split into blocks like BitTorrent.
When a file is being made available on the network, the peers need a way to identify each other, so the client application will identify them by their public IP address. If the files’ hash matches that of known CP, these tools will log that IP address, which they will then do an ARIN lookup and subpoena the internet service provider (ISP) for subscriber information of that IP address at the time the files were uploaded/downloaded. After a positive response from the ISP, LE will then get a search warrant for the subscriber’s physical address. Often, this search warrant is to seize “any and all” digital storage devices at the location and will often include verbiage that states something along the lines of, “this search warrant does not prove that any specific persons at the address are the suspect.”
After a hash analysis is performed on the seized devices, LE may identify the files they’ve been looking for. We’ve seen prosecutors bring charges against people based solely on the existence of these files on a device in their home. This is NOT how you prove a case. All too often a suspect is arrested and charges brought against him before a specific user is identified. LE and the prosecutor then need to prove who was using the device, whether the user knew of the files, and of the contents of the files, and that they had intent to possess or distribute the files. This can only be done by a DFE performing an expert analysis on the devices in question.
Once complete, the DFE should issue a report, which is facts stated with supporting exhibits, and expert opinions based on those facts. The report needs to include how the suspect was identified, how the files came to exist on the device(s), if/when the files were accessed, whether the files were deleted, and which user of the device created/accessed/deleted those files. Beyond just the files themselves, it also needs to be proved that the software used to upload these files was installed and running on the device, and whether the user was intentionally using that software to download and upload CP.
In my next few posts, I will discuss specific features of, and artifacts created by, the P2P client “ShareAza”. This is one of the most common P2P clients because of its ability to search for files across different types of P2P networks: GNUtella, GNUtella2, BitTorrent, and EDonkey2000. Since it is offered for free, anyone with an internet connection can download, install, and use the application.
We have also seen private individuals and organizations develop and use software that identifies CP, logs the user’s IP address, and save in a database or send it to LE for investigation. It is important to test that software to prove its functionality. If a tool has not been peer-reviewed, the Defense Counsel can present a Daubert challenge that could nullify the validity of that tool. This sort of review process generally does not happen, and someone who has not been qualified as an expert just stating that “the tool does this, and the tool does that” is not proof that the tool functions as stated.
In the previous post, I discussed the ability to locate someone’s phone via their Google account location data. However, it takes more than just that data to prove the person had been using their phone at the time. Being able to link a user to a phone, and subsequently prove that phone was in use during the time of the alleged incident, is vital to any case.
Usually, I can access and dump the data from a client’s phone. This will usually provide us information with the use of the phone in the form of text/picture messages, phone calls, or internet usage. However, there are the occasional cases where the client did not send any messages or make any calls at the time in question.
Luckily, Google will track certain application usage across logged in devices. I mentioned in my last post that I use two phones; an LG G6 and a OnePlus 5. Both phones had location services turned on, and both phones were in use throughout the day. The OnePlus gave me calendar alerts to let me know when/where my next appointment was, and the LG G6 used Google Maps to locate the address and plan my route.
I rarely used my phones as phones throughout the day, showing only the occasional call/text to let someone know I was on the way. If those communications didn’t occur, and if I was only able to obtain a logical and file system extraction on my phones, would there be any way to prove I was using either of the phones at the time?
When viewing the Google Takeout data, you can select to backup Calendar information as an ICS file. Here’s what a typical event looks like when you open the file in Notepad:
LOCATION:300 Quinton Ct\, Lexington\, KY 40509\, USA
SUMMARY:Showing @ 300 ATC
DESCRIPTION:This is an event reminder
You can see the start/end dates/times, created date/time, modified date/time, summary of the event, and an address/location. Some of this data is entered by the user, but it seems the created and modified dates are entered by Google. You can also see an Alarm event, but I am unable to determine what the “TRIGGER” value means or references. I did notice that all the alarm “TRIGGER” events had the same or near-similar value in my Calendar, so it may have something to do with the Google username or the time of the alarm before the event.
Other Google activity can appear in the form of notification dismissals. They come in the form of “cards”, which will have various values depending on the card. Depending on user activity, this can show that certain notifications have been viewed or dismissed. The number of card in each grouping of cards is relative to the activity throughout the day. The timestamp associated with the cards seems to correspond to the last card action in the feed. The card feed does not appear to be updated every day and is not included in the Google Takeout.
I had also been using Google Maps often that day and had searched for several places from different locations around Lexington, KY. Included in the Takeout is some search activity from both Maps and Google Search. Neither one points a specific device, but both include the GPS coordinates of the device at the time the search was performed.
If these same searches were found on a suspect’s cell phone at the same time, we can conclude the location of the cell phone at the time of search.
Keep in mind that every time you log in to the account, you are making changes to it, so here are a few suggestions to mitigate the changes you make:
Only log in once. The first time you log in you are adding your workstation to the list of logged in devices. Google will keep track of the last login time from each device, so logging in twice will alter the date/time of last login.
Keep track of which pages you visit. Google will show which pages were visited within the activity log but does not differentiate between which device browses which page. So, if someone else were to be accessing the account at the same time and deleting/altering data, there would be no accountability of whom performed what actions.
Stay logged in until you complete a download of the Takeout. Some of these Takeouts could be several GB (8+, based on my experience), and take a long time for Google to gather and for you to download. Your first download could fail, and you may have to re-initiate it. Staying logged in prevents you from having to deal with issues presented in Suggestion 1.
The only way to request the data is to have a notification emailed to the account; this cannot be disabled. Instead of going to the user’s email account to initiate the download, stay on the page you are brought to after selecting how to receive the archive. You should be able to download the data directly from that page. Otherwise, you can go to the Manage Archives page to check when it is available.
Do NOT use your browser for anything else until you log out of the account after the Takeout data has completed downloading. Every page you visit and every search you make are stored by Google under that account.
As always, if you plan on using any location data pulled from the account, you should attempt to match it with data pulled from a phone using that account. Generally, email account information is provided from a physical or file system extraction via Cellebrite. Showing that account was in use on the phone at the time is imperative but can be easily done by showing the account receiving emails on that device or, if a physical acquisition is possible, that the Google account was used to set up the phone.
Do you have a case that requires location reconnaissance? Contact us below.
At Cyber Agents, Inc., we often find ourselves tasked with determining a client’s location on a specific day and at a specific time. Fortunately, there are many ways a phone can record – and subsequently betray – location data.
In criminal trials, tower location data records (TLDR) can be obtained from cell service providers (CSP) to tie suspects to a crime. However, while TLDRs do show a relative area an individual may have been in, there are numerous other variables to consider: did the person of interest visit the area regularly? Was there an obstruction that could have caused the device to connect to another – more distant – cell tower? How long were they connected to the tower, and what is the range on the tower/cell phone? I have even had a case where the prosecution had attempted to use the TLDRs of a phone belonging to someone completely unrelated to the case. TLDRs provide useful data, but can leave a lot to be desired.
There are other ways of determining a client’s location; for instance, if they had a working cell phone with Google location data services turned on. It is possible to recover some location data on the phone directly, but the data may also be downloaded directly from a client’s Google account. The latter method often provides a more in-depth look at the client’s whereabouts for the day in question.
To demonstrate: I recently went apartment hunting. Throughout the day I had location services enabled on both my personal phone (OnePlus 5) and my work phone (LG G6). I traveled with my personal phone, and left my work phone at home. Afterward, I was able to access my Google Timeline and download a copy of my location data from that day. You can download it in KML format to use in Google Earth, or JSON format to use in Google Maps.
I’d also like to note that the times represented in the downloaded document are in UTC time. When viewed from your account page they should be your designated time zone. I manually converted the times during this narrative to reflect my current time zone (EST = UTC-5 and EDT = UTC-4).
A copy of an entire day’s location data will give you some overlap into the preceding day and the following day. The data we are looking begins at 3:35 PM on 19 Jan. 2018, and ends at 5:41 PM on 21 Jan. 2018. I remained at the same location from just before midnight on 20 Jan. 2018 until the first movement at 3:35 PM; Google exports the location recorded at midnight whether that entry begins hours or minutes before.
After importing the KML file into Google Earth, my entire day is mapped out with lines drawn between stopping points to indicate whether I was walking or driving. While the map does not show the precise route I took between points, it does show a direction of travel, arrival times, and departure times. During the driving portions multiple points are recorded and are logged as driving points. Location data was not available for my stationary device, the LG G6.
Still, this is not a perfect method. Some points are off by a significant distance, such as my apartment. But, Google location data does give a more precise area than TLDRs. Whenever possible, try to match any questionable locations with those found logged on the cell phone.
Notably, this timeline data can be altered by a user. The user can delete, modify, and view the data – which is logged in the account’s My Activity page. A user can also “snap” the plotted paths to the nearest roads which alters how the data is displayed in the map, but does not change times.
It is possible to have two devices logged in to the same Google account, and I have not been able to determine if/how Google separates the data from these devices. However, you can get an idea of what device was in use from the account history. It appears if an application is used that is manufacturer specific, you can determine which device was in use. For example, I was logged in to my account on my LG G6 as well, and found data showing access of an LG application. There was also some logged Android activity that showed up as coming from my G6.
This is not entirely indicative of use of a specific phone, but since the logged-in device’s data isn’t provided in the “takeout”, it can indicate the use of another device. Google now allows the user to download the activated devices (phones/tablets) on the account. This can reveal vital information such as: when the device was activated on the account, make/model of the device, and the last known IP address on the CSP network. This data can be found under the “Android Device Configuration Service Data” (ADSCD) section of the takeout package. Below is some (partially redacted) info on my LG G6’s ADSCD.
I’ll note that the populated “Serial Number(s)” field was incorrect, but all the other data about the hardware and software were correct. If you think a suspect or client had been using a device that has not been preserved, this data may be enough to compel him/her to turn it over for review.
Other data accessible by obtaining a “takeout” of the Google account includes: Browsing/Search History, Calendar data, Emails, Maps searches, Play Store pages/downloads, and YouTube search/watch history. All these sources can be used to link activity on a phone if you have the corresponding data dump.
Gaining access to someone else’s Google account can be an ordeal. The client often does not want anyone accessing their personal information. The data it contains is fundamentally pertinent to most cases so preservation of the data should happen quickly. As with preservation of digital data on devices, so must we preserve account data. Google’s location data could put a person within 10 yards of a crime scene or 10 miles away.
Do you have a case that requires location reconnaissance? Contact us below.