Journey Into Incident Response

This is a quick post to pass along that I updated my auto_rip script. For those who may not know, auto_rip is a wrapper script for Harlan Carvey's RegRipper program and it executes RegRipper’s plug-ins based on categories and in a specific order. To learn more about my script please see my previous post Unleashing auto_rip. The auto_rip updates are pretty minor. I separated out the changes to a change log instead of documenting changes in the script itself, added a device category (due to a new plug-in), and I added most of the new RegRipper plug-ins Harlan created (as of 7/30/15). The download location can be found on the right of my blog or using this link to its Google drive location.


****** 08/11/2015  Update *******

At this time I removed the compiled executable from auto_rip. The compiled executable is having issues and I'm working to resolve it. However, the perl script is present and works fine. As soon as I'm able to compile the script into an exe then I'll add it back to the auto_rip archive

The next two RegRipper plugins I wanted to highlight are: soft_run and user_run. Some may have been familiar with what these plugins did and the registry keys they checked. I’m referencing the past tense since Harlan has been busy working and he updated these plugins in the process. Not only were new run keys added to the plugins but Wow6432Node keys were added as well. The registry run keys are locations on a system which automatically start programs. Run keys are present in the Software registry hives which start programs when the operating system starts. Run keys are also present in the NTUSER.DAT hives and these execute programs when the user logs onto the system. These plugins are demonstrated against registry hives from a system infected with Symantec detection W32.SillyFDC (MD5 78c9d2949c81984414e6e1f5974905e1).

soft_run plugin

The soft_run plugin parses the run keys located in the Software hive. The following are the keys checked:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKLM\Software\ Microsoft\Windows\CurrentVersion\RunServices
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Runonce
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Run

Windows performs Win32 emulation on 64-bit operating systems to make 32-bit applications work. Part of the emulation is registry redirection. 32-bit applications are redirected to HKLM\Software\Wow6432Node when they try to access HKLM\Software. The additional Wow6432Node run keys parsed by the soft_run plugin are:

HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce

Running the soft_run plugin against the Software hive from the infected system produced the output below. In the output you will notice an entry for C:\Users\lab\Templates\cache\SFCsrvc.pif listed beneath a Wow6432Node. This malware entry provides us with a few different clues. First the malware obtained administrative privileges since a system-wide modification was made. The second was the malware was 32-bit executed on a 64-bit system.

soft_run v.20130329
(Software) [Autostart] Get autostart key contents from Software hive

Microsoft\Windows\CurrentVersion\Run
LastWrite Time Thu Apr 4 17:36:00 2013 (UTC)
VMware User Process - "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr

Microsoft\Windows\CurrentVersion\Run has no subkeys.

Microsoft\Windows\CurrentVersion\RunOnce
LastWrite Time Thu Apr 4 17:34:33 2013 (UTC)
Microsoft\Windows\CurrentVersion\RunOnce has no values.
Microsoft\Windows\CurrentVersion\RunOnce has no subkeys.

Microsoft\Windows\CurrentVersion\RunServices not found.

Wow6432Node\Microsoft\Windows\CurrentVersion\Run
LastWrite Time Thu Apr 4 18:48:45 2013 (UTC)
HotKey - C:\Users\lab\Templates\cache\SFCsrvc.pif
User Agent - C:\Windows\SysWOW64\fdisk.com

Wow6432Node\Microsoft\Windows\CurrentVersion\Run has no subkeys.

Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce
LastWrite Time Tue Jul 14 04:53:25 2009 (UTC)
Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce has no values.
Wow6432Node\Microsoft\Windows\CurrentVersion\RunOnce has no subkeys.

Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Run not found.

Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\RunOnce not found.

user_run plugin

The user_run plugin parses the run keys located in the NTUSER.DAT hive. The following are the keys checked:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce
HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Runonce
HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal
       Server\Install\Software\Microsoft\Windows\CurrentVersion\Run
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServicesOnce
Run value listed in HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows

Similar to the soft_run plugin, user_run also takes into account Win32 emulation on 64-bit operating systems. The additional Wow6432Node run keys parsed are:

HKCU\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
HKCU\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

Running the user_run plugin against the Software hive from the infected system produced the output below. In the output notice the entries for C:\Users\lab\Templates\cache\SFCsrvc.pif and C:\Users\lab\AppData\Local\Temp\svchost.com. The biggest clue provided by the output is the lab user account should be focused on to determine the initial infecton vector.

user_run v.20130329
(NTUSER.DAT) [Autostart] Get autostart key contents from NTUSER.DAT hive

Software\Microsoft\Windows\CurrentVersion\Run
LastWrite Time Thu Apr 4 18:48:45 2013 (UTC)
HotKey: C:\Users\lab\Templates\cache\SFCsrvc.pif
User Agent: C:\Users\lab\AppData\Local\Temp\svchost.com

Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run not found.

Software\Microsoft\Windows\CurrentVersion\RunOnce
LastWrite Time Thu Apr 4 17:35:09 2013 (UTC)

Software\Microsoft\Windows\CurrentVersion\RunOnce has no values.

Software\Microsoft\Windows\CurrentVersion\RunServices not found.

Software\Microsoft\Windows\CurrentVersion\RunServicesOnce not found.

Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\Run not found.

Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Windows\CurrentVersion\RunOnce not found.

Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run not found.

Software\Microsoft\Windows NT\CurrentVersion\Windows
LastWrite Time Thu Apr 4 18:48:46 2013 (UTC)
Run value = C:\Users\lab\AppData\Local\Temp\svchost.com
run value = C:\Users\lab\AppData\Local\Temp\svchost.com
load value = C:\Users\lab\AppData\Local\Temp\svchost.com

A new RegRipper plugin archive was released during the RegRipper Consolidation. The archive contains some new plug-ins; one of them is the MenuOrder.pl plug-in. Before discussing the plug-in I thought it would be helpful to first explain the importance of the registry key it parses. I was working a malware case when actions were taken in an attempt to remove the malware. Not only was malware deleted from the system but artifacts associated with the malware were deleted as well. Despite these actions taken, there was still evidence present in the MenuOrder registry key. This plug-in’s importance is not limited to malware cases; it’s important for any case where it’s important to know what programs or favorites were deleted from a system.

The MenuOrder registry key contains Start Menu and IE Favorites artifacts. The article Start Menu and IE Favorites Artifacts in the MenuOrder Registry Key explains in-depth how these artifacts get populated in this key. The article states:

“In most versions of Windows, a user can manually organize the order in which applications and application groups are displayed in the Start Menu. A user might, for example, drag a frequently-used application group to the top of the Start Menu and leave the remainder of the items in alphabetical order.”

“Similarly, a user can manually rearrange items in the Favorites menu”

In essence, when a user changes the display for either the Start Menu or IE Favorites these settings are stored in the registry. The information that gets stored includes the directory structure and file names for the program shortcuts in the Start Menu and favorites in IE. This means we are able to see how the Start Menu or IE favorites looked at a certain point in time even if actions were taken to delete the program shortcuts or favorites. The registry keys storing the information are:

- HCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu2\Programs

- HCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Favorites

This by itself makes the MenuOrder key a useful artifact to examine. However, Harlan discovered something even cooler. In his post DOSDate Time Stamps in Shell Items he mentions how the MenuOrder key contains shell items. This means there are timestamps accompanying the file and directory names stored in the registry key. It’s another source to get the creation dates for items.

I ran the plug-in against a Windows XP NTUSER.DAT hive I had laying around and here are a few snippets from its output (command was rip.pl –p menuorder –r ntuser.dat)


menuorder v.20121005

\Start Menu2
LastWrite: Wed Apr 9 13:15:39 2008 Z

\Start Menu2\Programs
LastWrite: Wed Oct 13 14:32:52 2010 Z
Microsoft Office 2003
Set Program Access and Defaults.lnk
Accessories
WinZip
Adobe Reader 9.lnk
Internet Explorer.lnk (@xpsp1res.dll,-11001)
Microsoft Access 2003.lnk
Microsoft Excel 2003.lnk
Microsoft PowerPoint 2003.lnk
Microsoft Word 2003.lnk

\Start Menu2\Programs\Accessories
LastWrite: Wed Jun 9 19:26:37 2010 Z
Accessibility (@shell32.dll,-21760)
Communications (@shell32.dll,-21768)
Entertainment (@shell32.dll,-21772)
System Tools
Address Book.lnk (@shell32.dll,-22017)
Calculator.lnk (@shell32.dll,-22019)
Command Prompt.lnk (@shell32.dll,-22022)
Notepad.lnk (@shell32.dll,-22051)
Paint.lnk (@shell32.dll,-22054)
Program Compatibility Wizard.lnk (@C:\WINDOWS\system32\compatUI.dll,-115)
Remote Desktop Connection.lnk
Synchronize.lnk (@shell32.dll,-22062)
Tour Windows XP.lnk (@C:\WINDOWS\system32\tourstart.exe,-1)
Windows Explorer.lnk (@shell32.dll,-22067)
WordPad.lnk (@shell32.dll,-22069)

.......

\Favorites\Links
LastWrite: Mon Oct 4 18:31:22 2010 Z
Customize Links.url
Free Hotmail.url
Windows.url
Windows Marketplace.url
Windows Media.url

\Favorites\Microsoft Websites
LastWrite: Tue Sep 7 15:34:21 2010 Z
IE Add-on site.url
IE site on Microsoft.com.url
Marketplace.url
Microsoft At Home.url
Microsoft At Work.url
Welcome to IE7.url

This is a piggyback post to an issue Harlan has been raising about the Wow64 issue. His most recent post on the subject Wow64Node: Registry Redirection goes into detail about what Wow64 is, it’s impact on registry analysis, and contains links to great resources. After giving some thought to this issue I’m in full agreement with Harlan when he said “this is huge”. Computing is moving on from 32-bit to 64-bit platforms. I am already witnessing the transition since the majority of the systems I see running Windows 7 are 64-bit. We are entering a 64-bit world and as this transition occurs systems will run both 64-bit and 32-bit applications. This is where Wow64 comes into play and I wanted to follow up Harlan’s post with a few more examples about why we should be aware about this issue. I’m not only expanding on what Wow64 is but I’m highlighting issues with our processes and tools to demonstrate why this is an important issue.

What Is Wow64

In addition to the links provided by Harlan, the Windows Internals book contains information about Wow64. It states “Wow64 (Win32 emulation on 64-bit Windows) refers to the software that permits the execution of 32-bit x86 applications on 64-bit Windows”. Part of the emulation involves redirecting a 32-bit application in both the file system and registry.

Windows Internals states the following about file system redirection:

“To maintain application compatibility and to reduce the effort of porting applications from Win32 to 64-bit Windows, system directory were kept the same. Therefore, the \Windows\System32 folder contains native 64-bit images. Wow64, as it hooks all the system calls, translates all the path-related APIs and replaces the path name of the \Windows\System32 folder with \Windows\Syswow64. Wow64 also redirects \Windows\LastGood to \Windows\LastGood\syswow64 and \Windows\Regedit.exe to \Windows\syswow64\Regedit.exe. Through the use of system environment variables, the %PROGRAMFILES% variable is also set to \Program Files (x86) for 32-bit applications, while it is set to \Program Files folder for 64-bit applications."

The file system redirection occurs transparently when a 32-bit application tries to access the System32 or LastGood folders. Something similar happens when 32-bit applications access the registry. Windows Internals mentions:

“the registry is split into two portions: Native and Wow64. By default, 32-bit components access the 32-bit view and 64-bit components access the 64-bit view”. “To implement this, Wow64 intercepts all the system calls that open registry keys and retranslates the key path to point it to the Wow64 view of the registry. Wow64 splits the registry at these points: HKLM\Software and HKEY_CLASSES_ROOT”. “Under each of these keys, Wow64 creates a key called Wow6432Node. Under this key is stored 32-bit configuration information. All other portions of the registry are shared between 32-bit and 64-bit applications (for example, HKLM\SYSTEM)."

The Win32 emulation on 64-bit Windows impacts our DFIR work because there are now additional locations we need to know about and examine. If we don’t Christian Wojner sums up the end result when he said

“In the worst case this can lead to an entirely wrong interpretation of a case/situation”

Wow64 Impact on Our Processes and Tools

Wow64 is one of the topics that have not been discussed extensively within our community. Harlan has been on his soapbox trying to raise awareness about its impact on our work and he provided examples how it affects registry analysis. Both Christian Wojner in his paper The “Wow-Effect” and Lenny Zelster in his post Incident Response on 64-Bit Windows Using 32-Bit Tools highlighted the impacts of file system redirection. Basically, the authors were demonstrating that an analyst may not be getting the whole picture when running 32-bit applications on a 64-bit system. The 32-bit applications were redirected to the \Windows\Syswow64 folder and were incapable of seeing the files located in the Windows\System32 folder. The “Wow-Effect” paper mentioned there are more situations and scenarios where the “Wow-Effect” can impact DFIR. He even suggested the reader could instantly come up with a lot more scenarios. I came up with a few and they impact: live, malware, and post-mortem analysis.

Wow64 Impact on Live Analysis

Both of Christian and Lenny's articles illustrated the Wow64 issue when performing live analysis. Wow64 introduces another wrinkle when performing live analysis besides running 32-bit executables on a 64-bit system. Indicators of Compromise (IOCs) are becoming more mainstream within enterprise environments. It appears more and more people are trying to leverage IOCs to determine if their organization is compromised. The wrinkle Wow64 throws into the process is on the way people use IOCs. IOCs are written by an author based on their systems and their environment. If a user downloads an IOC and runs it in their environment without knowing about the author's environment then the user may reach a false conclusion if the IOC performs a file and registry check.

There are very few public IOCs on the Internet. To illustrate my point I selected the publicly available Skyipot/Wyksol Trojan IOC. The IOC does a check on the following key:

Registry Path contains SOFTWARE\Microsoft\Windows\CurrentVersion\Run

If a user were to download this IOC and run checks against a 64-bit system they may encounter an issue and not even know about it. The Run key in the IOC is either for a 32-bit Skyipot/Wyksol Trojan on a 32-bit system or a 64-bit Skyipot/Wyksol Trojan on a 64-buit system. If a 64-bit system was infected with a 32-bit Skyipot/Wyksol Trojan then the Run key of interest will be located underneath the HKLM\ SOFTWARE\Wow6432Node. The current registry check in the Skyipot/Wyksol IOC will miss it. As more and more organizations start to use IOCs it will be critical for them to make sure they are using IOCs that are compatible with their 64-bit/32-bit environments. Otherwise the IOCs won't be as effective as they should be.

Wow64 Impact on Malware Analysis

Practical Malware Analysis defines malware analysis as "the art of dissecting malware to understand how it works, how to identify it, and how to defeat or eliminate it". At times when reversing malware dynamic analysis is performed to see how the malware behaves as it executes. This is an excellent technique to identify what changes are made to the system such as file creation or registry modification. The intelligence gained by identifying these changes can be used to write IOCs, provide others will indicators to look for, or to perform checks on other systems to determine if they are infected. The Wow64 issue comes into play when doing malware analysis; both if it is done using an online service or your own platform.

Online malware analysis services provide an easy method for people to perform dynamic analysis on a piece of malware. There are numerous free online services to choose from and I randomly selected ThreatExpert. Unfortunately, a good number of these services don’t provide detailed information about the systems the malware executes on so the information they provide may not be complete. To illustrate let’s use the Wow64 issue to see what we can find out about the systems on ThreatExpert. The Run key I mentioned before (it’s also the same one Harlan mentioned) is a popular location for malware to maintain persistence on a system. Searching the ThreatExpert site shows numerous malware reports with this registry key (Google search had 10,400 results). Now let’s search for the same key but taking Wow64 into account by searching for this key.

SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run

The Google search resulted in two hits; seriously only two hits. This demonstrates the majority of the ThreatExpert analysis is not running 32-bit malware on a 64-bit system to reveal all artifacts. ThreatExpert is not the only service where this occurs; happens at Anubis (419 Google Results vs. Zero Google Results) and antivirus sites such Symantec (8,800 Google Results vs. Zero Google Results).

Side note: to perform the Google search use the site: operator to point it at the website. My attempts to included the links to the search results didn't work.

Wow64 has the same impact on those who perform malware analysis themselves as opposed to online services. Are 32-bit malware being executed on 64-bit systems? If not, then the end result will be similar to the antivirus and automated analysis sites.

Wow64 Impact on Post-mortem Analysis

Harlan did an outstanding job highlighting the impact Wow64 has on registry analysis. There are a lot more autostart locations beneath the Wow6432Node then just the Run key. These locations are not getting parsed by numerous registry analysis tools. From open source tools to really expensive software such as the one that starts “En” and ends in “Case” (I’m running v6.X). Side note: as Harlan mentioned RegRipper is getting updated to account for Wow64. There are other important registry keys that have a 32-bit equivalent beneath Wow6432Node that has nothing to do with malware or autostart locations.

One of my initial steps in any case is to profile the system to get a better understanding about what I’m facing. One of the areas I consider when profiling is the installed software on a system. It tells me a lot about what type of data and artifacts I should expect. Harlan mentioned in a previous post how the Uninstall key beneath the Wow6432Node contained references to software not listed in the 64-bit Uninstall registry key. Well, I just looked at my system and I’m seeing the same thing. If I don’t take into account the Wow64 issue when profiling a system then I won’t see the complete picture.

Summary

Despite how the phrase is constantly misquoted: “Houston, we have a problem”. The proper quote and one that more closely resembles the Wow64 issue is “Houston, we’ve had a problem”. As in past tense, as in the problem has already occurred. The Wow64 issue is a significant problem and in the near future it will only become worse as the computing environment continues to move from the 32-bit to 64-bit world. Those of us who are aware about Wow64 can adjust to account for this when faced with 64-bit systems. Those who aren’t aware; well the misquote will apply to them. They will have a problem and it could lead them to “an entirely wrong interpretation of a case/situation.”

In closing, I wanted to say thank you to Harlan. Thanks for being consistent with trying to bring this issue to the forefront and making the community more aware about its significance.

In this Linkz edition I’m mentioning write-ups discussing tools. A range of items are covered from the registry to malware to jump lists to timelines to processes.

RegRipper Updates

Harlan has been pretty busy updating RegRipper. First RegRipper version 2.5 was released then there were some changes to where Regripper is hosted along with some nice new plugins. Check out Harlan’s posts for all the information. I wanted to touch on a few of the updates though. The updates to Regripper included the ability to run directly against volume shadow copies and parse big data. The significance to parsing big data is apparent in his new plugin that parses the shim cache which is an awesome artifact (link up next). Another excellent addition to RegRipper is the shellbags plugin since it parses Windows 7 shell bags. Harlan’s latest post Shellbags Analysis highlights the forensic significance to shell bags and why one may want to look at the information they contain. I think these are awesome updates; now one tool can be used to parse registry data when it used to take three separate tools. Not to be left out the community has been submitting some plugins as well. To only mention a few Hal Pomeranz provided some plugins to extract Putty and WinSCP information and Elizabeth Schweinsberg added plugins to parse different Run keys. The latest RR plugin download has the plugins submitted by the community. Seriously, if you use RegRipper and haven’t checked out any of these updates then what are you waiting for?

Shim Cache

Mandiant’s post Leveraging the Application Compatibility Cache in Forensic Investigations explained the forensic significance of the Windows Application Compatibility Database. Furthermore, Mandiant released the Shim Cache Parser script to parse the appcompatcache registry key in the System hive. The post, script, and information Mandiant released speaks for itself. Plain and simple, it rocks. So far the shim cache has been valuable for me on fraud and malware cases. Case in point, at times when working malware cases programs execute on a system but the usual program execution artifacts (such as prefetch files) doesn’t show it. I see this pretty frequently with downloaders which are programs whose sole purpose is to download and execute additional malware. The usual program execution artifacts may not show the program running but the shim cache was a gold mine. Not only did it reflect the downloaders executing but the information provided more context to the activity I saw in my timelines. What’s even cooler than the shim cache? Well there are now two different programs that can extract the information from the registry.

Searching Virus Total

Continuing on with the malware topic, Didier Stevens released a virustotal-search program. The program will search for VirusTotal reports using a file’s hash (MD5, SHA1, SHA256) and produces a csv file showing the results. One cool thing about the program is it only performs hash searches against Virustotal so a file never gets uploaded. I see numerous uses for this program since it accepts a file containing a list of hashes as input. One way I’m going to start using virustotal-search is for malware detection. One area I tend to look at for malware and exploits are temporary folders in user profiles. It wouldn’t take too much to search those folders looking for any files with an executable, Java archive, or PDF file signatures. Then for each file found perform a search on the file’s hash to determine if VirusTotal detects it as malicious. Best of all, this entire process could be automated and run in the background as you perform your examination.

Malware Strings

Rounding out my linkz about malware related tools comes from the Hexacorn blog. Adam released Hexdrive version 0.3. In Adam’s own words the concept behind Hexdrive is to “extract a subset of all strings from a given file/sample in order to reduce time needed for finding ‘juicy’ stuff – meaning: any string that can be associated with a) malware b) any other category”. Using Hexdrive makes reviewing strings so much easier. You can think of it as applying a filter across the strings to initially see only the relevant ones typically associated with malware. Then afterwards all of the strings can be viewed using something like Bintext or Strings. It’s a nice data reduction technique and is now my first go to tool when looking at strings in a suspected malicious file.

Log2timeline Updates

Log2timeline has been updated a few times since I last spoke about it on the blog. The latest release is version 0.64. There have been quite a few updates ranging from small bug fixes to new input modules to changing the output of some modules. To see all the updates check out the changelog.

Most of the time when I see people reference log2timeline they are creating timelines using either the default module lists (such as winxp) or log2timeline-sift. Everyone does things differently and there is nothing wrong with these approaches. Personally, both approaches doesn’t exactly meet my needs. The majority of the systems I encounter have numerous user profiles stored on them which mean these profiles contain files with timestamps log2timeline extracts. Running a default module list (such as winxp) or log2timeline-sift against the all the user profiles is an issue for me. Why should I include timeline data for all user accounts instead of the one or two user profiles of interest? Why include the internet history for 10 accounts when I only care about one user? Not only does it take additional time for timeline creation but it results in a lot more data then what I need thus slowing down my analysis. I take a different approach; an approach that better meets my needs for all types of cases.

I narrow my focus down to specific user accounts. I either confirm who the person of interest is which tells me what user profiles to examine. Or I check the user profile timestamps to determine which ones to focus on. What exactly does this have to do with log2timeline? The answer lies in the –e switch since it can exclude files or folders. The –e switch can be used to exclude all user profiles I don’t care about. There’s 10 user profiles and I only care about 2 profiles but I only want to run one log2timeline command. No problem if you use the –e switch. To illustrate let’s say I’m looking at the Internet Explorer history on a Windows 7 system with five user profiles: corey, sam, mike, sally b, and alice. I only need to see the browser history for the corey user account but I don’t want to run multiple log2timeline commands. This is where the –e switch comes into play as shown below:

log2timeline.pl -z local -f iehistory -r -e Users\\sam,Users\\mike,"Users\\sally b",Users\\alice,"Users\\All Users" -w timeline.csv C:\

The exclusion switch eliminates anything containing the text used in the switch. I could have used sam instead of Users\\sam but then I might miss some important files such as anything containing the text “sam”. Using a file path limits the amount of data that is skipped but will still eliminate any file or folder that falls within those user profiles (actually anything falling under the C root directory containing the text Users\username). Notice the use of the double back slashes (\\) and the quotes; for the command to work properly this is needed. What’s the command’s end result? The Internet history from every profile stored in the Users folder except for the sam, mike, sally b, alice, and all user profiles is parsed. I know most people don’t run multiple log2timeline commands when generating timelines since they only pick one of the default modules list. Taking the same scenario where I’m only interested in the corey user account on a Windows 7 box check out the command below. This will parse every Windows 7 artifact except for the excluded user profiles (note the command will impact the filesystem metadata for those accounts if the MFT is parsed as well).

log2timeline.pl -z local -f win7 -r -e Users\\sam,Users\\mike,"Users\\sally b",Users\\alice,"Users\\All Users" -w timeline.csv C:\

The end result is a timeline focused only on the user accounts of interest. Personally, I don't use the default module lists in log2timeline but I wanted to show different ways to use the -e switch.

Time and Date Website

Daylight savings time does not occur on the same day each year. One day I was looking around the Internet for a website showing the exact dates when previous daylight savings time changes occurred. I came across the timeanddate.com website. The site has some cool things. There’s a converter to change the date and time from one timezone to another. There’s a timezone map showing where the various timezones are located. A portion of the site even explains what Daylight Savings Time is. The icing on the cake is the world clock where you can select any timezone to get additional information including the historical dates of when Daylight Savings Time occurred. Here is the historical information for the Eastern Timezone for the time period from the year 2000 to 2009. This will be a useful site when you need to make sure that your timestamps are properly taken into consideration Daylight Savings Time.

Jump Lists

The day has finally arrived; over the past few months I’ve been seeing more Windows 7 systems than Windows XP. This means the artifacts available in the Windows 7 operating system are playing a greater role in my cases. One of those artifacts is jump lists and Woanware released a new version of Jumplister which parses them. This new version has the ability to parse out the DestList data and performs a lookup on the AppID.

Process, Process, Process

Despite all the awesome tools people release they won’t be much use if there isn’t a process in place to use them. I could buy the best saws and hammers but they would be worthless to me building a house since I don’t know the process one uses to build a house. I see digital forensics tools in the same light and in hindsight maybe I should have put these links first. Lance is back blogging over at ForensicKB and he posted a draft to the Forensic Process Lifecycle. The lifecycle covers the entire digital forensic process from the Preparation steps to triage to imaging to analysis to report writing. I think this one is a gem and it’s great to see others outlining a digital forensic process to follow. If you live under a rock then this next link may be a surprise but a few months back SANS released their Digital Forensics and Incident Response poster. The poster has two sides; one outlines various Windows artifacts while the other outlines the SANs process to find malware. The artifact side is great and makes a good reference hanging on the wall. However, I really liked seeing and reading about the SANs malware detection process since I’ve never had the opportunity to attend their courses or read their training materials. I highly recommend for anyone to get a copy of the poster (paper and/or electronic versions). I’ve been slacking updating my methodology page but over the weekend I updated a few things. The most obvious is adding links to my relevant blog posts. The other change and maybe less obvious is I moved around some examination steps so they are more efficient for malware cases. The steps reflect the fastest process I’ve found yet to not only find malware on a system but to determine how malware got there. Just an FYI, the methodology is not only limited to malware cases since I use the same process for fraud and acceptable use policy violations.

When I approach an analysis I perform the same initial steps to shed light on the system under examination. The first step is to review the master boot record and the second step is to obtain general information about the operating system and its configuration. The impact of the information on a digital forensic analysis can be significant.

Quick note before anyone takes the time to read further. My post doesn’t offer any new information. The registry keys referenced are well documented and the automation of Regripper is not new. I find it helpful to see how other analysts use tools and I thought others may feel the same way. My post demonstrates how Regripper can be automated in a batch file to reveal general information about a system; thereby saving some time when completing the information gathering examination step.

RegRipper is an open source tool for extracting data stored in the registry. When reviewing Regripper’s output I reference a document I created (outlines various artifacts) which allows me to see the data from registry keys in a specific order. I never thought twice about reviewing the output like this since I was only getting the initial information about the operating system. A couple of weeks ago I was going through Regripper reports when it dawned on me that I should automate the process. Create one report showing the information from the registry keys in a specific order. I wrote a small batch script to automate the creation of the operating system information report. If you just want the script then use the link at the end of the post. Otherwise, you can keep reading to see my thought process of how I put the script together before checking out the file. The script organizes information into the following five categories: general operating system information, user information, software information, networking information, and storage locations.

Thought Process behind the Batch File

        General Operating System Information

The first category has a significant impact on how the examination is conducted since it contains information about the operating system such as version, timezone settings, and machine security identifier (SID). The operating system version will dictate where certain artifacts are located and what tools can be used while the timezone settings should be self explanatory. The machine security identifier comes into play when looking at the user accounts’ SIDs since it shows if the user account is from the local or remote system. The following is the category’s information of interest and the registry keys containing the data:

* Operating system version and product name (HKLM\Software\Microsoft\Windows NT\Currentversion\)

* Registration information for owner and organization entered during installation (HKLM\Software\Microsoft\Windows NT\Currentversion\)

* Machine Security Identifier (SID) (HKLM\Security\Policy\PolAcDms)

* Shutdown information (HKLM\System\Controlset###\Control\Windows)

* Timezone information (HKLM\System\Currentcontrolset\Control\Timezoneinformation)

* Auditing configuration (HKLM\Security\Policy\PolAdtEv)

* Determine if the NTFS last access time is set to not to update (HKLM\System\CurrentControlSet\Control\Filesystem\NtfsDisableLastAccessUpdate)

        User Account Information

The next category obtains information about the user accounts associated with the computer. The information includes the configured local user accounts and groups as well as the artifacts of other user accounts (such as Windows domain users) logging onto the system. The category can help focus the examination on the activity of specific user accounts. The following is the category’s information of interest and the registry keys containing the data:

* Configured local user accounts and groups (HKLM\SAM\Domains\Account\)

* User profiles on machine and registered with Windows (Profilelist registry key)

* Logon username of the specified user account (HKCU\ Software\Microsoft\Windows\CurrentVersion\Explorer)

* Previous user accounts to log onto the machine (HKLM\Software\Microsoft\Windows NT\Currentversion\Winlogon\Defaultusername and HKLM\Software\Microsoft\Windows NT\Currentversion\Winlogon\Altdevaultusername)

        Software Information

The software category obtains information about programs installed and executed on the system. Knowing the software on a system can help shed light on the potential data available. For example, if the examination is interested in locating financial files then the software category will reveal the financial programs on the system thereby identifying the relevant file types. The following is the information of interest in the category and the registry keys containing the data:

* Programs showed on the Add/Remove Programs control panel applet (HKLM\Software\Microsoft\Windows\Currentversion\Uninstall)

* File system paths to various programs (HKLM\Software\Microsoft\Windows\Currentversion\App paths)

* Information about installed products (HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\UserData)

* Default web browser (one area to check is HKLM\Software\Classes\HTTP\shell\open\command)

* User specific software (HCU\Software)

* User activity via the Windows Explorer shell may show programs ran (HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist)

* Executables associated with the user account (XP is HKCU\Software\Microsoft\Windows\ShellNoRoam\MUICache and Vista/7 is is HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache in userclass.dat)

        Networking Information

The next category obtains information about networking such as the computer’s name, network shares, and firewall settings. The majority of computers are connected to some sort of network and the information in this category helps explain the type of network the system came from. The following is the information of interest in the category and the registry keys containing the data:

* Computer name (HKLM\System\Currentcontrolset\Control\Computername)

* Domain and hostname (HKLM\System\Currentcontrolset\Services\Tcpip\Parameter)

* Configured network shares on the computer (HKLM\System\Currentcontrolset\Services\Lanmanserver\Shares)

* Configured persistent routes (HKLM\System\ControlSet###\Services\Tcpip\Parameters\PersistentRoutes)

* Firewall configuration (HKLM\System\Currentcontrolset###\Services\Sharedaccess\Parameters\Firewallpolicy)

* Networking information (HKLM\System\Currentcontrolset###\Network)

* Cache of computers seen by Windows Explorer (HKCU\Software\Microsoft\Windows\Currentversion\Explorer\Computerdescriptions)

        Storage Location Information

The last category obtains information about the potential storage locations for user data. The category can reveal additional devices or folders that may contain data of interest. For example, the majority of Window systems I’ve seen in a corporate environment belong to a Windows domain where the IT departments have users store information on servers instead of their own computer (for backup purposes). One method used is to redirect certain folders in the user account’s profile – such as the My Documents- to a folder on the server. The storage location information category will quickly highlight this type of configuration. The following is the information of interest in the category and the registry keys containing the data:

* Devices and volumes mounted to the computer (HKLM\System\MountedDevices)

* Location of the user account profile folders (HKCU\Software\Microsoft\Windows\Currentversion\Explorer\User shell folders)

* Map network drives available to a user (HKCU\Software\Microsoft\Windows\Currentversion\Explorer\Map network drive MRU)

* Volumes mounted by a user (HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2)

Putting the Batch File Together

Putting the batch file together was fairly simple since I already outlined the order of the information I wanted presented and Regripper had plug-ins to extract the data from the registry. The batch file repeats the following three lines for each Regripper plugin to create one report about the operating system and how it’s configured.

echo: >> operating_system_information.txt
rip.exe -r "%regpath%\SECURITY" -p polacdms >> operating_system_information.txt
echo .........................................................................................................>> operating_system_information.txt

The two lines starting with echo are for formatting purposes. The echo: inserts a blank line in the operating_system_information.txt while the other echo command inserts a line of dots to separate each Regripper plug-in. Rip.exe is the commandline version of Regripper and there are two options. The –r specifies the registry hive and –p specifies the plug-in to run. The variable %regpath% gets populated with a prompt for the folder path containing the registry hives.

The batch file gets put in the Regripper folder and gets executed by double clicking the file. Three screenshots show the script against an image mounted with FTK imager.

Prompt for folder containing the registry hives

Asks to parse user's registry hive then prompts for its folder location

Regripper parsing the registry hives and creating the report

Portion of the report showing the Software and Networking Information categories

The information in the report doesn’t include everything that I’d want to know over the span of an examination but it does provide the initial information about the operating system and how it’s configured. Automating the process makes me a little bit more efficient when I’m completing the examination step.

I uploaded the batch file to the jIIr Google site and the file can be downloaded here (to execute the file change the file extension from txt to bat).

A forensicator lives on the 10th floor of a building. Every morning he rides down the elevator to the ground floor and leaves the building to go to his forensic lab. Every night he comes home after spending the day finding evil and gets on the elevator. If it was raining then he takes the elevator to the 10th floor. If the weather is good then he takes the elevator to the 7th floor and walks to the 10th floor using the stairs. Why does he do this?

The forensicator in the elevator is an analogy to a malware infected system. Trying to answer the above riddle cannot be done without looking at the man in his environment (the building). Picturing the forensicator in the building and everything that is in the elevator will shed light on to question of why he takes the stairs. This is similar to answering the question of how malware infected a system. The question can’t be answered without looking at the malware in its environment (the affected system) and examining the other activity on the system around the time the malware appeared. Take the antivirus write-ups as an example. The majority of the write-ups (I’ve read) analyze the malware outside of the environment where it was located. As a result, the write-ups provide vague information on the initial infection vector used such as the statement “distributed through spam campaigns and drive-by downloads, though given its versatility, other vectors may also be utilized”. The description doesn’t shed much light on how a specific system became infected since pretty much all of the bases are covered (SPAM, drive-bys, or some other method). If you have ever wondered what the artifacts are of malware being delivered through SPAM then the rest of this article will be of interest.

Someone was nice enough to send me a SPAM email last month (sarcasm doesn’t come off the some way as the spoken word). The SPAM was a mass mailing so I was probably just one recipient out of thousands but at least the email gave me something to analyze. The examination of this email will first explain the user’s actions followed by the DFIR practitioner’s examination.

Accessing Email

        User Perspective

The user fires up a web browser to check their email. Internet Explorer loads the home page before the user navigates to Yahoo email. A few emails are checked before the user comes across the message below.


The user overlooks the indications that the email is SPAM such as the misspellings, punctuation errors, and even a run-on sentence (see the picture below to see what was missed). They proceed to read the notification letter alerting them to some kind of issue with their tax return.

      
        DFIR Perspective

The forensicator was slowly making their way through a system timeline when there was activity involving Internet Explorer. There were modifications made to few Internet Explorer folders in the Administrator user account’s profile and the user account visited a Microsoft’s webpage.


After weeding through all of the web activity related to the Microsoft webpage he noticed the user went to Yahoo’s webpage and accessed their webmail.


The browser history and cache showed that the user spent some time using Yahoo email.

Opening the Email Attachment

        User Perspective

Worried there might be an issue with their tax return the user decides to open the email attachment. The user felt more comfortable opening the attachment since Norton Antivirus indicated it was virus free.


The attachment doesn’t initially open a document but instead opens a new window showing a file with the name IRS document.exe. Even though file extensions weren’t hidden by Windows Explorer the user didn’t notice the exe extension since they were too distracted worrying about not receiving their tax refund.


        DFIR Perspective

The Internet activity indicated the user was still accessing their Yahoo email when an entry at 06/20/2011 22:10:00 showed the user downloading a zip file.


The file IRS%20document[1].zip was created in the folder \Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\M20M2OXX\ one second after the browser entry made a reference to a zip file in Yahoo email.

Aftermath of Accessing Email Message

        User perspective

The user double clicks the file named “IRS document.exe” thinking the file contains the list of missing documents but nothing visually occurs. A document doesn’t open, no error messages popup, and the list of missing documents isn’t shown. The user closes the attachment’s Explorer window at 06/20/2011 10:22 and continues surfing the Internet. This is the point in the story where the user perspective ends. The story tried to illustrate how someone could be tricked into opening the attachment in the SPAM email.

        DFIR perspective

The forensicator continued to work his timeline when there was a flurry of activity involving executables. The first artifact was a prefetch file for a program - IRS document.exe - (MD5 hash 77065d6545b0226ccf66ce75d5254bfa and link to the VirusTotal report) that was the executable inside of the zip attachment. 10 seconds later the Windows svchost.exe executable ran before two additional malware were dropped on the system. The malware was PUSK3_~1.EXE (MD5 hash 541c25d26e8b1eb2d1a35cd52854650f and link to the VirusTotal report) and tmp75D5.tmp (MD5 hash 4bda47a91bea4ceccc6003a46aeb754d and link to the VirusTotal report). The executable activity is shown in the picture below.


The forensicator tied the execution of the IRS document.exe and pusk3.exe to the administrator account by finding the following information in the account’s MUICache registry key.

C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\Temporary Directory 1 for IRS%20document[1].zip\IRS document.exe (IRS document)
C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\pusk3.exe (ProcFeatures)

The last artifact pointing to a zip file occurred at 06/20/2011 10:22 and it was modifications being made to the HCU\Software\Microsoft\Windows\ShellNoRoam\BagMRU registry key. A summary of the information in the BagMRU registry key is provided below.

* Bag: 9
* Registry Key modification Time [UTC]: 06/21/11 02:12:22.734
* Folder Name: IRS%20document[1].zip
* Full Path: Desktop\{CLSID_MyComputer}\C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\M20M2OXX\IRS%20document[1].zip\

Summary

The artifacts of malware being delivered through SPAM consisted of a user accessing email and opening a file around the same time. These artifacts hold true for malware being delivered via email even if the circumstances are different. At one point I examined an infected system which didn’t involve the IRS notification letter SPAM or web email. The activity on the system showed emails were assessed around the time a zip file was opened which happened just before the first piece of malware appeared on the system. All of the activity (and lack of other activity such as a drive-by download) lead me to conclude the malware was the result of a malicious email attachment. The specific artifacts in the examination varied slightly compared to what was discussed in this article but the general overall artifacts (email and file access prior to malware appearing) remained consistent.

Only examining malware from a system may not indicate email was the vehicle used deliver it. This is similar to antivirus write-ups about the analysis of malware which leave out information about how a specific computer became infected. The same line of thinking applies to the well known but slightly modified riddle at the beginning of the post. The riddle can’t be answered by solely analyzing the man outside of his building. Sure the analysis will reveal a lot of information about the man but it won’t explain why he is on the 7th floor of his building. The man needs to be analyzed in his building and the activity that occurred prior to him reaching the 7th floor should be reviewed. Trying to solve the riddle in this manner will reveal the answer of why he walks the stairs from the 7th to the 10th floor. The guy is too short to press the 10th floor elevator button and the highest he can reach - without an umbrella - is the 7th floor button. Like the man in the riddle, the activity on a system preceding the malware should be analyzed to determine if an email, drive-by, or some other means was used for the delivery.

Your onsite performing a collection or you are in your lab when a computer is given to you and you don’t have a lot of time to answer a few initial questions. How would you quickly determine someone’s activity on the computer? What pictures were viewed, programs ran, files accessed, or removable devices used? Quickly assessing the computer will not only provide information to answer these questions but will also reveal relevant data storage locations for an investigation. This post describes a process – including tools usage – where a few initial questions can be answered in a matter of minutes by examining the user activity on a computer.

Approaching the Triage

I know I promised to write about how to answer questions in less than two minutes by examining user activity on a computer. Before I dive into the land of ones and zeros I wanted to take a step back to talk about the thought process of how to approach the triage. Goals need to be established and a plan needs to be developed on how those goals can be obtained. To accomplish this, the first three questions of the Alexiou Principle can be used:

* What question are you trying to answer?
* What data do you need to answer the question?
* How do you extract that data?

The Alexiou Principle is very versatile since it can be to create analysis design plans, assist with DFIR training (as I described in the Forensicator Readiness post), and guide the thought process for triaging. The first Alexiou Principle question is what question you are trying to answer and this question is pretty self explanatory. As it relates to triage, what are the initial questions to determine if “something” is relevant to the digital forensic examination? The initial questions will vary based on the type of DFIR case and customer needs but the opening paragraph provided a few example questions.

The second Alexiou Principle question is what data do you need to answer the question? The data not only includes data sources such as computers, servers, and people but it also includes what information in those data sources can help answer the questions. Take for example the question was someone accessing the jIIr blog and the only data source available is the person’s computer. What data in the computer can help determine if the person visited my blog? A few areas to check could be the installed software (what web browser are installed), web browser artifacts (history, cookies, or favorites/bookmarks), and maybe the TypedURLs key in the user account’s NTUSER.DAT hive.

The third Alexiou Principle question is how do you extract that data? The tools selected to perform the triage need to be able to extract the data that is required to answer the initial questions. This means the selection of tools should not occur before the data is identified since this may force people to have to work within the confines of the tools. Instead, the selection of tools should be one of the last things completed since the tools to use will be dependent on the goal(s) of the assessment. I wanted to mention this point because I’ve seen numerous times where discussions are started with “should I use this tool” when the discussion should start with this is what I’m trying/need to accomplish.

Triaging User Activity in Under Two Minutes

Now that I’ve explained the thought process of how to approach the assessment of user activity on a computer I’ll walk through an issue I had at one point. I work in corporate environments and as expected the majority of the networks are running Windows domains. A Windows domain can have a significant impact on digital forensic examination because the computer being collected may not contain all of the data relevant to an investigation. The IT department may have assigned home folders to employees using company computers to make it easier for the IT department to back up people’s files. If an organization is using home folders then most likely the organization is encouraging users to store all of their data in their home folders instead of the computers’ My Documents folders. In addition to home folders, the person may be accessing and storing data in network shares. One of the initial questions I need to answer in this type of environment is what data sources - besides the person’s computer – do I need to collect?

Two options to determine what data sources - besides the person’s computer – need to be collected is speaking with the IT department or quickly triaging the computer. IT departments are not known for their great documentation skills so the better option is to triage the computer to find the answer. What data is needed to determine the network shares a person accessed? The data to answer the question could be located in the person’s activity on the computer. Three locations containing user activity are the registry, system restore points/volume shadow copies’ registry files, and the link files in the user account’s profile. For additional references on the evidentiary value of the registry check out the book Windows Registry Forensics while the Digitial Forensic Search custom Google query for link files can be used to learn more about them.

How do you extract data stored in registry and link files? I took into account the following for my tool selection: had to extract the data, had to be fast, had to be command line tools (you’ll see why), and my preference was for tools already in my toolbox. Harlan Carvey’s Regripper was chosen to parse the registry files, Harlan’s RipXP (included in the Regripper downloaded) was chosen to parse the registry files in system restore points, a modified version of Harlan’s lslnk.pl script to parse the link files and FTK Imager to mount the hard drive/image.

The example I’m using is to determine the network shares accessed but keep in mind this will work for other types of user activity since the registry and link files store the information. I promised to write about how to answer a few initial questions in less than two minutes by assessing the user activity on the computer. Here goes ………..

Mount the Image/Hard Drive

The situation will dictate if the computer’s hard drive will be examined using a write blocker or if the forensic image of the computer’s hard drive will be examined. The triage will work the same regardless if the hard drive or image is being examined. When quickly triaging a system my preference is to parse the data of interest where it’s located instead of copying the data to my forensic computer. The image/hard drive has to be mounted to the forensic computer in order for the registry and link files to be parsed in their storage locations and this can be accomplished using FTK Imager version 3.0 with the “File System / Read Only” mount option (allows access to system restore points). F:\[root]\ is the path to the root of the volume I’m examining and the commands below will reflect the path.

User Activity Stored in Registry

A user account’s NTUSER.DAT registry hive stores configuration information and the user account activity on the system. A quick way to identify registry keys of interest (in addition to the Windows Registry Forensics book) is to reference registry checklists like AccessData’s Registry Quick Find Chart or review the Regripper’s plugin files. The three registry keys of interest are: Map Network Drive MRU since it lists the recently mapped network drives, MountPoints2 since it lists devices accessed, and RunMRU since one way to access network shares is using the run dialog box. Regripper has plugins to parse all three registry keys and the commands for running the command-line version of Regripper with the output being redirected to a text file is below.

rip.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -p mndmru >> rip-drives.txt

rip.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -p mp2 >> rip-drives.txt

rip.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -p runmru >> rip-drives.txt

The first command uses -p mndmru to specify the plugin for the Map Network Drive MRU registry key. The output of this command identifies four network shares that were mapped to the user account of interest as shown below.

Map Network Drive MRU
Software\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
LastWrite Time Sat May 14 18:13:18 2011 (UTC)
MRUList = dcba
c \\192.168.1.80\Map Drive 2
a \\192.168.1.80\Map Drive D
b \\192.168.1.80\Map Drive 1
d \\192.168.1.80\Map Drive 3

The second command uses -p mp2 to specify the plugin for the MountPoints2 registry key. The output of this command also identifies the same four network shares. A portion of the output is shown below.

MountPoints2
Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2
LastWrite Time Sat May 14 18:19:16 2011 (UTC)

Remote Drives:
Sat May 14 18:13:18 2011 (UTC)
##192.168.1.80#Map Drive 3
Sat May 14 18:04:37 2011 (UTC)
##192.168.1.80#Map Drive 2
Sat May 14 17:59:27 2011 (UTC)
##192.168.1.80#Map Drive 1
Sat May 14 17:56:10 2011 (UTC)
##192.168.1.80#Map Drive D

The third and last command uses -p runmru to specify the plugin for the RunMRU registry key. The output of this command shows the same device with the four network shares (192.168.1.80) as well as a new device (192.168.2.50). The output doesn’t show any network shares being accessed but it does attempts were made to access the devices in a method that will display the network shares (\\IP-Address). The runmru output is shown below.

RunMru
Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU
LastWrite Time Sat May 14 18:22:00 2011 (UTC)
MRUList = bca
a cmd\1
b \\192.168.2.50\1
c \\192.168.1.80\1

User Activity Stored in System Restore Points (or Volume Shadow Copies) Registry Files

Windows system restore uses restore points to return system files and settings to an earlier point in time for computers running Windows 2000 or XP. Windows Vista and 7 uses volume shadow copies instead of restore points. Registry files covering different points of time in the past are located the restore points and volume shadow copies, and these files may contain additional information about user account activity. To parse the registry hives in the volume shadow copies a simple batch file using the command-line version of Regripper can be used. RipXP.exe can be used to parse a key in the current registry hive and the registry hives in the restore points (RipXP.exe parses the current registry hive so the rip.exe commands can be skipped when using RipXP.exe in this triage method). RipXP.exe requires three switches: -r specifies the current registry hive, -d specifies the restore point directory, and –p specifies the plug to use. The commands to parse the three registry keys of interest with the output being redirected to a text file are below.

ripxp.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -d "F:\[root]\System Volume Information\_restore{3F806DB1-464B-46B0-B724-4376EC868222}" -p mndmru >> rip-rp-mndmru.txt

ripxp.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -d "F:\[root]\System Volume Information\_restore{3F806DB1-464B-46B0-B724-4376EC868222}" -p runmru >> rip-rp-runmru.txt

ripxp.exe -r "F:\[root]\Documents and Settings\Administrator\NTUSER.DAT" -d "F:\[root]\System Volume Information\_restore{3F806DB1-464B-46B0-B724-4376EC868222}" -p mp2 >> rip-rp-mp2.txt

The output of all three commands will be similar to the Regripper output I showed before with the exception the registry keys in all of the restore points being displayed. I'm only showing a portion of the Map Drive MRU registry key output since it demonstrates how the output will look. As can be seen below, RipXP.exe output first displays the registry data from the current registry hive before the restore point registry data. The current Map Drive MRU key has four mapped network drives while the restore point shown only has three.

RipXP v.20090818
Launched Sat May 14 19:46:12 2011 Z

F:\[root]\Documents and Settings\Administrator\NTUSER.DAT
Map Network Drive MRU
Software\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
LastWrite Time Sat May 14 18:13:18 2011 (UTC)
MRUList = dcba
c \\192.168.1.80\Map Drive 2
a \\192.168.1.80\Map Drive D
b \\192.168.1.80\Map Drive 1
d \\192.168.1.80\Map Drive 3
----------------------------------------
Restore Point Info
Description : access share files
Type : System CheckPoint
Creation Time : Sat May 14 18:08:38 2011

F:\[root]\System Volume Information\_restore{3F806DB1-464B-46B0-B724-4376EC868222}\RP10\snapshot\_REGISTRY_USER_NTUSER_S-1-5-21-1214440339-1708537768-725345543-500

Map Network Drive MRU
Software\Microsoft\Windows\CurrentVersion\Explorer\Map Network Drive MRU
LastWrite Time Sat May 14 18:04:37 2011 (UTC)
MRUList = cba
c \\192.168.1.80\Map Drive 2
a \\192.168.1.80\Map Drive D
b \\192.168.1.80\Map Drive 1

User Activity Stored in Link Files

The registry provides a wealth of information but link files is another location containing information about a user account activity on a computer. A link file is created when a person accesses a file on their computer's hard drive, removable media, or a network share. The link file contains information about the file including its storage location which will show someone accessing network shares. A few locations containing link files are:

Windows XP: C:\Documents and Settings\username\Recent and C:\Documents and Settings\\Application Data\Microsoft\Office\Recent

Windows Vista and 7: C:\Users\username\AppData\Roaming\Microsoft\Windows\Recent and C:\Users\\AppData\Roaming\Microsoft\Office\Recent

One of my requirements for a tool to parse link files was it had to be a command line tool. My reasoning is command-line tools can be used in scripts but more importantly command-line tools can be used in batch files to parse artifacts in volume shadow copies. I couldn't find a tool to meet my needs. Harlan provided the lslnk.pl script in WFA 2nd edition and it displays the information contained in link files. However, lslnk.pl only works against individual files when I needed a tool to parse an entire directory of link files. I'm not a programmer and I don't know Perl but I can use search engines so I decided to try to modified lslnk.pl. The first modification I made was to enable lsnk.pl to parse all of the link files in a directory with the output being in report format. The modified script - lslnk-directory-parse.pl - worked fine but the output wasn't the best for filtering data. I needed the output to display all of the information from a link file on one line so I perform a search I can see all information for a specific link file. I made another change to make the output contain one link file per line in comma delimited format and this resulted in the lslnk-directory-parse2.pl script. Both modified scripts can be found in the Yahoo Win4n6 group's tools folder. The only parameter required by the script is the directory to parse as shown below.

C:\Perl>lslnk-directory-parse2.pl "F:\[root]\Documents and Settings\Administrator\Recent" > lsnk-parse2-output.txt

The output is a comma delimited text file and this means it can be opened in Excel/Calc (to see how to import a text file in Excel check out my posts Reviewing Timelines with Excel or Reviewing Timelines in Calc). Opening the text file at this point will show the information from all of the link files instead of the information specific to the question at hand which is what network shares did an account access. The text file can be searched prior to it being reviewed in Excel/Calc and I use Grep (available in UnxUtils) to do this. There are numerous characteristics to search on such as filenames, directory paths, file extensions, removable media, and network shares. That's right, link files indicate if person accessed a file on a network share. The lslnk-directory-parse2.pl can be redirected to Grep for searching prior to the creation of the text file. The command below shows the lslnk-directory-parse2.pl output being searched for the word "network share" (the binary-file=text switch forces Grep to see the output as text).

C:\Perl>lslnk-directory-parse2.pl "F:\[root]\Documents and Settings\Administrator\Recent" | grep.exe -i --binary-files=text "network share" > lsnk-parse2-output.txt

The output file is still a comma delimited file but the only link files present will be the ones with the phrase "network share" in its information. Reviewing a portion of the output not only shows files accessed on the network shares identified previously with Regripper and RipXP but it also identifies files accessed in a new share (\\192.168.2.50\Share) as shown below.

Summary

The triage extracted data from registry and link files to answer the question of what network shares a person accessed. There was some redundancy in the extracted data since both locations showed the same user account activity (same network share access). However, at times one location may reveal information that is not present in the other. I promised to write about how to answer a few initial questions in less than two minutes by examining the activity on the computer. It took me less than one minute to run Regripper, RipXP, and lslnk-directory-parse2.pl, and to examine the output from the three tools. Within this one minute I was able to determine the network shares a user account had readily available access to (mapped drives) and network shares accessed. The process can be even quicker by creating a batch file with all of the commands since a batch file can just be executed. I answered a question network share access but the process I described should not be limited to only this activity. Different registry keys in combination with information contained in link files can be used to quickly determine someone’s activity on a computer.