I have to say that reading the Windows Incident Response blog has been very useful on several occasions. Particularly last month while helping at a client’s site. I had been called in to assist with detecting the Initial Infection Vector of a piece of malware that was propagating to random systems throughout a very large network. Luckily when I got onsite I was pleased to find that the company’s security staff were squared away and knew how to user their incident response procedures and tools very effectively. Really they just needed an extra set of hands and a little more organization to help them get over the hump.
After gathering some information from systems around the world (literally) I started doing some memory analysis information captured from one of the infected systems. Memory analysis quickly identified one process that had used for DLL injection. One of the exported functions of a DLL we had already flagged as “interesting” was exporting a function called “StartLoopRunDoor.” Although this could just be anomalous it sounds an awful like “backdoor” so we noted it. I moved onto generating timeline information from the systems files, folders, Event logs, and registry modifications and the security administrator helping me added “door” to his keywords and ran another search on the system. As he was reviewing the hits I heard him say, “What the hell. Hey come look at this.” As I Peeked over his shoulder he pointed me to a registry key that had the value “door.” I started to say, “Yeah, no big deal” when he asked me “Can you store executable files in the registry?” Smiling, I said, “As a matter of fact, you can.”
It turns out that just days before heading to the site Harlan had mentioned it in his post “More Links“. Basically Harlan points us to a write-up over at Sophos Labs titled “Persistence is Futile“. They outline one such infection very nicely and Harlan concludes his post with some interesting capabilities that we might want to take into consideration. Had I not read Harlan’s post I might not have been surprised by the malware hidden in the registry key values, but I would not have known where to go for immediate resources to help with the situation.
So, what am I really talking about. Well, luckily I have a few screen shots for you. First lets start with reviewing the Registry Key in question. Using Mitek’s Registry File Viewer we drilled down into \\Software Hive\Microsoft\SysMgr. The are several key values as you can see. One key value that is hidden is “addr” which contains the IP address of the infected system and one other IP address (not sure the reason).
Now, many of you will be quick to recognize “4D 5A” which corresponds with “MZ” located at the beginning of Windows-based executable and DLL files. For a better look, here is some of the information in the “ssdt” key value.
Definitely an executable or DLL. Turns out, that this file was getting written to disk. Funny thing is, Symantec and Microsoft were not detecting it at the time. (I have to say, at the time they were detecting the file in the “hide” registry key value but only on disk.) So, we gave them a call. First we started with the company’s Symantec contact. We explained what we were doing and then what we had found. His first words were “You can’t do that.” We politely informed him that we were looking right at it and it can be done. Next we pointed him to the SophosLab post so that he could do a little research and spin up on the concept. Next we asked if they could start working on signature for the malicious code injected into memory and the malicious files stored in the registry. His response “No and No.”
Let me break down why quickly. Basically Symantec does not scan memory. Oh it will look at memory. It detects what is running and then scans the files, executables, DLLS, etc on disk to see if they contain code that triggers one of their signatures. But beyond that they cannot detect malicious code that has been injected into memory. NICE!!! Next, although the engine (he said engine, not definitions) can look at certain “hard-coded” locations in the registry, it does not actively scan the whole registry looking for malicous behavior. NICE!!! Whether or not he new what he was talking about the answer we got at the end of the phone call was, “Send us your files and we’ll see if we can do anything.” Which, in the end, they did. But the situation as it occurred was not very promising.
TIP: You can export the file in any key value by clicking “Save data….” Hashes of the extracted file and malware found on the system were identical.
Next we called Microsoft. We explained the situation again to their support representative and the first words out of his mouth were “You can’t do that.” The rest of the conversation was very similar to the Symantec call.
Of course, while we are talking to these representative we were also looking at the other keys. Remember “door”? Well, a quick peek at its contents started to get us a little worried. Here is what we saw.
Notice the “db” at the beginning? What about the “yyy” (I know, deal with it!!) and “vk” values? Well, my friends, that is a little database right there in the registry. The first entry is the file that is located in the “ssdt” key value. I cannot show you the other entries in this database because they are related to client information from the registry. Stuff like account information, group policy settings, and software that was run on the system. Just little things like that.
So, not only do you have to be worried about the registry being used as a part of a malware’s persistence mechanism, you also have to be concerned about the registry being used as a staging area for your intellectual property, credit card information, user information, etc. All this with limited methods to detect these situations.
The next question is pretty obvious. If my anti-virus program cannot help me, what can I do to protect myself. Well, as I am tired, that is going to have to wait until tomorrow. Check back as I’ll have a registry detection script modeled after Harlan’s RegScan and three RegRipper timeline plugins.
Go forth and do good things,
Don C. Weber
