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

To help with this I have taken a relatively new piece of malware and run it through the paces that Harlan describes.  I have to warn you, there are still things that are not completely understood about this malware.  But, in the end, that is the point.  Some time in the future I can just take the report I generated and update it with any new information.  Not unlike what is currently done by most AV vendors.  But  I hope that Harlan’s method helps incident responders understand these reports a little better.  I think it will also provide them with the means to speak more intelligently about malware and present the issues and reasons for recommendations in a more professional and consistent manner.

I also want you to pay attention to the different sections of the write-up.  In addition to Harlan’s basic characteristics I have included a Research Notes section.  Although some of this information is apparent from the previous sections, I have tried to tie together how specific things were discovered or explain specific actions.  Especially things that are not covered by the AV vendors.  I believe it is a good example of how information obtained by incident responders can add to the details associated with a malware outbreak within an environment.  Many times quick and focused research can discover key aspects about the actions taken by a piece of malware that are not necessarily apparent in the write-up by AV vendors.  These details could drive your response or help you focus on specifics instead of operating with generalities.

NOTE: This post is best viewed using Firefox and may not render properly in Internet Explorer since most of this post is cut and pasted from Microsoft Word. *shrug* I needed the nested bullets.

Trojan.RegSubsDat.A

INITIAL INFECTION VECTOR

• Unknown - possibly email (from AV report) - I cannot figure this out for some reason
• Possibly associated with Excel Vulnerability or vulnerabilities in other Office documents

PROPOGATION MECHANISM

• Unknown - possibly email (from AV report)

PERSISTENCE MECHANISM

• Current User Run Key for ctfmon.exe
  • [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
    • ctfmon.exe = “%System%\ctfmon.exe”
  • NOTE: Use of this key appears to be behavior that is consistent with non-malicious activity associated with uncorrupted versions of this program.
• The malicious files ws2_32.dll and ctfmon.exe placed in the %SYSTEM%\dllcache directory to ensure that if they are deleted or modified the system will restore them automatically. This means that the sfcfiles.dll had to be updated to include the names of both files. This also means that the services had to be disable temporarily which could mean that the LastWrite time for the following key and value was updated. Unfortunately there are many key values associated with Winlogon and therefore the LastWrite time is modified regularly.
  • [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon]
    • SFCDisable should equal 0 to indicate that WFP is enabled
  • [HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Windows File Protection]
    • SFCDisable should equal 0 to indicate that WFP is enabled

ARTIFACTS

• Creates
  • %System%\ctfmen.exe
  • %System%\noise0.dat
  • %System%\regs.dat
  • %System%\subs.dat
  • %System%\windcb.dat
  • %System%\windows.dll
  • %System%\bkav2006.exe
• Modifies
  • %System%\dllcache\ws2_32.dll
  • %System%\dllcache\ctfmon.exe
  • %System%\ws2_32.dll
  • %System%\ctfmon.exe
  • C:\boot.ini - disables DEP
    • The boot.ini is modified so that DEP is disabled. This is done by changing the /noexecute value to “alwaysoff” - see the DEP reference in the notes
• Mutexes created – these may be due to the malware or due to other processes or the subverted programs
  • oleacc-msaa-loaded
  • MSCTF.Shared.MUTEX.APG
  • 08B1CDBCH
  • mutexA
• DNS Queries and Web activity
  • v4.windowsaupdate.com
  • happytimer.free.info
• Network Traffic
  • Possibly Excel or other Office or Wordpad Documents that contain shellcode to connect to remote sites and download malware
  • Multiple IDS/IPS signatures should detect shellcode, writes to system32 directory,
• Other
  • During initial malware infection the following files have been detected. These files may be associated with a completely different malware but their occurrence precedes the activity associated with Trojan.RegSubsDat.A and should be noted.
    • % Windir %\SchedLog.Txt or %Windir%\Tasks\SchedLog.Txt
    • At1.job associated with running the program TMP.EXE
    • TMP.EXE – content or actions of executable unknown
    • del.bat – content or actions of executable unknown
    • sfcfiles.dll – modified to include the %System%\ws2_32.dll and %System%\ctfmon.exe
    • %Windir%\JavaApplet
    • %Windir%\h323log.txt

RESEARCH NOTES

From system analysis it appears that the infection starts out by a scheduled task being created on the system.  The Scheduled Task Log shows that a task titled At1.job (probably depends if there is already an At1.job) is suppose to run “TMP.EXE”.  After this is run the other files appear on the system.  I also detect the occurrence of the file “del.bat” in system restore files.  I have not been able to recover either “TMP.EXE” or “del.bat” from any infected systems.  After that the dllcache files appear, the “boot.ini” file is modified, the sfcfile.dll is modified to include the new files in the dllcache, and the Prefetch file for CTFMON.EXE is created or modified.  Later after that the bkav2006.exe file, the “.dat” files, and the JavaApplet folder appear (possibly after a reboot), see the ThreatExpert update.  All of this activity appears to be surrounded by System Restore points being created.  These restore points could be caused by system files being updated or by some other system activity.

RECOMMENDATIONS

• Apply Microsoft Patches MS09-009 and MS09-010
• Update all third party applications including Microsoft Office and Adobe PDF (added for good measure)
• Monitor DNS logs for queries pertaining to “windowsaupdate” and “happytimer”
• Block via DNS, web proxy, or web filtering “windowsaupdate.com” and “happytimer.com”
• Do not read emails or surf the web from servers or critical assets
• Update IDS/IPS solutions to detect shellcode, shellcode in Office products, system32 writes, UPX packer detection
• Use file integrity products or host-based IDS solutions to detect modifications to system files
• Update AV signatures

RESOURCES

• ThreatExpert Trojan.RegSubsDat Report - http://www.threatexpert.com/report.aspx?md5=0cafb41eca73d768091bc93f4343cbb9
• IBM X-Force: Microsoft Excel Remote Code Execution Vulnerability - https://portal.mss.iss.net/mss/xftas/alertAdvisory/details.mss?alertAdvisoryId=3311
• Trojan.Regsubdat.A - http://www.symantec.com/security_response/writeup.jsp?docid=2009-042215-2550-99&tabid=2
• W32.Regsubdat.A!inf - http://www.symantec.com/security_response/writeup.jsp?docid=2009-042222-3030-99&tabid=2
• Microsoft Security Bulletin MS09-009 - Critical - http://www.microsoft.com/technet/security/Bulletin/MS09-009.mspx
• CVE-2009-0100 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0100
• Microsoft Excel Malformed Object Memory Corruption Bug Lets Remote Users Execute Arbitrary Code - http://securitytracker.com/alerts/2009/Apr/1022039.html
• A detailed description of the Data Execution Prevention (DEP) feature in Windows XP Service Pack 2, Windows XP Tablet PC Edition 2005, and Windows Server 2003 - http://support.microsoft.com/kb/875352
• Registry settings for Windows File Protection - http://support.microsoft.com/kb/q222473/
• Hacking Windows File Protection - http://www.bitsum.com/aboutwfp.asp

POSSIBLY RELATED

• Microsoft Security Bulletin MS09-010 - Critical - http://www.microsoft.com/technet/security/Bulletin/MS09-010.mspx
• Microsoft WordPad Text Converter Remote Code Execution Vulnerability - http://www.securityfocus.com/bid/32718/info
• Microsoft WordPad Word 97 Text Converter Memory Corruption Error Lets Remote Users Execute Arbitrary Code - http://securitytracker.com/alerts/2008/Dec/1021376.html

For those of you still reading I’ll provide you with what is currently being provided by Symantec and Microsoft for this malware.  I am going to leave the recommendations off of the Symantec write-up to save space.  One note I would like to make is that the Symantec write up talks about injecting code into specific dlls.  This is a perfect example of information that malware analysis will discover that an analysis of system artifacts may miss.  These write-ups are still necessary and helpful.

Symantec - Trojan.Regsubdat.A

Discovered: April 22, 2009

Updated: April 23, 2009 7:45:14 PM

Type: Trojan

Infection Length: 33,280 bytes

Systems Affected: Windows 2000, Windows 95, Windows 98, Windows Me, Windows NT, Windows Server 2003, Windows Vista, Windows XP

The Trojan may arrive as an email attachment.

Once executed, the Trojan creates the following files:

• %System%\ctfmen.exe
• %System%\noise0.dat
• %System%\regs.dat
• %System%\subs.dat
• %System%\windcb.dat
• %System%\windows.dll

It then modifies the following files:

• %System%\dllcache\ws2_32.dll
• %System%\dllcache\ctfmon.exe
• %System%\ws2_32.dll
• %System%\ctfmon.exe
• C:\boot.ini

The Trojan then disables the Data Execution Prevention (DEP).

Next, the Trojan injects executable code from the non-executable .dat files into the ctfmon.exe process and any other process that loads the following file:
%System%\ws2_32.dll

Once the compromised computer has restarted, the Trojan contacts the following remote location and may download additional files:
v4.windowsaupdate.com

Microsoft - Virus:Win32/Kirpich.A

Summary
This software threat is detected by the Microsoft antivirus engine. Technical details are not currently available for this threat.

Go forth and do good things,

Don C. Weber

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

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

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

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

• 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

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

Incident Response should be handled like any other project.  It should be managed.  As most incident responders are aware, SANS GCIH course outlines 6 distinct phases of an incident response:

1. Preparation
2. Identification
3. Containment
4. Eradication
5. Recovery, and
6. Lessons Learned

Ah, Lessons Learned is the final step.  Actually, it is circular, so the final step leads into the first step.   I say leads into whereas a better metaphor might be “feeds.”  Or in the terms of following flow charts, for you management types out there, the outputs of Lessons Learned are the inputs of Preparation.  Here’s a question for you though, during your preparation phase did you look at the methodologies that you use to improve how you identify, prioritize, address, and follow-up on your lessons learned?  Or, when you are finished with your lessons learned meeting, do you have a list of action items that have been assigned to a specific individual who understands the criteria for successfully completing the action?

I just asked two questions that took your simple lessons learned meeting from a quick five minute session to a thirty minute plus session.  Although you might think that the issues will drive how long this meeting will last, in actuality that is not correct.  With proper methodology, in other words a practiced plan, this meeting can still be very quick while producing the key outputs that are necessary to augment your preparation phase.

Silver Bullet time.  Yes, I know, you want the silver bullet that is going to help you increase the effectiveness of your lessons learned process.  Guess what!!  Most likely you already have it.  Do you use process management to plan your software, hardware, or infrastructure development?  Bingo, then you have the means to improve your lessons learned.  Start using the processes that you already have in place.  I say this because it is the fastest and cheapest method to gaining control over this process.

For those of you who do not have a process in place, never fear, I have one word for you: Why.  Just ask why.  But ask it five times.  Asking why five times is the technique for determining root cause.  Gasp, Root Cause Analysis.  It is used during the Six Sigma process as well as being integrated into other project development schemes.  In his 5 Whys post Eric Ries explains that Taiichi Ohno of Toyota fame wrote about this technique in his book Toyota Production System: Beyond Large-Scale Production.

Now, this might seem silly to some at first.  It will seem especially silly to those individuals and groups that are not use to management their projects or doing root cause analysis.  This is where the longer meetings are going to come into play.  Of course, this is true of any new process.  New things take time to understand and get use to performing.  For some people the learning curve on how to conduct themselves in these meetings is going to be a long and tough journey.  But by consistently applying one of these methodologies to your lessons learned process you will find that each of your meetings is shorter and more productive.  The implementors will be happier because they are being heard (if they are participating) and the managers and executives will be happier because of the increased productivity and effectiveness of the end results.

Certainly I have only touched on this topic briefly.  If you have techniques that have worked to improve the effectiveness of your lessons learned meetings, please share them with us in the comments.

Go forth and do good things,

Don C. Weber

http://www.sans.org/?utm_source=web&utm_medium=text-ad&utm_content=affiliate_link1&utm_campaign=Cutaway_Security

This virus is especially fun because it is very good at propagating throughout a Microsoft Windows environment very quickly.  Here are some of the most interesting features:

Virus:Win32/Virut.BM

Win32/Virut.BM disables Windows System File Protection (SFP) by injecting code into WINLOGON.EXE. The injected code patches sfc_os.dll in memory which in turn allows the virus to infect files protected by SFP.

The virus infects .EXE and .SCR files on access, hence actions such as copying or viewing files with Explorer, including on shares (with write access) will result in files being infected, and the virus spreading from machine to machine.

W32/Scribble-A

A injects a malicious iframe into files whose extensions start with HTM, PHP or ASP, with affected files detected as Troj/Fujif-Gen. At the time of writing the iframe points to a site that hosts more malware.

PE_VIRUT.BO

This file infector connects to a remote IRC server. It then joins a channel to receive and execute commands on the affected system. This routine effectively compromises system security.

I can hear what you are thinking about these capabilities.  Nothing too unusual.  Companies should be able to handle this sufficiently.  It appears that the Anti-Virus vendors are on top of the situation so prevention and clean-up should be a breeze.  Well, that is where the complications begin.  Remember that little bit about disabling Windows File Protection?  This means that Virut can and will infect critical system files.  One detail that some AV vendors leave out or bury is the fact that cleaning up after Virut is not that easy.  Microsoft helps us with a little note in their write-up.

Virus:Win32/Virut.BM

Note: The method of infection used by Win32/Virut can damage some infected files beyond repair. In these cases, in order to return a machine to its pre-infected state, it may be necessary to install a clean backup of the operating system and associated applications.

Now it starts getting interesting.  Let me give you another scenario.  Your organization is very robust and you are using roaming profiles to allow your users to log into multiple workstations.  All of a sudden your server that hosts these roaming profiles is infected.  Users start logging in because that is what they do.  Bang, workstation after workstation is infected.  The only way to stop it is to stop users from logging in or taking your roaming profile server offline.  Who’s going to make that call?  No worries, your users don’t have administrator privilieges, correct?  Of course, it does not have to be a roaming profile server.  Do you have any file sharing configured within your network? Sweetness.

Here is a great scenario for administrators.  Do you have any web-based administration tools?  What about your developers?  No admin tools, okay, do you have any internal websites?  Wow, suddenly this is adversely affecting a whole bunch of applications and not just the operating system.

So now I’ll let you decide.  Would you rather spend your time rebuilding your critical systems and user workstations or spend the time doing a little preparation?  Actually, the protections are all the same ones that every security professional has been pushing over the last five years.  There is nothing new or golden.  But lets go over a few (this is not a comprehensive list) so that I can say I pointed you in the right direction.  By the way, if you have some to add, please add a comment or two.  As usual, all of these should be evaluated to determine if they do reduce risk while not adversely impacting business operations.

Quick Techniques:

• If it is determined that a server that provides roaming profiles, login scripts, or any network share has been infected the systems should be immediately isolated from the network.  Users should not log into any systems that require roaming profiles or are connected to network shares until the server(s) that provide this functionality are clean.
• All systems should be updated to include the new virus definitions provided by the AV vendor.  If maintenance agreements are in place, the AV vendors should be contacted to determine if they have provided definitions or protections for the new strains of the Virut virus currently propagating in the wild.
• All network and host-based IDS/IPS systems and applications should be updated to include new signatures associated with detecting the activity generated by this malware.  If maintenance agreements are in place, the network and host-based IDS/IPS should be contacted to determine if they have provided definitions or protections for the new strains of the Virut virus currently propagating in the wild.
• Remote systems such as laptops should be required to update their AV software and scan the system before being permitted to connect to the network.
• Users should be required to scan all removable media (regardless of size or content) on an isolated, patched, and AV up-to-date virus scanning system before being allowed to connect to an computer (server or workstation).
• On critical resources create a local administrative level account Where possible isolate critical systems from network shares and resources.  Temporarily band network login, the use of removable media, and any unnecessary network activity such as checking email or browsing the Internet from these resources.  This may require the creation of a local (non-roaming profile) administrative level account to administer the system in case the roaming profile or server providing login scripts is compromised.
• Complete, operating system level backups of all critical assets should be created and tested to ensure that these systems can be recovered quickly and accurately.
• Monitor the list of viruses cleaned by Microsoft Malicious Software Removal Tool to determine when it provides functionality for the new strain of Virut.  Have administrators practice remotely and locally deploying using this tool.
• Monitor network traffic for bot-like activity connecting to Internet servers as outlined by AV site Virut descriptions.
• Specific administrators should be assigned to monitor for updated information from AV vendor websites.

Don’t think those are hard enough to implement threat or no threat?  Try these long term protections.

Long Term Techniques:

• Users that do not require administrator capabilities should not be given administrator rights on their systems.
• Systems that do not require access to network shares and other resources should not be configured to utilize these shares or resources.
• Network resources and user profiles should be segregated by domain restrictions provided through robust Active Directory configurations.
• All systems and servers (on which it does not pose an adverse impact to operability) should have centrally managed AV and Host-base Intrusion Detection/Prevention software installed.
• Autorun should be disabled on all systems and servers.
• All operating systems and third party applications should be routinely patched.  All unnecessary operating system functionality or third party applications should be removed from any system that does not require them to operate or provide business related functionality.
• Review and upate all maintenance agreements with AV and network/host-based IDS/IPS vendors.
• Review, update, and implementation of a policies detailing acceptable use pertaining to removable media, email usage, and Internet usage.

All of this said I would like to remind everybody that the key to incident response is the preparation phase.  If we are not thinking about how to handle these situations within our environments then we are not going to be prepared.  As I stated before, this virus is nothing special in the grand scheme of malware.  Good security should limit, quickly contain, and eradicate an infection.   Not taking the affects of a virus such as this into consideration, however, is going to mean some long evening and weekend hours for the server and workstation administrators.  It also means that funds that could have been spent on increasing protections are going to be wasted on the clean-up effort.  Hopefully this put the bug into your ear and gives you a little information and methodology to help you educate others within your organization.

As I stated before, please leave a comment if you would like to add something.  Quick stories about how Virut affected your organization may help others understand what they could be up against.

Go forth and do good things,

Don C. Weber