Security Ripcord

I was learning how to use Mandiant’s Memoryze the other day and having a bit of trouble getting to know the XML configuration files.  My real task was to get Memoryze working with memory shared from a remote system using F-Response.  To do this I was pointing Memoryze to the memory instance, instead of an image file, and then using Audit Viewer to parse the information.  Unfortunately I was not able to get it working.  This was more likely due to user error and my not initially understaning how to implement the XML configuration file properly. (More on F-Response and Memoryze later!!)

Right when I thought I had figured out how to use the XML files I got a pleasant little surprise on the Mandiant blog.  Audit Viewer has been updated to run Memoryze automatically.  Now we have a quick and easy method to set up Memoryze’s XML configuration files automatically.   Parsing memory for valuable information has just become is as easy as it can get.

Before I was able to test this new version of Audit Viewer with F-Response I got a chance to use it on a memory dump from a system infected by the Conficker malware.  Conficker has been analyzed in detail by several organizations.  I like the series of blog posts on the Symantec blog as well as the very detailed analysis by SRI International.  Using the capabilities of Memoryze, however, I was able to see some Conficker activity that was not mentioned in any of the analysis that I have reviewed so far.

I’ll start out by mentioning, as most of you know, I am not a malware analyst.  I’m just pointing out a few things that appear to be interesting.

Let’s start with quick background.  The system that I gathered the memory from was a Windows XP SP3 system that was infected by Conficker via a USB drive.  I don’t have the system any more and although I could infect another system to confirm some of this information I don’t have a stand alone system readily available to infect.  We all know now that Conficker has some builtin virtual machine detection so I didn’t attempt to replicate using a VMware image.

The system showed the usual symptoms.  The Registry pointed to a randomly named service calling a randomly name DLL in the c:\WINDOWS\system32 directory.  In this case the DLL was named taqswng.dll.  The following image shows a listing of all the files that start with “ta” in the System32 directory.   Conficker marks the file as hidden so I had to use the “dir /A H” command to get it output with the rest of the files. (Right click on any image and select “View Image” to see a larger, more readable, image.)

Since I was here I ran two other commands.  First I wanted to see that processes were currently running.  Using the Tasklist command I determined that the process with ID 1484 looked interesting.  It is calling many other services that resemble the functionality outlined in many of the Conficker write-ups.  The image below highlights what I am talking about.

Next I wanted to know what the system would display as open connections.  Conficker is suppose to start an HTTP service on a random port between 1024 and 10,000.  The next image shows that the process 1484 does have a LISTENING port on 2980.

Now, I didn’t think that I would get any new information out of reviewing the memory of this system.  I just wanted to show myself what Memoryze could offer and how I could leverage it in the future when investigating processes.  After I used Audit Viewer to parse the memory for everything (use the PDF manual that is provided as part of the download to help you use Audit Viewer and Memoryze) the first thing I did was locate process 1484 and check the files tab to see if I noticed anything.  After review I noticed the taqswng.dll file was listed.

Excellent but I have to admit.  This would have been lost in the shuffle to me.  Basically, this is good verification that I have found the proper process.  Next I checked the Port tab.  This is where it gets interesting.  From the netstat command I know that I should be looking at TCP port 2980 and UDP ports 1023 and 1034 (both UDP ports on the loopback).  But look what Audit Viewer gives me.

But where does TCP port 1033 come into the picture?  I wish I still had this system so that I could try and connect to this port.  I did a quick review of all the analysis resources I am aware of and they do not reference a second listening service.  I can tell you that we did verify that this was Conficker.B and not Conficker.C.  Of course the varient does not matter because this would be different functionality.

The next interesting part came when I reviewed the Memory Sections tab.  The information provided here points to the process accessing the “index.dat” file.  Now, I’m not sure if this is to get the proxy settings to help access the Internet.  It very well could be and I have not researched to determine if this is the case.  But why Conficker is accessing the files listed in the image below are beyond me.  As with the extra port, there is no mention of this behavior in any Conficker resource.

If anybody has an answer to these questions I would like to know.  Post your explanation in the comments or, if you would rather speak with me privately, just include a valid email address in your comment and I will contact you directly.  I would have investigated this a little more deeply but due to time and resources I thought it better to get the question out there.

Good luck if you are still dealing with Conficker.  While you are addressing it, beware Virut.

Go forth and do good things,
Don

---

Help support my training and travel to security conferences. Get your SANS Training and GIAC Certifications through the Security Ripcord.

---

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.