The Mystery of MUICache...solved??

Holy Registry keys, Batman!

Okay, I've been tossing this around for a while, and even put it on the back burner, but never completely forgot about it. The issue is this MUICache Registry key, or more specifically:

HKEY_CURRENT_USER\Software\Microsoft\Windows\ShellNoRoam\MUICache

This is an issue, as a while back, I started noticing references to malware creating values beneath this key...specifically, Trojan-Alexmo and Adware-BlowSearch. The technical write ups simply stated that the keys were created, but gave no indication as to their use. Was this a new startup location that malware authors had discovered? What is the key used for? I did some searches, but found way too much information to wade through and digest. I posted questions, but didn't get responses.

So, I'm over on ForensicFocus today, and "Lance" (I'm assuming this is the Guidance Lance) says something about the MUICache key values that point executables having window names as their values. You know, when you open up the command prompt on XP, for example, it says "Command Prompt" as the title (Trivia Question: Does anyone remember how to change that title in a DOS batch file, so something other than "Command Prompt" appears??) of the window. Well, I opened up my RegEdit and took a look at the entries under the key. I took a close look at some of the values that pointed to executables, and tried opening some. I began to see that the information in the Registry wasn't what I was seeing as the window titles.

So then I fired up Perl, and ran a script that I use that retrieves file version information from executables (ie, EXE, DLL, etc.). Lo and behold, but there under the FileDescription value, was the string that I was looking at in the Registry!

So, what does this mean? Well, I started doing searches for "Muicache + filedescription" and I found this archived entry from the OldNewThing blog. From there, I found others...in particular, this one from the Sun Java forum.

From reading through these entries, my understanding of this issue is that the values that you see under the MUICache key are not placed there by the executable, but by the shell (ie, Explorer.exe). Therefore, when a technical description of malware states that the executable "creates an entry under the MUICache key", this isn't technically correct. In fact, what's happening is that the shell is creating the entry when the malware is run.

From the forensic analysis aspect of things, how does this help us? Well, it shows that an application was run on an XP (I don't have a Win2k system to test right now) system at some point, whether the executable is there or not. However, we don't know when the application was run, as there is no MRUList associated with the entries. One indicator may be a corresponding entry for the executable in the PreFetch directory.

Well, it would seem that the veil of secrecy on that particular issue has been pierced...at least, to a degree. There are still questions, such as, is there a limit on the number of entries in this key?

Also, there needs to be some testing done. For example, if someone gets a Trojan on a system, and gets the user to launch it somehow, one would think that an entry would appear beneath the key. However, if the attacker were able to get another executable on the system, and launch it via the Trojan (something as simple as a netcat listener would suffice for testing), would an entry be made for that second executable? It would stand to reason that malware that runs as a service wouldn't appear in this entry, because such applications are not tied usually tied to an interactive user's account.

Thoughts?

Addendum 30 Dec: In case it wasn't clear, one of the points to my entry is that at least on A/V vendor had done "analysis" of some of the new malware (linked) and found that one of the changes that occurred on the system was that values were added to the MUICache key. Googling for this kind of thing reveals "analyses" at other A/V sites that include equally vague information. However, it seems that this key is NOT, in fact, set by the malware in question but instead by the shell.

So, as an aside, whom do you trust when it comes to this kind of analysis?

Registry Reference

I've been working away on a Registry reference, basically, an Excel spreadsheet of Registry keys. The idea is to list them with some sort of categorization, listing each by key name/path, value (if applicable), a brief description, and then any references that may apply.

In the case of what I'm working on, most of the references so far are MS KB articles that describe the keys and/or values.

The descriptions are meant to provide information regarding how these keys/values are useful during forensic investigations. Many of them can also be useful during live response investigations, as well.

Work is coming along smoothly...oddly enough there isn't a great deal of this sort of information out there. I've been pointed to several resources, and in most cases they lead back to either my original spreadsheet, or stuff from AccessData.

The age of "Nintendo forensics"...

...is coming to a close. Or, rather, it needs to. Looking around, seeing what's going on in the community, and in particular, in the news, I have to think that the days of blindly imaging a system and then running searches for keywords or images are going to be a thing of the past soon.

Windows systems in particular hold a wealth of information. There are areas of systems that are largely unexplored by many forensic analysts, particularly on the law enforcement side of the house. Now, I know that this is in large part due to case loads, staffing, training, and simply time. However, more knowledgeable law enforcement officers (at all levels...local, state, and even federal) as well as more knowledgeable system administrators (and even CIOs) will serve to level the playing field between the good guys and the bad guys.

What am I talking about? I'm talking about the fact that Windows XP and 2003 are becoming more prevalent by the day, and soon Vista will be in production and on the streets. We (the forensic community) can no longer operate from an MS-DOS standpoint.

Don't get me wrong...data reduction through the use of searches, file hashes, etc., is still extremely useful. However, a search for an ASCII string may turn up very little when searching the Windows Registry. One needs to understand the format of the Registry (even on the binary level) and how the Registry is structured. The same holds true with other file formats...OLE/compound documents (MS Word being the most prevalent example), PE files, Event Log files, INFO2 files, and even shortcuts. Yes, there are tools that can be run to pull information from the files but does the person running the tool understand what's happening "under the hood"?

Now, some of you are going to say, "Hey, I don't need to know how to locate and program the computer systems in my car in order to drive a car.", and I'd say, "You're right." However, what I'm talking about is pulling more comprehensive information from an image of a Windows system, and building a better case. In the face of more sophisticated malware, the expanding use of rootkits, and the increase of publicized anti-forensic techniques, I'm beginning to see how a greater level of knowledge is necessary.

Visibility?

Posts have been sporadic, and not nearly as frequent as before...I know. That'll change.

For now, though, I've got a question for the readers...one that you can really help me with. Just about every month, I run across someone (usually online) who says, "I wish I knew more about this...". In the past, it was things like NTFS alternate data streams. More recently, it's been USB device artifacts in the Registry. The thing is, regardless of the topic, I will do a simple Google search and turn up some pretty good resources (if it's stuff I've done, I cheat a little and just send them the link).

So, my question is this...how do you make things more visible? Take information as an example. You write an article about something that may be very useful to a group of people. You get the article published in a magazine or journal that caters to that group of people. However, not everyone in that group gets the journal.

Things I've tried include presenting at conferences (and in the case of my book, giving away free copies after the presentation), writing articles, posting to online forums, talking to people, etc. Now, I'm not saying that that's all that can be done, or that I've done any of those things enough. What I am asking is, what are some things that I can do to market stuff I've done...not just books, but code and any other information that I develop/produce.

Thanks...thoughts and especially solutions are appreciated.

Registry Reference

One thing I've really noticed over the years is that while some information is available out there on some Registry keys and values, there really isn't much that is useful/credible and geared toward forensic analysis. So I've been considering starting up a reference resource...well, I brought the subject up on a couple of lists, mostly looking for input, and the overwhelming response was, "Great! Let me know what I can do to help."

I haven't really settled on a format, per se, outside of basic elements, such as key/value path, data type of the value(s), a description or explanation of the key/value and what conditions lead to the creation/modification of the key/value, credible references, and the name of the submitter. One thought I had was to list everything in HTML, making it easily portable. Another thought was to use a database of some sort, because in doing so, scripts can be written to search the database, or extract information into text, HTML, XML, etc....whatever format suits the user.

Again, the goal is to provide credible, referenced information about Registry keys, as Registry analysis is something that simply hasn't been explored up to this point...at least, not in any great depth.

If you've got any thoughts on this, let me know. And yes, I am aware of the paper AccessData put out...thanks.