Thursday, March 28, 2013

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.


4 comments:

Dedric B. said...

Harlan, seems this blog is lately the "Regurgitation of the 'Journey Into Incident Response' blog."

I love Corey's blog too. I would like to propose the "Official JIIR drinking game." Everyone blog reader must drink from the tasty beverage each time you mention Corey's name or blog in your posts. Which lately, is about 3.5 times on average per post.

Keep up the great work though. I too think Corey is awesome. Darn -- now I have to *DRINK!!*

Keydet89 said...

...seems this blog is lately the "Regurgitation of the 'Journey Into Incident Response' blog."

Why do you think that is?

Corey Harrell said...

@Dedric B.

Thanks for the compliments about the blog. I have no interest in trying to wade into something. I'm only offering my observations since I'm the one being talked about.

I wouldn't be too quick to make judgments especially based off of "lately". Blog posts don't reflect the entire picture; it doesn't reflect that Harlan and I have been talking about and working on similar stuff (personal research related). It might not have been clear but Harlan and I are working together on the persistence mechanisms since I help support RegRipper. Hence, the cross mentions in our recent posts.

Something else to consider is blogging is a form of communication. In some instances, bloggers carry on conversations through their posts. When this happens it is the coolest thing. One blogger will discuss some topic which gets the attention of another blogger. They in turn discuss the topic by expanding on it and taking it one step forward. I don't see this as regurgitating content; it's more like discussing a similar topic from different perspectives and experiences. Every once in awhile you see it happen and when it does everyone in the community benefits. I think the better route is to encourage this so it happens more often.

Lastly, something to take into consideration is blogging is tough. It takes a lot of time, sacrifices, and work to frequently maintain a blog. Take a look at all the DFIR blogs out there. There are blogs associated with organizations/companies and personal ones. How many of them are frequently updated? For the ones associated with organizations/companies, how many of them are providing original content besides advertising the services, products, or trainings they offer? There's not many and this results in very few blogs consistently providing content back to the community. Bloggers (myself included) tend to mention each other and link back to each other. If the pool of blogs to mention is small then people get mentioned more often. Look at my blog, I frequently mention the same people and same blogs. I don't do it since I have some quid pro quo going on in the background (another topic I have no interest in nor do take part in since I believe in full disclosure). I do it because there is nothing else to talk about when others are not producing free content back to the community.

I could go on but this comment is long enough. Again, I'm not wading into anything and I have no interest in doing so. I'm only offering my thoughts since I and my blog are the topic of conversation.

Thanks again for the compliments. In the spirit of full disclosure, do you reveal your full name?

Keydet89 said...

I can understand the initial visceral reaction some have had to Dedric's comment, but I think that something we have to remember is that we can't go around adding context to and inferring tone from ASCII text.

Yes, Corey and I do have a lot of similarities in what we're saying via our blogs, particularly recently. I tend to think that this is a good thing...in part, because of where these very same things aren't being said.

Also, there are some differences, as well. In his most recent post, Corey gives an example of using a particular tool to locate specific information, whereas I shared the process that I use. The difference may be subtle, because we're both essentially talking about the same thing...but why's that a problem, exactly?

Maybe the reason we're talking about this is because it's important. Maybe it's because Corey and I are two people who think about what we do. For example, not long ago, I posted an article to my blog talking about Wow6432Node and the effect it can have on Registry analysis. Not long after that, I asked folks online what improvements and new plugins they'd like to see added to RegRipper...covering Wow6432Node was just one of the things that Corey asked for, and Corey was the only one who asked at all.