Tuesday, December 27, 2005

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?

19 comments:

Anonymous said...

About "when the application was run" could you not dump the registry with "reg export" and then view the dump with http://www.mitec.cz/wra.htm
to see the timestamp of the entry?

H. Carvey said...

Sure, you could, but isn't that an awful lot of work for something like that? After all, I've written Perl scripts that retrieve that information directly from the Registry. Go to the Windows-ir.com web site, click on "Tools", and there's a link to an archive for several tools that includes "keytime". This comes as a standalone EXE as well as a Perl script.

Thanks,

Harlan

Anonymous said...

RSS Feed. Off topic, but wanted to request if you could turn on your site feed so I can add it to my google homepage.

Anonymous said...

Hi Harlan
So "we don't know when the application was run" is not entirely true or? does this "keytime" tell us when?

H. Carvey said...

RSS Feed is on: http://windowsir.blogspot.com/atom.xml

Let me know if it works for you, and what site you're using.

As far as the keytime goes, take a look at the MUICache key...there's not MRUList, so you can't tell when the last entry was made, or even which one was the last entry. You'd have to correlate the information in the key with info from the filesystem, but there isn't enough info using just the key.

Anonymous said...

I tried that link last night using google's homepage, but it seems to work now. Thanks!

H. Carvey said...

What site will the feed be going to?

What's your site?

Anonymous said...

A possible answer to the Trivia Question:


cmd.exe /k cd c:\ && color fc && title ***** HERE IS WHAT YOU WANT TO CHANGE *****

H. Carvey said...

I was really hoping to get some comments on the Registry key...

Anonymous said...

Hiya. This is a really, really old post, and I have no idea if anyone will read it -- HOWEVER, I can tell you this: I just wrote a little program in VB.Net,and I wanted to get it to show up on the OpenWith dialog's list of Recommended Programs. I used Inno Setup to create an installer package for the program, and (using Inno Setup) made some Registry entries that would add keys and values to get the program on the List, and delete same on uninstall. However, in order to get the program's NAME (or any other info I wanted) to show up on the list, I had to create an entry in the MUICache.

Hope this helps.

Anonymous said...

The entries under this key are also used as the application title displayed in the task bar when the icons have been grouped together. This happens on XP and 2003 when "Group Similar Taskbar Buttons" has been enabled. Also, this entire subkey is refreshed by explorer.exe often, so don't count on keys being retained.

Anonymous said...

According to your entry, the values under the key are FileDescription(s) for the executable(s).

Moving forward, I changed the name of the executable and ran it via the shell, hoping to verify that indeed it was the FileDescription that was reflected in the registry. Somehow, the value reflected the changed name of the executable instead.

Anonymous said...

Like "Anonymous", I also created a little picture-viewing program that I wanted to appear in "OpenWith..." and I also used InnoSetup. The problem I'm having is getting the description to STAY in the MUICache. The program remains, and it stays on the OpenWith list, but the description periodically disappears. Don't know Why. Have to go back in and edit the key's Value to get it back. Weird. Any thoughts what could be doing this? (also unable to get the icon correct.)

So the MUICache is can be, in my opinion, more innocuous than some think; but it also appears to be more complex.

H. Carvey said...

Lynn,

I'm not sure how this is a forensics-related post...it may be best answered on a programmer's forum.

Thanks.

Anonymous said...

Hi. I do forensics, too and stumbled across your site. Looks great!

I am cleaning a system now (XPH) and it had a ton of malware, including backdoor.genlot.aet, and sembako-chzjlog.exe, among others.
I had tried BitDefender on it (just to try BD) and it cleaned out 3260 infected items.

After BD cleaned it and the sembako- file was deleted, the reboot showed an error saying that that file could not be found. I did find it in the registry under the MUICache.

I thought, being a cache, that this was only a list of recently run files.

Under Winlogon is a key Shell that has the value Explorer.exe "C:\Windows\sembako-chzjlog.exe"

As far as max entries, this one has 112 entries.

Rajiv said...

Boethos.

I am facing similar problem with another Sembako-cjzjlri.exe ...

How do I remove this error beep? I am not a tech guy... however, can follow the instruction up to opening of registry ....

please mail me at rajiv.bishnoi@gmail.com

Thanks

Rajiv

Kejenne said...

Hi everyone

So, I understood most of the post, though (5 years later) I do not know the context, so I have some questions please?

Are these .exe files created dangerous? Why is the malware causing the Explorer.exe shell to create them?

Are they responsible for opening up random websites through firefox? Why do they cause error pop-ups if they are malware - surely if they were harmful or collecting/sending data it would be smarter to be "invisible"?

How can I STOP them? Or stop the error pop-ups? I have recently been attacked by Antimalware Doctor (AD), and though I have cleared my registery and run a scan and cleaned out what was left, I still have residual issues. Are these pop-ups originally supposed to LOOK like AD's fake scan pop-ups that would try to convince you to buy the product? And now because the malware's files are mostly removed all that's left is an executable file with no camouflage, that without the right tools fails to run?

Does this mean that I may DELETE these executable files please? And what about the Explorer shell - can I locate the point where the malware is being activated to stop creating more files? It seems to put a lot of pressure on explorer.exe, or messing with the process, because explorer.exe also has error pop-ups and at shutdown brings up "this programme is taking too long to respond. Wait or shut down immediately"

I look forward to hearing from you, and seeing if I understand anything at all!

Stephen said...

It is not clear to me what executables are referenced in the MUICache and which are not. I understand what element of the PE resource is read and added to the registry key, but it doesn't seem to be the case that if an .exe has a string added to the FileDescription field of its VERSION_INFO resource section that it will automatically be added to the MUICache when launched.

if two .exe's both have a string added to their FileDescription field...why will one be added to the MUICache and the other not?

Thanks,
Stephen

H. Carvey said...

It is not clear to me what executables are referenced in the MUICache and which are not.

I don't think that's clear to anyone.