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.

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.

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.


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.


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


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

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.

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.

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:


...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:




...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):


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

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:

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


...and got the following:


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.

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.

I recently conducted some research into a specific event/activity on a system, and found that timeline analysis proved to be an extremely valuable technique to use in this case.  I see a good number of questions online in the various forums asking about what could lead to a particular event, and in most cases, I ask the poster if they'd considered generating a timeline.  After all, any time you're interested in an event that occurred, particularly one that occurred at a specific time, generating and analyzing a timeline is a great way to answer that question.  It's also a great way to conduct analysis as part of research.

As indicated in my previous post, I had read online that the volume GUIDs found in the value names within the MountedDevices key, as well as within a user's MountPoints2 subkey names follow the UUID v1 format discussed in RFC 4122.  As such, this GUID contains a node identifier, which is most often a MAC address from the system.  Okay, that's easy enough.  There is also a 60-bit time stamp embedded in the GUID, which tracks 100 nano-second intervals since 15 Oct 1582...and I got interested in determining to what event that time stamp referred or was associated, specifically on my Windows 7 Ultimate test system.

I purchased a SanDisk Blade thumb drive (it was on sale), as I knew that such a device had never been connected to my system.  I then recorded the time and date that I booted system, as well as when I first connected the device to the system.  After connecting the device and noting the drive letter to which it was mapped, I disconnected it, waited a couple of hours and reconnected the device.  After disconnecting it, I shut the system down.  Again, I recorded the significant times in my notes.

Several days later, I copied the setupapi.dev.log file, extracted the System, Software, and NTUSER.DAT hives via FTK Imager, and dumped the System Event Log via LogParser, using the following command:

logparser -i:evt -o:csv "Select RecordNumber,TO_UTCTIME(TimeGenerated),EventID,SourceName,Strings from System" > d:\cases\local\system.csv

Using the appropriate tools, I generated my events file in preparation for creating a timeline.  I wrote a specific script to parse the System Event Log entries into the necessary five-field format, and crafted a specific variant of the RegRipper mp2.pl plugin to parse the volume GUIDs based on the UUID v1 time stamps.  I used regtime.pl (part of my timeline tools) to parse the Registry hives into the necessary format.

Now, what I didn't do was create a supertimeline from all data sources, as it wasn't necessary to do so.  No new Prefetch files had been created during the testing process, and I hadn't created or edited files on the thumb drive, so there really was no need to collect file system metadata.  I focused solely on the System Event Log as I understand that a number of event records are created in that log file with respect to drivers and USB devices, as well as a number of system-specific records.

What I was able to determine is that the time stamp within the volume GUID refers to the boot time of the boot session during which the device was connected to the system.  For example, I booted my test system at approximately 4:29pm EDT on 4 April 2012 (as indicated by a Microsoft-Windows-Kernel-General record with event ID 12); however, I didn't plug the device into the system until 4:55pm EDT (remember, I disconnected it and then plugged it again later at 9:02pm EDT).  When I parsed the volume GUID for the time stamp and normalized it to 32-bit time format, the time was within a second of the boot time of the system.  Throughout the rest of the timeline, I saw the creation of keys beneath the Enum\USB and Enum\USBStor keys within the System hive, as well as several other keys that need to be researched further and possibly included in the USB device analysis process.  I was also able to see that there were a number of event records that pertain to the use of USB devices.

Another example where this sort of analysis can be applied is in determining artifacts corresponding to a CD or DVD being burned on a Windows 7 system.  The System Event Log will have an event record with a source name of "cdrom" and an event ID of 133, indicating that the CDROM was locked for exclusive use.  If the user burned an ISO image, you'll see an indication of the access to the ISO image beneath the user's RecentDocs key, just prior to the ID 133 event.  If the user chose to send a selection of files to the CD/DVD drive and to "burn a disk", you'll likely see an isoburn.exe Prefetch file.

Again, it's very clear that timelines are an extremely valuable technique, not only for analysis of acquired images, but also when conducting research with respect to developing context and an increased relative confidence in the data and events in which you may be interested.

Zena Forensics: Recipe -Recipes are cool.  I like to cook.  Not everyone cooks the same way...if they did, how much fun would that be?  Not long ago, on a blog not far away, I ran across a "recipe" where someone used some of the scripts I wrote for parsing Windows XP/2003 Event Log records, and adapted them to Windows Vista+ Windows Event Logs, by tying in MS's LogParser.

LogParser is an extremely useful tool.  I recently sought some assistance on the Win4n6 Yahoo group with getting LogParser to spit out Windows Event Log records TimeGenerated times in UTC format, rather than local time (from my analysis system).  This was an important issue in some testing I was doing recently,

The command I ended up using looked similar to the following:


The key element was the bolded statement.  Using this statement, I didn't have to reset my system clock to GMT time, or add more "moving parts" or do anything else that would have potentially led to errors.

What I really like about this recipe is that the author needed to do something, needed to do something that he may not have had the ability to do through commercial tools, and did it.  Not only that but he did it open source, and provided it for others.  Great job, and I, for one, greatly appreciate the fact that the author decided to share the script.

RegRipper Plugin Maintenance Script - Recently, Corey Harrell and Cheeky4n6Monkey (why does that name make me think of the episode of "Family Guy" where Chris and Peter made up the "Handi-Quacks" cartoon??) put their heads together and come up with a very interesting tool.  In short, the apparent back-story is that Corey mused how "it would be cool" to have a tool that would run through the RegRipper plugins directory, as well as the profiles, and see which plugins were available that had not been included in a profile.  Cheeky took this and ran with it, and came up with the RegRipper plugin maintenance script.

Up to this point, per Windows Registry Forensics, you could view a listing of plugins a couple of ways.  One is to use rip.pl/.exe at the command line; the following command will print out (to STDOUT) a list of available plugins:


If you add the "-c" switch, you can get that listing in .csv format.

The other way to view the plugins is to use the Plugin Browser, which is a graphical tool that lets you browse the available plugins, as well as create your own profile.

As with the recipe listed in the first part of this post, I greatly appreciate the effort that went into creating this script, as well as the fact that it was provided to the community at large.  You can download the script from Cheeky's site, or you may see it referenced at Brett's RegRipper site.   I also think that this is a great benefit to the community, as I'm sure that there are folks out there who didn't even know that they could use this script, but will end up finding it to be extremely valuable.

Registry Findings
A while back, I wrote some code to parse Windows 7 Jump Lists, and as part of my research for that project, I ran into volume GUIDs (within the LNK format TrackerData block), which are based on the UUID v1 format specification, detailed in RFC 4122.  Two of the pieces of information of interest that can be parsed from the GUID are a time stamp, and a MAC address.

I recently caught something online that indicated to me that there might be other opportunities to make use of the work that I'd already done.  Specifically, some of the values beneath the MountedDevices key (those that begin with "\??\Volume"), as well as some of the subkeys beneath a user's MountPoints2 key, are volume GUIDs maintained in the UUID v1 format.  We already know that these two pieces of information are used to help us map the use of USB devices on systems, so how does this initial information about the GUID format help us?

The usefulness of the MAC address should be somewhat intuitive.  Perhaps more than anything else, what this means is that the MAC address is, in fact, stored in the Registry...not so much "stored" in the sense that there's a value named "MAC address", but more so in the sense that it's there.  Testing using a live system corroborates the fact that a MAC address is used; I say "a" because my testing system is a laptop, and has a number of IPv4 interfaces (LAN, WLAN, VirtualBox).  Interestingly, one of the MAC addresses that appeared in several GUIDs was from VMWare, which had been installed at one point on my system (I removed it). As entries from the UserAssist key showed when I had installed VMPlayer (launched the installer), I had a time frame that pertained to when the device(s) could have been used.

Note: Over on the Girl, Unallocated blog, Case Experience #2.4 illustrates some good examples of the volume GUIDs, from both the MountedDevices key, and the user's MountPoints2 key.

In a couple of cases, I found devices...specifically, the laptop's built-in hard drive and DVD/optical drive...where the node identifier didn't correlate to a MAC address from my system.  This was an interesting finding, but not something that really needs to be run down at the moment.

What this demonstrates is that the MAC address of a system is, in fact, recorded in the Registry, albeit not necessarily as a value named "MAC address".

More research is required regarding the time stamp.

Addendum, 20120410: Testing indicates that the time stamp points to the boot time for the boot session during which the device was connected.

Registry Parsing
Andrew Case, developer of Registry Decoder, recently posted regarding using reglookup for Registry analysis.  There are a number of links in Andrew's post to some of Tim Morgan's papers regarding such topics as looking for deleted Registry keys, so be sure to take a look.

PFIC 2011
I had an opportunity to meet a lot of great folks in Park City, many of whom I had only known about via their online presence.  One of those is fellow DFIR'er and fellow former Marine Corey Harrell. Corey's one of those impressive folks that you want to reach to and find in the community; rather than just sitting quietly, or just clicking "+1" or "Like", Corey goes out and does stuff, a good deal of which he's posted to his blog.

Corey posted his PFIC 2011 Review to his blog recently (Girl, Unallocated posted her thoughts and experiences, as well)...this is great stuff, for a couple of reasons.  First, some conferences, like PFIC, have a number of good topics and speakers, often during the same time slot.  As such, you may not be able to get to all of the presentations that you'd like to, and having someone post their "take-aways" from the presentation you missed is a good way to get a bit of insight beyond simply downloading the slide pack.  Taking that a step further, not everyone can attend conferences, so this gives folks who couldn't attend an opportunity to peek behind the curtain and see what's going on.  Finally, this gets the word out about next year's conference, as well, and may get someone over the hump of whether to attend or not.

DoD CyberCrime
Speaking of presentations, I got word recently that my DoD CyberCrime Conference presentation on timeline analysis on 25 Jan 2012, from 8:30-10:20am.  The last (and first) time I attended DC3 was in 2007, and unfortunately, within less than an hour of finishing my presentation, I was on an incident call, and off the next day to another major city.  Ah...such was the life of an emergency responder.

My timeline analysis presentation (an example of a previous presentation can be found here) is a bit different from most of those that I find available online, in part because I don't focus on using the SANS SIFT Workstation.  That's not to say that SIFT isn't a great resource...because it is.  Rob's done a great job of assembling a range of open source tools, and getting them all set up and ready to use.  However, the approach I tend to take is to start by attempting to engage the audience and discussing with them the reasons why we'd want to do timeline analysis in the first place, discussing concepts such as context and increased relative confidence in the data.  Understanding these concepts can often be what gets folks to see the value of creating a timeline, when "...because this guy said so..." just isn't enough.  From there, we walk through using the tools, and demonstrate how timelines can be used as part of your analysis process...keeping in mind that like any other tool, this is just a tool and needs to be used accordingly.  Creating a timeline when it doesn't make sense to do simply...well...doesn't make sense.

Anyway, I'm really looking forward to this opportunity, and hopefully seeing a bunch of really good presentations, as well.  Looking at the conference agenda as it is so far, it looks like there's a couple of good social events, as well, which will lead to some great networking.

MMPC Updates
The Microsoft Malware Protection Center (MMPC) recently posted regarding some new MSRT definitions, including Win32/Cridex, another bit of malware that steals online banking credentials.  Cridex uses the user's Run key for persistence, and apparently stores data in the Default value of the HKCU\Software\Microsoft\Windows Media Center\ key.  Figure 3 of the MMPC post includes a screen capture of what this data looks like.

Duqu
Although I haven't had an opportunity to analyze a system infected with Duqu, as always, I remain interested in what's out there, particularly from a host-based perspective.  I ran across a set of open source tools for detecting Duqu files (readme here).  There's also the Symantec write-up on Duqu, which is very interesting, as it defines the Duqu "load point", which is a driver loaded as a Windows service, specifically HKLM\SYSTEM\CurrentControlSet\Services\JmiNET3.  Apparently, configuration information is maintained in the FILTER subkey beneath this key.

Interestingly, the load point is described as "JmiNET7.sys", but the Symantec paper goes on to say that the service name is "JmiNET3".

The Symantec paper goes on to describe the loading techniques for the payload loader, and method 3 involves a section within a DLL called ".zdata".

Finally, the Diagnostics section of the paper includes another Registry key that is supposed to indicate an infected system; specifically, HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\4\”CFID”.

Anyone interested in learning more about Duqu should take a look at the Symantec paper, as well as anything else that's out there.  There seem to be some interesting (and possibly unique) indicators that you can use to scan your infrastructure for infected systems; per the Symantec paper, part of the Duqu threat involves infostealers.

Tool Updates
There've been some updates to the SysInternals tools recently, in particular to AutoRuns (new v 11.1), including some new autostart locations.  Check them out.

Andreas has updated his Evtx Parser tool (written in Perl), as well.

ImDisk was recently updated to version 1.5.2.

I updated my maclookup.pl WiFi geolocation script to macl.pl.   The previous version of the script used Skyhook to perform lookups, in an attempt to translate a WiFi WAP MAC address (found in the Windows Registry) to a lat/long pair.  I found out recently that this stopped working, so I sought out...and found...a way to update the script.

Reading
The e-Evidence.info what's new site was updated recently, and as always, there's lots of great reading material.  This presentation on using open source tools for digital forensic analysis spends a good couple of slides demonstrating how to use RegRipper.  David Hull has a timeline presentation available that discusses the use of SIFT v2.0 to create super timelines.