Security Ripcord

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

This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported.

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