There Are Four Lights: Malware Indicators in the Registry

It can be extremely beneficial to understand various artifacts that malware creates on a system, particularly in light of the fact that AV isn't catching everything.  Most AV appears to look for and then scan across executable files...some AV does find indicators based on text-based data, such as JavaScript code, etc.

Not all malware uses the Registry for persistence.  For example, Theola uses a Chrome plugin to perform bank fraud, and W32/Crimea modifies imm32.dll in order to remain persistent (I found this variant in 2010; this is a write-up from another variant from 2007).

Not all malware creates really obvious indicators in the Registry, either.  Corey talked about indicators for a variant of ZeroAccess.  However, I analyzed a system that had been infected with another variant of ZA, one that created the HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{8AD9C840-044E-11D1-B3E9-00805F499D93} key, the effect of which is explained in this GreyHatHacker blog post.  While this isn't a persistence mechanism, it does illustrate an indicator of a malware infection.

"Detecting" Persistence Mechanisms
There was a SANS webcast in January 2012 titled Detecting Persistence Mechanisms, during which a number of persistence mechanisms were mentioned, including several found in the Registry.  However, something that wasn't mentioned was how to actually go about detecting persistence mechanisms being created by malware.  Corey recently published an excellent blog post titled, Tracking Down Persistence Mechanisms, which does a great job of illustrating how easy it is to quickly examine the contents of autostart (or "ASEP") locations, particularly in the Registry.

The process I use to detect the use of Registry persistence mechanisms and other malware artifacts is to start by adding the key LastWrite times from the Registry hives (both NTUSER.DAT and USRCLASS.DAT for users) to my timeline.  This is exactly how I found the ZeroAccess artifact I described earlier in this blog post...the modified key was right there in the timeline.  I even went so far as to examine the hive file extracted from a VSC created just prior to the LastWrite time of the key, and I was able to determine that the LastWrite time was, in fact, when the key was created (i.e., the key didn't exist in the hive file from the VSC).  Timelines are a fantastic way to add context to the data that you're looking at, as well as to increase your relative level of confidence in the validity of that data.  However, timeline analysis is best utilized as part of an overall analysis plan, developing pivot points and items of interest via other data retrieval and analysis mechanisms.

Once I find an interesting Registry artifact in close proximity to other activity on the system that is associated with the malware, I have a number of options available to me.  Many times, I will open the hive in a viewer and take a look at what information is contained in the key itself...examine the subkeys, values and data.  I can correlate this with information gleaned from online searches, and very often, quickly write a new or modify an existing RegRipper plugin.  I then ensure that the Registry artifact is included as part of my shortened view of the overall timeline, along with a clear description of why it's significant, along with supporting documentation and references.  This serves the purpose of not only providing information to my customer, but also documenting the information for my own use.  In most cases, this entire process covers a span of a couple of minutes, maybe up to an hour depending up how much information is out there and available.

When Does It Start, and Why Does It Matter?
Where within the system that malware creates it's persistence mechanism has significant impact on your investigation, in part because investigations no longer center around the question of "was the system infected?" 

Take a look at this ThreatExpert report; the report points to a Registry value within the user hive that the malware adds data to in order to remain persistent, and then states:

...so that %AppData%\skype.dat runs every time Windows starts

IMHO, this can be easily misinterpreted.  If the analyst assumes that "Windows" refers to the system, then the statement is incorrect.  However, if "Windows" refers to the shell, then it is correct...but to a point.  In this case, the malware will start the next time that user logs into the system, and the Windows Explorer shell starts for that user. 

Ok...but so what?  Well, this can be a very important distinction to make.  For example, let's say that someone from the helpdesk logs into an account on a user's workstation in order to assist with or fix something.  They go to a web site to download a patch or update, and while it's installing, they do a bit of surfing...and the system gets infected.  If the malware infects the system within the context of only that user account (i.e., creates a Registry persistence mechanism in the "HKCU" hive), then that malware will not be launched again until that user account is used to log into that system again.  Where this distinction is important is in cases of the "Trojan Defense" (was the system infected, and did the malware execute?), as well as PCI forensic audits, where the PCI Council requires the analyst to identify the "window of compromise" in a dashboard area of the report.  For merchants that know about how many credit card transactions they have in a given time period, that "window of compromise" can have a significant effect on the overall outcome of the report, potential fines levied by the council, etc.  I examined a system once where the malware was identified and deleted by an on-demand AV scan less than 48 hrs after it was created on the system, and the intruder didn't upload a new version of the malware (albeit with the same name) for 6 weeks...which, like I said, had a significant impact on the overall outcome of the investigation.

In another example, I've seen a server systems that were infected with malware when an administrator logged in and performed some series of activities (usually web surfing or checking email...hey, it happens...) that led to the infection, with the persistence mechanism for the malware being in the Administrator user's NTUSER.DAT.  When the server is rebooted, the malware doesn't persist and begin running again until the user logs into that account...in some cases, depending upon the server, that could be for several days or weeks.  Once again, this is a very important distinction to make.

The ThreatExpert report mentioned above is only an example...it isn't the only site where these sorts of messages can be seen.  I've seen reports at the MMPC site that state that malware creates a persistence mechanism in the HKCU\..\Run key so that it "starts whenever the system starts".  The same is true for a number of reports at AV vendor sites.

Wow6432Node
I discussed Wow6432Node in a previous blog post, and Corey has discussed this as well. And yes, it is very important to point out yet again.  And again.  And again.  Why is that?  Because I honestly believe that most analysts are missing this source of data.