Windows IR | SANS Computer Forensic Investigations and Incident Response

Category Archives: Windows IR

Learn To Investigate Data Breach Incidents

Comments Off

Posted by sansinstitute on December 23, 2009 – 5:19 pm

Filed under Computer Forensics, Evidence Analysis, Incident Response, Linux IR, Malware Analysis, Windows IR

Computer Forensic Training is becoming more critical to your organizations incident response plan due to some of the current threats that are being discovered. Organizations will find more and more that they will need a team of trained incident responders and computer forensic analysts. Your organization needs to be prepared on how to handle sophisticated incidents and organized groups that can easily walk around your perimeter defenses.

Here are just a few recent headlines over the last year scoping the current threat against many networks.

MSNBC: “Report: Obama helicopter security breached. Pa company says blueprints for Marine One found at Iran IP address”

Wall Street Journal: “Computer Spies Breach Fighter-Jet Project”

Aviation Week: “Attacks on US computer systems stress supply chain security and reveal shortage of defenders”

Wall Street Journal: “FBI Probes Hack at Citibank”

Our intermediate Computer Crime Investigations course (Computer Forensics, Investigations, and Incident Response – FOR508) has recently been updated to address the crimes associated with data breach incidents and the advanced persistent threat. We want to highlight some of the computer forensic training classes out there that you should look at. As an added bonus, classes tend to be smaller at these conferences, allowing for even more individual attention.

Most of the upcoming events for all the Digital Forensic Courses and training that SANS offers can be found at the upcoming events page of the Computer Forensics Website.

Forensics 508 – Computer Forensics, Investigation, and Incident Response

Community SANS Lake Tahoe 2010	Lake Tahoe, CA	January 25, 2010 – January 30, 2010
Community SANS Forensics DC 2010	Alexandria, VA	February 22, 2010 – February 27, 2010
Community SANS Boston 2010	Boston, MA	March 15, 2010 – March 20, 2010
Community SANS Virginia Beach 2010	Virginia Beach, VA	May 24, 2010 – May 29, 2010

Forensics 606 – Data Recovery and Drive Forensics

Community SANS Atlanta 2010

Atlanta, GA

February 09, 2010 – February 13, 2010

Forensics 563 – Mobile Device Forensics

Community SANS San Antonio 2010

San Antonio, TX

April 19, 2010 – May 01, 2010

http://computer-forensics.sans.org

Extracting VB Macro Code from Malicious MS Office Documents

Posted by Lenny Zeltser on November 23, 2009 – 7:13 pm

Filed under Computer Forensics, Email Investigations, Evidence Analysis, Incident Response, Malware Analysis, Reverse Engineering, Windows IR

An incident responder or forensic investigator should be prepared to examine potentially-malicious document files, which may be located on the compromised system or discovered in email, web, or other network streams. After all, embedding malicious code into documents, such as Excel spreadsheets or Adobe Acrobat PDF files is quite effective at bypassing perimeter defenses. This note deals with one such scenario, focusing on how to extract Visual Basic (VB) macro code that may be embedded in malicious Microsoft Office files. I will discuss how to extract macros from both legacy binary Office files (.doc, .xls, .ppt), as well as modern XML-based Office formats that support macros (such as .docm, .xlsm, .pptm). As you’ll see, OfficeMalScanner will be my tool of choice for getting the job done.

Malicious Use of Macro Code in Microsoft Office Document Files

Recent versions of Microsoft Office disable macros by default. However, with a bit of social engineering, an attacker can often trick the user into enabling macros. The attacker may then use embedded VB macro code to run arbitrary commands on the victim’s system. For instance, Metasploit can generate its payload as a VB script, which can easily be embedded in an Office document; similarly, tools exist for converting arbitrary EXEs into VB script.

Legacy binary Microsoft Office formats don’t differentiate between document files that may and may not include macros. In contrast, when the documents are saved using new XML-based file formats, introduced in Microsoft Office 2007, macros are only supported for file’s extension that end with “m”:

.docm, .xlsm, .pptm, .dotm, .xltm, .xlam, .potm, .ppam, .ppsm, .sldm

For this note, I created a sample set of “malicious” Excel document files: malware.xls (legacy binary format) and malware.xlsm (current XML-based format). The files include VB code that mimics an attacker’s attempt to run commands on the victim’s system. The code in this example pings localhost and launches notepad.exe when the victim opens the document and allows macros. Here’s what it will look like from the victim’s experience (the screen shot didn’t capture the instance of Notepad, which would also be running):

macros-user-experience

I took this proof-of-concept code from the example published on the Invisible Denizen blog. You can download my sample files here; the password for the zip file is the word “infected.”

Let’s say you need to analyze a potentially-malicious Microsoft Office document files like these. The approach I’d like to demonstrate involves extracting VB macro code using MalOfficeScanner, a free tool by Frank Boldewin, which can deconstruct Microsoft Office files and extract embedded shellcode and VB code. I’ll explore only the features of this tool related to VB.

Extracting VB Macro Code from Binary Microsoft Office Files

Let’s start with the malware.xls example, you’ll be more likely to encounter such binary files than XML-based ones. Legacy binary formats of Microsoft Office files (.doc, .xls, .ppt) are considered more risky than newer XML-based formats, because the programs parsing binary files tend to be more complex and, therefore, more prone to bugs.

Place the suspicious document file on the laboratory system running Microsoft Windows, where you placed MalOfficeScanner. Go to the command prompt. To scan the file (malware.xls) for the presence of VB macro code, type “OfficeMalScanner malware.xls info“.

1-extract-macros-from-xls

The tool will examine the file and, if it locates VB macros, extract the code into text files in the “MALWARE.XLS-Macros” folder. Since an Excel spreadsheet can have multiple sheets, you will see a file per sheet, as well as the file called “ThisWorkgroup” for global macros. In my example, the relevant VB code is in the “ThisWorkgroup” file:

Sub Run_Cmd(command, visibility, wait_on_execute)
Dim WshShell As Variant
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run "%COMSPEC% /c " & command, visibility, wait_on_execute
End Sub
Sub Run_Program(program, arguments, visibility, wait_on_execute)
Dim WshShell As Variant
Set WshShell = CreateObject("WScript.Shell")
WshShell.Run program & " " & arguments & " ", visibility, wait_on_execute
End Sub

Sub Workbook_Open()
Const VISIBLE = 1, INVISIBLE = 0
Const WAIT = True, NOWAIT = False
Run_Cmd "ping 127.0.0.1", VISIBLE, WAIT
Run_Program "notepad.exe", "", VISIBLE, NOWAIT
End Sub

Extracting VB Macro Code from XML Microsoft Office Files

The “info” option of MalOfficeScanner only works with legacy binary Microsoft Office files. If you try to use it on “malware.xlsm”, you’ll get an error.

info-fails-on-xlsm

No problem. XML-formatted versions of Microsoft Office files, which typically have extensions such as .docx, .xlsx, and .pptx, are actually zip-compressed archives that contain several files. You can unpack the archive using tools such as unzip and ZipReader (e.g., “unzip malware.xlsm“).

unzip-office-xml-file

In this case, the “vbaProject.bin” file contains extracted VB macro code in a binary format.

Alternatively, you can unpack the archive using the “inflate” option of MalOfficeScanner, which will also identify the extracted files that contain VB. To do this, you would type “OfficeMalScanner malware.xlsm inflate“.

inflate-xlsm-file

Whether you obtained the binary VB file using manual unpacking or OfficeMalScanner’s “inflate” feature, you can extract scripts from .bin files using the “info” feature: “OfficeMalScanner vbaProject.bin info“.

info-of-bin-file-extracts-macros

You can now look at text files in the VBAPROJECT.BIN-Macros folder to examine extracted VB code. In this case, the code is identical to the one I showed earlier in the note.

All Done

There you have it. An approach to extracting VB macro code from malicious Microsoft Office files, whether they use legacy binary or recent XML-based formats. Do you have another approach, or any thoughts on this one? Tell us in comments below.

If you found this note useful, you may like the Analyzing Malicious Documents cheat sheet, which outlines these and other tips for examining Microsoft Office and PDF files.

– Lenny

Lenny Zeltser teaches the Reverse-Engineering Malware course at SANS Institute. You can find him on Twitter as @lennyzeltser.

Helix 3 Pro: First Impressions

Posted by jarocki on November 20, 2009 – 11:16 am

Filed under Computer Forensics, Evidence Acquisition, Evidence Analysis, Incident Response, Linux IR, Memory Analysis, Registry Analysis, Windows IR

I have used several versions of Helix over the recent years. I enjoy the tool set and recommend it to forensics colleagues, sysadmins, and even family members.

Quite a substantial ruckus was raised this year when e-fense announced that Helix 3 would no longer be free to download. Instead, would-be users must pay to register as a forum user to get access to Helix 3 Pro updates for a year.

I took the plunge and purchased my forum membership. Here are the first things I noticed:

Some of the highlights…
- The forum allows access to the Helix 3 software the member applies a registration token.
- After adding the token, I was able to download not only Helix 3 Pro, but also Helix 3, and contributed tools.
- Helix 3 Pro is really nothing like the 1.8 and 1.9 versions that came before it. Although it still provides a bootable live CD as well as executables that can be run in Windows in Linux, the interfaces for all the modes of use have been made more consistent and seamless. Also, a Mac OS X set of tools have been added.
- The Helix 3 Pro CD also provides a set of cell phone forensics tools (that I will cover in a follow-on posting).
- One of e-fense’s goals with the Helix 3 release was to provide a forensics tool that did not touch the host computer in any way. I have not tried to verify this yet, although I intend to do so soon.
And the lowlights…
- On my Dell D630 laptop (and few other systems), the boot process generated a number of errors and — in some cases — would not detect a graphical interface mode correctly, leaving me with an unusable Helix environment.
- The majority of the tools that made previous versions of Helix useful are just completely gone. This is apparently done so that the Helix Pro 3 image can be trusted. I spoke to a sales representative at e-fense who told me that several customers were using Helix 3 Pro in environments where open source software of questionable origins is, well, frowned upon.
- Static binaries formerly found on the Helix 1.x CDs are now separate downloads. They are still available through the Helix forums.

This is the first in a series of blog postings I plan to publish on Helix 3 Pro. Please post comments if there are specific tools or features of the LiveCD you would like me to cover.

John Jarocki, GCFA Silver #2161, is an Information Security Analyst specializing in intrusion detection, forensics, and malware analysis. He also holds GCIA, GCIH, GCFW and GSEC certifications and is the Treasurer of NM InfraGard. John recently co-authored a controversial paper on using LiveCDs to mitigate online banking risks.

3 Lists for Investigating Malware Incidents

Posted by Lenny Zeltser on November 7, 2009 – 4:24 am

Filed under Incident Response, Malware Analysis, Network Forensics, Reverse Engineering, Windows IR

When investigating an incident that involves malicious software, it helps to understand the context of the infection before starting to reverse the malware specimen. Some of the ways to accomplish this involves:

Examining the websites that may be associated with the incident, often because they are suspected in hosting exploits that acted as the infection vector
Obtaining reputational data about IP addresses of systems involved in the incident, often because they are suspected of hosting malicious files that were dropped on the system, or acting as the command and control server for the attacker
Looking up IP addresses associated with the infected organization in blocklists, to determine whether additional systems may have been performing malicious activities and may have gotten compromised
Performing automated behavioral analysis of malware involved in the incident, to get a general sense for its characteristics to plan subsequent manual reverse-engineering tasks

Each of the following pages lists 10 or so freely-available on-line tools for helping to perform the tasks outlined above:

What other on-line tools help understand the context of the infection? Tell us in comments below.

– Lenny

Related Posts

PDF Malware Analysis

Lenny Zeltser teaches the Reverse-Engineering Malware course at SANS Institute. You can find him on Twitter as @lennyzeltser.

Windows Scheduler (at job) Forensics

Posted by johnmccash on September 16, 2009 – 12:20 pm

Filed under Computer Forensics, Evidence Analysis, Incident Response, Windows IR

This information may be useful to people responding to compromise incidents involving Windows. Typically these days, when a job is scheduled for execution later, possibly every day, week, or month, it’s done via a GUI tool or ‘schtasks‘. However , you can still use the original command line ‘at‘ tool. This utility also allows such jobs to be scheduled over the network if admin credentials are possessed, which makes it quite useful to an attacker for post exploitation activities. When cleaning up after something like this, it’s useful to know a bit about what it does under the hood, including the formats of the associated .job file, and the structure and location of associated log entries.

Figure 1: A scheduled job created by the At command

When the job is scheduled using the ‘at’ command, a file is created under the Windows\Tasks folder. This file has a .job extension, is named At#.job (jobs not scheduled by the ‘at’ command will have arbitrary names), and its format is described on msdn. If the job is not set up for repeat execution(weekly, monthly, etc.) then the file is deleted after the job is run. In some cases I’ve been able to extract the data portion from unallocated space by searching for a characteristic comment string that the ‘at’ command (I haven’t been able to create a search keyword that will find generic .job files that weren’t created by ‘at’), at least in Windows XP, places on all .job files that it creates, “Created by NetScheduleJobAdd.”. Note that this string is in Unicode, and is null-terminated. The 16 bits immediately following the two nulls at the end of this unicode string contain the length (little-endian) of the User Data section in bytes, and they are followed by that section (if the length is non-zero). After this section comes the reserved data size ( another 16 bit little endian value in bytes), followed by the reserved data section. Then there’s a 16 bit trigger count, which contains the size of the array of triggers that follows. According to the MS documentation, this value is supposed to be the number of bytes in the array, but as it’s one in all the examples I’ve personally seen, I think it’s really supposed to be the number of triggers defined. The trigger value starts with a 2-byte size, which should be 0×30 (little-endian, of course, which means 3000). Then there’s a 2-byte reserved field, followed by three more 2-byte little-endian values specifying the year, month, and day when the job is scheduled to execute first. Next come three more 2-byte values which would specify end year, month, & day for repeating jobs, and finally two more two byte values, for the start hour and start minute. There are other fields in the structure, but these are the important ones. (While there’s a field specifying the job’s author, in all examples I’ve seen from the At command, it’s set to “System”.)

Figure 2. Hex dump of the At1.job shown above

When a scheduled job is actually executed (not when it’s scheduled), a log entry is written to the scheduler’s log file. The name of this file is defined by the registry key HKLM\Software\Microsoft\SchedulingAgent, but it defaults to SchedLgU.txt. On WinXP, this file is located in the Windows folder, but on Vista, they’ve moved it to Windows\Tasks. The log entry format looks something like the following (in unicode):

“At#.job” (filename.exe)

Started #/##/2009 #:##:## PM

“At#.job” (filename.exe)

Finished #/##/2009 #:##:## PM

Note that the numbers aren’t padded with leading zeros, and that the above lines are two separate 2-line log entries. It’s possible that other entries could fall in between the Start and Finish for a given job. Also, these entries are written for any scheduled job, regardless of whether it was created by ‘at’ or one of the other scheduler utilities. Of course if it was created by something other than ‘at’, the .job file will probably have a different name.

As always, please feel free to leave commentary if you liked this article or want to call me on the carpet for some inaccuracy.

John McCash, GCFA Silver #2816, is currently a Forensic Investigator employed by a fortune 500 telecommunications equipment provider.

USB Key Analysis vs. USB Drive Enclosure Analysis

Posted by robtlee on September 9, 2009 – 7:31 am

Filed under USB Device Analysis, Windows IR

Computer Forensic Guide To Profiling USB Drive Enclosures on Win7, Vista, and XP

There has been much talk about USB Device Forensic Analysis. Many assume that analyzing a USB Key will be the same as analyzing a USB Drive Enclosure (e.g. USB Key Analysis = USB Drive Enclosure analysis). This is inaccurate.

USB Drive Enclosure

USB Key/Thumbdrive

The fundamentals of examining a USB Key and a USB Drive Enclosure are similar, but have some unique properties that require a different set of guidelines to account for the differences. I have created a new guide that you can download at the bottom of this post that will step you through how to forensicate USB Drive Enclosures for XP, VISTA, and Win7.

The fundamentals of the USB examinations are the same with a couple of key exceptions.

1. There will not be a ParentPrefixID created for these devices.

2. You cannot figure out the device GUID by searching for the Serial Number in the SYSTEM\MountedDevices Key.

MBR Disk Signatures

The information that is needed is the MBR Disk Signature that is located in the MBR, it is a 4-byte value. I have not had the chance to test this with a GPT table, but according to the fifth edition of Windows Internals, it is supposed to use the GUID instead of the Disk itself.

How does this work? First, written in the MBR at decimal offset 440 will be the MBR Disk Signature. These signatures are kept in HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices for connecting disk partitions and drive letters. This 4-byte value is written to the disk. If the disk does not have a MBR Disk Signature, windows will create one for it.

Example 1:

Here is the first example:

MBR Disk Identity Found At Decimal Offset 440

MBR Disk Signature Found At Decimal Offset 440

Finding the Registry Key HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices we will locate the signature in one of the drive letters and GUID found there:

HKEY_LOCAL_MACHINESYSTEMMountedDevices

Once we have located the key, we can find the MBR Disk Signature in the MountedDevices Key:

MBR Disk Signature Found in Registry

You can see the value is 5e 82 A0 EC. However, you might be wondering what the 8 bytes of information that immediately follows it. Those bytes (00 00 10 00 00 00 00 00) is the byte offset of the location of the beginning of the partition. If you convert to little endian and covert to decimal the value stored in those 8 bytes = 1048576 bytes. If you divide by the sector size (512 bytes), the value would be sector address 2048. If you look in the MBR above, you can see that the first partition begins at sector address (00 08 00 00 = sector 2048). The last 8 bytes of the signature stored in the registry key point to the byte offset of the start of the partition itself after you convert the bytes into the sector address.

Why is this? Simple. If you have a drive enclosure or a disk drive with two or more partitions, the MBR Disk Signature will be the same. Therefore, the last 8 bytes are needed to tell one partition apart from the other at the operating system. In some cases, you will have two partitions that have the exact same MBR Disk Signature, but are two different partitions from the same drive.

Here is another example:

Same MBR Disk Signature: Two Partitions Example

In the above example, we can see the MBR Signature is a2 ee b2 28. We can see one partition is located at byte offset (00 00 10 00 00 00 00 00 = 1048576) 1048576/512 = Sector 2048. In the second one, we can see the second partition located at byte offset (00 00 50 06 00 00 00 00 = 105906176 bytes) 105906176 bytes/512 bytes = Sector address 206848.

Example 2:

Here is the MBR Disk Identity found at decimal offset 440 in another drive enclosure:

MBR Disk Signature Found At Decimal Offset 440

The MBR Disk Signature is 42 AE 74 5C. We can also see that this is an NTFS Partition (0×07) and the begginning of the partition starts at sector address (3f 00 00 00 or Sector 63). If we convert that to a byte offset, we multiple 63*512 bytes = 32256 which would be (00 7e 00 00 00 00 00 00) for the 8 byte partition beginning.

So for the partition located in this disk image we should find a disk signature and partition beginning noted by the following: 42 AE 74 5C 00 7E 00 00 00 00 00 00

We will now look in the HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices and compare the values there:

As you can see above, we found it. The key is identifying the MBR Disk Signature and if needed, we can identify the specific partition by looking at the 8 bytes following it.

USB Drive Enclosure Examination Guide

Because of this new information, I have updated the USB Forensic Guide to account for this information and created a new guide that will follow this process in XP, VISTA, and Win7.

The USB Drive Enclosure guide can be found here:

USB Drive Enclosure Guide

If you find any errors in the guide, please let me know. rlee@sans.org

Some caveats. 1. If you do not have the disk drive or enclosure when you begin forensication, I am still figuring out a way to map the GUID to the drive without knowing the MBR Disk Signature. If you have any thoughts on how to solve this challenge, please let me know. I am still looking for another way to figure out how to do that without having the drive handy. 2. This guide assumes there is a single partition. If you have more than one patition, you will need to figure out the specific starting sector, convert it to byte offset in 8 byte little endian format to find the specifc device in the MountedDevices key.

Forensicate Away!

This material was created as a part of SEC408: Computer Forensic Essentials. SANS Security 408: Computer Forensic Essentials focuses on the essentials that a forensic investigator must know to investigate core computer crime incidents successfully. You will learn how computer forensic analysts focus on collecting and analyzing data from computer systems to track user-based activity that could be used internally or in civil/criminal litigation.

__________________________________________________________________________

Rob Lee is a Director for MANDIANT, a leading provider of information security consulting services and software to Fortune 500 organizations and the U.S. Government. Rob has over 13 years experience in computer forensics, vulnerability discovery, intrusion detection and incident response. Rob is the lead course author and faculty fellow for the computer forensic courses at the SANS Institute. In his spare time, he is now pondering creating additional guides for eSATA and Firewire Devices.

Computer Forensic Guide To Profiling USB Device Thumbdrives on Win7, Vista, and XP

Posted by robtlee on September 9, 2009 – 5:21 am

Filed under Computer Forensics, USB Device Analysis, Windows IR

Several times over the past year it has come up in a discussion about the key differences between examining USB Key/Thumbdrives on XP, VISTA, and Windows 7. We did an initial post several weeks ago, but found some new information and have updated our guides as a result. Thanks to SANS Digital Forensic Instructor Colin Cree for the wonderful feedback.

As a part of the SEC408: Computer Forensic Essentials course, we have an extensive section on residue left by USB Devices. I am providing a single guides to help you answer the key USB Key/Thumbdrive questions for your case covering XP, VISTA, and Win7.

How would you examine these keys? We recommend Access Data’s Registry Viewer and Regripper. Even though you can get access to the data, there is not a tool that has this process automated yet. The guides will help you step through the keys/values in addition to the files you will need to correctly parse the data.

USB Device Forensics for Windows XP: DOWNLOAD

USB Device Forensics for Windows VISTA/WIN7: DOWNLOAD

__________________________________________________________________________

De-mystifying Defrag: Identifying When Defrag Has Been Used for Anti-Forensics (Part 1 – Windows XP)

Posted by Chad Tilbury on August 5, 2009 – 8:06 am

Filed under Computer Forensics, Evidence Analysis, Registry Analysis, Windows IR

I have seen the following Windows Prefetch entries in nearly every Windows XP / Vista machine that I have reviewed over the past several years. Their existence always reminds me of the imperfect nature of information gained via individual artifacts. Does this mean that a user ran the Microsoft Defragmenter application on July 16, 2009 at 1:19PM? Or was the defragmenter started automatically by Windows? The defragmenter tool has been used very effectively as an anti-forensic tool since it was first introduced. In cases where data spoliation could be important, it is critical for the examiner to be able to identify any overt actions by a user. Complicating this is that starting with Windows XP, the operating system conducts limited defragmentation approximately every three days. [1] This post seeks to identify forensic artifacts which can help us determine if a user initiated the defrag application.

$Figure 1: Defrag entries in C:\Windows\Prefetch directory$

Figure 1: Defrag entries in C:\Windows\Prefetch directory

We will focus on two primary methods a user can invoke the Windows Defragmenter tool:

Running defragmenter from a graphical user interface (GUI)
Running defrag from the command line using defrag.exe

Defragmenter Artifacts in Windows XP – Identifying GUI Usage

The GUI defragmenter tool leaves a wealth of artifacts that can distinguish user execution of defrag from system execution. It is commonly accessed from the Start Menu -> Accessories -> System Tools menu. We will query the following artifacts to identify user actions:

Prefetch Entries
UserAssist Registry Key
Registry MMC Recent File list
File Access Timestamps

Prefetch Entries

The addition of Windows Prefetch in XP has provided investigators with an excellent artifact for identifying applications executed on a system. While it won’t give us everything we need in this situation, it is an excellent starting point. Entries are located in the C:\Windows\Prefetch directory and can be parsed using Mark McKinnon’s Prefetch Parser or your favorite forensic suite.

When the defragmenter is run using the GUI, only the dfrgntfs.exe entry is updated within the Prefetch directory (with an updated access time stamp and execution count). This immediately reveals that the artifacts shown in Figure 1 were not left by the GUI tool. It may also explain why we often see higher execution counts for dfrgntfs.exe than defrag.exe when parsing the Prefetch entries. As an aside, it is interesting to note that I found differences in how the execution count was updated. When using the GUI, the execution value for dfrgntfs.exe was incremented by one and when using the command line application, the counts were incremented by three.

Since the GUI version of the defragmenter is essentially a Microsoft Management Console (MMC) snap-in, an entry for MMC.exe is also created in the Prefetch folder. It is important to note that MMC.exe can be present in the Prefetch due to the use of other snap-ins (such as viewing the event logs). Its proximity to the dfrgntfs.exe entry is one clue, but Prefetch files can also show what was loaded by the application, and further investigation reveals that dfrgres.dll and dfrgui.dll are both loaded by MMC.exe whenever it facilitates the defragmenter snap-in.

Figure 2: Prefetch entries indicating the GUI defragmenter tool was run

UserAssist Registry Key

Prefetch can indicate that the GUI application was run, but it gives no information regarding user attribution. Luckily we have an artifact available in the NTUSER.dat hive file that does both. The UserAssist registry key, HKCU\Software\Microsoft\Windows\Currentversion\Explorer\UserAssist\{GUID}\Count, stores information on applications run per user. This is a terrific artifact for proving user activity and can be easily viewed using UserAssist.exe written by Didier Stevens. Evidence of manual execution can be found within this registry key when the defragmenter is accessed via the GUI interface. You should be looking for entries for “Disk Defragmenter.lnk” and “mmc.exe”. The “Last” time indicates when the application was last run by the user. One unfortunate limitation of this artifact is that applications run from the command line are not recorded.

Figure 3: Using UserAssist.exe to parse the registry values

Registry MMC Recent File List

Since we know that the MMC is utilized by the defragmenter GUI, there is an additional registry artifact dedicated to recording MMC usage. Looking at HKCU\Software\Microsoft\Microsoft Management Console\Recent File List, we should see an entry for dfrg.msc, which is the Microsoft Common Console file for the defragmenter snap-in. If this is the last value recorded, the key last write time will indicate when the defragmenter was last run. Additionally, note that this registry key is under HKey_Current_User (NTUSER.dat hive), giving us another artifact for proving user attribution.

Figure 4: The MMC Recent File List reviewed using regedit.exe

Figure 4: MMC Recent File List reviewed using regedit.exe

File Access Timestamps

Finally, we can tie everything together neatly by doing a timestamp analysis. The access timestamps for the following files indicate when these files were last run. Any mismatch with the times indicated in the Prefetch and UserAssist artifacts can tell us if there was any additional defrag activity after the GUI was run:

C:\Windows\System32\Dfrgntfs.exe
C:\Windows\System32\Dfrg.msc
C:\Documents and Settings\All Users\Start Menu\Programs\Accessories\SystemTools\Disk Defragmenter.lnk

Defragmenter Artifacts in Windows XP – Identifying Command Line Usage

In contrast to our investigation of artifacts generated by the GUI interface, command line use of the defrag tool gives us much fewer artifacts to work with. We will be required to focus on:

Prefetch entries (including timestamps)
Timeline analysis of contemporaneous events
Layout.ini

Figure 5: Example of running defrag.exe from the XP command line

Prefetch Entries

Unlike the artifacts for the GUI defragmenter, the Prefetch artifacts left by command line execution of defrag.exe are the same as those left by the Windows automated process. Upon command line execution both defrag.exe and dfrgntfs.exe are created in the Prefetch directory. Further, their last access times are updated to the time the application was run. This tells us when the defrag tool was last run, but does not allow us to differentiate between system defrags and user generated activity. Therefore we will need to turn to timeline analysis.

Timeline Analysis

With very limited artifacts, old fashioned timeline analysis will likely be our best bet to identify user defrag activity. This is not a theoretical exercise. We have seen instances of the defrag tool used as an anti-forensics tool in recent intrusion cases. Often this plays out with the intruder installing their payload on the system, deleting it, and then running defrag.exe to prevent the malware from being recovered by incident responders.

Figure 6: Sorting Prefetch entries by last accessed time and reviewing nearby applications

In this situation we will often be looking for the opening of a command shell (cmd.exe) near the time that defrag.exe was run. This is a key differentiator since Windows does not require an interactive command shell when kicking off automated processes. Figure 6 shows how this might look in the Prefetch directory. In addition to just Prefetch entries, other timeline entries like created and deleted files can provide further context. Admittedly, this evidence is very temporal and presumes that collection occurs as close a possible to the time the intrusion occurred.

Layout.ini

The layout.ini file is located in the C:\Windows\Prefetch directory and is used by the Prefetch process to more efficiently place system and frequently used applications during the limited defrag sequence. It is not used during a standard manual defragmentation. Therefore it can be a good indicator for distinguishing between user and system actions. In the example shown in Figure 7, the modification time of the layout.ini coincides with the defrag applications and indicates that they were run by the operating system (not the user).

Figure 7: Sequential Prefetch entries indicating that a limited defrag was completed by the system

A Note Regarding Event Logs

In Windows XP, there is no native capability to record defragmenter usage in the event logs. [2] Thus we will not be able to leverage this source of information as we could for other actions like task scheduler usage.

Conclusion

We stand our best chance of tying defragmenter execution to a user account if it was conducted via the GUI interface. Many of our most valuable Windows artifacts are not updated when an application is run from the command line. However, we will often be able to turn to old-fashioned timeline analysis to assist in these circumstances.

It should be noted that there are plenty of legitimate reasons for running the defragmenter tool. Other contemporaneous actions need to be reviewed to assess a user’s true intent.

The Vista operating system changes many of the artifacts covered in this post. Part 2 will cover performing this analysis on a Vista system.

References

[1] http://msdn.microsoft.com/en-us/magazine/cc302206.aspx

[2] http://support.microsoft.com/kb/294743

System State Backup

Posted by craigswright on July 3, 2009 – 3:36 pm

Filed under Computer Forensics, Evidence Acquisition, Incident Response, Windows IR

The Windows system state backup is in effect a backup of the complete system. Everything that is present within the system will be copied as backup so that no data or information is lost whenever there is a system crash or corruption of the driver files, if certain system files stop the system from functioning properly. To perform a forensic analysis of evidence on a Windows system, backing up a system’s registry is insufficient. An extensive backup of data is essential so that the system can be secured against any malfunctions.

This is most commonly an issue when conducting a live analysis.

A full system state backup saves the:

Active Directory (NTDS),
Windows Boot files,
COM+ class registration database,
Registry,
System volume (SYSVOL), and
The IIS metabase.

The process to create a System State Backup is simple:

Go to Start > Programs > Accessories > System Tools > Backup,
In the Backup tab, check the System State box,
Select the Schedule Job tab and Select Add Job button,
Select Yes and choose “media options”

Media type,

Location, and

Backup name.

Select Next and check that the Normal option is selected, and then Select Next again.
When backing-up to disk there is no need to verify data. Select Next.
Choose if you want to append to or replace an existing backup. Select Next.
Schedule the backup. Select Next.
Set the account to one that has the required permission to run the backup.
Select Finish.

A good deal of information is available from and is stored within the Windows system state. Don’t overlook it.

Craig Wright is a Director with Information Defense in Australia. He holds both the GSE-Malware and GSE-Compliance certifications from GIAC. He is a perpetual student with numerous post graduate degrees including an LLM specializing in international commercial law and ecommerce law as well as working on his 4^th IT focused Masters degree (Masters in System Development) from Charles Stuart University where he is helping to launch a Masters degree in digital forensics. He is engaged in his second doctorate, a PhD on the quantification of information system risk at CSU.

Live Investigations

Posted by craigswright on June 22, 2009 – 7:20 am

Filed under Evidence Acquisition, Evidence Analysis, Incident Response, Windows IR

Ever need to get hold of a set of trusted tools to check processes on a live windows host and just don’t have a disk with these on you?

Well, the answer is at hand. SysInternals have a “live site. On this site, they provide a simple list of all of their tools ready for a direct downloads where-ever you are (as long as you have Internet access of course). As the site states:

Sysinternals Live is a service that enables you to execute Sysinternals tools directly from the Web without hunting for and manually downloading them. Simply enter a tool’s Sysinternals Live path into Windows Explorer or a command prompt as http://live.sysinternals.com/<toolname> or \\live.sysinternals.com\tools\<toolname>.

One of these tools is pslist.

Pslist displays process, CPU and memory information or thread statistics for all processes that are presently running on the system. The information listed for each process includes the time the process has executed, the amount of time the process has executed in kernel and user modes, and the amount of physical memory that the OS has assigned the process. Command-line switches allow the viewing of memory-oriented process information, thread statistics, or all three types of data.

Syntax

pslist [-?] [-d] [-m] [-x][-t][-s [n] [-r n]][\\computer [-u username] [-p password]] [name | pid]

Some common parameters

· -d Shows statistics for all active threads on the system, grouping threads with their owning process.

· -m Shows memory-oriented information for each process, rather than the default of CPU oriented information.

· -x Shows CPU, memory, and thread information for each of the processes specified.

· -t Shows the tree of processes.

This tool (and many others) can be downloaded from http://live.sysinternals.com/.

In its standard mode, this tool is similar to the UNIX ‘ps’ command. When run with a combination of the parameters, it can become a powerful tool that can greatly aid in locating malware on live systems. The ‘-x’ parameter groups processes with the information concerning the process allowing for a far more granular look at what is occurring on the system (as is displayed below).

The ‘-t’ or tree option on the other hand displays the process hierarchy and the dependencies.

Best of all, these tools can now be run directly from the web.