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.