In a Windows system what directory contains drivers logs and registry files

System and Network Auditing

System and network security event logs are a keystone for managing the ongoing security of any system. In a cloud, audit events will be generated in fundamentally different trust zones; these range from highly secured network and security components to systems where the CSP grants significant control to tenants or users. Thus, security events should be recognized as having different degrees of integrity. The following are key requirements for the generation and management of audit events:

Auditing is required for all operational systems, from infrastructure system and network components up to but not necessarily including customer VMs. Tenant confidentiality agreements along with service contracts may set the boundary for what data can be collected within a tenant VM, and in many cases tenant virtual networks.

All security-relevant events must be recorded with all relevant information that is necessary to analyze the event; this shall include the correct time, resolvable system, and user IDs and appropriate event codes and supporting information.

Generated audit events must be logged in a near-real-time manner. The correct operation of auditing and logging shall be verified on an ongoing basis using means such as heartbeat or call-and-respond.

All audit events and logs shall be continually and centrally collected to ensure their integrity and to support timely alerting and monitoring.

All audit events and logs shall be retained and securely archived for at least as long as the security policy requires, preferably indefinitely to support retroactive long-term analysis to either support legal action or to improve security and security monitoring.

As necessary to support the validated legal or operational needs of tenants or customers, audit records will be sanitized to allow sharing with tenants and customers—either as a part of a security service or as needed.

Controls must be implemented to protect the confidentiality, integrity, and availability of audit events, audit log collection, log centralization, archiving, processing, and reporting.

NIST Common Criteria

By enabling the Windows Firewall to log audit events to the Security event log along with the default firewall log. The Windows Firewall in Windows XP SP2 and Windows Server 2003 SP1 keeps firewall log information in two locations:

%windir%\Pfirewall. log

Security event log

The problems with this scenario are that it is difficult to troubleshoot Windows Firewall connectivity issues, and you are not compliant with the Common Criteria. The Common Criteria state that all security auditing needs to be comprehensive and contain all security-oriented events. They also mandate that if auditing cannot be performed, the system fails. For example, if the audit log becomes full—a condition known as CrashOnAuditFail—the Pfirewall.log file doesn’t satisfy these two criteria. On the other hand, the Windows Security event log does. Therefore, all logging of both filtering and policy happens in the Security event log, complying with the Common Criteria requirements, which makes it easier for enterprises in the government, healthcare, and financial industry sectors.

Note

Windows Vista allows administrators to continue using Pfirewall.log, although it is now stored in %windir%\system32\LogFiles\Firewall\Pfirewall.log.

Examine Logs

☑ Look in all available log files on the compromised system for traces of malicious execution and associated activities such as creation of a new service.

► Log files can provide some of the most useful historical detail relating to a malware incident, giving visibility into past events, the sequence of activities related to an attack, and clues about what the intruder did on the compromised system. The logs that are available on a Windows system will depend on its configuration and installed programs. Some of the more common log files are summarized here with examples of their usefulness.

•

Windows Event Logs: Logon events recorded in the security event log, including logons via the network, Remote Desktop, and Remote Authentication Services, can reveal that malware or an intruder gained access to a compromised system via a given account at a specific time. Other events around the time of a malware infection can be captured in Windows Event logs, including the creation of a new service or new accounts around the time of an incident. Windows Event logs can be examined using tools such as Log Parser8 and Event Log Explorer9 as shown in Figure 3.8 with the ability to filter on specific types of events. Additional information about Log Parser and its flexibility is available in Microsoft Log Parser Toolkit from Syngress.10

Web browser history: The records of Web browsing history on a compromised computer can reveal access to malicious Web sites and subsequent download of malware. In addition, some malware leaves traces in the Web browser history when it spreads to other machines on the network.

Desktop firewall logs: Windows firewall and other desktop security programs may be configured to record access attempts and other activities on the compromised system.

AntiVirus logs: When a Windows system is compromised, AntiVirus software may detect and even block malicious activities. Such events will be recorded in a proprietary log file with associated date-time stamps, and any quarantined items may still be stored by the AntiVirus software in a holding area.

Dr. Watson: The Dr. Watson log, located in “Drwtsn32.log,” can contain information about programs that crashed and produced debug information. When Dr. Watson traps a crashing program, it can create a file named “User.dmp” containing memory contents from the crash, which may provide additional information.

Overview of Enterprise Networks

Digital investigators must be sufficiently familiar with network components found in a typical organization to identify, preserve, and interpret the key sources of digital evidence in an Enterprise. This chapter concentrates on digital evidence associated with routers, firewalls, authentication servers, network sniffers, Virtual Private Networks (VPNs), and Intrusion Detection Systems (IDS). This section provides an overview of how logs from these various components of an Enterprise network can be useful in an investigation. Consider the simplified scenario in Figure 9.1 involving a secure server that is being misused in some way.

Logs generated by network security devices like firewalls and IDSs can be a valuable source of data in a network investigation. Access attempts blocked by a firewall or malicious activities detected by an IDS may be the first indication of a problem, alarming system administrators enough to report the activity to digital investigators. As discussed in Chapter 4, “Intrusion Investigation,” configuring firewalls to record successful access as well as denied connection attempts gives digital investigators more information about how the system was accessed and possibly misused. By design, IDS devices only record events of interest, including known attack signatures like buffer overflows and potentially malicious activities like shell code execution. However, some IDSs can be configured to capture the full contents of network traffic associated with a particular event, enabling digital forensic analysts to recover valuable details like the commands that were executed, files that were taken, and the malicious payload that was uploaded as demonstrated later in this chapter.

Routers form the core of any large network, directing packets to their destinations. As discussed in the NetFlow section later in this chapter, routers can be configured to log summary information about every network connection that passes through them, providing a bird's eye view of activities on a network. For example, suppose you find a keylogger on a Windows server and you can determine when the program was installed. Examining the NetFlow logs relating to the compromised server for the time of interest can reveal the remote IP address used to download the keylogger. Furthermore, NetFlow logs could be searched for that remote IP address to determine which other systems in the Enterprise were accessed and may also contain the keylogger. As more organizations and ISPs collect NetFlow records from internal routers as well as those at their Internet borders, digital investigators will find it easier to reconstruct what occurred in a particular case.

Digital investigators may be able to obtain full network traffic captures, which are sometimes referred to as logging or packet capture, but are less like a log of activities than like a complete videotape of them—recorded network traffic is live, complete, and compelling. Replaying an individual's online activities as recorded in a full packet capture can give an otherwise intangible sequence of events a very tangible feel.

Authentication servers form the heart of most enterprise environments, associating activities with particular virtual identities. Logs from RADIUS and TACACS servers, as well as Windows Security Event logs on Domain Controllers, can help digital investigators attribute activities to a particular user account, which may lead us to the person responsible.

Practitioner's Tip: Virtual Identities

Because user accounts may be shared or stolen, it is not safe to assume that the owner of the user account is the culprit. Therefore, you are never going to identify a physical, flesh-and-blood individual from information logs. The universe of digital forensics deals with virtual identities only. You can never truly say that John Smith logged in at 9:00 am, only that John Smith's account was authenticated at 9:00 am. It is common, when pursuing an investigation, to conflate the physical people with the virtual identities in your mind and in casual speech with colleagues. Be careful. When you are presenting your findings or even when evaluating them for your own purposes, remember that your evidence trail will stop and start at the keyboard, not at the fingers on the keys. Even if you have digital images from a camera, the image may be consistent with the appearance of a particular individual, but as a digital investigator you cannot take your conclusions any farther.

As discussed later in this chapter, VPNs are often configured to authenticate via RADIUS or Active Directory, enabling digital investigators to determine which account was used to connect. In addition, VPNs generally record the remote IP address of the computer being used to connect into the network, as well as the internal IP address assigned by the VPN to create a virtual presence on the enterprise network. These VPN logs are often critical for attributing events of concern within an organization to a particular user account and remote computer.

Practitioner's Tip: Tracking Down Computers within a Network

When a computer is connected to a network it needs to know several things before it can communicate with a remote server: its own IP address, the IP address of its default router, the MAC address of its default router, and the IP address of the remote server. Many networks use the Dynamic Host Configuration Protocol (DHCP) to assign IP addresses to computers. When a networked system that uses DHCP is booted, it sends its MAC address to the DHCP server as a part of its request for an IP address. Depending on its configuration, the server will either assign a random IP address or a specific address that has been set aside for the MAC address in question. In any event, DHCP servers maintain a table of the IP addresses currently assigned.

DHCP servers can retain logs to enable digital investigators to determine which computer was assigned an IP address during a time of interest, and potentially the associated user account. For instance, the DHCP lease in Table 9.1 shows that the computer with hardware address 00:e0:98:82:4c:6b was assigned IP address 192.168.43.12 starting at 20:44 on April 1, 2001 (the date format is weekday yyy/mm/dd hh:mm:ss where 0 is Sunday).

Table 9.1. DHCP Lease

lease 192.168.43.12 {

starts 0 2001/04/01 20:44:03;

ends 1 2001/04/02 00:44:03;

hardware ethernet 00:e0:98:82:4c:6b;

uid 01:00:e0:98:82:4c:6b;

client-hostname "oisin";

}

Some DHCP servers can be configured to keep an archive of IP address assignments, but this practice is far from universal. Unless you are certain that archives are maintained, assume that the DHCP history is volatile and collect it as quickly as possible.

A DHCP lease does not guarantee that a particular computer was using an IP address at a given time. An individual could configure another computer with this same IP address at the same time, accidentally conflicting with the DHCP assignment or purposefully masquerading as the computer that originally was assigned this IP address via DHCP. The bright side is that such a conflict is often detected and leaves log records on the systems involved.

The same general process occurs when an individual connects to an Internet Service Provider (ISP) via a modem. Some ISPs record the originating phone number in addition to the IP address assigned, thus enabling investigators to track connections back to a particular phone line in a house or other building.

Obtaining additional information about systems on the Internet is beyond the scope of this chapter. See Nikkel (2006) for a detailed methodology on documenting Internet name registry entries, Domain name records, and other information relating to remote systems.

Collecting Intelligence about Botnets or Virus-Infected Systems

Using virtualization to execute the code on a suspected bot client or virus-infected system permits the investigator to gather valuable insights about the workings of malicious code. From the security event log you can see any attempts to guess passwords using brute force. You also find the identity of other bot clients that are involved in the brute force attacks. Using the firewall logs you see any inbound-opens that have been attempted. You can learn the identity of websites that delivered malicious code by looking at the firewall logs around the time of the malware detection. Watching network traffic from the suspect computer, you can identify ports opened by malicious code and the ip addresses of other parts of the botnet. These other parts of the botnet may be providing malicious code, such as retroviruses, to kill off your anti-virus protection, or lists of email addresses and spam templates. If the bot client uses Internet Relay Chat (IRC) you may find the Command and Control server, nick, userid, and password. You can then use this information to detect other infected computers in your organization and prevent future communications with the mother ship.

Locating the actual malware is a primary goal of a forensic examination of a bot client or virus-infected computer. Chapter 6, “Malware Analysis,” describes the process of running code samples in a sandbox to perform malware analysis.

Relational Analysis

A simple example of relational analysis relates to trust relationships between a compromised system and other systems on the network. For instance, some malware spreads to computers with shared accounts or targets systems that are listed in the “system32\drivers\etc\lmhosts” file on the compromised Windows system. Alternately, an examination of mounted network shares may reveal that a user on the compromised machine inadvertently clicked on malware that was stored on a file server. In such cases, discovering such relationships between the compromised system and other computers on the network may lead digital investigators to other compromised systems and additional useful evidence.

Another common and effective use of relational analysis arises when a worm spreads across a network and there are network-level logs that record the incident. Other infected hosts can be located by searching network logs for the Internet Protocol (IP) address that connected to the compromised computer at the time of infection.

Case Scenario

“Worm Sign in Windows Event Logs”

A worm infected several workstations on an internal network via NetBIOS, and digital investigators want to determine its origin. Unfortunately, there is no network-level logging on the internal network, making it difficult to determine which hosts were involved. However, using Windows Event Logs on compromised systems, it was possible to determine when and where a worm propagated. When a worm spreads via NetBIOS, information in the Security Event logs on a compromised computer can show which computer and user account the worm came from. The sample log entry in Figure 4.5 shows the name of the computer (“WKSTN-EG265”) and the username (“otoor”) that was attempting to logon to the compromised system immediately prior to the worm infection.

Figure 4.5. Event Log Entry Shows Workstation Name

Searching the logs of all computers on the network for this computer name and username could lead to other compromised systems. In some instances, the IP address of the remote computer is also recorded in the Security Event log or other logs related to the failure of a service, providing digital investigators with another piece of information to determine the source and scope of the malware incident.

Other Tools to Consider

Logparser Microsoft tool for examining various log formats, including NT Event logs

Sawmill Log analysis tool that facilitates searching and drill down of various log formats, including NT Event Logs (www.sawmill.net)

Splunk A format-independent log analysis and correlation tool that interprets log data dynamically, providing indexing and categorization to provide flexible searching and correlation of logs from any source (www.splunk.com)

Logger.pl Script specifically for examining Security Event logs and identifying patterns (http://pantheon.yale.edu/~kjh27/logger.html).

Another form of relational analysis involves looking for commonality or interactions between the malware and other objects on the compromised computer. In the simplest case, the folder where the malware resides may contain additional pieces of malware or associated log files. Alternately, the file system permissions or flags set on a piece of malware may be distinctive enough to be useful for finding other files with the same settings. As an example, Windows can assign “ownership” of a file to a particular user account. If this account is not in widespread use on the system, a digital investigator could look for other files that are assigned the same user account.

In some cases, malware is programmed to download additional components or create files on a compromised system. For instance, one bot generated a “.reg” file to reconfigure the system, and used a simple batch script to load these changes into the Registry (e.g., W32.Spybot.ANDM).

Once the components that relate to a piece of malware have been identified, digital investigators can look for them on the compromised system and in network traffic. In one case, the malware was programmed to connect out to a server periodically, and it maintained a log of these connections. Once this log file was discovered on one system, digital investigators were able to locate other compromised systems in two ways: 1) searching network-level logs for all connections to the remote server, and 2) looking for the presence of this log on computers.

Publisher Summary

This chapter demonstrates the value of preserving volatile data, and provides practical guidance for preserving such data in a forensically sound manner. The value of volatile data is not limited to process memory associated with Malware, and includes passwords, Internet Protocol (IP) addresses, Security Event Log entries, and other contextual details that can provide a more complete understanding of the Malware and its use on a system. In a powered-up state, a subject system contains critical ephemeral information that reveals the state of the system. This volatile data is sometimes referred to as stateful information. Incident response forensics, or live response, is the process of acquiring the stateful information from the subject system while it remains powered on. The Order of Volatility is considered when collecting data from a live system to ensure that critical system data is acquired before it is lost or the system is powered down. The chapter provides methodology for preserving volatile data on a Windows system during a Malware incident, and uses case scenarios to demonstrate the collection process as well as the strengths and shortcoming of the data acquired in the process.

Event Logs

Windows systems are capable of recording a number of different events in the Event Log, depending on the audit configuration (we will discuss in Chapter 5 how to determine the audit configuration). The Event Log files on Windows 2000, XP, and 2003 systems are made up of event records that are stored in a well-documented binary format (found at http://msdn.microsoft.com/en-us/library/aa363646(v=VS.85).aspx). Part of this format includes a “magic number” that is unique to individual event records (including the header record, which contains information about the Event Log file itself), as illustrated in Figure 4.2.

As illustrated in Figure 4.2, the “LfLe” “magic number” can be used to identify event records within the Event Log file. The 4 bytes immediately prior to the event record (0xE0 in Figure 4.2) tell us the size of the event record in bytes. This information is not only useful in parsing through the Event Log file on a binary level, extracting each record in turn (and writing tools to help us do this), but it can also be used to extract event records from relatively unstructured data, such as unallocated space (or the page file), which will be described later in this section.

Many analysts have discovered that when extracting Event Log files from an acquired image and opening them in the Event Viewer on the their analysis system, they will often encounter a message stating that the Event Log is “corrupt.” This is usually not due to the Event Log files actually being corrupted, but instead is often due to the fact that some message dynamic linked library (DLL) files may not be available on the analysis system. As such, I’ve written several tools to assist me with collecting information pertinent to my analysis from Event Log files. The first is the Perl script “evtrpt.pl,” which collects information about the event records, such as the frequency of events based on event sources and identifiers (IDs), an excerpt of which, from an Application Event Log, appears as follows:

SourceEvent IDCount----------------------SecurityCenter18002SecurityCenter1807192Symantec AntiVirus1217Symantec AntiVirus1417Symantec AntiVirus1612Symantec AntiVirus533

This information is a quick way to determine the type and number of the various event records within the Event Log, based on event sources and IDs. This is a great way of providing an overview of the Event Log content, and whether or not I can expect to find any records of value to my analysis. Having this information available has let me see some things very quickly. For example, if I’m working a malware issue and see that there are several event records with the source “Symantec AntiVirus,” I know that the system had the application installed at one point, and that can help guide my analysis. In particular, if I opt (as part of my malware detection process, something we will discuss in Chapter 6) to mount the image as a volume and scan it with an AV product, I know not to use the product that was installed on the system. Similarly, while I most often start my analysis of the Event Logs by looking at what is actually being audited via the audit policy, there have been times when, although logins are being audited, the system has been running for so long that no one has needed to log into it. As such, I have found Security Event Logs with no login events available in the visible event records.

“Evtrpt.pl” also provides the date range of all of the event records within the file, as follows:

Date Range (UTC)

Thu Jan 18 12:41:04 2007 to Thu Feb 7 13:39:25 2008

The date range information can be very useful, as well. There have been times when I’ve been asked to provide information regarding which user was logged into the system on a certain date or within a specific timeframe. Evtrpt.pl provides me with a quick view into whether or not digging deeper into the Event Logs is of value, or perhaps I should decrease the priority of the logs as a source of information and focus my analysis on more profitable targets.

Note

AV Logs

Most antivirus (AV) products produce some sort of logs; many produce text-based logs that are easy to view and parse, particularly if you load them into Excel. Many AV products will also write their logs to the Application Event Log, but for some, this can also be a configurable option. I have analyzed systems on which I have easily located the AV application logs, but have not seen any corresponding entries in the Application Event Log.

Another tool that I like to use for parsing Event Log records is the Perl script “evtparse.pl.” This Perl script reads through the Event Log files on a binary level, locating and parsing the records without using any of the native Windows API functions. This has a couple of benefits; one is that you don’t have to worry about the Event Log file being deemed “corrupted,” as will sometimes occur when using tools (such as the Windows Event Viewer) that rely on native Windows application programming interface (API) functions. The other is that the Perl script is platform-independent; it can be used on Windows, Linux, and even Mac OS X. The script is capable of parsing event records into either CSV format, suitable for opening Excel, or into a format suitable for timeline analysis (which will be discussed in greater detail in Chapter 7).

Parsing the values is only half the battle, though. There are a number of resources available that provide information and details regarding what the various event records, either individually or correlated together, can mean. One of my favorite resources is the EventID web site (http://www.eventid.net). The $24 annual registration fee is well worth the expense, as I can log into the site and run searches to not only get additional information about Microsoft-specific events, but also see information with respect to issues that others (mostly system administrators) have observed or encountered, as well as links to pertinent Microsoft KB articles. All of this can be very revealing, even if it only provides me with additional leads or places to look. Application-specific event records are usually best researched at the vendor’s web site, as blogs and forum posts can provide a great deal of information about various events generated by these applications.

Another resource for finding information about Security Event Log entries is the Ultimate Windows Security Event Log site (http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx). This site provides an easily searched list of Security Event Log entries, with some explanations to provide context. The site provides information regarding Security Event Log entries for Windows XP and 2003 systems, as well as corresponding entries for Vista and Windows 2008 systems.

Tip

Event Log Analysis

When conducting analysis on a Windows system, I don’t have specific event records that I search for every time; rather, what I look for depends heavily on the goals of the examination and the system’s audit configuration. While many of the systems I’ve analyzed have had fairly default configurations (minimal changes, if at all, beyond the default, out-of-the-box settings), I have found great value in those systems where settings had been modified, to include the Event Log size being increased. I once had the opportunity to analyze a Windows XP system on which not only were both successful and failed logon events being recorded, but Process Tracking was also enabled. When analyzing this system, I created a timeline (discussed in detail in Chapter 7) of system activity, and the additional detail provided by the Event Log configuration was invaluable.

The Event Logs themselves are not always the sole source of event records on a system. Event Log records, like other data, may be found within the pagefile or within unallocated space. I was once asked to analyze a system from which very few event records were found in the Event Logs and the Security Event Log had an event ID 517 record, indicating that the Event Log had been cleared. As such, one of the steps in my analysis was to attempt to recover deleted event records. My first step was to use the Sleuthkit (http://www.sleuthkit.org/) tool “blkls.exe” to extract all of the unallocated space from the acquired image into a separate file. I then loaded that file into BinText (http://www.mcafee.com/us/downloads/free-tools/bintext.aspx) and saved the list of strings located within the file. I then wrote a Perl script to go through the list of strings and locate all those that contained the event record “magic number” (i.e., “LfLe”); when BinText reports the strings that it locates, it also provides the offset within the file where that string is located (“strings.exe,” available from Microsoft, will do the same thing if you add the “-o” switch to the command line—the utility can be downloaded from http://technet.microsoft.com/en-us/sysinternals/bb897439).

For every string that BinText located that began with “LfLe,” the Perl script would go to the offset within the file containing the unallocated space, “back up” 4 bytes (a “DWORD”), and read the size value. As the event record structure begins and ends with this 4-byte size value, the script would then read the total number of bytes, and if the first and last DWORDs in the sequence were the same, the event record was assumed to be valid, extracted, and parsed. Using this technique, I was able to recover over 330 deleted event records. Another way to do this would be to simply have a slightly modified version of either the “evtrpt.pl” or “evtparse.pl” script parse through unallocated space 4 bytes at a time, looking for the event record “magic number,” and then processing each event found to be a valid record. However you go about doing this, it can be a very valuable technique, particularly if you’re trying to construct a timeline, as discussed in Chapter 7. The point of this is to illustrate how understanding the various data structures on Windows systems can lead to the recovery of additional data that may significantly affect your overall analysis.

Tip

Interesting Artifacts

While I do not have a list of specific event IDs that I look for during every analysis engagement, there are some records of interest that I do look out for when required by the goals of the engagement. As mentioned previously in the chapter, a Security Event Log entry with event ID 517 indicates that the Event Log was cleared. Further, on most systems, some Windows services being started will result in an event with the “Service Control Manager” source and an ID of 7035 being generated by the system shortly after the system is booted. As such, services started by a user hours or days after the system was last started may indicate normal system administration activity, or provide indications of a compromise, such as an intrusion or malware being installed. Further, a number of organizations may use tools such as “psexec.exe” (http://technet.microsoft.com/en-us/sysinternals/bb897553) to access and remotely manage systems; however, intruders will sometimes use “psexec.exe” or similar tools (such as “rcmd.exe,” the remote command utility available from Microsoft) to remotely access systems. The use of such tools usually results in a service being started in the context of the user account used to launch the tool, and is preceded by a network logon (security event ID 540, type 3).

Windows Event Log

With Vista, Microsoft modified a great deal about how events are recorded, as well as the types of events recorded, the location where the events are recorded, and the structure of those recorded events. This new mechanism is referred to as the “Windows Event Log,” rather than just “Event Log” as seen on Windows XP and 2003 systems. On Vista through Windows 7 systems, the Windows Event Logs are stored in the “C:\Windows\system32\winevt\Logs” folder (by default), and are stored in a binary extensible markup language (XML) format.

On a system with a default installation of Windows 7 and only MS Office 2007 installed, I found 134 different .evtx files in the “winevt\Logs” directory. There are two types of Windows Event Logs: Windows logs and Application and Services logs. Figure 4.3 illustrates these logs, visible via the Event Viewer.

Figure 4.3. Windows 7 Event Logs (via Event Viewer).

You can see a number of the Event Logs that you’d expect to see on a Windows system in Figure 4.3. For example, there are the Application, System, and Security Event Logs, which correspond to “appevent.evt,” “sysevent.evt,” and “secevent.evt,” respectively, on Windows XP/2003 systems. The Security Event Log records many of the same events as you may be used to seeing on Windows XP systems, including logons and logoffs (depending on the audit configuration, of course). However, there is a difference—many of the event IDs you would be interested in are different for the same event. For example, on Windows XP, an event ID of 528 would indicate a logon; for Windows 7, that same event would have an event ID of 4624. The difference between these two event IDs is 4096; this holds true for a number of Security events. The Ultimate Windows Security site has a fairly exhaustive listing of both Windows XP and Windows 7 Security Event Log records that you might expect to see, which can be found at http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx.

You will also see the Setup and Forwarded Event Logs in Figure 4.3. According to Microsoft, the Setup log contains events related to application setup; however, reviewing the various entries on a live system reveals that the statuses of Windows Updates are also recorded in this log. The Forwarded Event Log is intended to store events forwarded from other systems.

The remaining logs are Applications and Services logs and store events for a single application or component, rather than events that would affect the entire system. These logs have four subtypes: Operational, Admin, Analytic, and Debug. By default, on a normal Windows 7 system, you’re likely to see Operational and Admin logs, although now and again you’ll see Analytic logs. Admin events are targeted at end users and system administrators, and provide information that an administrator may use to fix an issue or take some other action. Operational logs are generally used to diagnose an issue. For example, the Microsoft-Windows-WLAN-AutoConfig/Operational log provides information about wireless networks that the system has associated with, and through which network adapter, as illustrated in Figure 4.4. Events such as this can be instrumental not just in diagnosing problems, but can also provide clues to examiners during an investigation.

Figure 4.4. Event from the WLAN-AutoConfig/Operational log.

The Debug and Analytic logs are intended for developers and used to diagnose problems that cannot be handled through user intervention.

Tip

VHDs and VMs

I’ve done a bit of testing of virtual hard drives (VHDs) while writing this book (see Chapter 3), mounting and removing them from my Windows 7 system. As such, the Microsoft-Windows-VHDMP/Operational.evtx log has a number of events visible that are associated with the “surfacing” (mounting) of VHD files (event ID 1) and “unsurfacing” (removing) of those files (event ID 2). However, this log applies only to the mounting and removal of VHD files. The Microsoft-Windows-Virtual PC/Admin log maintains records of the use of Virtual PC to create and start virtual systems or machines (VMs), including “XP Mode,” a version of Windows XP available to maintain compatibility with applications that may not run well (or at all) on Windows 7. This log also maintains information about applications installed in XP mode, but launched from Windows 7. Both of these may provide valuable information during exams, particularly when you’re looking for files that may not be in the Windows 7 file system, but may have been accessed from a VHD or VM.

All this aside, what are some of the ways to get at the data within the Windows Event Logs? One means for parsing Windows Event Logs that I’ve found to be very effective is to install Microsoft’s free Logparser tool (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=24659) on a Windows 7 analysis system, and then either extract the Windows Event Log files from the acquired image, or mount the acquired image as a volume. From there, I then use the following command to extract all of the event records from each log:

logparser -i:evt -o:csv "SELECT * FROM D:\Case\System.evtx" > output.csv

When using this command, it’s important to remember that Logparser relies on the APIs (available via DLLs) on the analysis system. As such, you won’t be able to use it to parse Vista or Windows 7 Event Logs if you’re running Windows XP on your analysis system, as the Event Log APIs on Windows XP aren’t compatible with the Vista/Windows 7 Windows Event Log format. Similarly, you can’t use Logparser to parse Windows XP or 2003 logs on a Vista/7 analysis system. Sending the output of the Logparser command to CSV format allows for easy viewing and analysis via Excel, in addition to providing additional columns for you to add references or your own notes. The format also allows for easy parsing, as we will see in Chapter 7.

Tip

Converting Event Logs

While attempting to use Logparser running on a Windows 7 system to parse Windows XP Event Logs won’t result in anything useful, you can use “wevtutil.exe” (native to Windows 7) to convert the XP Event Logs to Windows 7 Event Log format, using a command line similar to the following:

D:\tools>wevtutil epl appevent.evt appevent.evtx /lf:true

Andreas Schuster, whose blog can be found at http://computer.forensikblog.de/en/, has put a good deal of effort into deciphering and decoding the Windows Event Log format, and creating a Perl-based library and tools collection for parsing the events from a log. As of this writing, the version of his library is 1.08. You can download and install Andreas’ library, or you can use tools that have the library and tools already installed, such as the SANS Investigative Forensic Toolkit (SIFT) Workstation that Rob Lee developed. SIFT version 2.1 was available at http://computer-forensics.sans.org/community/downloads when this chapter was being written.

4.2 The WMI security configuration

Any manageable object we discussed in the previous chapters can be accessed under some security conditions. The WMI access is defined by three methods:

During the WMI connection, the entity accessing a system must provide an authentication method and some privileges to perform specific tasks (i.e., system reboot) or access some specific manageable objects (i.e., security event log).

The entity accessing the manageable object is granted access to a CIM repository namespace and allowed to perform some specific operations. The entity in question could also be part of an authorized group.

The manageable object is restricted in access in a namespace by the means of a security descriptor. A security descriptor is nothing other than a representation, in the form of a list, of the access rights granted or denied to entities for the purpose of accessing a secured object in the system.

4.2.2 The group membership

By default, every CIM repository namespace is secured from the Root namespace, while subnamespaces inherit the security settings from the Root (see Figure 4.1).

Figure 4.1. The default security settings on the Root namespace.

By default, only two built-in groups are configured to access a CIM repository namespace: Administrators and Everyone. While the Administrators group has full access to any CIM repository namespace by default, the Everyone group is restricted to a limited number of accesses, such as reading some configuration data from the local system.

Table 4.2 summarizes the access type granted to the default groups for the Root namespace. Each of these rights is stored in the CIM repository in the form of a security descriptor.

Table 4.2. The Default Right Settings on the WMI Root Namespace

AdministratorsEveryoneLocal ServiceNetwork ServiceExecute MethodsXXXXFull WriteXPartial WriteXProvider WriteXXXXEnable AccountXXXXRemote EnableXRead SecurityXEdit SecurityX

Which registry root key contains information about file types?

The HKEY_CLASSES_ROOT (HKCR) key contains file name extension associations and COM class registration information such as ProgIDs, CLSIDs, and IIDs. It is primarily intended for compatibility with the registry in 16-bit Windows.

What registry key contains profile information for each user who has signed in to a computer?

The registry contains a key called ProfileList located in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion. This registry key contains one subkey for each user profile on a Windows machine.

Which registry hive contains information about computer hardware?

The HKEY_LOCAL_MACHINE Registry hive contains information about the computer's hardware. It is also known as HKLM.

What kind of Windows full disk encryption can be used with removable drives?

Used Space Only encryption in BitLocker To Go allows users to encrypt removable data drives in seconds. BitLocker could require users to enter a recovery key when system configuration changes occur. BitLocker requires the user to enter a recovery key only when disk corruption occurs or when the PIN or password is lost.