Mass Triage: Retrieve Interesting Files Tool (FRAC and RIFT) Part 2

Our story so far...
Frank, security analyst, reviews the files uploaded by Tony. During the review, Frank notes that AT jobs were used to run malicious tools on Bob's machine. Some of the AT jobs show some unknown batch files being ran during the same time frame as the malicious tools. It is possible that the actors have moved latterly within the network. Outside of the AT jobs, the ShimCache shows WinRAR being ran, among other things.

Frank decides that he should scan all 15,000 endpoints and servers for signs of the actors. He'll pull the normal system files for triage and search for the Indicators of Compromise (IOCs) he found on Bob's laptop. Frank calls management to let them know his next steps and kicks off FRAC.

Many organizations, large and small, struggle with conducting a mass triage during an incident. The two biggest problems they face is:
1) Gathering up the required files
2) Searching for signs of activity

Forensic Response ACquistion (FRAC) and Retrieve Interesting Files Tool (RIFT) were written to address problem 1. FRAC can be configured to sweep across an enterprise and gather up the files required for triage. Once the files have been gathered up, another toolset is required to process the files (i.e. problem 2). I'll detail solutions for problem 2 in the next article.

How It Works: FRAC and RIFT

FRAC is a GPLv2 project that can run remote commands across a Windows enterprise network. It consists of a Perl script, basic configuration files, and an SMB share. It uses PAExec or Winexe to connect to the remote machines, and then runs the commands required. It doesn't require a powerful system to run from, but does require lots of disk space if it has been configured to collect files. FRAC can run on the Linux, *NIX, and OSX using Winexe to connect to the remote Windows machines. As long as you can get Winexe compiled for the operating system you're golden. On the Windows side, PAExec was chosen because it is open source and doesn't produce any pops or signs that is running on the remote machine. Due to requirement for System level privileges to access the $MFT, PSExec, while it does work, had a pop-up that told the user that it was running. In a triage file-gathering scenario, you don't want your users killing the processes that are used to gather the files or run commands on the remote machine.

FRAC reads in a file containing either IP addresses or a range of IP addresses. It also reads in the cmd.txt file that contains the command that FRAC will execute. Upon reading this data, it will then start contacting remote machines.

FRAC is threaded. By default, FRAC will reach out to 25 machines at a time. Once a machine is finished processing, FRAC will kick off new threads until there are no more IP addresses remaining. In testing, 25 seemed to work better than a greater number. It should be noted that using FRAC to download very large files from multiple machines could impact the network. Think about what is likely to come across the network and set the number of threads to what your network could handle. This is one of those cases where it's better to test before kicking it off live on the network.

To gather files, Retrieve Interesting Files Tool (RIFT) is used as the command that FRAC will run on each remote machines. RIFT requires parts of Sleuthkit and a SMB share to store the retrieved files. When RIFT kicks off on the remote machine, it reads in the regex list of files/directories and then uses Sleuthkit's FLS to start parsing the $MFT. RIFT will create a directory with the hostname of the machine on the SMB share it was given. Then as the $MFT is parsed, RIFT will use Sleuthkit's ICAT to copy the files/directories over to the SMB share. The directory structure will be recreated for where the files were found on the SMB share under the hostname. For example, if the registry files were copied over, there would be a directory structure that looks like this:

{hostname}/windows/system32/config/{registry hive}

In other words it would look like this for pulling the SYSTEM hive from a workstation called Workstation13:

Workstation13/windows/system32/config/SYSTEM

Once RIFT has complete parsed the $MFT, it will end and return execution to FRAC. Overall there is very little impact to the machine itself as far as resources such as CPU & memory usage go.

If RIFT isn't run with FRAC, any other command could be run on the remote machines. For example, a batch script can be used to kick off winpmem to capture memory on the remote machine. Beware doing this type of activity across the board on your network. Capturing memory over the network should be done on a case-by-case basis.

FRAC tracks IP addresses that cannot be reached and writes those addresses to a text file. Once, FRAC is finished going through the IP addresses, the analyst can re-kick off the scan using generated text file to try those IP addresses that failed.

FRAC can be downloaded at:
https://github.com/chaoticmach... sure to review the documentation on FRAC and RIFT for additional details on how to setup and use the tools.

In Part 3, I will start discussing mass triage and how to process those hundreds of files recovered by FRAC into a meaningful manner that isn't time consuming. The goal of conducting mass triage to get answers quickly in the areas of:

• Which machines were accessed by the actors
• Tools and methods used by the actors
• Determine which machines need further analysis
• Maybe identifying any exfil tools used

Keven Murphy works for the RSA Incident Response team working on APT to commodity incidents.