Testing Registry Modification Scenarios

After reading some of the various open reports regarding how malware or threat actors were "using" the Registry, manipulating it to meet their needs, I wanted to take a look and see what the effects or impacts of these actions might "look like" from a dead-box, DFIR perspective, looking solely at the Registry.  I wanted to start with an approach similar to what I've experienced during my time in IR, particularly the early days, before EDR, before things like Sysmon or enabling Process Tracking in the Security Event Log. I thought that would be appropriate, given what appears to be the shear number of organizations with limited visibility into their infrastructures. For those orgs that have deployed Sysmon, the current version (v14.1) has three event IDs (12, 13, and 14) that pertain to the Registry.

The first scenario I looked at was from this Avast write-up on Raspberry Robins's Roshtyak component; in the section titled "Indirect registry writes", the article describes the persistence mechanism of renaming the RunOnce key, adding a value, then re-renaming the key back to "RunOnce", apparently in an effort to avoid rules/filters that look specifically for values being added to the RunOnce key. As most analysts are likely aware, the purpose of the RunOnce key is exactly that...to launch executables once. When the RunOnce key is enumerated, the value is read, deleted, and the executable it pointed to is launched. In the past, I've read about malware executables that are launched from the RunOnce key, and the malware itself, once executed, will re-write a value to that key, essentially allowing the RunOnce key and the malware together to act as if the malware were launched from the Run key.

I wanted to perform this testing from a purely dead-box perspective. Using EDR tools, or relying on the Windows Event Logs. Depending upon your configuration, you could perhaps look to the Sysmon Event Log, or if the system had been rebooted, you could also look to the Microsoft-Windows-Shell-Core%4Operational.evtx Event Log and Events Ripper to percolate unusual executables.

For reference, information on the Registry file format specification can be found here.

Methodology
The first thing I did was use "reg save" to create a backup of the Software hive. I then renamed the RunOnce key, and added a value (i.e., "Calc"), and renamed the key back to "RunOnce", all via RegEdit. I then closed RegEdit and used "reg save" to create a second copy of the Software hive. I then opened RegEdit, deleted the value, and saved a third copy of the Software hive.

During this process, I did not reboot the system; rather, I 'simulated' a reboot of the system by simply deleting the added value from the RunOnce key. Had the system been rebooted, there would likely be an interesting event record (or two) in the Microsoft-Windows-Shell-Core%4Operational.evtx Event Log.

Finally, I created a specific RegRipper plugin to extract explicit information about the key from the hive file.

First Copy - Software
So, again, the first thing I wanted to do was create a baseline; in this case, based on the structure for the key node itself. 

Fig 1: Software hive, first copy output

Using the API available from the Perl Parse::Win32Registry module, I wrote a RegRipper plugin to assist me in this testing. I wanted to get the offset of the key node; that is, the location within the hive file for the node itself. I also wanted to get both the parsed and raw information for the key node. This way, I could not only see the parsed data from within the structure of the key node itself, but I could also see the raw, binary structure, as well.

Second Copy - Software2
After renaming the RunOnce key, adding a value, and re-renaming the key back to "RunOnce", I saved a second copy of the Software hive, and ran the runonce_test.pl plugin to retrieve the information illustrated in figure 2.

Fig 2: Plugin output, second copy, Software hive

We can see between figures 1 and 2 that there are no changes to the offset, the location of the key within the hive file itself. In fact, the only changes we do see are the LastWrite time (which is to be expected), and the number of values, which is now set to 1.

Third Copy - Software3
The third copy of the Software hive is where I had deleted the value that had been added. Again, this was intended to simulate rebooting the system, and did not account for the malware adding a reference to itself back to the RunOnce key once it was launched.

Figure 3 illustrates the output of the plugin run against the third copy of the Software hive.

Fig 3: Plugin output, third copy, Software hive

Again, the offset/location of the key node itself hasn't changed, which is to be expected. Deleting the value changes the number of values to "0", and adjusts the key LastWrite time (which is to be expected). 

I then ran the del.pl plugin (to get deleted keys and values from unallocated space within the hive file) against the third copy of the Software hive, opened the output in Notepad++, searched for "calc", and found the output shown in figure 4 below. I could have used regslack, from Jolanta Thomassen (go here to see Jolanta's thesis from 2008), but simply chose the RegRipper plugin because I was already using RegRipper.

Fig 4: Del.pl output from third copy, Software hive

Unfortunately, value nodes contain neither time stamps, nor a reference back to the original key node (parent key offset) to which they were a member, as described in sections 4.1.1 and 4.1.2 of the Registry file format specification for key nodes; value node structures are described in sections 4.4.1 and 4.4.2. 

Conclusion
As we can see from this testing, there's not much that we can see just from the Registry hive file that would lead us to believe that anything unusual had happened. While we might have an opportunity to see something of this activity via the transaction logs, that would depend a great deal upon how long after the activity that the incident was discovered, the amount of usage on the system, etc. It appears that the way this specific activity would be discerned would be through a combination of malware RE, EDR, Windows Event Log records, etc.

Next, I'll take a look at at least one of the scenarios presented in this Microsoft blog post.

Addendum, 1 Nov: Maxim Suhanov reached to me about running "yarp-print --deleted" to get a different view of deleted data within the hive, and I found some anomalous results that I simply cannot explain. As a result, I'm going to completely re-run the tests, fully documenting each step, and providing the results again.

#OSDFCON

 The agenda for the 11th annual Open Source Digital Forensics Conference has been posted.  I've attended OSDFCON before (several times), it's one of the conferences where I've enjoyed presenting over the years. Maybe someone reading this remembers the "mall-wear" incident from a number of years ago.

So, on 18 Nov, I'll be speaking on Effectively Using RRv3. This past spring, I shared some information about about this new version of RegRipper (here, and here), as well as highlighting specific plugins. What I'd like to do is, in the same vein as the conference agenda, crowd-source some of the content for my 30 min presentation.

What would you like to see, hear, or learn about during my 30-ish minute presentation regarding RegRipper 3.0?

Updated samparse.pl plugin

I received an email from randomaccess last night, and got a look at it this morning.  In the email, he pointed out there there had been some changes to the SAM Registry hive as of Windows 8/8.1, apparently due to the ability to log into the system using an MSDN Live account.  Several new values seem to be added to the user RID key, specifically, GivenName, SurName, and InternetUserName.  He provided a sample SAM hive and an explanation of what he was looking for, and I was able to update the samparse.pl plugin, send him a copy, and update the GitHub repository, all in pretty short order.

This is a great example of what I've said time and again since I released RegRipper; if you need a plugin and don't feel that you can create or update one yourself, all you need to do is provide a concise description of what you're looking for, and some sample data.  It's that easy, and I've always been able to turn a new or updated plugin around pretty quickly.

Now, I know some folks are hesitant to share data/hive files with me, for fear of exposure.  I know people are afraid to share information for fear it will end up in my blog, and I have actually had someone tell me recently that they were hesitant to share something with me because they thought I would take the information and write a new book around it.  Folks, if you take a close look at the blog and books, I don't expose data in either one.  I've received hive files from two members of law enforcement, one of whom shared hive files from a Windows phone.  That's right...law enforcement.  And I haven't exposed, nor have I shared any of that data.  Just sayin'...

Interestingly enough, randomaccess also asked in his email if I'd "updated the samparse plugin for the latest book", which was kind of an interesting question.  The short answer is "no", I don't generally update plugins only when I'm releasing a new book.  If you've followed this blog, you're aware that plugins get created or updated all the time, without a new book being released.  The more extensive response is that I simply haven't seen a SAM hive myself that contains the information in question, nor has anyone provided a hive that I could used to update and test the plugin, until now.

And yes, the second edition of Windows Registry Forensics is due to hit the shelves in April, 2016.

More Registry Fun

Once, on a blog far, far away, there was this post that discussed the use of the Unicode RLO control character to "hide" malware in the Registry, particularly from GUI viewers that processed Unicode.

Recently, Jamie shared this Symantec article with me; figure 1 in the article illustrates an interesting aspect of the malware when it comes to persistence...it apparently prepends a null character to the beginning of the value name.  Interesting, some seem to think that this makes tools like RegEdit "brokken".

So, I wrote a RegRipper plugin called "null.pl" that runs through a hive file looking for key and value names that being with a null character.  Jamie also shared a couple of sample hives, so I got to test the plugin out.   The following image illustrates the plugin output when run against one of the hives:

Figure 1

All in all, the turn-around time was pretty quick.  I started this morning, and had the plugin written, tested, and uploaded to Github before lunch.

Later in the day, Eric Zimmerman followed up by testing the hive that Jamie graciously shared with me against the Registry Explorer.  I should also note that MiTeC WRR has no issues with the value names; it displays them as follows:

Figure 2

Addendum, 20 Jan: On a whim, I ran the fileless.pl plugin against the hive, and it detected the two values with the "fileless" data seen in figure 2.

HowTo: Determine Program Execution

Sometimes during an examination, it can be important to determine what programs have been executed on a

system, and more specifically, when and by which user. Some of the artifacts on a system will provide us with indications of programs that have been executed, while others will provide information about which user launched the program, and when.  As such, some of this information can be included in a timeline.

Hopefully, something that will become evident throughout this post, as well as other HowTo posts, is that rather than focusing on individual artifacts, we're going to start putting various artifacts into "buckets" or categories.  The purpose for doing this is so that analysts don't get lost in a sea of artifacts, and are instead able to tailor their initial approach to an examination, possibly using an analysis matrix.

Okay, let's get started...

AutoStart Locations
Before we begin to look at the different artifacts that can be directly tied to a user (or not), I wanted to briefly discuss autostart locations.  These are locations within the system...file system, Registry...where references to programs can reside that allow  programs to be executed automatically, without any interaction from the user beyond booting the system or logging in.  There are a number of such locations and techniques that can be used...Registry autostart locations, including the ubiquitous Run key, Windows services, the StartUp folder on the user's Program Menu, and even the use of the DLL Search Order functionality/vulnerability.  Each of these can be (and have been) discussed in multiple blog posts, so for now, I'm simply going to present them here, under this "umbrella" heading, for completeness.

Scheduled Tasks can be, and are, used as an autostart location.  Many of us may have QuickTime or iTunes installed on our system; during installation, a Scheduled Task to check for software updates is created, and we see the results of this task now and again.  Further, on Windows 7 systems, a Scheduled Task creates backups of the Software, System, Security, and SAM hive files into the C:\Windows\system32\config\RegBack folder every 10 days.  When considering autostart locations, be sure to check the Scheduled Tasks folder.

Tip
On a live system, you need to use both the schtasks.exe and at.exe commands to get a complete listing of all of the available Scheduled Tasks.

Tools: RegRipper plugins, MS/SysInternals AutoRuns; for XP/2003 Scheduled Task *.job files, jobparse.pl; on Vista+ systems, the files are XML

User
There are a number of artifacts within the user context that can indicate program execution.  This can be very useful, as it allows analysts to correlate program execution to the user context in which the program was executed.

UserAssist
The contents of value data within a user's UserAssist subkeys can provide an excellent view into what programs the user has launched via the Explorer shell...by double-clicking icons or shortcuts, as well as by navigating via the Program Menu.  Most analysts are aware that the value names are Rot-13 encoded (and hence, easily decoded), and folks like Didier Stevens have gone to great lengths to document the changes in what information is maintained within the value data, as versions of the operating systems have progressed from Windows 2000 to Windows 8.

Tools: RegRipper userassist.pl and userassist_tln.pl plugins

RunMRU
When  a user clicks on the Start button on their Windows XP desktop, and then types a command into the Run box that appears, that command is added to the RunMRU key.

Interestingly, I have not found this key to be populated on Windows 7 systems, even though the key does exist.  For example, I continually use the Run box to launch tools such as RegEdit and the calculator, but when I dump the hive file and run the runmru.pl RegRipper plugin against it, I don't see any entries.  I have found the same to be true for other hives retrieved from Windows 7 systems.

Tools: RegRipper runmru.pl plugin

ComDlg32\CIDSizeMRU Values
The binary values located beneath this key appear to contain names of applications that the user recently launched.  From my experience, the majority of the content of these values, following the name of the executable file, is largely zeros, with some remnant data (possibly window position/size settings?) at the end of the file.  As one of the values is named MRUListEx, we can not only see (via a timeline) when the most recent application was launched, but we can also see when other applications were launched by examining available VSCs.

AppCompatFlags
According to MS, the Program Compatibility Assistant is used to determine if a program needs to be run in XP Compatibility Mode.  Further, "PCA stores a list of programs for which it came up...even if no compatibility modes were applied", under the Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Compatibility Assistant\Persisted key in the user's NTUSER.DAT hive.  As such, we can query these values and retrieve a list of programs run by the user.

Tools: RegRipper appcompatflags.pl plugin (I updated the plugin, originally written by Brendan Cole, to include retrieving the values beneath the Persisted key, on 6 July 2013; as such, the plugin will be included in the next rollout)

MUICache
The contents of this key within the user hives (NTUSER.DAT for XP/2003, USRCLASS.DAT for Win7) often contains references to applications that were launched within the user context.  Often times, these application will include command line interface (CLI) utilities.

Windows shortcuts/LNK files and Jump Lists
You're probably thinking..."huh?"  Most analysts are familiar with how shortcuts/LNK files (and Jump Lists) can be used to demonstrate access to files or external storage devices, but they can also be used to demonstrate program execution within the context of a user.

Most of us are familiar with the LNK files found in the ..\Windows\Recent and ..\Office\Recent folders within the user profile...so, think about how those shortcuts are created.  What usually happens is that the user double-clicks a file, the OS will read the file extension from the file, and then query the Registry to determine which application to launch in order to open the file.  Windows will then launch the application...and this is where we have program execution.

Many times when a user installs an application on their system, a desktop shortcut may be created so that the user can easily launch the application.  The presence of an icon on the desktop may indicate that the user launched an installer application.

Tools: custom Perl script, tools to parse LNK files

Java Deployment Cache Index (*.idx) Files
The beginning of 2013 saw a lot of discussion about vulnerabilities to Java, as well as reports of 0-days, and as a result, there was a small number of folks within the community looking into the use of Java deployment cache index (*.idx) files during analysis.  The use of these files as artifacts during an investigation goes back to well before then, thanks to Corey Harrell.  These files provide indications of downloads to the system via Java, and in some cases, those downloads might be malicious in nature.  These artifacts are related specifically to Java being executed, and may lead to indications of additional programs being executed.  Further, given that the path to the files is within the user profile folder, we can associate the launch of Java with a specific user context.

Tools: idxparse.pl parser

Browser History
A user's browser history not only indicates that they were browsing the web (i.e., executing the browser program), but the history can also be correlated to the *.idx files discussed above in order to determine which site they were visiting that caused Java to be launched.

System
There are a number of artifacts on the system that can provide indications of program execution

Prefetch File Analysis
Most analysts are aware of some of the metadata found within Prefetch files.  Application prefetch files include metadata indicating when the application was last launched, as well as how many times it has been launched.  This can provide some excellent information

Tools: pref.pl, or any other tools/scripts that parse the embedded module strings.  Recent versions of scripts I've written and use incorporate an alerting mechanism to identify items within the strings and string paths found to be "suspicious" or "unusual".

AppCompatCache
This value within the System hive in the Registry was first discussed publicly by Mandiant, and has proven to be a treasure trove of information, particularly when it comes to malware detection and determining program execution, in general.

Tools: Mandiant's shim cache parser, RegRipper appcompatcache.pl plugin (appcompatcache_tln.pl plugin outputs in TLN format, for inclusion in timelines).

Legacy_* Keys
Within the System hive, most of use are familiar with the Windows services keys.  What you may not realize is that there is another set of keys that can be very valuable when it comes to understanding when Windows services were run...the Enum\Root\Legacy_* keys.  Beneath the ControlSet00n\Enum\Root key in the System hive, there are a number of subkeys whose names being with LEGACY_, and include the names of services.

There are a number of variants of malware (Win32/Alman.NAD, for example) that install as a service, or driver, and when launched, the operating system will create the Enum\Root\Legacy_* key for the service/driver.  Also, these keys persist after the service or driver is no longer used, or even removed from the system.  Malware writeups by AV vendors will indicate that the keys are created when the malware is run (in a sandbox), but it is more correct to say that the OS creates the key(s) automatically as a result of the execution of the malware.  This can be an important distinction, which is better addressed in another blog post.

Tools: RegRipper legacy.pl plugin

Direct* and Tracing Keys
These keys within the Software hive can provide information regarding program execution.

The "Direct*" keys are found beneath the Microsoft key, and are keys whose names start with "Direct", such as Direct3D, DirectDraw, etc.  Beneath each of these keys, you may find a MostRecentApplication key, which contains a value named Name, the data of which indicates an application that used the particular graphics functionality.  Many times during an exam, I'll see "iexplore.exe" listed in the data, but during one particular exam, I found "DVDMaker.exe" listed beneath the DirectDraw key.  In another case, I found "mmc.exe" listed beneath the same key.

I've found during exams that the Microsoft\Tracing key contains references to some applications that appear to have networking capabilities.  I do not have any references to provide information as to which applications are subject to tracing and appear beneath this key, but I have found references to interesting applications that were installed on systems, such as Juniper and Kiwi Syslog tools (during incident response engagements, this can be very helpful and allow you collect Event Logs from the system that have since been overwritten, and included in a timeline...).  Unfortunately, these artifacts have nothing more than the EXE name (no path or other information is included or available), but adding the information to a timeline can provide a bit of context and granularity for analysis.

Tip
When examining these and other keys, do not forget to check the corresponding key beneath the Wow6432Node key within the Software hive.  The RegRipper plugins address this automatically.

Tools: RegRipper direct.pl and tracing.pl plugins

Event Logs
Service Control Manager events within the System Event Log, particularly those with event IDs 7035 and 7036, provide indications of services that were successfully sent controls, for either starting or stopping the service.  Most often within the System Event Log, you'll see these types of events clustered around a system start or shutdown.  During DFIR analysis, you're likely going to be interested in either oddly named services, services that only appear recently, or services that are started well after a boot or system startup.  Also, you may want to pay close attention to services such as "PSExeSvc", "XCmdSvc", "RCmdSvc", and "AtSvc", as they may indicate lateral movement within the infrastructure.

On Windows 2008 R2 systems, I've found indications of program execution in the Application Experience Event Logs; specifically, I was examining a system that had been compromised via an easily-guessed Terminal Services password, and one of the intruders had installed Havij (and other tools) on the system.  The Application-Experience/Program-Inventory Event Log contained a number of events associated with program installation (event IDs 903 and 904), application updates (event ID 905), and application removal (event IDs 907 and 908).  While this doesn't provide a direct indication of a program executing, it does illustrate that the program was installed, and that an installer of some kind was run.

On my own Windows 7 system, I can open the Event Viewer, navigate to the Event Log, and view the records that illustrate when I have installed various programs knowingly (FTK Imager) and unknowningly (Google+ Chat).  There are even a number of application updates to things like my ActiveState Perl and Python installations.

Tools: LogParser, evtxparse.pl

Other Indirect Artifacts
Many times, we may be able to determine program execution through the use of indirect artifacts, particularly those that persist well after the application has finished executing, or even been deleted.  Many of the artifacts that we've discussed are, in fact, indirect artifacts, but there may still be others available, depending upon the program that was executed.

A number of years ago, I was...and I don't like to admit this...certified to perform PCI forensic audits.  On one case, I ran into my first instance of a RAM scraper...this was a bit of malware that was installed on a point-of-sale (POS) back office server (running Windows) as a Windows service.  After the system was booted, this instance of the malware would read the contents of a register, do some math, and use that value as a seed to wait a random amount of time before waking up and dumping the virtual memory from one of eight named (the names were listed in the executable file) processes.  The next step was to parse the memory dump for track data, and this was accomplished via the use of Perl script that was "compiled" via Perl2Exe.  I'm somewhat familiar with such executables, and one of the artifacts we found to validate our findings with respect to the actual execution of the malicious code was temporary directories created by "compiled" script.  When executables "compiled" with Perl2Exe are run, any of the Perl modules (including the runtime) packed into the executable are extracted as DLLs into a temporary directory, at which time they are "available" to the running code.  As the code was launched by a Windows service, the "temp" directories were found in the C:\Windows\Temp folder.  The interesting thing that we found was that the temp directories used to hold the modules/DLLs are not deleted after the code completes, and they persist even if the program itself is removed from the system.  In short, we had a pretty good timeline for each time the parsing code was launched.

On my own Windows 7 system, because I run a number of Perl scripts that were "compiled" with Perl2Exe within the context of my user account, the temp directories are found in the path, C:\Users\harlan\AppData\Local\Temp...the subdirectories themselves are named "p2xtmp-", and are followed by an integer, and themselves contain subdirectories that represent the Perl runtime namespace.  The time stamps (creation dates) for these subdirectories provide indications of when I executed scripts  that had been compiled via Perl2Exe.

Memory Dumps
During dead box analysis, memory dumps can be an excellent source of information.  When an application crashes, a memory dump is created, and a log file containing information including a process list also created.  When another application crash occurs, the memory dump is overwritten, but the log file is appended to, meaning that you can have a number of crash events available for analysis.  I have found this historical information to be very useful during examinations because, while the information is somewhat limited, it can illustrate whether or not a program was running at some point in the past.

We're not going to discuss hibernation files here, as once you access a hibernation file and begin analysis, there really is very little difference between analyzing the hibernation file and analyzing a memory dump for a live system.  Many of the techniques that you'd use, and the artifacts that you would look for, are pretty much the same.

Tools: text viewer

Malware Detection
Another use of this artifact category is that it can be extremely valuable in detecting the presence of malware on a system.  However, malware detection is a topic that is best addressed in another post, as there is simply too much information to limit the topic to just a portion of a blog post.

Resources
This idea of determining program execution has been discussed before:
Timeline Analysis, and Program Execution
There Are Four Lights: Program Execution

Shellbag Analysis, Revisited...Some Testing

I blogged previously on the topic of Shellbag Analysis, but I've found that in presenting on the topic and talking to others, there may be some misunderstanding of how these Registry artifacts may be helpful to an analyst.  With Jamie's recent post on the Shellbags plugin for Volatility, I thought it would be a good idea to revisit this information, as sometimes repeated exposure is the best way to start developing an understanding of something.  In addition, I wanted to do some testing in order to determine the nature of some of the metadata associated with shellbags.

In her post, Jamie states that the term "Shellbags" is commonly used within the community to indicate artifacts of user window preferences specific to Windows Explorer.  MS KB 813711 indicates that the artifacts are created when a user repositions or resizes an Explorer windows.

ShellItem Metadata
As Jamie illustrates in her blog post, many of the structures that make up the SHELLITEMS (within the Shellbags) contain embedded time stamps, in DOSDate format.  However, there's still some question as to what those values mean (even though the available documentation refers to them as MAC times for the resource in question) and how an analyst may make use of them during an examination.

Having some time available recently due to inclement weather, I thought I would conduct a couple of very simple tests in to begin to address these questions.

Testing Methodology
On a Windows 7 system, I performed a number of consecutive, atomic actions and recorded the system time (visible via the system clock) for when each action was performed.  The following table lists the actions I took, and the time (in local time format) at which each action occurred.

Action	Time
Create a dir: mkdir d:\shellbag	12:54pm
Create a file in the dir: echo "..."  > d:\shellbag\test.txt	1:03pm
Create another dir: mkdir d:\shellbag\test	1:08pm
Create a file in the new dir: echo "..." > d:\shellbag\test\test.txt	1:16pm
Delete a file: del d:\shellbag\test.txt	1:24pm
Open D:\shellbag\test via Explorer, reposition/resize the window	1:29pm
Close the Explorer window opened in the previous step	1:38pm

The purpose of having some time pass between actions is so that they can be clearly differentiated in a timeline.

Once these steps were completed, I restarted the system, and once it came back up, I extracted the USRCLASS.DAT hive from the relevant user account into the D:\shellbag directory for analysis (at 1:42pm).  I purposely chose this directory in order to determine how actions external to the shellbags artifacts affect the overall data seen.

 Results
The following table lists the output from the shellbags.pl RegRipper plugin for the directories in question (all times are in UTC format):

Directory	MRU Time	Modified	Accessed	Created
Desktop\My Computer\D:\shellbag	2012-10-29 17:29:25	2012-10-29 17:24:26	2012-10-29 17:24:26	2012-10-29 16:55:00
Desktop\My Computer\D:\shellbag\test	2012-10-29 17:29:29	2012-10-29 17:16:20	2012-10-29 17:16:20	2012-10-29 17:08:18

Let's walk through these results.  First, I should remind you that that MRU Time is populated from Registry key LastWrite times (FILETIME format, granularity of 100 ns) while the MAC times are embedded within the various shell items (used to reconstruct the paths) in DOSDate time format (granularity of 2 seconds).

First, we can see that the Created dates for both folders correspond approximately to when the folders were actually created.  We can also see that the same thing is true for the Modified dates.  Going back to the live system and typing "dir /tw d:\shell*" shows me that the last modification time for the directory is 1:42pm (local time), which corresponds to changes made to that directory after the USRCLASS.DAT hive file was extracted.

Next, we see that MRU Time values correspond approximately to when the D:\shellbag\test folder was opened and then resized/repositioned via the Explorer shell, and not to when the Explorer window was actually closed.

Based on this limited test, it would appear that the DOSDate time stamps embedded in the shell items for the folders correspond to the MAC times of that folder, within the file system, at the time that the shell items were created.  In order to test this, I deleted the d:\shellbag\test\test.txt file at 2:14pm, local time, and then extracted a copy of the USRCLASS.DAT and parsed it the same way I had before...and saw no changes in the Modified times listed in the previous table.

In order to test this just a bit further, I opened Windows Explorer, navigated to the D:\shellbag folder, and repositioned/resized the window at 2:21pm (local time), waited 2 minutes, and closed the window.  I extracted and parsed the USRCLASS.DAT hive again, and this time, the MRU Time for the D:\shellbag folder had changed to 18:21:48 (UTC format).  Interestingly, that was the only time that had changed...the Modified time for the D:\shellbag\test folder remained the same, even though I had deleted the test.txt file from that directory at 2:14pm local time ("dir /tw d:\shellbag\te*" shows me that the last written time for that folder is, indeed, 2:14pm).

Summary
Further testing is clearly required; however, it would appear that based on this initial test, we can draw the following conclusions with respect to the shellbag artifacts on Windows 7:

1.  The embedded DOSDate time stamps appear to correspond to the MAC times of the resource/folder at the time that the shell item was created.  If the particular resource/folder was no longer present within the active file system, an analyst could use the Created date for that resource in a timeline.

2.  Further testing needs to be performed in order to determine the relative value of the Modified date, particularly given that events external to the Windows Explorer shell (i.e., creating/deleting files and subfolders after the shell items have been created) may have limited effect on the embedded dates.

3.  The MRU Time appears to correspond to when the folder was resized or repositioned.  Analysts should keep in mind that (a) there are a number of ways to access a folder that do not require the user to reposition or resize the window, and (b) the MRU Time is a Registry key LastWrite time that only applies to one folder within the key...the Most Recently Used folder, or the one listed first in the MRUListEx value.

I hope that folks find this information useful.  I also hope that others out there will look at this information, validate it through their own testing, and even use it as a starting point for their own research.

Links, Tools, Etc.

Windows 8 Forensics
There is some great information circulating about the Interwebs regarding Windows 8 forensics.  There's this YouTube video titled A Forensic First Look, this blog post that addresses reset and refresh artifacts, the Windows 8 Forensics Guide (this PDF was mentioned previously on this blog), this blog post on the Windows 8 TypedURLsTime Registry key, and Kenneth Johnson's excellent PDF on Windows 8 File History...in addition to a number of other available resources.  Various beta and pre-beta versions of Windows 8 have been out for some time, and with each release there seems to be something new...when I went from the first version available for developers to the Consumer Preview, one of the first things I noticed was that I was no longer able to disable the Metro interface.

So what does all this mean?  Well, just like when Windows XP was released, there were changes that would affect how we within the digital analysis community would do our jobs, and the same thing has been true since then with every new OS release.  While our overall analysis process wouldn't change, there are aspects of the new operating system and it's included technologies that require us to update the specifics of those processes.

Timeline Analysis
Over at the Sploited blog, there's an excellent post on how to incorporate Java information into your TLN-format timeline, in order to help determine the exploit used to compromise a system.  In addition to the information available in the two previous posts (here, and here, respectively), this post includes code for parsing .idx files, and incorporating log entries into a TLN-format timeline.

Just to be clear, this is NOT a RegRipper plugin (there is often times confusion about this...), but is instead a file parser that you can use to incorporate data into your timeline, similar to parsing Prefetch file metadata.  As such, it can very often add some much-needed detail and context to your analysis.

Posts such as this go hand-in-hand with the excellent work that Corey Harrell has done in determining exploit footprints on compromised systems.

PList Parser
If you do forensics on iDevices, or you get access to iDevice backups via iTunes on a system, you might want to take a look at Maria's PList Parser.  Parsing these files can provide you with a great deal of insight into the user's behavior while using the device.  Maria said that she used RegRipper as the inspiration for her tool, and it's great to see tools like this become available.

ScheduledTask File Parser
Jamie's released a .job file parser, written in Python.  These files, on WinXP and 2003 systems, are in a binary format (in later versions of Windows, they're XML) and like other files (ie, Prefetch files) can contain some significant metadata.  In the past, I've found analysis of these artifacts to particularly useful when responding to incidents involving certain threat actors that moved laterally within the compromised infrastructure...one way of doing so was to schedule tasks on remote systems.

Not only does Jamie provide an explanation of what a .job file "looks like", but she also provides references so that folks can look this information up themselves, and develop a deeper understanding of what the tool is doing, should they choose to do so.  Also, don't forget the great work Jamie has done with her MBR parser, particularly if you're performing some sort of malware detection on an acquired image.

Registry Analysis
I ran across this write-up on Wiper recently via Twitter,

In the write-up, the authors state:

"...we came up with the idea to look into the hive slack space for deleted entries."

Hhhmm...okay.  My understanding of "slack space", with respect to the file system, is that it's usually considered to be what's left over between the logical and physical space consumed by a file.  Let's say that there's a file that's 892 bytes, and in order to save it to disk, the system will allocate 2 512 byte sectors, or 1024 bytes.  As such, the slack space would be that 132 bytes that remains between the logical end of the file, and end of the second physical sector.

Now, this can be true for the hive files themselves, as some data may exist between the logical end of the hive, and the end of the last physical sector.  This may also be true for value data, as well...if the 1024 bytes are allocated for a value, but only 892 bytes are actually written to the allocated space, there may be slack space available.

However, if you look at the graphic associated with the comment (excellent use of Yaru, guys!), the first 4 bytes (DWORD) of the selected data are a positive value, indicating that the key was deleted.  As such, the key becomes part of the unallocated space of the hive file, just like the sectors of a deleted file become part of the unallocated space of a volume or disk.  So, the value appears to have been part of unallocated space of the hive file, rather than slack space.

With respect to overall Registry analysis, perhaps "...we came up with the idea..." isn't the most systematic approach to that analysis.  Admittedly, the authors found something very interesting, but I'd be interested to know if the authors found an enum\Root\Legacy_RAHDAUD64 key in that Registry hive they were looking at, or if they found a Windows Event Log record with source "Service Control Manager" and an ID of 7035 (indicating a service start message had been sent), and then opted to check for deleted keys in the hive after determining that there was no corresponding visible keys for a service of that name in the System hive.

Looking for Suspicious EXEs
Adam wrote an interesting blog post on finding suspicious PE files via clustering...in short, assuming PE files may have been subject to timestomping (ie, intentional modification of MFT $STANDARD_INFORMATION attribute time stamps), and attempting to detect these files by "clustering" the PE file compile times.

You can read more about methods for detecting malicious files by reading Joel Yonts' GIAC Gold Paper, Attributes of Malicious Files.

ShellBag Analysis

What are "shellbags"?
To get an understanding of what "shellbags" are, I'd suggest that you start by reading Chad Tilbury's excellent SANS Forensic blog post on the topic.  I'm not going to try to steal Chad's thunder...he does a great job of explaining what these artifacts are, so there's really no sense in rehashing everything.

Discussion of this topic goes back well before Chad's post, with this DFRWS 2009 paper.  Before that, John McCash talked about ShellBag Registry Forensics on the SANS Forensics blog.  Even Microsoft mentions the keys in question in KB 813711. 

Without going into a lot of detail, a user's shell window preferences are maintained in the Registry, and the hive and keys being used to record these preferences will depend upon the version of the Windows operating system.  Microsoft wants the user to have a great experience while using the operating system and applications, right?  If a user opens up a window on the Desktop and repositions and resizes that window, how annoying would it be to shut the system down, and have to come back the next day and have to do it all over again?  Because this information is recorded in the Registry, it is available to analysts who can parse and interpret the data. As such, "ShellBags" is sort of a colloquial term used to refer to a specific area of Registry analysis.

Tools such as Registry Decoder, TZWorks sbag, and RegRipper are capable of decoding and presenting the information available in the ShellBags.

How can ShellBags help an investigation?
I think that one of the biggest issues with ShellBags analysis is that, much like other lines of analysis that involve the Windows Registry, they're poorly understood, and as such, underutilized.  Artifacts like the ShellBags can be very beneficial to an examiner, depending upon the type of examination they're conducting.  Much like the analysis of other Windows artifacts, ShellBags can demonstrate a user's access to resources, often well after that resource is no longer available.  ShellBag analysis can demonstrate access to folders, files, external storage devices, and network resources.  Under the appropriate conditions, the user's access to these resources will be recorded and persist well after the accessed resource has been deleted, or is no longer accessible via the system.

If an organization has an acceptable use policy, ShellBags data may demonstrate violations of that policy, by illustrating access to file paths with questionable names, such as what may be available via a thumb drive or DVD.  Or, it may be a violation of acceptable use policies to access another employee's computer without their consent, such as:

Desktop\My Network Places\user-PC\\\user-PC\Users

...or to access other systems, such as:

Desktop\My Network Places\192.168.23.6\\\192.168.23.6\c$

Further, because of how .zip files are handled by default on Windows systems, ShellBag analysis can illustrate that a user not only had a zipped archive on their system, but that they opened it and viewed subfolders within the archive.

This is what it looks like when I accessed Zip file subfolders on my system:

Desktop\Users\AppData\Local\Temp\RR.zip\DVD\RegRipper\DVD

Access to devices will also be recorded in these Registry keys, including access to specific resources on those devices.

For example, from the ShellBags data available on my own system I was able to see where I'd accessed an Android system:

Desktop\My Computer\F:\Android\data

...as well as a digital camera...

Desktop\My Computer\Canon EOS DIGITAL REBEL XTi\CF\DCIM\334CANON

...and an iPod.

Desktop\My Computer\Harlan s iPod\Internal Storage\DCIM

Another aspect of ShellBags analysis that can be valuable to an examination is by the analyst developing an understanding the actual data structures, referred to as "shell item ID lists", used within the ShellBag.  It turns out that these data structures are not only used in other values within the Registry, but they're also used in other artifacts, such as Windows shortcut/LNK files, as well as within Jump List files.  Understanding and being able to recognize and parse these structures lets an analyst get the most out of the available data.

Locating Possible Data Exfil/Infil Paths via ShellBags
As information regarding access to removable storage devices and network resources can be recorded in the ShellBags, this data may be used to demonstrate infiltration/infection or data exfiltration paths.

For example, one means of getting data off of a system is via FTP.  Many Windows users aren't aware that Windows has a command line FTP client, although some are; in my experience, it's more often intruders who are conversant in the use of the command line client.  One way that analysts look for the use of the FTP client (i.e., ftp.exe) is via Prefetch files, as well as via the MUICache Registry key.

However, another way to access FTP on a Windows system is via the Windows Explorer shell itself.  I've worked with a couple of organizations that used FTP for large file transfers and had us use this process rather than use the command line client.   A couple of sites provide simple instructions regarding how to use FTP via Windows Explorer:

MS FTP FAQ
HostGator: Using FTP via Windows Explorer

Here's what a URI entry looks like when parsed (obfuscated, of course):

Desktop\Explorer\ftp://www.site.com

One of the data types recorded within the ShellBags keys is a "URI", and this data structure includes an embedded time stamp, as well as the protocol (ie, ftp, http, etc.) used in the communications.  The embedded time stamp appears (via timeline analysis) to correlate with when the attempt was made to connect to the FTP site.  If the connection is successful, you will likely find a corresponding entry for the site in the NTUSER.DAT hive, in the path:

HKCU/Software/Microsoft/FTP/Accounts/www.site.com

Much like access via the keyboard, remote access to the system that provides shell-based control, such as via RDP, will often facilitate the use of other graphical tools, including the use of the Windows Explorer shell for off-system communications.  ShellBag analysis may lead to some very interesting findings, not only with respect to what a user may have done, but also other resources an intruder may have accessed.

Summary
Like other Windows artifacts, ShellBags persist well after the accessed resources are no longer available.  Knowing how to parse and interpret this Registry data

Parsing ShellBags data can provide you with indications of access to external resources, potentially providing indications of one avenue of off-system communications.  If the concern is data infiltration ("how did that get here?"), you may find indications of access to an external resource, followed by indications of access to Zip file subfolders.  ShellBags can be used to demonstrate access to resources where no other indications are available (because they weren't recorded some where else, or because they were intentionally deleted), or they can be used in conjunction with other resources to build a stronger case.  Incorporation of ShellBag data into timelines for analysis can also provide some very valuable insight that might not otherwise be available to the analyst.

Resources
ForensicsWiki Shell Item page

Timeline Analysis, and Program Execution

I mentioned previously that I've been preparing for an upcoming Timeline Analysis course offered through my employer.  As part of that preparation, I've been using the tools to walk through the course materials, and in particular one of the hands-on exercises that we will be doing in the course.

One of the things I'd mentioned in my previous post is that Rob Lee has done a great deal of work for SANS, particularly in providing an Excel macro to add color-coding of different events to log2timeline output files.  I've had a number of conversations and exchanges with Corey Harrell and others (but mostly Corey) regarding event categorization, and the value of adding these categories to a timeline in order to facilitate analysis.  This can be particularly useful when working with Windows Event Log data, as there a good number of events recorded by default, and all of that information can be confusing if you don't have a quick visual reference. 

As I was running through the exercises, I noticed something very interesting in the timeline with respect to the use of the Autoruns tool from SysInternals; specifically, that there were a good number of artifacts associated with both the download and use of the tool.  I wanted to extract just those artifacts directly associated with Autoruns from the timeline events file, in order to demonstrate how a timeline can illustrate indications of program execution.  To do so, I ran the following command:

type events.txt | find "autoruns" /i > autoruns_events.txt

...and then to get my timeline...

parse -f autoruns_events.txt > autoruns_tln.txt

...and got the following:

Tue May 29 12:56:02 2012 Z

  FILE                       - ..C. [195166] C:/Windows/Prefetch/AUTORUNS.EXE-1CF578DD.pf

  FILE                       - ..C. [44056] C:/Windows/Prefetch/AUTORUNSC.EXE-C5802224.pf

Tue May 15 21:14:55 2012 Z

  REG      johns-pc         john - M... HKCU/Software/Sysinternals/AutoRuns

  REG      johns-pc         john - [Program Execution] Software\SysInternals\AutoRuns (EulaAccepted)

Tue May 15 21:14:07 2012 Z

  FILE                       - MA.B [195166] C:/Windows/Prefetch/AUTORUNS.EXE-1CF578DD.pf

Tue May 15 21:13:57 2012 Z

  PREF     johns-PC          - [Program Execution] AUTORUNS.EXE-1CF578DD.pf last run (1)

  REG      johns-pc         john - [Program Execution] UserAssist - C:\tools\autoruns.exe (1)

Tue May 15 21:13:53 2012 Z

  FILE                       - M.C. [640632] C:/tools/autoruns.exe

  FILE                       - M.C. [26] C:/tools/autoruns.exe:Zone.Identifier

  REG      johns-pc     - M... [Program Execution] AppCompatCache - C:\tools\autoruns.exe

Tue May 15 21:13:42 2012 Z

  FILE                       - MAC. [877] C:/Users/john/AppData/Roaming/Microsoft/Windows/Recent/Autoruns.lnk

  JumpList johns-pc         john - C:\Users\john\Downloads\Autoruns.zip

Tue May 15 21:13:32 2012 Z

  FILE                       - MA.B [44056] C:/Windows/Prefetch/AUTORUNSC.EXE-C5802224.pf

Tue May 15 21:13:28 2012 Z

  PREF     johns-PC          - [Program Execution] AUTORUNSC.EXE-C5802224.pf last run (1)

  REG      johns-pc         john - [Program Execution] UserAssist - C:\tools\autorunsc.exe (1)

Tue May 15 21:13:23 2012 Z

  FILE                       - M.C. [49648] C:/tools/autoruns.chm

  FILE                       - M.C. [26] C:/tools/autoruns.chm:Zone.Identifier

  FILE                       - M.C. [559736] C:/tools/autorunsc.exe

  FILE                       - M.C. [26] C:/tools/autorunsc.exe:Zone.Identifier

  REG      johns-pc     - M... [Program Execution] AppCompatCache - C:\tools\autorunsc.exe

Tue May 15 21:12:10 2012 Z

  FILE                       - ...B [877] C:/Users/john/AppData/Roaming/Microsoft/Windows/Recent/Autoruns.lnk

  FILE                       - ..C. [535772] C:/Users/john/Downloads/Autoruns.zip

  FILE                       - ..C. [26] C:/Users/john/Downloads/Autoruns.zip:Zone.Identifier

Tue May 15 21:11:59 2012 Z

  FILE                       - MA.B [535772] C:/Users/john/Downloads/Autoruns.zip

  FILE                       - MA.B [26] C:/Users/john/Downloads/Autoruns.zip:Zone.Identifier

Wed May  9 15:08:16 2012 Z

  FILE                       - .A.B [640632] C:/tools/autoruns.exe

  FILE                       - .A.B [26] C:/tools/autoruns.exe:Zone.Identifier

  FILE                       - .A.B [559736] C:/tools/autorunsc.exe

  FILE                       - .A.B [26] C:/tools/autorunsc.exe:Zone.Identifier

Sat Nov  5 17:52:32 2011 Z

  FILE                       - .A.B [49648] C:/tools/autoruns.chm

  FILE                       - .A.B [26] C:/tools/autoruns.chm:Zone.Identifier

What I find most interesting about this timeline excerpt is that it illustrates a good deal of interaction with respect to the download and launch of the tool within it's eco-system, clearly demonstrating Locard's Exchange Principle.  Now, there are also a number of things that you don't see...for example, this timeline is comprised solely of those lines that included the word "autoruns" (irrespective of case) somewhere in the line; as such, we won't see things such as the query to the "Image File Execution Options" key, to determine if there's been a debugger assigned to the tool, nor do you see ancillary events or those that might be encoded.  However, what we do see will clearly allow us to "zoom in" on a specific time window within the overall timeline, and see what other events may be listed there.

The timeline is clearly very illustrative.  We can see the download of the tool (in this case, via Chrome to a Windows 7 platform), and the assignment of the ":Zone.Identifier" ADSs, something that with XP SP2 was done only via IE and Outlook.  Beyond the file system metadata, we start to see even more context, simply by adding additional data sources such as the Registry AppCompatCache value data, UserAssist value data, information derived from the SysInternals key in the user's Registry hive, Jump Lists, etc.  In this case, the Jump List info in the timeline was extracted from the DestList stream found in the Jump List for the Windows Explorer shell, as zipped archives will often be treated as if they were folders.

Another valuable aspect of this sort of timeline data is that it is very useful in the face of the use of counter-forensics techniques, even those that may be unintentional (i.e., performed by an administrator, not to hide data, but to "clean up" the system).  Let's say that this tool had been run, and then deleted; remove all of the "FILE" entries that point to C:/tools from the above timeline, and what do you have left?  You have those artifacts that persist beyond the deletion of files and programs, and provide clear indicators that the tools had been used.  We can apply this same sort of analysis to other situations where tools had been run (programs executed) on a system, and then some steps taken to obviate or hide the data.

M... [Program Execution] AppCompatCache - C:\tools\autorunsc.exe

The "M..." refers to the fact that, as pointed out by Mandiant, when the tool is run, the file modification time for the tool is recorded in the data structure within the AppCompatCache value.  The "[Program Execution]" category identifier, in this case, indicates that the CSRSS flag was set (you'll need to read Mandiant's white paper).  The existence of the application prefetch file for the tool, as well as the UserAssist entry, help illustrate that the program had been executed.

One of the unique things about the SysInternals tools is that after they were taken over by Microsoft, they began to have EULA acceptance dialogs added to them.  Now, there is a command line switch that you can use to run the CLI versions of the tools and accept the EULA, but the tools will create their own subkey beneath the SysInternals key in the Software hive, and set the "EulaAccepted" value.  Even if the tool is renamed, these same artifacts will be left on a system.

File system metadata was extracted from the acquired image using TSK fls.exe.  As such, we know that the MACB times are from the $STANDARD_INFORMATION attribute within the MFT, which are highly mutable; that is to say, easily modified to arbitrary values.  We can see from the timeline that Autoruns.zip was downloaded on 15 May, and according to the SysInternals web site, an updated version of the tool was posted on 14 May.  The files were extracted from the zipped archive, carrying with them some of their original file times, which is why we see ".A.B" times prior to the date that the archive was downloaded.  Had the file times been modified to arbitrary values (i.e., "stomped"), rather than the files being deleted, we would still see the other artifacts listed in the timeline, in that order.  In essence, we'd have a "signature" for program execution.

Other sources of data that would not appear in a timeline can include, for example, the user's MUICache key.  This key simply holds a list of values, and in a number of exams, I've found references to malware that was run on the system, even after the actual files had been removed.  Also, if the AutoRuns files had been deleted, I could parse the AutoRuns.lnk Windows shortcut file to get the path to, as well as the MA.B times for, the target file.  In order to illustrate that, what follows is the raw output of an LNK file/stream parser:

atime                         Tue May 15 21:11:59 2012                         
basepath                    C:\Users\                                        
birth_obj_id_node       08:00:27:dd:64:d1                                
birth_obj_id_seq         9270                                             
birth_obj_id_time        Tue May 15 21:09:27 2012                         
birth_vol_id                 2C645C57D81C5047B7DDE13C2834AAD2                 
commonpathsuffix       john\Downloads\Autoruns.zip                      
ctime                           Tue May 15 21:11:59 2012                         
filesize                        535772                                           
machineID                  john-pc                                          
mtime                         Tue May 15 21:11:59 2012                         
netname                     \\JOHN-PC\Users                                  
new_obj_id_node        08:00:27:dd:64:d1                                
new_obj_id_seq          9270                                             
new_obj_id_time        Tue May 15 21:09:27 2012                         
new_vol_id                 2C645C57D81C5047B7DDE13C2834AAD2                 
relativepath                ..\..\..\..\..\Downloads\Autoruns.zip            
vol_sn                        F405-DAC1                                        
vol_type                     Fixed Disk                            

The "mtime","atime", and "ctime" values correspond to the MA.B times, respectively, of the target file, which in this case is the Autoruns.zip archive.  As such, I could either go back and add the LNK info to my timeline, or automatically have that information added during the initial process of collecting data for the timeline.  In this case, what I would expect to see would be MA.B times from both the file system and the LNK file metadata at exactly the same time.  Remember, the absence of an artifact where we expect to find one is itself an artifact, and as such, if the Autoruns.zip file system metadata was not available, that would tell me something and perhaps take my analysis in another direction.

[Note: I know you're looking at the above output and thinking, "wow, that looks like a MAC address in the output!"  You're right, it is.  In this case, looking up the OUI leads us to Cadmus Systems, and yes, the system was from a VM running in VirtualBox.  Also, there's a good deal of additional information available in the LNK file metadata, to include the fact that the target file was on a fixed disk, as opposed to a removable or network drive.]

The Value of Multiple Data Sources
Regarding the value of data from multiple sources (even additional locations within the same source, in a comment to his post regarding a RegRipper plugin that he'd written, Jason Hale points out, quite correctly:

I didn't think there was a whole lot of value in the information from the TypedURLsTime key itself (other than knowing that computer activity was occurring at that time) without correlating it with the values in TypedURLs.

Jason actually wrote more than one plugin to extract the TypedURLsTime value data (this key is specific to Windows 8 systems). I've looked at the plugin that outputs in TLN format, for inclusion in a timeline...I use a different source identifier in version I wrote (I use "REG", for consistency...Jason uses "NTUSER.DAT").  However, we both reached point B, albeit via different routes.  This will definitely be something I'll be including in my Windows 8 exams.

Key Concepts
1. Employing multiple data sources to develop a timeline of system activity provides context, as well as increases our relative confidence in the data itself.
2. Employing multiple data sources can demonstrate program execution.
3. Employing multiple data sources can illustrate and overcome the use of counter-forensics activities, however unintentional those activities may be.

Registry Analysis

I have several upcoming speaking engagements, during which I will be talking about digital forensic analysis of Windows systems (with a focus on Windows 7), as well as about Registry analysis.  When preparing for presentations, I like to stay current (as much as I can) on what's being seen and visible through the media, so that I can provide up-to-date examples of what can be found on systems, particularly in the Registry.

The Microsoft Malware Protection Center recently provided information regarding April 2012 updates to the Microsoft Malicious Software Removal Tool (referred to as either "MSRT" or "MRT").  The April update includes coverage for three threat families.  The reason I mention this is, in part, because some of this malware is pretty "interesting"...one mines BitCoins from the compromised user.

The other reason I mention this is, even with the apparent sophistication of the malware itself, most authors still want their malware to remain persistent.  Win32/Gamarue can create an entry in the "load" value, or create a value beneath the HKLM\..\Run key.  Win32/Claretore creates a value beneath the HKCU\..\Run key.  These and other artifacts can make the malware easy to detect, even when all you have to examine is an acquired image.

You're probably thinking, "so what", right?  Big deal.  Well, you know why malware authors continue to use these "obvious" locations to have their code remain persistent?  Because it works.  That's pretty much it.  You see, the bad guys aren't trying to hide from me...they're trying to hide from you and your users.  If neither you nor your users are aware of these persistence mechanisms, and your approach to malware is to use commercial AV products, then you can be pretty sure that the bad guy is going to remain undetected long enough to get what they want.  I did emergency incident response for ISS (later, IBM ISS) for 3 1/2 years...the very nature of what we did was predicated by the incident already having happened, very often days, weeks or even months before we were called.

Regarding the AV products, Rob Lee recently posted some very interesting findings regarding AV products and the use of real-world malware in the capstone exercise for his FOR508 course.  Why would I bring this up?  Well, Rob's post illustrates an important factor to keep in mind when dealing with current issues...sometimes, the solution we've employed may not be sufficient.  When I teach my malware detection course, I describe four characteristics of malware that incident responders and digital forensic analysts can use as a framework for determining if a system had been infected with malware.

As an example, consider the Conficker/Downadup family of malware...I'm sure many of you remember it (perhaps not too fondly).  MS's write-up of this malware family includes five variants...and the one thing that they all have in common is their persistence mechanism...they all create a randomly-named Windows service...as such, there are a number of ways to detect the presence of this malware without using AV, including Registry and Event Log analysis.

I can remember back when I started getting into Registry analysis, and thinking that malware authors were pretty sophisticated in their use of persistence mechanisms.  Back then, it appeared that just the Registry locations that malware authors could use for persistence were near-infinite.  Now, a dozen or more years later, I still see the same Registry keys being used time and time again.  Because they work.

Registry analysis is only one component of your overall analysis framework.  However, many times, I feel as if it's misunderstood or simply not performed.  The nature of the Registry makes it an incredibly rich artifact environment, providing a wealth of information, intelligence and context.

Need resources to better understand the Registry?  I may be available to speak to your group (depends on scheduling...feel free to contact me) or take a look at my books...Mike Ahrendt recently posted a review of two of them.