After completing this chapter, you should be able to
• Define volatile and nonvolatile information and describe techniques for collecting nonvolatile information, including cache, cookie, and history analysis
• Discuss various forensic tools and how to search with the Microsoft Event Viewer
• Explain various processes involved in forensic investigation of a Windows system, such as memory and registry analysis, Internet Explorer cache analysis, cookie analysis, MD5 calculation, Windows file analysis, and metadata investigation
• Explain how to parse process memory and a memory dump, and how to analyze restore point registry settings
• Discuss Windows password security issues, including password cracking
• Describe logfile analysis, including IIS, FTP and system file logs, event logs, static and dynamic event log analysis, and account management events
• Define a password cracker and the terminologies used in password cracking, summarize the various kinds of passwords, and recall default passwords
• Describe how a password cracker works, various password-cracking techniques, and various types of password attacks
• List various system and application software password-cracking strategies and attacks, and discuss various password-cracking tools
When you have the largest market share of any other operating system, it means (among other things) that you present a bigger target. Think for a minute about the effect of finding a zero-day vulnerability in Microsoft Windows 7. The number of machines that can be exploited by this flaw is enormous.
A forensic analysis can be static (“dead”), dynamic (“live”), or both. Static analysis occurs when we have brought the digital equipment to our lab, created a forensic image of persistent storage, and then begun our analysis using that image (or, better yet, a copy of the original forensic image—remember?). Dynamic analysis occurs when we encounter a running machine at the scene and we believe that there is evidence that would be lost or destroyed if the machine were shut down. Any evidence that would exist after a shutdown would be classified as persistent (nonvolatile) data, while any information lost during a shutdown would be classified as volatile information.
According to EC-Council, a digital forensics investigator (DFI) can examine three general areas as part of their analysis. These are the event logs, memory dumps, and Windows registry.1 In the case of static analysis, we can examine event logs and the Windows registry: They’re both part of persistent storage. The contents of memory, however, reflect dynamic information. Turn off the device, and essentially, the information is lost. The DFI has two choices here: collect the information that is stored in memory and reflects the dynamic state of the device, or capture all the memory and perform this analysis later without the same constraints of time and place.
The challenge is how to maximize our chances of retaining information that would help us in our investigation. Table 7-1 lists some alternatives.
Table 7-1 Methods of Collecting Volatile and Nonvolatile Information
If we need to collect volatile information, we can either perform a live analysis or dump the contents of random access memory (RAM) from the device to analyze later. In dynamic analysis, we can perform a live analysis immediately (both for memory and file system information), as well as a live capture of file system information.
CAUTION Factor time into your decisions. It takes time to perform a live analysis or capture, time that may be better spent elsewhere.
My personal perspective on Windows operating systems is that you can divide the history into three segments: before Windows NT, up to Windows XP, and Vista and beyond. That is to say, certain features appeared in Windows XP as an add-on facility, but then became part of the standard distributions in Vista and then Windows 7 (the PowerShell software is a good example). Microsoft Vista and later versions packaged two different command-line programs: cmd.exe and powershell.exe. Cmd.exe has been around since the Windows NT days (1992) and remains an efficient way to access various utilities to gather information with a minimal amount of muss and fuss (but you do need to know your command-shell features, such as I/O redirection). Figure 7-1 shows an example of the Windows command shell running the tasklist command.
Figure 7-1 Output of the tasklist command
Powershell.exe has shipped with Windows since Windows 7 and Windows Server 2003 (it was available as a separate download for Windows XP). The advantage to the DFI is that its command set is more regular, and the ability to pipeline command output displays information more efficiently. Figure 7-2 shows the powershell command that produces output similar to the tasklist command (don’t worry, though, those same ol’ command-line programs are still there should you need them).
Figure 7-2 Task listing in Windows PowerShell
EXAM TIP The CHFI v8 exam will ask questions about commands that can be executed from the cmd shell. However, PowerShell will become increasingly available as Windows machines are upgraded to Windows 7 or Windows 8 and it’s easier to extract the information that you need. Powershell is the wave of the future.
Where do all these nifty command-line programs come from? Many of them are part of a standard Windows installation. Start a command shell (cmd.exe) and type “help” at the prompt. Table 7-2 lists several useful commands that are part of a standard Windows 7 distribution. Other native tools are part of a set of administrator tools provided with the operating system (OS) (such as nbtstat) or tools meant to report on various networking aspects (arp, netstat, tracert, and so on).
Table 7-2 Windows Native Commands
Two collections of tools are absolute musts for your forensic toolkit. These tools can be burned to a CD or loaded onto a universal serial bus (USB) stick. The Sysinternals suite of programs was created by Mark Russinovich and Bryce Cogswell back in 1996 (www.sysinternals.com). Sysinternals.com was eventually purchased by Microsoft, but the tools are still available and are steadily being improved upon even as new tools are added. A second collection of tools is the NirSoft Utilities collection by Nir Sofer (www.nirsoft.com) A third program, Windows System Control Center (WSCC)(www.kls-soft.com/wscc), bundles both of these collections and provides a front-end graphical user interface (GUI) for managing these programs. Figure 7-3 shows the user interface (UI) for this program.
Figure 7-3 Windows System Control Center choices
WSCC offers the advantage of updating and gathering new tools as they become available. Each tool is assigned a category; categories are listed in Table 7-3.
Table 7-3 Tool Categories in the WSCC Software
We’ll be referring to several of these tools as we talk about static and dynamic forensic activities. We’ll use the convention that the program name will be suffixed by an “(s),” an “(n),” or an “(m),” indicating that the software is provided by Sysinternals, NirSoft, or Microsoft, respectively, as a separate download. The absence of a suffix indicates that the program is part of a standard Windows OS distribution (XP, Vista, or 7).
The prevailing wisdom these days is that capturing volatile information is as important, if not more important, as the static acquisition of persistent storage. In order to capture volatile information, you need to know which tools are needed to capture specific information. Second is your plan of action. You can collect this information manually or by running a script that you’ve written previously. You can run a command-line tool to capture all of the information specified as volatile.
In his paper, “Live Response Using PowerShell 2,” Sajeev Nair lists these elements of volatile and nonvolatile data.2 Volatile data includes such data as
• Machine and operating system information
• User accounts and current login information
• Network configuration and connectivity information
• Antivirus application status and related logs
• Startup applications
• Running process-related information
• Running services-related information
• Drivers installed and running
• Dynamic link libraries (DLLs) created
• Open files
• Open shares
• Mapped drives
• Scheduled jobs
• Active network connections and related process
Nonvolatile data includes data such as
• Hotfixes applied
• Installed applications
• Link files created
• Packed files
• USB related
• Shadow copies created
• Prefetch files and timestamps
• Domain Name System (DNS) cache
• List of available logs and last write times
• Firewall configuration
• Audit policy
• Temporary Internet files and cookies
• Typed uniform resource locators (URLs)
• Important registry keys
• File timeline
• Important event logs
Intimidating?! Nah.
As it turns out, some of the volatile information may actually persist. For example, a list of installed drivers can be obtained via a static analysis, but which ones were actually running at that particular time would depend on a dynamic analysis. Certain data will be available from your forensic disk image, regardless of the analysis you’re doing: Anything written to the file system (and this includes the Windows registry) should persist after the device is shut down, assuming there are no specific shutdown procedures that would remove that data. Essentially, volatile information will disappear upon shutdown.
In order better to understand volatile information, let’s do a quick review of some operating system details. A process is a computer entity that consumes system resources (memory, storage) and is runnable (that is, the computer will execute instructions associated with that entity). At rest, it’s a program; while running, it’s a process. Each process has at least one (many have more than one) “thread of control” (abbreviated as “thread”) that is defined as a set of instructions and an indication of which instruction should execute next (the “program counter”). Some computer architectures schedule threads; other architectures schedule processes. Generally, since resource usage is associated with processes, we’ll focus on those. Each process is identified by its process ID (PID). Processes can create new processes that either can run independently of the parent process or can run as a child of that process.
Much of this information is associated with running processes and their use of system resources. One set of resources shared among processes is network connections—that is, data structures that associate a port assigned to a particular process with an external device. The OS kernel is responsible for sending information via the network to these destination devices and making sure that the response is delivered to the correct process. In the TCP/IP protocol, these end points are described by a protocol/port number pair, so the kernel might send data addressed to the pair (TCP, 23) to a process that is awaiting for data (“listening”) on that port.
The first thing to do is determine the system date and time. The command line to do this is:
This will output the current date and time to a file that will store the results of our volatile information capture. Running software to capture volatile information will “leave a mark,” so it’s a good idea to reflect the date and time when we started our analysis. The DFI will create some of the activity that occurs on the device after this time, but not all.
Any data collection after this should be appended to the output file. For example, if we wanted to get a list of running tasks, we could do so by issuing the following command:
Logged-in Users and Open Files We need to determine who is logged in to the device, what files are open, what programs are running, and what external connections exist. The psloggedon(s) command will list the users logged on to the device, either locally or remotely, as will the net session command. We are most concerned with open files that are the result of an external user connected to a file share. Here again our faithful friend the net command will serve us well. The net view command will list local resources that are available as shares, and net file will show files that are open remotely.
Who’s Running What? The next information we want to collect is what programs are running on the device. The Sysinternals suite provides a number of tools that will list various information about all running processes. The tasklist(s) command has several options for listing running programs, as you can see in Figure 7-4. The command can be run on a remote device, the command output can be filtered, and you can specify the output format (table [default], list, or CSV [comma-separated values, suitable for importing into a database or a spreadsheet]). For example, the command
Figure 7-4 Tasklist options
would list all the processes on the local machine that incorporated the bcrypt.dll library and output the results in CSV format.
Network Connections Nbtstat.exe indicates the status of the Windows NetBIOS connections. Figure 7-5 lists the various options for this command.
Figure 7-5 Nbtstat.exe options
Capturing the state of the non-NetBIOS network connections (TCP/IP) is another critical step in live forensics. We’ll cover networking details in Chapter 9, but it’s worth mentioning the netstat.exe command. This command provides a wealth of information about the device’s network connections. Figure 7-6 lists the various options supported.
Figure 7-6 Netstat.exe options
Netstat can be found on Windows, Mac OS X, and Linux systems. Each system has its own variations on the command-line arguments, but the standard options chosen are list all connections, just display host IP addresses, and list the process ID of the process that owns that connection. On Windows, these arguments are -a (all connections), -n (addresses and port numbers only), and -o (display the owning process ID), abbreviated as -ano. The -b option will list all the executables involved in creating that connection. As the help options mention, you may need special permission to use the -b option. Figure 7-7 shows the output of that command when run on my desktop computer. In addition to the process ID, the name of the executable file is listed.
Figure 7-7 Netstat -anob command
TIP I’ve frequently encountered the “access denied” problem when invoking a command from a cmd.exe window when running on a 64-bit system, even with administrator privileges. The solution is to create a command-line window by using a Start|All Programs| Accessories menu entry and executing cmd.exe as an administrator. The problem has to do with running 32-bit Windows commands from a 64-bit context: Executing cmd.exe from the Start menu as an administrator and then running the offending command from that window will often prove successful.
All the information we discussed is stored and used by the operating system. If we don’t capture it while the device is still running, it will be gone once the machine is shut down. In order to preserve that information, we need to capture an image of computer memory (RAM). Software exists that will allow us to retrieve our volatile information from a memory dump like we could from the memory of a running machine.
A memory dump simply creates a copy of memory from a running computer. How we get access to memory will vary from OS to OS and from version to version of that OS. Assuming that all memory was utilized, we could be storing anywhere from 2 to 8GB of data or more. This calls for intelligent parsing of memory to determine which memory “pages” are in use. One particularly useful combination of software tools is the DumpIt utility (www.moonsols.com/resources) paired with the Volatility framework (code.google.com/p/volatility). The DumpIt utility is the essence of simplicity: It creates a dump file in the connected directory and asks one question: Are you feeling lucky? (Okay, it actually asks, “Do you want to continue?”) Answer yes, and the dump file is created after a suitable pause.
NOTE Think first and then press ENTER. The file that will be generated will be a number of gigabytes of storage, not something that you want to continually copy from place to place. But that was part of your forensic analysis plan, wasn’t it?
Once the file has been created, you can provide that as input to the Volatility framework. Basic Volatility commands take the form of
In my case, the name of my dump file is CLB-WIN7-20131125-205740.raw (let’s call it CLB.raw for short) and my machine profile is WIN7SP1x64 (Windows 7, Service Pack 1, 64-bit OS). The command to run the pslist command on that image would be
Volatility will accept a wide range of input formats. As stated on the software’s Web page:
Volatility supports memory dumps from all major 32- and 64-bit Windows versions and service packs, including XP, 2003 Server, Vista, Server 2008, Server 2008 R2, and 7. Whether your memory dump is in raw format, a Microsoft crash dump, hibernation file, or virtual machine snapshot, Volatility is able to work with it. It also now supports Linux memory dumps in raw or Linux Memory Extractor (LiME) format and includes 35+ plug-ins for analyzing 32- and 64-bit Linux kernels from 2.6.11 to 3.5.x and distributions such as Debian, Ubuntu, OpenSuSE, Fedora, CentOS, and Mandrake. It supports 38 versions of Mac OS X memory dumps, from 10.5 to 10.8.3 Mountain Lion, both 32- and 64-bit. Android phones with Advanced RISC machines (ARM) processors are also supported.3
That should be enough to get you going.
Nonvolatile data are data that remain (persist) after the device is powered off. Some of the volatile data that we’ve talked about can still be recovered from persistent storage if certain conditions are met. Microsoft has documented that one condition is whether the pagefile.sys file on Windows is wiped clean when the machine shuts down (this can be controlled by the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management\ClearPageFileAtShutdown registry key).
What kind of information must persist? Logically, the OS needs to keep enough information available to be able to boot up in essentially the same state it was in when the machine was powered off.
NOTE One difference would be if there were pending updates, deletions, or other tasks scheduled to run at system shutdown or system startup.
Likewise, information must be kept for any individual user that would allow the user to return to their previous state (for example, restoring the open tabs present when you shut down your web browser).
TIP Current thinking is that the DFI should perform some live investigation prior to shutting down the computer in order to capture the most valuable information from a running system.
The challenge for a DFI is remembering what all those places are, what tool to use to display the information, and what information will be the most important to either confirm or deny the initial hypothesis. As an experienced DFI, you will learn not to depend on your own memory, but rather create a script file that you can run from an attached portable drive that will retrieve all relevant information.
Earlier we said that there are three general sources of information for forensics analysis. The Windows registry is a treasure trove of information about the state of the device, past and present. History files kept by various applications such as web browsers or Windows 7 jump lists track which web sites have been visited or which files have been accessed. Finally, event log files are either generated by the OS or created by various applications. Combining these sources of information can help the DFI create a timeline of activities on the device where these activities can be corroborated by information stored in other locations. This chapter focuses on information stored on the device itself. In Chapter 9, we’ll examine information that is collected external to the device.
Recall that our main purpose in performing this analysis is to prove or disprove our hypothesis concerning the 5WH (who, what, when, where, why and how) for that particular device. One aspect of this analysis is looking at the history of activities: web sites visited, files uploaded, files deleted or modified. A second aspect of our analysis is to ensure that we can prove “individuation”—that is, that the suspect and only the suspect could have performed those activities.
Registry analysis is a huge topic, and you literally could write a book on the subject. (And someone did—Harlan Carvey in his book Windows Registry Forensics: Advanced Digital Forensic Analysis of the Windows Registry.) The Windows registry is actually composed of multiple files that live in the %Systemroot\system32\Config directory (you will probably need administrative privileges to access this directory if you’re running live). The files are named SYSTEM, SECURITY SOFTWARE, and SAM. SAM is the security hive, and isn’t accessed via the standard registry tools regedit.exe and reg.exe.
The registry is organized in a hierarchy. At the root of the hierarchy are five major keys, also known as “hives” or root keys. The five root keys are special: You can’t modify them, nor can you delete them. In addition, two of them (HKEY_CURRENT_USER and HKEY_CURRENT_CONFIG) are created at runtime and point back to the other keys.
• HKEY_CLASSES_ROOT
• HKEY_CURRENT_USER (subkey of HKEY_USERS)
• HKEY_LOCAL_MACHINE
• HKEY_USERS
• HKEY_CURRENT_CONFIG (subkey of HKEY_LOCAL_MACHINE)
Each cell in the registry is one of the following types:
• Key cell Contains a named key.
• Value cell Contains data. Several registry data types are listed in Table 7-4.
• Subkey list cell List of subkeys for a given key.
• Value list cell List of values for a given subkey.
• Security descriptor cell Security identifier for a particular cell.
Table 7-4 Windows Registry Data Types (Source: Russinovich, M., Solomon, D. Microsoft System Internals, 4th ed. (WA: Russinovich and Solomon, 2005) p. 185.)
Figure 7-8 shows the registry as it appears when using the Regedit program. The root keys are listed in the left pane, and the HKEY_CURRENT_CONFIG has been opened to view the Software\Quicken PDF Printer subkey. The right pane lists values associated with that key. The TC value is stored as REG_BINARY, meaning that only the Quicken PDF Printer software can derive its meaning.
Figure 7-8 Windows registry showing hive, keys, values, and data
Malware often tries to hide information within the registry. Although ultimately limited, values of type REG_BINARY or REG_EXPAND_SZ can store arbitrary data. Malware can also set itself up to run automatically when the device is powered on. The Autoruns(s) tool shows all of the registry keys and their values that pertain to software that is automatically run. For example, the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run lists all programs that are automatically started. The reg.exe utility allows the DFI to query registry values from the command line. The equivalent reg command to list the contents of the HKLM\…\CurrentVersion\Run is
Although the output of that command is less visually pleasing, all of the information is there. Harlan Carvery’s RegRipper toolset (regripper.wordpress.com) provides yet another means of selectively accessing information based on a profile. Standard profiles exist for the system, software, and security hives.
Windows File Analysis Several registry keys provide information about user activity in the file system. Table 7-5 lists several registry keys and their description.
Table 7-5 Information Stored in Registry Keys (Adapted from: EC-Council, “Windows Forensics I”, Computer Forensics: Investigating Hard Disks, File and Operating Systems, (MA: Cengage Learning, 2010), pp. 4:30-4:31.)
Now that you’ve seen what information is available from registry keys and you know how to access these keys (regedit, reg, RegRipper), a better strategy is to obtain a toolset such as the NirSoft utilities or the OSForensics software (www.osforensics.com). These tools provide a canned list of programs that will retrieve the same information and format it to make it more readable. The OSForensics software provides the ability to save this information as a part of a case.
As a DFI, you should also learn at least one scripting language (Perl, Python, PowerShell) so that you can create your own tools if necessary. Perl and Python both offer modules that let you access the Win32 application programming interfaces (APIs) and various system objects like the registry (the RegRipper main program, rr.exe, is written in Perl and has been compiled into a stand-alone .exe file). You won’t need to program a solution for every investigation, but you’ll be a better investigator if you know how to look under the hood.
Metadata Investigations All files contain metadata. Some of it may be brief, consisting of the filename, its extension, and its Modified/Accessed/Changed (MAC) times. Other file types contain more extensive metadata. Microsoft Office files often contain information about the author, organization, department, recipients, and so on, as do Portable Document Format (PDF) files. We’ve already seen that graphics files contain extra metadata that can indicate where and when a particular photograph was taken.
As with any information retrieved from a suspect machine, you need to cross-check information retrieved with other information from that same investigation. Phil Harvey’s exiftool software (www.sno.phy.queensu.ca/~phil/exiftool/) allows a user to modify image file metadata such as the date and time the photo was taken. Any discrepancies between the file metadata and the file system metadata will need to be understood and explained.
Restore points were introduced in Windows XP, and are an attempt by the OS to capture a snapshot of the state of the OS prior to installing new software. This facility has been updated in Vista and Windows 7 under the name volume shadow copy. Regardless of the name, both techniques will create a copy of files that may be changed during an update so that the update can be rolled back if necessary (such as when a new device driver is uploaded that causes the machine to not boot successfully). Other examples include backing up the Windows registry prior to removing incorrect or outdated information. A DFI can view the earlier version of a file that has been modified since the creation of the last restore point.
On occasion, a DFI may be asked to evaluate a claim that a particular system was infected by malware (Trojans, worms, viruses, adware, spyware, and so on). You will need to determine if there is any truth to that claim, and in order to make that determination, you will need to evaluate where there is any evidence of malware on that particular machine. This analysis may require that you make a copy of a running process to disk. The procdump(s) utility will do exactly that. The copy of the running program may not be exactly as the file would appear on disk since the malefactor often will use “packer” software—software that compresses (“packs”) the file. This is done in order to avoid antivirus or malware scanners that attempt to recognize malware based on its file signature (which, as you may have guessed already, is a hash of the file). True evildoers will use a known packer to pack a program that includes packed code that is password protected.
Static File Analysis A file on disk can be examined with all the tools we’ve mentioned previously as applicable to other file types. The strings(s) program or Bin-Text (http://www.mcafee.com/us/downloads/free-tools/bintext.aspx) can search for sequences of printable characters, the grep(w) program can search for patterns, or the file can be opened using a universal hex editor such as Win-Hex (www.winhex.com). More specialized tools such as PEview or Dependency Walker (www.dependencywalker.com) can list the contents of the header for the portable executables (PE) file, while Dependency Walker will show relationships between various .dll files. These last two programs and other similar programs are meant for the malware analyst. As a rule, a forensic analyst should consider running the file through an antivirus program or sending the file to the www.virustotal.com web site for analysis.
Dynamic File Analysis Dynamic file analysis requires that the suspicious code be run within a test environment so the DFI can observe its behavior. Two things to watch for are the network connections that are made and the access to files and the registry.
The Wireshark network protocol analyzer (www.Wireshark.org) is your best bet for capturing network traffic. The procmon(s) utility from the Sysinternals software suite is an excellent tool for observing runtime behavior on Windows: It captures all calls to the registry as well as opening and closing files. Lastly, running the program under the control of a debugger such as Ollydbg (www.ollydbg.de) or Immunity Debugger (www.immunityinc.com) or a disassembler like Ida Pro (www.hex-rays.com) provides an instruction-by-instruction look at exactly what the software is doing.
You should only run malware on systems that will wiped after the analysis, or on virtual machines. Virtual machine (VM) software such as Parallels, VMware, Microsoft Virtual PC, VirtualBox, or QEMU has excellent candidates for installing versions of various operating systems. Be aware, though, that some malware will behave differently when run in a virtual environment rather than on actual hardware. Once you’ve finished the analysis, forensically delete the files containing the VMs.
CAUTION Don’t run malware on your forensic production systems. Malware has been known to “escape from the lab,” and cleaning up the mess is neither fun nor quick.
One thing you can count on in a forensic investigation is human laziness. Given a choice, we’d rather have our computers take care of things rather than have to remember what to do. The other aspect of this is that most people won’t take the time to read the instructions. While there are ways to delete all of the data saved by a browser, most people won’t set it up that way. The same is probably true for “private browsing” that states any file retrieved or any history of the sites you visit won’t be recorded.
All browsers, unless instructed otherwise, will keep information around that will allow a user to return to a previous site, quickly, and without having to enter information again. This information includes the following:
• Cache The cache is used to store files downloaded as part of visiting a particular web page, usually graphic images displayed as part of the web page, or ancillary files that may be downloaded, such as video or audio. These data are cached to improve display performance—your browser doesn’t have to go back to the web server to retrieve these resources.
• Cookies Cookies are collections of name/value pairs that are stored for a particular web site. They can contain information that you’ve entered for a particular site (such as your login name, e-mail address, and so forth). When you access a web page, the server can request that these cookies be stored on your computer such that if you access the page again, the data stored by the server will be returned in that request.
• History Most browsers will gladly keep a history of web sites you’ve visited in the recent past. Since this history information is labeled with the time and date of access, the history list provides a time-ordered map of where the suspect has been on the Internet. This kind of history will be merged with other time-based events to create a timeline for analysis.
Logs, log, logs. Sometimes it feels that there are just too many log files to analyze. Windows (and many other operating systems) have system logs, generated by OS services and the OS itself, and application-specific log files. These logs may be stored in a single location (in Linux, it’s usually /var/log), by a centralized service (in Linux, it’s syslog or syslog-ng), or by individual applications.
The third primary source of information about Windows is the event logs. Event logs are generated either by the OS or by individual applications. If you have created a forensic image of the device’s persistent storage and you mount this as a particular file system, your software should be able to access these files directly, assuming that the disk hasn’t been encrypted, which presents a different problem. You can view system event logs under the registry key HKLM\System\CurrentControlSet\Services\Eventlog.
The location of the three Windows OS event logs varies depending on the version of the OS in use. In Windows XP, event logs can be found in the %SystemRoot%\System32\Config directory, and are named sysevt.evt, secevent.evt, and appevent.evt. Internally, the files consist of a header record, a floating trailer record, and a set of event records. In Windows 7, they are in %Systemroot%System32\winevt\Logs, and have an .evtx extension, since log file entries in Windows 7 are written in Extensible Markup Language (XML).
The content of these files will vary, depending on the version of Windows you’re running. In XP, the files are binary and consist of a header and a series of event records. The event records are treated as a circular buffer, which means that over time, older records are overwritten with newer records. The header record itself consists of 48 bytes that we can represent using the following C programming language structure. The label “uint32” means a 4-byte (32-bit) unsigned integer value that can store values from 0 through 4,294,967,295 inclusive.
In Vista and Windows 7, the event file is stored in XML format. In Windows 7, the log file extension is .evtx and the files are stored in %Systemroot%\system32\winevt\logs. You can examine the system event log using standard Windows system administration tools such as eventvwr.exe. Microsoft also provides software called logparser.exe(m), and if you’re an SQL wizard, this might be your tool of choice. If you’re not, then the Log Parser Lizard software provides a GUI interface for searching the event logs.
The three standard event logs are
• Application
• System
• Security
OS event log files can be found in the %Systemroot%\System32\Config directory, and are named sysevt.evt, secevent.evt, and appevent.evt. Internally, the files consist of a header record, a floating trailer record, and a set of event records.
Individual application logs can provide more detailed information about application behavior than is recorded in the Windows systems logs. Applications are free to create their own event logs. One location is under the %SystemRoot%\users\<username>\AppData file system hierarchy. Other applications, especially those that run as services, may store their log files under %SystemRoot%\ProgramData\<progname>. Among the many applications running on a Windows computer, three stand out for forensic investigations: the IIS server (Internet Information Server [web server]), the FTP server, and the system firewall logs. IIS and FTP are two services that allow data from the machine to be read (and written) remotely without a console login. In addition, the firewall log can provide information about traffic in and out of the computer: what was blocked and what was accepted. This information helps to build the case for local information that has been accessed by devices, or data that have been accessed or stored external to the device we’re analyzing.
If the firewall log indicates that the user directly connected to the Dropbox file storage service, then we can ask ourselves about what other information we should be seeing. Where’s the companion Dropbox folder on the machine? What are the MAC times of files contained within that folder? Do they match? If not, why not? And so forth.
IIS and FTP Server The IIS stores its log files in the %WinDir%\System32\Logfiles directory as a text file, although the location can be reconfigured. Files are stored using a naming convention of exyymmdd.log. The default options for storing this log are to have logging enabled and to use the W3C (World Wide Web Consortium) extended log file format. Each field in this record format is named such that you can determine whether the information pertains to the client, the server, or a communication between them. Names beginning with a “c” pertain to the client, “s” to the server, “cs” to client to server, and “sc” to server to client. Table 7-6 lists the fields in the IIS log and their descriptions.
Table 7-6 IIS Log Fields and Descriptions. (Source: W3C Extended Log File Format (IIS 6.0), http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/676400bc-8969-4aa7-851a-9319490a9bbb.mspx?mfr=true.)
Other fields in the log include bytes sent and received, duration of the action, protocol version (HTTP or FTP), the host name used, the user agent (browser) used to issue the request, the cookie sent or received, the referrer URL, and the protocol substatus error code.
The FTP server stores its logfile in %WinDir%\MSFTPSVC as ex<yymmdd>.log. The FTP server uses the same field names as the IIS server, with the exception of fields that don’t apply to the FTP service, such as cs-uri-query and the cookie sent or received.
DHCP Server and the Windows Firewall The DHCP (Dynamic Host Configuration Protocol) stores logs in the %SystemRoot%\System32\DHCP directory. If the Windows Firewall is running, logs for that service are stored in %SystemRoot%\System32\pfirewall.log and %SystemRoot%\System32\Wbem\Repository\FS\objects.data.
Figure 7-9 shows the beginning of a Windows Firewall log. Thanks to the helpful headers, we can determine that the time stamps in the file are based on machine local time. The first line of the file is that at 9:58:23 AM on November 26, 2013, TCP traffic from 192.168.1.147 on port 53645 was allowed to 192.168.1.20 port 445. Remaining fields are either zero or not set or available, and the PATH (the module processing the incoming packets) was RECEIVE.
Figure 7-9 List of the Windows Firewall log
EXAM TIP Know your log file format, since these logs can tell you a great deal about who, what, when, and where information was accessed.
Events stored in the OS event logs are one of three types: error, warning, or information. Events are stored with an event ID, and several event records signify information about the state of the machine that helps the DFI determine the timeline of events that occurred on that particular device. Consider the various programs that run as services on Windows (Linux users will recognize that as system daemons). Two significant events are4
• Event ID 7035 (a service has been requested to stop)
• Event ID 7036 (the service has stopped)
Account management events include
• Event ID 624 (an account has been created)
• Event ID 642 (an account has been modified)
• Event ID 612 (modifications were made to the audit policy)
Event IDs 560 (an object has been opened), 567 (object access attempted), and 562 (handle closed) indicate access to a particular object if auditing is enabled.
Another critical aspect for the forensic analyst is identifying who and when someone was logged onto the system. Several events provide data concerning logins:
• Event ID 4624 (successful logon)
• Event ID 4647 (user-initiated logoff; both logon and logoff events are correlated by logon ID)
• Event ID 4625 (logon failure)
The logon failure codes provide additional information for the forensic analyst. Table 4-7 presents the failure codes that are most interesting for the analyst since they indicate an abnormal condition.
Table 7-7 Interesting Login Failure Codes and Descriptions
Windows password storage is provided in the Security Account Manager (SAM) hive file in the %SystemRoot%\System32\Config directory. Passwords are not stored as cleartext; instead, various algorithms are used to create a hash code from the entered password. Algorithms for creating the password hash include the Lanman (LM) hash function (still in use, primarily for backward compatibility) and the NT Lanman (NTLM) hash that repairs several security flaws with the LM password. Systems that are members of a domain will use Kerberos authentication. The RegRipper tool provides a specific profile for accessing SAM information.
We’ve already talked about a number of tools that are provided either as part of a standard Windows OS distribution or as a suite of third-party tools. We’ll look further at several integrated forensic tools suites in Chapter 8. The OSForensics software straddles the line between a tool suite and a more full-featured forensic suite.
Frequently, alternatives exist for performing a particular type of analysis. As an example, consider the different tools available for searching the event logs. If we don’t have anything else available, the standard Windows event viewer supports searching for particular events. The DFI will turn to the Windows system event logs for more general analysis. You can access these logs via the command C:\Windows\System\eventvwr.exe, or click the Event Viewer entry under the Administrator menu. Where this entry is located will vary based on your OS; on my Windows 7 machine, it’s in the Start menu under All Programs | Administrator Tools.
As is the case with other kinds of treasure, just because you know where it is, this doesn’t mean that you won’t have to work to get it.
Figure 7-10 shows the dialog box for searching the system event log for all error events.
Figure 7-10 Searching with Windows Event Viewer
The Windows LogParser.exe software is a command-line tool that enables the user to search multiple log formats using an SQL-like syntax. The command
LogParser "Select * from System where EventTypeName = 'Error Event'"
would list all error events from the System event log. The Log Parser Lizard software (www.lizard-labs.net) provides a powerful GUI front end to this program. Figure 7-11 shows the results for the aforementioned command when using this tool.
Figure 7-11 Log Parser Lizard GUI for the Windows event logs
In this section, we will examine the various techniques and tools used when cracking passwords. A “password cracker” (usually abbreviated to “cracker” versus “hacker”) is someone who specializes in extracting and decoding passwords from applications or operating systems. A software program used to extract and decode these passwords can be called a “password cracker” as well, although context should distinguish between the two. The goal of this software is to retrieve the plain text password (“plain”) from its encrypted form by effectively “guessing” the password or by using all possible combinations of characters entered from a computer keyboard (called “brute forcing” the password).
A DFI becomes a password cracker at certain stages in an investigation. One stage could be booting up a machine where the BIOS has been password protected, or attempting to log in as an administrator or other privileged user. The BIOS password can be defeated by removing the battery that provides power to the system when the device itself is powered off. About half an hour later, you should be able to replace the battery and power up the device such that you can access the BIOS, and the password should be blank. If you’re attempting to log on to a device as an administrator, you can use a special boot disk called a rescue disk to modify passwords on the subject disk in order to log in. On such disk is the “ntpasswd” disk that can change the administrator password on a Windows OS. This disk boots up a live Linux distribution that contains a program that will search out the password file on the subject disk and set the administrator password to blank (meaning no password). Restart the subject machine and log in as an administrator with no password. Done and dusted.
CAUTION While powering on a device and attempting to log in is certainly possible, you know by now that this is a bad idea because of potential changes to the underlying system as part of the initial boot sequence. Weigh the consequences of losing data against having no data at all.
You may encounter files that have been encrypted individually (Microsoft Office documents, .pdf files, .zip files, and other applications all allow a file to be encrypted and password protected). No password, no decryption. No decryption, no probative evidence.
TIP Many forensic tools will generate a wordlist of all words found on a particular disk image. Try this as your dictionary to guess a password.
Before we begin, let’s establish some terminology. The set of characters from which the password is created is called the “alphabet.” The larger the alphabet, the more passwords we can generate of length N (the “keyspace”). For example, if we have the lowercase characters “abcde” in our alphabet and I limit the length of the password to two characters, then we have 25 possibilities (5 * 5)—so few, in fact, that you could imagine cracking the password by simply entering all the possibilities until you find the right one. This technique is called “brute forcing,” and is guaranteed to work, given world enough and time.
The time needed to examine all the possible candidates depends on the length of the password and the “alphabet” from which we choose each character. If we use only the printing characters on a computer keyboard, we have 26 uppercase characters, 26 lowercase characters, 10 numeric characters, and 33 punctuation characters, for a choice of 26 + 26 + 10 + 32 = 95 possible characters. If we allow control characters (CTRL key + an alphabetic characters), we add another 26 characters to the mix (CTRL -A through CTRL -Z). Assuming that each character is equally probable, all two-character printing sequences are 95 * 95 = 952 = 9,025 possibilities. Three-character strings result in 857,375 possibilities, and six-character strings result in 735,091,890,625 possibilities. If you could guess 1 million passwords per second, it would take 735,091 seconds, or roughly 8.5 days, to brute force this password; 1,000 guesses per second would require 23+ years.
Standard password advice is a combination of do’s and don’ts.5 When creating a password, don’t
• Use words from a dictionary. Any dictionary.
• Use personal information (family members, birthdays, favorite sports teams, and so on).
• Use a small alphabet (for example, all lowercase letters and numbers).
• Use passwords shorter than 8 characters.
Conversely, when you create a password, do make sure that you
• Change the password frequently.
• Use one password in one place only.
• Use a phrase that you can remember, and then use a system of replacing letters with numbers and symbols. As an example: “Mary had a little lamb / its fleece was white as snow” might become “Mh@ll/1fw**@5”—13 characters long, upper-/lowercase alphabetic, numbers, and printable symbols. Looks promising, doesn’t it? Read on.
NOTE Remember that your password has to be chosen randomly. The problem with “Mary had a little lamb…” is that it follows an algorithm for replacing characters as well as dictionary words and is a phrase from a well-known nursery rhyme in North America and the United Kingdom.
Longer is better—the more characters in your password, the more time it would take to crack. The best way to choose a password is to use a generator. Figure 7-12 shows the generation dialog box from the 1Password program. In addition to specifying the length of the password and the alphabet, you can specify whether to duplicate characters and not to use characters that can be mistaken one for another. My personal favorites are “0” and “O” and “l” and “1”: In many cases, the font chosen will represent these characters such that they aren’t distinguishable to the human eye—at least not to this human’s eye.
Figure 7-12 Password generation dialog from 1Password
Password-cracking software can be designated as either system software or application software. The examples we’ve shown so far have been system software, as it’s aimed at deriving the passwords for system applications (such as the logon applications). Application software is meant for particular applications. The major components of Microsoft Office (Word, Excel, and PowerPoint) all have individual programs aimed at retrieving the password from files created by those applications. Other tools are available to look up passwords for web browsers: the NirSoft utilities include ChromePass(n), IE Passview(n), and PasswordFox(n).
Password-cracking types generally are considered either online or offline and active or passive. Passive online attacks include extracting passwords from network communications (aka “sniffing the wire”) or by initiating a “man in the middle” (MiTM) attack, grabbing a hash, and then initiating a replay attack. Passive offline attacks include using some form of malware to intercept the separate characters from the user’s password by capturing the password, or starting the real program, or using a keystroke logger.
Active online attacks include attempting to guess a password via automated login attempts, such as to a web site. Hash injection attacks involve an attacker gaining access to a user’s device and extracting the password hash in order to impersonate the user. In the case of active online attacks, passwords are extracted from network communication or by directing the victim to a site that is impersonating a real web site in order for the victim to enter their credentials. In all cases, our goal is to obtain either the password itself or an encrypted value of the password. At this point, most direct attacks at online services are foiled because of account lockout features. As a defender, increasing the “work factor” (the amount of time an adversary has to spend compromising your device) is a good deterrent. The longer it takes, the greater the chance that someone will notice the attack.
The various password-cracking methods that we’ll discuss here are all methods that apply to offline attacks, with the exception of the “educated guess.” Given that, most login accounts will enforce a timeout after a certain number of bad entries, or possibly destroy the data on the device itself in the case of certain smart phones.
A guess isn’t usually a series of random words or characters. Instead, educated guessing is using passwords that utilize information about a specific individual (family, friends, hobbies, religious affiliation, favorite movies or books, and so on). In addition, these words will be transformed in regular ways based on research indicating that many people modify their passwords in particular ways, including capitalizing the first letter and ending the passphrase with a punctuation symbol.
A dictionary attack will try a set of words from a dictionary or wordlist. Dictionaries are available for multiple languages, and you can obtain lists of passwords of users who have been part of a logged-in community. There are multiple variations on a dictionary attack. These include a hybrid attack where the attackers use dictionary words with other characters either appended or prepended (passwords that consist of a word plus a “!” character are quite popular). Similar to this is the syllable attack that combines brute force and dictionary attacks. Instead of the whole word, the attacker combines syllables to create nondictionary words (think “psydood”).
TIP Many forensic tools will generate a wordlist of all words found on a particular disk image. Try this as your dictionary to guess a password.
The most basic attack is the brute force attack. Here, the attacker tries to derive a password by creating strings of all possible characters. Given world enough and time, brute force will always find a password (on the average, this will take 50 percent of the time required to guess all the passwords).
As Bruce Schneier once said, attacks against cryptography just keep getting better, never worse. So it is with password cracking. Ars Technica (www.arstechnica.com) ran a series of articles during 2013 that clearly demonstrated recent advances in password cracking. Using GPUs (graphics processing units—like CPUs but part of the graphics hardware) markedly increases the number of tries per second. “A PC running a single AMD Radeon HD7970 GPU, for instance, can try on average an astounding 8.2 billion password combinations each second, depending on the algorithm used to scramble them.”6 A major source of new information is a security breach where user names and password hashes are downloaded. Aside from impersonating a legitimate user, these password lists provide a treasure trove of actual password usage “in the wild.” A professional cracker will add these passwords to their dictionaries to use in future password-cracking attempts. Astute password crackers are now entering phrases from Wikipedia and the Bible: One researcher was able to crack the password “Ph’nglui mglw’nafh Cthulhu R’lyeh wgah’nagl fhtagn1” because it had appeared in a Wikipedia article.7
Rule-based attacks are used when a particular set of constraints is known. For example, some systems provide rules for passwords that look like this: The password must be at least eight characters long; have at least one uppercase character, one number, and one special character (what we’ve listed as “printable” previously); and cannot be a word found in the dictionary. Given this information, a cracker can program these into a rule that will only select strings that match these criteria.
Finally, rainbow tables are special files that contain starting and ending values of a chain (sequence) of a particular length. The chain is produced by alternating a particular hash function (say, MD5) with a reduction function that can generate a new (plain text) password given a hash value. If we want to derive the plain text password given its hash value, we apply the reduction function and see if the result is in one of our end points. If so, we start at the beginning of the chain and alternate applying hash and reduction functions until we find the plain text that creates our initial hash. This technique allows us to store and recompute hash chains that can reflect all possible passwords given a particular alphabet (such as all lowercase letters). By precomputing our hash chains and by saving only the starting and ending plain text values, we trade off storage space for computation time. This doesn’t mean that rainbow tables are small: Collections of rainbow table files can easily exceed 1TB of storage.
Social engineering occurs when a victim somehow is convinced to reveal their password. Good social engineers understand what motivates people to reveal information (such as helping someone in trouble, or baser instincts like the love of chocolate), and are experts at working their confidence games. After all, why waste time trying to brute force an eight-character password when a well-chosen tale of hard luck and desperation might extract the password much more quickly?
The online version of this game is the “phishing” e-mail that announces a bank account has been blocked and you should really log in to the bank’s web site using the URL provided. If you do access that site, it will look remarkably like the real bank’s web site (it should—most of the data have been downloaded from the actual site), including the dialog box where you’re asked for your login information (user name and password). Enter your credentials here, and you will find yourself redirected to the actual web site. It will ask you to re-enter your credentials, which is a little surprising, but you assume that you mistyped something, and all goes smoothly after that, until the day you discover that your account balance is now $0. “Spear phishing” is when a high-value executive is made a target—often, high-level executives have a great deal of privilege regarding what information they can access.
Many vendors ship products with a default password. The Internet is littered with lists of particular vendors and the default passwords for their products. For many reasons (most including human laziness and ease of use), the default passwords are never changed, although some vendors require that you change the default password when installing their software products.
TIP When encountering a new device that is password protected, look to see if that make and model is contained in a default password list. Try that one first. You may be pleasantly surprised.
Some of the classic password-cracking tools are still available. Among them are Cain and Abel (www.oxid.it/cain.html) and Ettercap (www.ettercap.github.io/ettercap) that are used for capturing passwords from the network. John the Ripper (www.openwall.com/john) and L0phtcrack6 (www.l0phtcrack.com) are offline tools. Figure 7-13 illustrates the Cain UI. In this case, we see the password listed between a Dropbox client and the Dropbox server.
Figure 7-13 Cain UI displaying captured password
A major password-cracking tool currently in use is hashcat (www.hashcat.net/hashcat). This software supports over 80 different hashing algorithms and five attack modes (straight, combination, toggle case, brute force, permutation, and table lookup), the first two of which can support external rules. Figure 7-14 illustrates the hashcat-gui front end to the tool.8
Figure 7-14 Hashcat-gui showing parameter settings
Conducting a forensic analysis on a computer running a Windows OS is a matter of knowing where to look for the information you need to place the suspect at the keyboard. Volatile information can only be captured if the machine is already running by using various software tools to extract that information, or by creating a memory dump file and using other offline tools to analyze that file later. Nonvolatile (persistent) information can be captured while the machine is still running, or from the forensic image you create as part of your initial search and seizure. Event logs (both system and application) and the Windows registry provide nonvolatile information that can help you identify a suspect’s actions prior to the seizure of the device.
Password hashes are stored in the SAM hive in the %systemroot%\system32\config directory. Passwords can be computed using the obsolete LM function, NTLMv1 or NTLMv2, or via MD4. Passwords for web sites are stored either in a Windows-protected area or in database files maintained by individual browsers.
Password cracking is the attempt to determine the password used by a particular application or to log on to a device. Online attacks against passwords may involve repeated login attempts or using software tools to extract the hashed password from the network traffic. Offline attacks attempt to crack the password when provided with the hashed version of the password. It’s becoming much easier to crack a password given the increases in computing power (using GPUs in parallel to increase the number of candidate searches). Also, crackers have become more proficient in generating dictionaries. Combine the two, and even the seemingly best passwords may fail in time.
1. Dumping a copy of memory saves what kind of information?
A. Volatile
B. Nonvolatile
C. Historical
D. Snapshot
2. Where would a forensic analyst look for web sites that were previously accessed? Choose all that apply.
A. Registry
B. Shared cookie
C. Page cache
D. Browsing history
3. Where are Internet Explorer saved passwords stored?
A. The Windows protected area
B. IEPasswd.dat
C. NTuser.dat
D. The HKEY_CURRENT_USER registry key
4. Microsoft’s log parser software uses which language to query the registry?
A. Perl
B. Python
C. SQL
D. PowerShell
5. Which of the following tools can be used to dump memory for a particular process?
A. DumpIt
B. Procdump
C. Procmon
D. MemDump
6. Which files contain metadata beyond file size, filename, modified times, and so forth? Choose all that apply.
A. EXE files
B. JPEG files
C. Microsoft Office files
D. PDF files
7. What can an analyst use to view previous versions of a file? Choose all that apply.
A. Windows restore points
B. Recycle Bin
C. The HKEY_CURRENT_USER\…\FileVersions registry key
D. Windows backup volumes
8. True or false: The MD5 algorithm is used to compress file data.
A. True
B. False
9. Which tool allows the analyst to view all registry and file system access?
A. Procexp
B. Procmon
C. ListDLLs
D. ProcViewer
10. What is the purpose of establishing a timeline of activity?
A. Correlate suspect’s activities with external activities
B. Identify possible network activity
C. Track failed logins
D. Identify gaps in use of the device
11. What is the term for targeted e-mail or social engineering attacks against a high-value target?
A. Whaling
B. Tagging
C. Spear phishing
D. Frack attack
12. Given a hash value, a password cracker tries to derive the _____ password.
A. Cryptotext
B. MD4
C. NTLMv2
D. Plain text
13. Hash injection attacks occur when _____.
A. Hashed passwords are replaced in network traffic
B. Hashed passwords are modified, thereby denying service
C. Hashed passwords from previous logins are used to impersonate another user
D. Hashed passwords are passed in carrier files
14. This form of password cracking uses precomputed tables with hash chains to derive all possible passwords for a given alphabet.
A. Rainbow tables
B. Dictionaries
C. Brute force
D. Intelligent guessing
15. Using _________ allows a password cracker to look up the hash of a password in a list of passwords and their associated hashes.
A. Rainbow tables
B. Dictionaries
C. Brute force
D. Intelligent guessing
1. A. Volatile.
2. A, D. Registry and browsing history.
3. A. Windows protected area.
4. C. SQL.
5. A. DumpIt.
6. A, B, C, D. All these file types contain extra metadata.
7. A. Windows restore points.
8. B. False.
9. B. Procmon.
10. A. Correlate suspect’s activities with external activities.
11. C. Spear phishing.
12. D. Plain text passwords.
13. C. Hashed passwords from prior logins are used to impersonate that user.
14. A. Rainbow tables.
15. B. Dictionaries.
1. EC-Council. “Windows Forensics I”, Computer Forensics: Investigating Hard Disks, File and Operating Systems, (MA: Cengage Learning, 2009), pp. 4:2.
2. Nair, S. Live Response Using PowerShell 2 (MA: SANS, 2011), pp. 10–11.
3. “The Volatility Framework.” Retrieved from www.google.com/p/volatility.
4. EC-Council. “Windows Forensics II,” Computer Forensics: Investigating Hard Disks, File and Operating System (MA: Cengage Learning, 2009) pp. 5:8-5:9.
5. EC-Council. Computer Forensics: Investigating Hard Disks, File and Operating Systems (MA: Course Technology, 2010), pp. 7–28.
6. Goodin, D. “Why Passwords Have Never Been Weaker—and Crackers Have Never Been Stronger” (Ars Technica, 8/20/2012). Retrieved from http://arstechnica.com/security/2012/08/passwords-under-assault/.
7. Goodin, D. “How the Bible and YouTube Are Fueling the Next Frontier of Password Cracking” (Ars Technica, 10/8/2013). Retrieved from http://arstechnica.com/security/2013/10/how-the-bible-and-youtube-are-fueling-the-next-frontier-of-password-cracking/.
8. Retrieved from Hashcat.org/hashcat-gui.