Security Ripcord

I had not heard about this update yet, but I was pleasantly surprised when I visited Access Data’s download site today.  It appears that they have updated their FTK Imager Lite to version 2.6.1.  I am not sure about all of the updates that were included, but the most important thing I do know about is that it will now acquire system memory.

If you don’t have FTK Imager Lite in your arsenal you should reconsider why you have not obtained it yet.  This tool is one of the most important tools when it comes to rapidly obtaining system information.  Put this tool on a USB drive, attach it to the system you are investigating, and quickly grab system memory, the registry, system event logs, a directory listing including deleted files, and any other system file you think might help your efforts.

Now this just needs a technique to gather volatile system information such as a list of processes and network connections and you have everything you need for a full blown system investigation.  Oh, wait, system memory contains all that information.  EXCELLENT!!!!!  I guess you better start looking at those memory analysis tools again.

Go forth and do good things,

Don C. Weber

In Quick Incident Response Techniques I,  II and III we talked about how to use F-Response and FTK Imager to gather hard drive and memory information from a remote system and what to do with some of that information.  Now we need to talk alittle bit about what we can do with the memory image from that system.

With a copy of the remote system’s memory and an understanding of F-Response’s impact on that system an analysis of the system’s memory can be performed. Advances in memory analysis are rapidly moving forward. A good and free tool for memory analysis is Mandiant’s Memoryze. Memoryze parses the bit-stream memory file and generates XML output associated with the contents of the memory. To review these XML files and present it as human-readable information Mandiant’s developers have released Audit Viewer. Although Memoryze can be run manually, it is much easier to utilize the functionality of Audit Viewer to Launch Memoryze to analyze the memory file.

Audit Viewer

By clicking the Launch Memoryze button the analyst is presented with the usual configuration functionality. The analyst will point the tool to the Memoryze executable, the memory file, and the information output directory where the XML files will written. The other configuration considerations pertain to the information that will be collected from the memory file.

• MemoryDD will acquire memory from the system Memoryze is run on or from a Physical Drive such as those provided through F-Response’s functionality.

• ProcessDD will collect information pertaining to the process name or identification number provided. This will actually pull copies of the process executable and drivers associated with the process and copy them to the output directory.

• Driver Walk List will parse through the memory and determine the drivers being used by the system.

• DriverDD will collect information pertaining to a single driver name or all drivers. This will actually pull copies of the driver from memory and create driver files in the output directory.

• Processes will collect information pertaining to a single process or all processes. Specific information about a process can be selected. These include:

  • Handles

  • Sections

  • Ports

  • Strings

  • Imports

  • Exports

  • Injected DLLs

• Hook Detection – actually, I have to admit that I don’t know much about hook analysis. This information is key for determining the affects of malware on a system. Memoryze can be configured to collect information pertaining to:

  • System Service Descriptor Table call table

  • System Service Descriptor Table functions

  • Interrupt Descriptor Table

  • IRP tables

Launch Memoryze

Once Memoryze has completed its analysis of the memory file Audit Viewer can analyze the XML output. After pointing Audit Viewer to the output information details about the information can be reviewed. The following image shows how network connections can be identified. In this example, Audit Viewer shows the the Telnet service has an established connection with a remote system.

Telnet with Established Connection

Of course, F-Response also has an established connection. Of course, as we know from earlier we should expect to see two network connections associated with the F-Response process. The presence of only one connection shown in the following image could be a result of Memoryze’s parsing method or the exact time that the memory image was generated.

F-Response with Established Connection

The following image shows F-Response is connected to the log file name f-response-ent.exe.log. This is a good indicator of how Memoryze and Audit Viewer can provide information about running processes that cannot be determined from simply understanding that a process or service is running on a system.

F-Response with open log file

The default analysis activity associated with each process parsed by using the the Process configuration is just to grab information about each process. Audit Viewer provides the ability to output the process executable and all for driver files associated with the selected process. These, in turn, can be analyzed individually using malware analysis or code review.

Acquire F-Response Process

Depending on the system and the process being acquired the acquisition process could take one to five minutes. The analyst can determine when the acquisition process is complete by monitoring the Audit Viewer command window that is started for the acquisition process. Once the acquisition is completed the command window will close.

Audit Viewer parsing process files

As mentioned, the acquired files will be written to the output directory for further analysis.

Acquired Files

Well, I think this is going to mark the end of this series of posts.  Hopefully you have a better understanding of some of the techniques and tools utilized when performing quick incident responses for yourselves or your customers.

If there is something else you would like to see or that you would like me to talk about, just drop a comment and I will look into it.  For now, however, I will be moving onto some of those scripts I was talking about and one or two other ideas that I have to help advance these techniques and tools.

Go forth and do good things,

Don C. Weber

In our first Quick Incident Response Techniques I and II we talked about how to use F-Response and FTK Imager to gather hard drive and memory information from a remote system.  Now we need to talk alittle bit about what we can do with access to the remote system.

Setting this up again.  We have connected to a remote system using F-Response Enterprise Management Console (FEMC).  This provides us with Read-Only access as a physical drive on the local system.  We are not going to do things with that access.

Files pulled from remote system can be analyzed using any number of tools. A good example of this is pulling the Registry files and parsing them with RegRipper. Understanding registry settings and Last Write times associated with registry keys is critical when trying to piece together what has occurred on a system in the times leading up to an incident.

RegRipper

Although files can be pulled from the remote system and stored locally, they can also just be parsed, as is, from the local representation of the remote system. The following example shows RegRipper parsing the SAM registry file to pull local user account information for the remote system. The text output can be written to the local drive or to an external storage device. The same can be accomplished for the System, Software, and Security registry files. This example is not limited to the Registry files. Analysts can use their favorite analysis and parsing tools to access other important files such as the Windows Event Log or other application log files.

RegRipper parsing SAM registry file from remote system

Local access to the remote file systems allow analysts to perform timeline analysis to determine what has occurred on a system. Timeline analysis provides a sense of logical progression. Although some malware will use the anti-forensic techniques of modifying file times this will not occur for every file or in every instance. Anti-forensic techniques only means that the analyst needs to understand that the times used to parse the information might be slightly off. Body file scripts are easily generated using Perl or Python to stat every file available through the attached Drive Letter. The following image demonstrates this technique. Other, more through methods, can be performed such as using Sleuthkit’s FLS to grab file information from available and deleted files and folders. Unless specifically programmed to identify deleted files and folders, the Perl and Python stat scripts will not provide access or information about these important files.

Generating a Timeline BodyFile using Python

As you know, I like to share scripts I have written to perform tasks such as creating the body file you see in the image above.  However, as he often does, Harlan has already pointed us to a better way of creating this body file.  Basically, just use the functionality inherit to FTK Imager to create a directory listing.  Now the file that is created will be tab delimited and it will be encoded UCS-2LE.  Although the tab delimiting is not a problem, the UCS-2LE encoding makes it difficult to grep through for specific files and directories.  I have found two ways around this.  First, on Windows systems, you can use Notepad++ to convert from UCS-2LE to UTF-8 through the Format dropdown in the Main Menu.  On Linux systems you should use the iconv command to do the same thing.  Hopefully soon enough I will have a script that will convert this output to a bodyfile.  Either that or Harlan will beat me to it as usual.

As F-Response is a live response tool it is important to understand the impact it will have on a remote system. Three files will be written to the %System% directory. F-response-ent.exe is the executable file. F-response-ent.exe.ini is the configuraiton file for the executable. F-response-ent.exe.log is a log file that records F-Response activity and can be used for debugging issues.

F-Response files on remote system

As F-Response is a client/server program there will be a network connection associated with the communication between the two components. Actually as the remote client connects back to the FLMM and the FEMC there should be two network connections to port 5681, which is the default configuration setting.

F-Response Established Connections

Hopefully that is enough for today.  Next time we will start looking at how to analyze the memory we acquired.

Go forth and do good things,

Don C. Weber

Picking up where we left off in the last post, Quick Incident Response Techniques, we are about to connect to the  hard drive and memory of a remote system.  In this case a Windows 2000 VMware image.  Our goals are to collect system information that will be helpful during an incident response.

At this point we have used the F-Response Enterprise Management Console (FEMC) to connect to the remote system.  Now we are going to access these resources.

Login requests are performed by selecting the system disk or memory to access and the selecting Connect → Login to F-Response.

Login to Remote Disks and Memory

Successful logins will be represented by the blue F-Response icon. Selected disks and memory can now be accessed by any number of methods from the local operating system to data acquisition programs such as EnCase, FTK, FTK Imager, and ProDiscover, just to name a few. Analysts should note that the Connect tab in the FEMC now displays a Physical Drive location on the local system. Another welcome improvement in this new version.

Connected to Remote Disks and Memory

Once connected to a remote system the local operating system will attempt to provide a local drive letter to all partitions whose file system it understands. To help identify which drive letters have been assigned to these partitions the local system’s Disk Manager can be used. Once the Disk Manager has been opened, if the remotes system’s memory has been connected, or if the local system does not recognize the remote file system it may notify the user with a request to format the remote disk. As all disks are mounted as Read-only devices this should not be a problem, but selecting Cancel is the recommended action.

Disk Manager - Memory Format

Disk Manager should now display all of the connected Physical Drives as well as any drive letters that have been assigned to them.

Disk Manager

Now that the remote systems disk and memory are accessible as local Physical Drives, as mentioned previously, any data analysis tool can be used to collect the information provided by these drives. One freely available tool that is capable of connecting to Physical Drives is AccessData’s FTK Imager.

FTK Imager

To connect FTK Imager to Physical Drives an analyst only has to press the icon with the green plus symbol. This will produce the Select Drive window. Because of the new markings provided by FEMC each Physical Drive is clearly marked as to the remote system and Physical Drive number making it easy for analysts to keep track of the resources with which they are working.

FTK Imager Connecting to Physical Drives

Once connected to a remote drive using FTK Imager the analyst can review the information on the remote system and either acquire the full system or pull individual files including those that are normally locked by the operating system.

FTK Imager Viewing Remote Drive

To create an image of memory the analyst only has to right click on the Physical Drive representing the remote system’s memory and select Export. This will pop-up the Create Image window which will allow the analyst to select the location to store the bit-stream image of memory.

FTK Imager Creating Image of Memory

Accessing files on Physical Drives that have been assigned Drive Letters does not require any special tools. As long as the local operating system understands the file structure the individual files and folders can be accessed through the Windows Explorer. This is a Read-only access that will allow the analyst to copy selected files out to their designated storage location. Unlike many data acquisition tools, however, the origin and other information pertaining to the copied file will not be saved for future use. Analysts will have to keep their own detailed notes when using this method of file access and collection. This type of access also allows for the use of many tools installed on the local system. Malware analysis is a great example. Anti-virus scanners or the Gargoyle tool can be pointed to this Drive Letter to perform their malware analysis.

Review Files Via Read-Only Disk Drive

It should be noted, however, that reviewing some files and folders using this method may not be possible without elevated privileges.  The local system is still going to honor setting such as those files and folders marked as “hidden.”  To over come this limitation using the Windows Command Shell and programs such as SysInternal’s PSEXEC may be necessary.

But more on that later.  For now I think this is enough.

Go forth and do good things,

Don C. Weber

<!– @page { size: 8.5in 11in; margin: 0.79in } P { margin-bottom: 0.08in } –>

When answers are needed fast an incident handler needs to be able to quickly gather pertinent information and begin data analysis. Two things are necessary in these situations. First, knowing what to look for and second know how to get it. On the Windows Incident Response blog Harlan has been providing us with some of the important, detailed information required during incident responses in his posts about “Looking for Bad Stuff” and “Timeline Analysis.”

When specifics are not know there are several parts of a Windows operating system that are necessary for analysis. These include:

1. The memory of the system to determine what and how a process is running.

2. The registry of the system to determine information such as Autoruns, services, and other important configuration settings.

3. System event logs for system access.

4. A timeline of file and folder events.

5. Anti-virus scan of the system to determine if the system is infected.

Armed with this information an incident handler can at least start an investigation and obtain an understanding of events on the target system.

Now that we know what we want, how do we get it. Traditional methods tell us to image the system to get the information necessary for an incident response. But that takes time and physical access to systems. These requirements can complicate things. Third-party hosting or requirements for surreptitious information gathering may be factors of consideration. This is where F-Response comes into play. By now most of you know its capabilities of providing remote access to a system and providing access to the target system’s hard drives and memory. Recent advances, particularly the April 15^th, 2009 release of F-Response Enterprise Management Console (FEMC), make remote information gathering much easier and stealthier.

The information that follows is a quick run through of how to use FEMC in conjunction with a variety of tools to gather the pertinent system information that we have already covered.

First we have to start with a remote system. For this example I will be using a Windows 2000 Professional system loaded into Vmware Workstation. This will provide us with all of the necessary components of a remote system.

Windows 2000 Logon

<!– @page { size: 8.5in 11in; margin: 0.79in } P { margin-bottom: 0.08in } –>

Next step is to start the F-Response License Manager Monitor (FLMM). This will require that a dongle is inserted into one of the Universal Serial Bus (USB) ports on the system. For systems with fewer USB ports a USB 2.0 Hub comes in very handy. Be sure to pay close attention to the IP Address that the FLMM is configured to listen on. Using Vmware is a perfect example because it makes the Host system an multi-homed system. If the correct IP Address is not selected the remote system, in this case the VMware Guest, will not be able to contact the FLMM and the remote F-Response program will not start.

Start F-Response License Manager Monitor

<!– @page { size: 8.5in 11in; margin: 0.79in } P { margin-bottom: 0.08in } –>

Next we start the FEMC. As I mentioned, the FEMC makes deploying and managing remote deployments of F-Response very easy and intuitive.

F-Response Enterprise Management Console

<!– @page { size: 8.5in 11in; margin: 0.79in } P { margin-bottom: 0.08in } –>

Before deploying F-Response to remote systems the remote program has to be configured. This is done by selecting File → Configuration. Several items need to be configured. First is the Domain/Network Credentials. This is the authentication necessary to access the remote system. These credentials require Administrative level capabilities because the program will be installed in the systems %SYSTEM% directory. Generally, C:\WINNT\system32 or C:\Windows\system32. Administrative level capabilities are also necessary because F-Response will be started as a service. Next, the Host Configuration should be configured. I generally always select Physical Memory because even if I initially decide that I don’t want the system memory something I see on the system might change my mind. The only real reason to not select Physical Memory would be if you were deploying F-Response to a 64-bit system. Currently F-Response does not support acquisition of Physical Memory on 64-bit systems. The Username and Password fields are used to authenticate connections to the remote deployments. The Username must be eight characters log and the password must be fourteen characters long. The IP Address in the Validation Configuration should default to the settings applied to the FLMM, a quick verification would not hurt to ensure proper configuration. The last thing to consider during configuration is information about the remote F-Response deployment. Service Name refers to the name of the service F-Response will run as on the remote system. Executable refers to the executable that will be pushed to the remote system. Both of these input should be noted and remembered so that they can be easily identified and distinguished during data analysis. A good trick is to rename the executable before pushing it to the remote system. This will help keep other persons and processes on the remote system from easily identifying that F-Response has been deployed.

F-Response Configuration

<!– @page { size: 8.5in 11in; margin: 0.79in } P { margin-bottom: 0.08in } –>

One of the strengths of F-Response is its discovery capabilities. By selecting Scan → ??? or Scan → IP Address the analyst can quickly identify all systems on the network. This is very helpful in quickly identify remote systems within an environment. It can, however, also take quite a bit of time obviously generate network traffic that might generate alerts on intrusion detection systems. Additionally, collecting information from multiple remote systems will obviously have an impact on the local system’s network activity and hardware performance. For instances where these factors are a concern or if a single remote system is all that is necessary a direct connection functionality is available through Scan → Direct Connect. Direct Connect will accept the entry of a Host Name or an IP Address to locate the remote system. Once the Open button is click FEMC will attempt to contact the remote system and authenticate. If connection and authentication is successful the Direct Connect window will display the Install F-Response radio button. When selected this radio button will push the F-Response client to the remote system. This will activate the Start F-Response radio button. As you will notice, only the actions that can be performed will be made accessible by the Direct Connect window.

Direct Connect

<!– @page { size: 8.5in 11in; margin: 0.79in } P { margin-bottom: 0.08in } –>

If the start request was successful the Direct Connect will display the Stop F-Response and Issue Discovery Request radio buttons. If it was not successful then only the Start F-Response radio button will remain available. Analysts should give the process a little time to let the remote process start and respond back. If the start was not successful there could be a number of reasons. Analyst should double check the credentials provided during the configuration. If that does not work then the IP Address provided during the configuration and to the FLMM should be checked.

Start F-Response

<!– @page { size: 8.5in 11in; margin: 0.79in } P { margin-bottom: 0.08in } –>

Once F-Response has been successfully deployed and started on the remote system the Direct Connect window can be closed by selecting the Close or Quit button. The focus will be returned to the FEMC main window. In the bottom section there are several tabs. Activity associated with problems or successful start should be displayed in the Messages tab. Remote systems that have been successfully connected to will be displayed in the Active Clients tab.

Active Clients

<!– @page { size: 8.5in 11in; margin: 0.79in } P { margin-bottom: 0.08in } –>

Once a client is activated it is time to determine what is available to be accessed. This is done by performing an Issue Discovery Request. In this case there is only one remote system available, but F-Response is capable of issuing discovery request to as many systems as are available. This is done by highlighting the clients available in the Active Clients tab and then selecting Deployment → Issue Discovery Request.

Discovery Request

<!– @page { size: 8.5in 11in; margin: 0.79in } P { margin-bottom: 0.08in } –>

The discovery request will inform FEMC of the available disks and memory on each remote system selected. Discovered disks and memory will be displayed in the Connect tab. A new feature and distinct improvement in the 3.09 version of F-Response is the fact that it displays not only the host name of the remote system but it also provides name of the connected disk or memory. Access to the whole physical disk or separate partitions is available as is the system memory when selected. Although these disks and memory have been identified these resources are not accessible until a Login request has been issued.

Discovered Disk and Memory

That is more than enough for now.  If you are still with me, check back later for more on how to initiate the connection to the remote systems drives and memory.

Go forth and do good things,

Don C. Weber

Here is a question for those of you collecting memory from systems:

What do you do when you need to acquire memory from a 32-bit operating system that is running on hardware with more than 4 GB of physical memory?

Well, if your experiences are like my experiences then you crash the system.  Of course it makes sense and I should have thought of it before trying to acquire the memory.  It sure is tough looking sheepishly at a system administrator and saying “Sorry about that.”  This is why I recommend acquiring systems during off hours or scheduled maintenance windows.  This makes the sheepish “Sorry” a little less bitter.

I can imagine that the reason for this is that  memory tools such as Memoryze, Fast Dump, F-Response (in combination with FTK Imager from a remote system), and others are programs that are running on the operating system, the 32-bit operating system.  Although you would think that they would only be able to see what the operating system is able to access, their functionality provides them with direct access to the physical memory.  So, once the program gets to memory locations beyond what a 32-bit operating system can understand it does what all good operating systems do when they don’t understand: BSOD.

Recent experiences that I have had with acquiring physical memory that breaks the 4 GB boundary have not been successful at all.  Even on 64-bit operating systems I have achieved the grand BSOD.  Not sure why yet, or if this is just user error, but time and experimentation will tell.

Now, I’m not proud of crashing a customer’s system.  Especially multiple systems muliple times, but if we are going to get the information we need for an incident response then sometimes that is just going to happen.  However, with a little knowledge and forthought some of these system crashes can be avoided.

For now, I will just have to avoid these systems and ask that system administrators don’t buy systems with lots of memory if they are not going to run 64-bit operating systems (call your application vendors before considering this!!!).  If you do have a method for overcoming these issues, please leave a comment.  We would all like to know.

Go forth and do good things,

Don C. Weber

Although analyzing information provided in a system’s memory is not a new trick, the tools that help us automate these tasks are still new.  The three products that I am currently using to help me with memory analysis are Volatility(Vol), Mandiant’s Audit Viewer (MAV), HBGary’s Responder Field Edition (RFE).  These tools are very helpful and provide a wealth of system information that can help an analyst understand what is happening on a system without using tools that could be circumvented through techniques such as kernel hooking. Although this post is not meant to be an analysis of each of these separately, I would like to say that there are cool features in each tool that the others do not provide.  Here are a couple of examples:

• RFE provides a malware report summary that provides additional information pertaining different types of kernel hooks detected.
• Audit Viewer highlights specific processes when searching on key words.
• RFE allows the analyst to drill down into a hex dump of the memory and even performs some disassembly.
• Vol provides very clean outputs for placing information in reports.
• Audit Viewer shows if a network connection is LISTENING or ESTABLISHED.
• etc.

I included the “etc” because, obviously, there are more but you should investigate the other “quirks” for yourself.

Now, you can see that these tools definitely do perform differently but thus far it is mainly just style and information presentation.  Well, style and presentation are not the only ways that these tools differ.  They also differ in the how they look at specific information within the image of a system’s memory.  I found a good example when searching for active network connections.  The scenario is that a piece of malware was attempting to connect to a server on the Internet to perform some assumed malicious activity.  Through other analysis techniques the IP address was known to me and, in fact, I could search the system’s memory image and receive hits on the IP address in memory.

I initially used RFE to parse the system’s memory and it gave me some great detail about each process, Internet activity, keyword searches, etc.  But when I reviewed the information for the specific process that I believed was connecting to the remote system I did not receive any information about port activity.  In fact, the Network tab for the process did not display any information (no ESTABLISHED connections, no LISTENING ports).  So I checked the network connections for all processes and, as you can see in the image below, it provided no details about connections to the Internet.  All of the connections listed here are either loopback or internal to the network. (To view the full image just right-click and select “View Image”.)

RFE Network Connections

So, I decided to see what MAV would show me.  I did this because I had noticed that MAV did  display LISTENING and ESTABLISHED information for each connection.  But, when I pulled up the specific process in MAV I was provided with information that RFE did not provide me.  That is that the process I was investigating, svchost with PID 1052, was actually LISTENING on TCP port 3389.

Mandian't Audit Viewer Network Connection

Since I received conflicting information and the memory came from a Windows XP system, I decided to see what information Vol would provide to me.  Using the sockscan2 plugin I scanned the memory for open sockets.  This provided me with a wealth of information about open sockets.  Actually, as you can see, it provided me with more open socket information than that provided by RFE (although not shown, it provided more information than MAV as well.)

Volatility SockScan2 Plugin

Next I ran Vol’s connscan2 plugin.  Expecting the same information as that provided by RFE and MAV I was completely taken off guard by what Vol displayed.  Active network activity between the PID I was investigating and the server on the Internet.

Volatility's ConnScan2 Plugin

What is the moral of this post?  All of these great tools have functionality differences due to the different levels of experience and specific goals of each tool’s team of developers.  Analysts need to understand these differences through testing and implementation.  Additional insight may come from utilizing a variety of analysis tools rather than just relying on one or, as we have seen here, even two tools.  Certainly, running all of your data analysis through multiple tools every time is not the best use of your time.  But doing so on a periodic basis will help add strength to your conclusions while also keeping you up-to-date with the differences and the development progression of each tool.

UPDATE: I should have mentioned earlier that I have contacted the developers for each of these tools.  Although this is the first time most of them have heard about it I have opened a ticket with HB Gary’s support concerning displaying ESTABLISHED connections.  They have been very responsive to this and all of my other requests and recommendations.

Go forth and do good things,

Don C. Weber

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

I just updated the Scout Sniper page with a new release of the tool.  Actually, this tool was originally called Yara-Scout Sniper but I changed the name because of the new functionality that was added.

Scout Sniper now uses two different methods to detect suspicious files on a local or remote system(s).  The original functionality using the Yara Rules to locate malware files is still present.  Because of difficulties I ran into generating Yara Rule files to alert on Conficker/Downadup, I decided to try other methods to detect similar files.  I initially started looking into generating hashes for the PE file headers and sections but after some testing and recommendations from a few friends I fell back to using fuzzy hashing.  The new feature using Fuzzy Hashing functionality from the ssdeep project determines if any files are similar to a sample file provided by the user.

The tool has also been updated to provide copying and deletion capabilities.  Hense the Scout Sniper title.  Users can now copy or delete files that generate alerts.  Of course the delete functionality should be used with caution.

As usual, please provide me with any feedback, recommendations, or requests.  I would also be very happy to know how Scout Sniper is being used and any success or failure stories.

Go forth and do good things,

Don C. Weber

Thomas H. Ptacek of Matasano Security asked a question to all of the Twits following his tqbf twitter account:

Quick, Twitterverse. You put a “canary” email account in your database to see if you get owned. You start getting spam to it. NOW WHAT?

I only had time for a quick exchange and I couldn’t follow along with all the responses in real time.  My answer basically boiled down to:

@tqbf I’m coming in late but here is my quick answer Don’t panic if you have implemented a canary you have a IR plan. Follow it.

Let’s set up the situation a little bit to ensure that everybody understands what Thomas was referring to as a “canary.”  I am fairly certain that most everybody understands that miners use to take a canary with them to act as an early warning system in the event of toxic gases.  In this case an extra entry has been created in a database that is supplying information to another application (internal or external) to help provide a warning that the application or database has been compromised.  The thought process being that the only way that knowledge of the email address associated with the “canary” entry would be if there was a compromise.  Although you can tell from his tone (especially if you understand Thomas’ usual approach to showing that something does not make much sense), Ryan Russell pointed out that Thomas was most likely making a statement that the canary was “stupid cause he thinks there’s no IR that makes sense or that anyone would do.”

I am not going to recap any of the responses to and from Thomas as you can do it yourself should you have time to click back and forth through the twitter accounts Thomas responded to during the exchange.  I would like to follow up on my comment and how I think a canary record in a database may be helpful.

What does the canary in this situation really represent?  Basically, it is a mechanism to help you identify when your other controls have failed for any number of reasons:

• poor configuration
• bypass
• not monitoring the attack vector
• user error
• malicious insider
• [insert your own here]

It is one more piece of the defense in depth that may come in handy.  It is not designed to provide any more information other than the fact that an event has occurred that has exposed the canary to the real world.  Utilizing it an a number of ways may help provide more information about when, how, and what happened but most likely if will not.

What should you do if you start receiving email to a canary email address?  I stand by my very first statement.  DO NOT PANIC.  You received an email to an account.  That is all.  Until more information about the activity can be determined there is no specific methodology, outside of an incident response plan, that should be implemented.  The database server and application server do not need to be imaged and forensically examined on this information alone.  You could do so, but it is a knee-jerk reaction that could be, and more than likely is, wasting valuable time.

Hopefully, if your organization has implemented a canary it has also developed and tested an incident response plan.  The person monitoring the email account who has detected the anomaly should initiate this plan.  More than likely this will initially pull a limited number of key personnel together to evaluation the situation, identify what is happening, and decide on a course of action.  If your company does not have an incident response plan then you should read this paragraph again and use it as the basis for your initial reaction.  Pulling the proper personnel together right off the bat will help narrow down the events that have transpired and thereby initiating a more focused and proactive response.  More than likely that will begin with more information gathering to get a better understanding of the situation.

Now some people might still argue that to be on the safe side the database and web applications systems should be forensically imaged or even taken off-line.  I noticed from some of Thomas’ tweets while getting the links for this post that he did receive some of these responses and he pointed out, rightfully so, that it more than likely would not be cost effect, even extremely detrimental, to take either system offline.  Although a system can be imaged while running, there is always the risk that while doing a live response and copying memory and/or all internal media that there will be a system failure thereby bringing down the database, application, or even the whole server.  Now wouldn’t a incident responser look a little silly if they brought down the only web application servicing a business’ e-customers just to discover later that the email address was leaked out when an internal document detailing the canary methodology, including the email address, was leaked to the world by an internal user and their authorized/unauthorized peer-to-peer file-sharing software?  That’s a BIG opps that could have potentially been avoided with a little investigation and a little less knee-jerk reaction.

After thinking on whether the canary in the database method is a technique that should be implemented I have come to the age old conclusion: “Maybe.”  What it really boils down to is what other actions has an organization implemented to prepare themselves for the day that the canary account does start getting email.  There will be no way to begin answering the questions pertaining to root cause for such a leak if the appropriate logging on the network, operating system, application, database, and other controls has not been implemented.  If you cannot accurately determine the details behind an event then you cannot determine the details behind an incident. Having a canary in this situation would only lead to too many meetings, poor response efforts, and more money in resources and man-hours than an organization is capable of absorbing effectively.  That said, with the proper controls and incident response plan in place, a canary record in a database, a canary file in a file-share, an embedded html tag in a document, or a network monitor on a dark net are a few techniques that only take a few minutes to implement but could provide valuable information about an event and possibly and incident.  These could be leading contributors to detecting and reacting to an unforeseen threat or newly exposed vulnerability.  Although simple, they could be the piece of the puzzle that allows an organization to close the gap between the incident and the initial response.

Go forth and do good things,

Don C. Weber