Security Ripcord

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