Links

This is not the persistence mechanism you were looking for...
First off, thanks to David Cowen for taking the time to address a question regarding the use of the SvcHost key in the Software hive as a persistence mechanism.

It all started with a response to one of David's Sunday Funday challenges, where the SvcHost key was held out as a persistence mechanism in and of itself.  This got me to thinking because it wasn't something I was familiar with, based on my own research...so I wanted to know more and posted a question.  David took it on as an exercise for himself, and posted his findings.  Thanks to Dave to doing the work and sharing his findings with the community.

The purpose of this isn't to prove someone wrong...not at all.  Rather, it is to challenge popularly-held beliefs about DFIR artifacts and ask, is this correct?  Very often, something we've read or heard persists (no pun intended) long enough that it becomes accepted as fact.  One example that I see time and time again is malware that creates persistence in the HKCU\..\Run key, and the report stating that the malware does this to start again when the system boots.  This simply isn't the case, but it's stated on the Microsoft MMPC site, as well as by other malware analysts, often enough that it's simply accepted as "fact".

Interesting Reading
I saw that Corey Harrell linked to a couple of interesting articles on Twitter, one being a report indicating that security professionals in enterprise environments lack malware detection skills.  If you follow the links to the report, you'll see that its based on a survey; even so, I think that as a responder, it correlates pretty closely to my experience, as well as that of others who've responded to incidents such as these, either as a consultant or as an FTE.  The report lists three "root causes for the "darkness"", but I would suggest that they missed the most important one...management.  Folks in the IT industry focus on where their management tells them to focus, and well as what management supports.  If management focus is to keep email up and running, that's where IT will focus.  If management sends IT staff off to training, but there's no requirement to use any of that training when they return, the new skills atrophy.

I have a couple of posts that may be of use to folks, most of which are linked via this one.  Also, WFA 3/e (and the upcoming 4/e) has an entire chapter that covers this material, as well.  Also, be sure to read Corey's blog post on malware root cause analysis, which provides a great deal of valuable information, as well as his Triaging Malware Incidents post.

The other article points to a new post-exploitation wiki that is available from the folks at the NoVA InfoSec group.  This effort appears to be getting up and running, but it is a pretty cool idea to take a great deal of the knowledge and experience in responder's heads and post it in a way that it can be shared with others.  This is definitely a site to keep an eye on.

Malware Persistence
While we're on the topic of malware, I ran across this very interesting write-up on the Terminator RAT.  What I found most fascinating about the malware is the persistence mechanism; specifically, the malware 'sits' in a user's Startup folder, but can modify the Registry to redirect where that Startup folder is within the file system.  That is, it can "tell" the OS to use another folder besides the user's Start Menu\Programs\StartUp folder.  After reading this write-up, it took me only about 6 minutes to write a RegRipper plugin to extract this information, so now I can automatically search for this item.  It didn't take too much more to add a check to the plugin, so that if the path is anything other than what is expected, the plugin will flag it for me.  Interestingly, this is one of the suggested locations to look based on Symantec's list of common Registry key locations used by malware.

That's not the only interesting persistence mechanism I've seen recently; I ran across a description of Win32/KanKan not too long ago and wrote up a RegRipper plugin to help detect anomalies in under 20 minutes.

Tools
Lance recently posted on tools he uses during exams; it's a great list, and probably indicative of what many DFIR folks use.  I hadn't really thought about it before.

I don't have the tier 1 tools that Lance has, so my list is a bit different.  More often than not, I've found that the tiers of tools that I use depends heavily on the goals of the examination...I base my analysis process on what I'm asked to show, demonstrate or discover.  For example, I've had analysis engagements where the goal was to answer questions based on the Windows XP/2003 Event Logs, which had been cleared.  As such, my tier 1 tools become mmls.exe and blkls.exe from the TSK tools, strings from MS, and Perl.  In one case, I was able to retrieve over 330 event records, to include the "smoking gun", but in another case, I found over 73K valid event records, none of which was the one I was looking for (parsing the Security hive with the RegRipper auditpol.pl plugin showed me why this was the case).

In a more general sense, I usually start off using FTK Imager for image verification.  Like Lance, I use LogParser, great tool from MS for extracting records from Windows Event Logs, and it's useful for a number of other things, as well.

Also like Lance, I write a lot of my own tools and utilities in Perl, or add to ones that I already have (RegRipper, etc.).  Some of the code that I use isn't so much full tools but subroutines and functions that I can cut-and-paste into other tools, such as a function that I have for dumping binary data in hex editor-format.

Windows 8 Forensics
I've been working on updating WFA to the fourth edition, and as such, I've been attempting to address for DFIR analysts the recurring question of "...what's new that we need to know in Windows ___?" (insert whichever version, starting with XP...).  I thought I'd post a bunch of the links I've found to be very useful in helping to answer that question.  Here are the links I've found recently:

Amanda Thompson's Windows 8 Forensic Guide

Ken Johnson's SANS DFIR Summit 2012 presentation: Windows 8 Recovery Forensics

ForensicsWiki: Prefetch - the page links to research conducted by Jared Atkinson and Yogesh Kahtri, both of whom have documented changes in the Windows 8 .pf file format.

Digital Forensics Stream: Windows 8 and 8.1 Search Charm History

Windows 8 Forensics: Recycle Bin

CyberArms: Windows 8 Forensics: Internet History Cache; also, David Cowen posted the answer to his blog challenge regarding how to analyze the IE10 web history database.

Shell Item Artifacts, Reloaded

I spoke on David Cowen and crew's Forensic Lunch a bit ago, on the topic of shell item artifacts.  I put together some slides at the last moment to use as visual references for the discussion, to illustrate what I'd done with respect to digging into the talk a bit more.  The slides

In short, what I'd done is this...based on a previous Forensic Lunch, during which Joachim Metz discussed the existence of MFT file reference numbers within some of the shell item structures.  Specifically, starting with Vista, shell items pointing to files and folders appear to contain MFT file reference numbers.  This is mentioned not only in Joachim's Windows Shell Item format specification, but it's also described on Willi Ballenthin's Shellbags analysis page.

Accepting this, I wanted to validate the information and see what it looks like in the real world.  Using FTK Imager Lite, I extracted the MFT and USRCLASS.DAT hive file from my own Windows 7 system.  Parsing the shellbags entries from the USRCLASS.DAT hive (using a customized RegRipper plugin), I was able to get a hex dump of specific shell items as all of the shellbags were being parsed.  I redirected the output of the plugin to a file, and selected specific entries for analysis.  Figure 1 illustrates one of those examples.

Fig. 1: Sample Shell Item

The example that we're using is for a shell item that points to the D:\cases folder, with the key path Shell\BagMRU\1\2\18.  As you can see in figure 1, I've boxed the DOSDate times in yellow; the MFT file reference number is marked in colored text, with the MFT record entry (i.e., 45) in red, and the sequence number (i.e., 13) in green.  I highlighted these values, as we'll be using them in the rest of our examination.

The translated DOSDate times are as follows:

M: 2011-11-29 20:27:44
A: 2011-11-29 20:27:44
B: 2011-11-29 20:27:44

The times listed above are the last modified, last accessed, and creation/born dates for the folder, extracted and translated from the shell item that points to the folder (see fig. 1).  Per Joachim's format specification, there doesn't seem to be an entry modified time value available.  All of the times are listed in UTC format.

It's important to keep in mind where these times come from...the time stamps are read from the MFT (in FILETIME format) and translated to DOSDate time stamps via the FileTimeToDosDateTime() function.  

I had also extracted the MFT from the D:\ volume and parsed it via a custom Perl script.  I searched the output for record number 45, and it still had the sequence number of 13.  

The times from the $STANDARD_INFORMATION attribute:

M: Mon Sep 23 16:17:36 2013 Z

A: Mon Sep 23 16:17:36 2013 Z

C: Mon Sep 23 16:17:36 2013 Z

B: Tue Nov 29 20:27:43 2011 Z

The times from the $FILE_NAME attribute:

M: Tue Nov 29 20:27:43 2011 Z

A: Tue Nov 29 20:27:43 2011 Z

C: Tue Nov 29 20:27:43 2011 Z

B: Tue Nov 29 20:27:43 2011 Z

Now, the big question is...so what?  Well, the fact is that this information can be extremely useful to an analyst.

The time stamps can be extremely telling.  In this case, we see that the times from the shell item are relatively close to those within the $FILE_NAME attribute; this tells us that 

Sebastien pointed out something important with respect to shellbags on Windows 7 systems a bit ago over on the Win4n6 Yahoo group, specifically:

"Go in your Windows 7 help file and search for "Folders: frequently asked questions". Then select: "Why doesn't Windows remember a folder window's size and location on the desktop?". You will find why you are not able to find something similar on Win7:

"In Windows Vista, a folder window opens at the same size and location on the desktop that it did the last time you closed it, based on the location where the folder is stored. For example, if you resize the Music folder window and then close it, it'll be the same size the next time you open it.

Windows 7 remembers one size and location setting for all your folders and libraries. So each time you open Windows Explorer, it'll open at the same size and location on the desktop that it did the last time you closed it, regardless of which folder or library you open.""

The MFT file reference number tells us something about the MFT record; specifically, MFT records are reused, not deleted, when a file is deleted, and the sequence number is incremented each time the record is reused.  In our example, the folder still exists, and the MFT file reference number from the shell item points to an existing record in the MFT.  If this wasn't the case...if the sequence number in the MFT was 14 or more, then the information from the shell item would provide us with historical information from the system, showing us what existed on the system at some point in the past.  In this case, the LastWrite time for the key in question (which, based on the MRU values, applies to the item of interest), is 2012-05-22 14:34:27 UTC, which tells us when the folder in question actually existed on the system.  So, in addition to VSCs and hives in the RegBack folder, we have yet another potential source of historical information on systems, and it's simply a matter of how this information will be applied during an investigation.

Where this becomes really valuable, particularly if it pertains to the goals of your exam, is that you can develop a partial reconstruction of what a system "looked like" in the past...it would be more of a smear than a snapshot, given the various sources.  What I mean by that is that shell items exist within many more locations and artifacts on a Windows system than simply the shellbags...as previously mentioned, shell items exist in shortcut/LNK files, Jump Lists (Win7/8), as well as a number of locations within the Registry.  In short, there are a lot of locations within a Windows system where these particular artifacts can be found, and they seem to get more numerous as the versions of Windows increase, and they're created behind the scenes by the operating system.  As such, they're not only useful for seeing that the system "looked like" in the past, but they can also be valuable if the use of anti-forensics techniques are suspected.

Finally, I'm sure that you noticed the slight discrepancy between the times listed in the shell item, and what's in the MFT.  This most likely has to do with the translation that occurs via the API function...a 64-bit value with 100 nanosecond granularity is reduced to a 32-bit value with second granularity.  Also, per the API function, the seconds are divided by 2, and there's no sub-second granularity to the value.