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?