Updates

RegRipper Plugins
I recently created a new RegRipper plugin named lastloggedon.pl, which accesses the Authentication\LogonUI key in the Software hive and extracts the LastLoggedOnUser and LastLoggedOnSAMUser values.

I wrote this one as a result of research I'd conducted based on a question a friend had asked me, specifically regarding the LastUserUsername value beneath the WinLogon key.  As it turned out, I wasn't able to locate any information about this value, nor was I able to get any additional context, such as the version of Windows on which this value might be found, etc.  I found one reference that came close to the value name, but nothing much beyond that.

Keep in mind that this plugin will simply get the two listed values.  In order to determine users that had logged in previously, you should consider running this plugin against the Software hives found in the RegBack folder, as well as within VSCs, and those extracted from memory dumps or hibernation files.

Another means of determining previously logged in users is to move out of the Registry and parse Windows Event Log records.  However, you can still use information within available Registry hives by mapping user activity (UserAssist, RecentDocs, shellbags, etc.) in a timeline.

Note that in order to retrieve values beneath the WinLogon key, you can simply use the winlogon.pl plugin.

AmCache.hve
Eric Zimmerman recently conducted a SANS webcast, during which he discussed the AmCache.hve file, a file on Windows systems that replaces/supersedes the Recentfilecache.bcf file, and the contents of which are formatted in the same manner as Registry hive files (the AmCache.hve file is NOT part of the Registry).

I enjoyed the webcast, as it was very informative.  However, I have to say that I haven't had a great deal of luck with the information available in the file, particularly when pivoting off of ShimCache data during an exam.  For example, while analyzing one image, I extracted the below two entries from the ShimCache data, both of which had the "Executed" flag set:

C:\Users\user\AppData\Local\Temp\Rar$EXa0.965\HandyDave.exe  
C:\Users\user\AppData\Local\Temp\110327027.t.exe

Parsing the AmCache.hve file from the same system, I found two entries for "HandyDave.exe", neither of which was in the same path as what was seen in the ShimCache.  I found NO references to the second ShimCache entry in the AmCache.hve file.

How did I parse the AmCache.hve file, you ask?  I used the RegRipper amcache.pl plugin.  While AmCache.hve is NOT a "Registry file" (that is, it's not part of the Registry), the file format is identical to that of Registry hive files and as such, viewing and parsing tools used on Registry hive files will work equally well on this file.

I found a lot of what Eric said in the webcast to be very informative and useful.  Just because I've struck out on a handful of exams so far doesn't mean I'm going to stop including parsing the AmCache.hve file for indications of malicious activity.  All I'm saying is that while conducting analysis of systems known to have been infected with something malicious, and on which an AmCache.hve file has been found, I have yet to find an instance where the malicious executable appears listed in the AmCache.hve file.

AppCompatCache
Speaking of Eric and his BinForay site, I've also been taking a look at what he shared with his recent AppCompatCacheParser post.  I have taken some steps to address some of the issues with the shimcache.pl plugin that Eric described and have included an updated script in the RegRipper repository.  There's still one issue I'm tracking down.

I also wanted to address a couple of comments that were made...in his post, Eric documented some tool testing he'd conducted, and shared the following:

appcompatcache.pl extracted 79 rows of data and in reviewing the data it looks like it picked up the entries missed by the Mandiant script from ControlSet01 but did not include any entries from ControlSet02:

That's due to the design...from the very beginning, all of the RR plugins that check values in the System have first determined which ControlSet was marked "current", and then retrieved data from that ControlSet, and just that ControlSet.  Here's one example, from 2009, where that was stated right here in this blog.

Eric had also said:

In my testing, entries were found in one ControlSet that were not present in the other ControlSet. 

I've also found this, as well.  However, about as often, I've seen where both ControlSets have contained identical information, which was further supported by the fact that the keys containing the data had the same LastWrite times (as evidenced by examination, as well as inclusion in a timeline).

Addendum: A short note to add after publishing this post earlier this morning; I believe I may have figured out the issue with the appcompatcache.pl and shimcache.pl plugins not displaying all of the entries, as Eric described in his post.  In short, it is most likely due to the use of a Perl hash, with the file name as the key.  What happens is that the manner in which I had implemented the hash has the effect of de-duplicating the entries prior to parsing the hash for display.

Addendum #2: Okay, so it turns out I was right about the above issue...thanks to Eric for taking the time to identify the issue and point it out.  I've not only updated the appcompatcache.pl,  appcompatcache_tln.pl, and shimcache.pl plugins, I've also created a shimcache_tln.pl plugin, as well.  I hope that someone finds them useful.