Hacking Exposed
Page 28
The two fields we care most about, however, are the FILE and DIRECTORY fields. These will locate the file in the cache for us. Take a look at the directory structure of the Content.IE5 directory:
As you can see, several directories have very obscure names. However, if you look at the DIRECTORY field in the index.dat entry, it says 0PQLIJYD, one of the directories in the hierarchy. If you go into that directory, you will find a file named 7M{T57_]6423LU+]OD] QKP[1].jpg, or the same value as the FILENAME field. You can repeat this step until all the files for a page including graphics and includes are located, allowing you to reconstruct completely the page that the user loaded and interacted with. The reconstruction process allows you to show pages as the user saw them and interacted with them by evaluating the base HTML documents and then resolving all the links.
Tips for Working with Internet Explorer
Working with IE can quickly get messy. The key to performing investigations on IE-related activities is to understand the overall scheme of how IE stores data. IE always uses an index.dat to serve as a lookup table to find the history, cache, and cookies for the username under which it’s logged in. As long as you completely understand both the structure of the index.dat and the structure of the data to which it refers, you will be OK. If you try to perform investigations without fully understanding this scheme, you will get lost. Many tools automate this process to one level or another. But realize that even if you use an automated tool, if you are called to testify about the results, you must understand what the tool is doing. Don’t fall into the temptation of using a graphical tool as a crutch.
Firefox/Mozilla Forensics
Firefox/Mozilla (Firefox from here out) is the primary browser used in open source circles. It was born out of Netscape’s “crash-and-burn” back in 1998. It has been ported to every major operating system and is the Linux browser of choice. Its design focuses on cross-platform compatibility, so the information and metadata that you will be looking for is commonly kept in a file with an industry standard format as opposed to the IE way of doing things. This being said, you will have to deal with some interesting artifacts because the way it was developed (such as the history format) during your investigation.
Viewing the History
The Mozilla history format (MORK) is an example of what happens when open source goes bad. MORK replaced the standard Berkeley database format (DBM), and no one really knows why. In fact, the format is listed as a bug on the Firefox development tracker.
Several free options are available for viewing the history, but the one we like the best is Red Cliff Web Historian. This will extract the history data and put it into plaintext or HTML. If you are working an investigation and must look forensically at the history file, you might also want to check out a tool called NetAnalysis, which we will use in the case study, to perform the searching. To become familiar with the format, however, let’s look at the output from one of these tools. The location of the history file will vary based on operating system. In Windows, the file is located at C:Documents and Settings
As you can see, three columns of data are presented. The first column is the last access time in microseconds. The next column represents the number of times the URL has been accessed. This can be useful in showing that a user didn’t just inadvertently end up on a Web site and was actually a repeat visitor. The third column is the URL that was accessed by the request. This is good for a cursory check of what a user was doing on a machine. A ton of information is included in the file that can help with an investigation. Unfortunately, because of the file format, you are going to have to learn to decipher it yourself or buy a tool that does it for you. Unless you have a degree in computer science or at least a strong background in linguistic computing, we recommend the latter. We have had good luck with the tool FireFox Forensics by Machor Software. It can automatically break out the profile data and user settings from these preference files.
Finding Information in Cookies
What Firefox lacks in a history file format it makes up for with cookies. All the client’s cookies are stored in a central file, cookies.txt, which is in the profile directory. If you open it, you will notice that this file is human-readable and no special tools are required to view it. Let’s look at a few lines of the file:
This is the cookie and variables for amazon.com, as you can see in the first column. The second value is the flag that says whether or not the cookie allows the POST command. The third column, a directory entry, tells the site for which URLs and sub-URLs the cookie is valid. The fourth value is the flag indicating whether the cookie is used on a secure (SSL/TLS) site. The end of the metadata information contains the expiration time of the cookie in milliseconds. Finally, the last two columns are the variable name and value. As you can see from the entry, this information can be useful because you can see that a session was created with Amazon, denoting a login.
As of version 3 of Firefox, the browser now uses a SQLite database to store the cookies as well as other information. The best way that we have found to view these databases outside of forensic tools is through the use of SQLite Manager, a free add-on for Firefox. You can open the history file on another computer and export the results as a comma separated value (CSV) file.
Reconstructing Activity from the Cache
Cache browsing in Firefox is actually an easy process. If you can get hold of the cache directory in the profile, you can use Firefox to navigate it. Make sure that you make the cache read-only and that you properly hash everything before and after doing this, since you will be accessing the data with a non-forensics tool. That being said, fire up Firefox with the profile of the suspect. Then, in the browser bar, enter the URL about:cache, as shown in Figure 12-8.
Figure 12-8 Firefox’s cache navigation tool
You are concerned with the cache on the disk, so first ensure that the Cache Directory is set correctly and then click List Cache Entries. After you do this, you will see a listing of every file in the cache along with metadata, as shown in Figure 12-9.
If you need to drill down even more on a specific URL, you can click it to get more information, as shown in Figure 12-10.
As you can see in Figure 12-10, you are presented with everything you would want to know, and more, about the file. The most important part is the local filename, which tells you where to look on the file system to find the cached data. You can use this information to reconstruct entire pages with images and all includes.
Figure 12-9 Looking at the URLs in the cache
Tips for Working with Firefox
History file aside, Firefox is much easier to work with during an investigation than Internet Explorer. Everything you need to look at is consolidated into one central location and the formatting is well documented. In addition, unlike IE, the location of the files stays relatively the same from operating system to operating system. The downfall of Firefox during an investigation, however, is the history file. If you are doing an investigation that you think may end up in court at some point, save yourself the worry and effort and purchase a tool that can decode the history file for you and present the data in a meaningful manner. As mentioned regarding IE forensics, however, do try and understand what you know and don’t know about the format. Several good resources on the MORK format are available; read through these before you use a graphical tool.
Figure 12-10 Getting information about a specific URL
Case Study: Using NetAnalysis to Perform an Investigation
NetAnalysis is a graphical tool that makes investigation of web activity easy by pulling everything into one place. Let’s look at how you can use this tool to do a complete web investigation.
This case involves an employee who is suspected of working with a competitor to leak corporate secrets via the competitor’s Web site. The sus
pect was allegedly hacking into servers that contained secret information. We want to find out whether the user’s web activity tells us anything about the hack. The user has Windows XP with Firefox/Mozilla as the browser.
Our first step is to check the history and determine whether he has accessed the competitor’s site. After we have created a forensic copy of the user’s web browser profile and are properly documented, we open the history in NetAnalysis, as shown next. We do this by choosing File | Open History.
Once open, we can see exactly what our suspect has done. Let’s see what he was searching for with Google. The best way to do this is by using a filter. Let’s add one for searches we’re looking for by choosing Investigate | Google Search Criteria. This will limit the history only to the queries made in Google.
As you can see, the suspect used Google heavily (in fact, he even had a gmail account), as pretty much anyone who uses the Internet does. Let’s search the queries that he made and see if he was trolling around for corporate secrets or passwords.
As you can see, he was definitely looking for things he shouldn’t have been looking for with Google. This is a common pre-hack tactic to find out information about the company as well as passwords. Next, we follow proper forensic procedures to tag and bag the evidence and create our report for the higher ups.
OPERATING SYSTEM USER LOGS
The operating system on the computer can also be an effective tool in reconstructing user activities. While we discuss a few of these in depth in Chapters 6, 7, and 8, you should pay special attention to the UserAssist logs stored in Windows 2000, XP, and Vista. UserAssist can be immensely valuable in the timeline creation process.
UserAssist
UserAssist is a monitoring tool that tracks user activity: the programs a user accesses, double-clicks shortcuts, and performs other activities. The UserAssist key also maintains a count of these actions, as well as the last date and time a program was run by a user. It was first implemented in the Windows 2000 operating system.
Working with UserAssist
While UserAssist logging can be disabled, most casual computer users are not even aware that it is running. Because UserAssist is encrypted with ROT13, the average user wouldn’t even know the UserAssist key if they saw it. ROT13 is a substitution cipher (also known as the Caesar cipher); it simply replaces a letter with another letter 13 places down the alphabet. While someone may easily figure out how to delete their Internet history, it never occurs to them to disable the UserAssist feature or to delete entries from the UserAssist key; thus the UserAssist log usually remains untouched and provides a history of user activity.
UserAssist is found under the following registry key in the NTUSER.DAT file:
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionExplorerUserAssist
The UserAssist key consists of two subkeys. One key is for the Active Desktop and the other is for the Internet toolbar. If the system in question uses Internet Explorer 7.0 installed, you will see a third subkey.
As you can see in Figure 12-11, each of the UserAssist subkeys contain the Count subkeys that contain a substantial amount of information. Figure 12-12 illustrates how one of these keys appears when the Registry Editor is used to view it.
Figure 12-11 UserAssist “Count” subkeys
Figure 12-12 View of the key from Registry Viewer
Since Windows uses ROT13 to encrypt the data, the entries contained in the Count subkeys appear to be gibberish. However, several utilities can be used to decrypt them. One of them is Didier Stevens’s UserAssist utility, which is free and available to download from his Web site at http://blog.didierstevens.com/programs/userassist/).
Figure 12-13 shows the UserAssist data decrypted. Many of the decrypted entries contain one of three tags: RUNPATH, RUNPIDL, and RUNCPL. Numerous other tags appear as well, but these three will be of the most interest to you as forensic examiner. RUNPATH is linked to when a user double-clicks an icon for an application (such as Word). RUNPIDL is related to the access of shortcuts or .lnk files. The Last Write date/time is updated every time a user performs a specific action. RUNCPL is associated with the execution of a Control Panel applet, such as Add/Remove Programs.
Figure 12-13 UserAssist data decrypted
Paraben’s Registry Analyzer also decrypts ROT13 data. It shows both the raw (ROT13) data and the decrypted data, as illustrated in Figure 12-14. Using the ROT13 decryption, we can see, for example, that when HRZR_EHACNGU:NRKE.yax is decrypted, it is actually UEME_RUNPATH:AEXR.lnk.
Microsoft has removed several UserAssist entries in the Vista rollout that were present in XP. Depending on what user activity you’re looking for, it may be logged but could appear with a different tag, the entry may not contain the same specific information found in XP, or it may not be logged at all. You must verify whether or not you are examining a computer that has been upgraded from XP to Vista. If that is the case, you may see the old XP UserAssist entries as well as the Vista entries, so it’s important to pay special attention when reviewing the UserAssist registry keys.
Figure 12-14 View of both ROT13 and decrypted data
Tips for UserAssist
As you can see, UserAssist contains a lot of useful information. It can help you find new artifacts of user activity or to support other evidence of user activity you may have already found.
For more information about UserAssist, read “ROT13 is used in Windows? You’re joking!” at www.net-security.org/dl/insecure/INSECURE-Mag-10.pdf and Didier Steven’s blog at http://blog .didierstevens.com. In addition, many forensic tools can be used to view or search for ROT13 within their environment.
CHAPTER 13
FORENSIC ANALYSIS OF MOBILE DEVICES
When I first wrote this chapter in 2004, little did I know how radically personal digital assistant (PDA) and cell phone technologies would evolve in a few short years—not only technically, but in our society and culture—as very real parts of our daily lives. In 2004, the concept of a combination cell phone/PDA was just really starting, and I thought I was on the cutting edge, because I had a Mobile Windows device that I could also use to place a call. Today, these combination devices have permeated our lives, and people are tied to them in ways they never thought possible. In the late 1990s, The X Files Agent Scully told Mulder he’d go catatonic if he went without his cell phone for 24 hours. Today, the same can be said of almost everyone I know.
In 2004, I thought it was insanely cool to be connected all the time. Today, one of my fondest wishes is to donate my PDA phone to David Letterman for the “What happens if you throw this off the top of the Ed Sullivan Theater” skit.
In 2006, when my son started junior high school, I got the cultural shock of my life. It was the first day of school and I was standing at the front door of the school, waiting to meet my sixth grader. The bell rang, doors opened, and a crowd of teenagers rushed by me. The memories started flooding back of my time at his age, and then I heard something I never heard back then. Almost at once, as if by some grand queue from the cosmos or one of those unexplained wonders of nature, like salmon possessed to swim upstream, flip, flip, flip, flip, flip, flip, flip. I looked back and saw swarms of school children flipping open their cell phones to check their voice mails or make that call home. As my son and I walked to the car, I noticed kids on the school buses, heads crouched over, texting. The next day I asked one of the school bus drivers if the texting thing was normal, and she said the kids even text their friends on the same bus instead of just standing up, walking over, and actually having a conversation with one another and building some interpersonal communication skills. Then it hit me, on a gut level, just how much these devices have truly permeated our society.
The reason I bring all this up isn’t a form of self-therapy; rather, it’s to make a point — to convey the concept in a way that will help you understand it on a gut level, as I did. Mobile devices are part of almost everyone’s lives, and people feel very comfortable around them, which is nothing bu
t good for investigators. Because when people are comfortable, they are truly themselves and they will let their defenses down. When people are comfortable, they will take risks they wouldn’t normally take, and this could mean that you’ll have good luck collecting relevant information from one of these devices. Cases in point: The gangster who killed a guy and took a picture of the deceased with his phone. The vandal who documented his actions using his phone and posted his crime on YouTube.
We’ve come a long way from the days of simple phones that let you make calls, or PDAs that simply maintained contacts, kept your schedule straight, and allowed you to take notes. Today, mobile devices provide wireless access to corporate e-mail servers, and they can surf the Web at broadband speeds, in color! They can also run database applications, create documents with embedded graphics, create spreadsheets, act as clients to terminal services, be cell phones, and, oh yeah, keep your contacts and schedule straight. Today’s mobile devices really are computers in every sense of the word.
In 2004, only a handful of forensic tools had PDA and cell phone analysis capabilities. Today’s forensic analyst has a wide range of options, from tools that are specifically designed to do nothing but acquire and analyze these devices, to tools that include this feature as part of a suite of functions.