Home

Awesome

ir-rescue

ir-rescue is composed of two sister scripts that collect a myriad of forensic data from 32-bit and 64-bit Windows systems (ir-rescue-win) and from Unix systems (ir-rescue-nix). The scripts respect the order of volatility and artifacts that are changed with the execution (e.g., prefetch files on Windows) and are intended for incident response use at different stages in the analysis and investigation process. Each are described as follows:

ir-rescue is designed to group data collections according to data type. For example, all data that relates to networking, such as open file shares and Transmission Control Protocol (TCP) connections, is grouped together, while running processes, services and tasks are gathered under malware. The acquisition of data types and other general options are specified in a simple configuration file. It should be noted that the scripts launch a great number of commands and tools, thereby leaving a considerable footprint (e.g., strings in the memory, prefetch files, program execution caches) on the system. The runtime varies depending on the computation power, disk write throughput and configurations set. Disk performance is especially important if secure deletion is set and when dumping 64-bit memory (usually 8 GB in size), which can take a considerable amount of time.

ir-rescue has been written for incident response and forensic analysts, as well as for security practitioners alike, and is used in companies such as Cisco, PepsiCo, SaskTel, Praetorian and Counteractive Security. It represents an effort to streamline host data collection, regardless of investigation needs, and to rely less on on-site support when remote access or live analysis is unavailable. It can thus be used to leverage the already bundled tools and commands during forensic activities.

Dependencies and Usage

ir-rescue relies on a number of third-party utilities for gathering specific data from hosts. The versions of the tools are listed in the last section and are provided with the package as is and, therefore, their licenses and user agreements must be accepted before running ir-rescue. Note that Sysinternals utilities cannot be redistributed for others to copy according to the Sysinternals Software License Terms. Because of this, ir-rescue is no longer published along with Sysinternals utilities, and so all entries enumerated in section Third-Party Tool List and References must be downloaded from the Sysinternals Live Repository and moved into their appropriate folders in order for the script to run.

The descriptions and organization of the toolset are given below, with both 32-bit and 64-bit versions of Windows tools included adjacently, if applicable:

ir-rescue-win needs to be run under a command line console with administrator rights while ir-rescue-nix needs to be run under a command line window with root privileges. Both require no arguments and make use of a respective configuration file to set desired options. As such, executing the scripts simply needs the issuing of the files as follows:

Some tools that perform recursive searches or scans are set only to recurse on specific folders. This makes the data collection more targeted while taking into account run time performance as the folders specified are likely locations for analysis due to extensive use by malware. The locations for recursive search and non-recursive search for Windows and Unix systems can be changed at will in the respective text files under the configuration folders. Some of the tools have dedicated files with specific locations in which to and not to recurse. These are named recursive-<tool>.txt and nonrecursive-<tool>.txt, with <tool> being changed to the tool name. Each file must have one location as full path per line without trailing backslashes or forward slashes.

During runtime, all characters printed to the Standard Output (STDOUT) and Standard Error (STDERR) channels are logged to UTF-8 encoded text files. This means that the output of tools are stored in corresponding folders and text files. Status ASCII messages are still printed to the console in order to check the execution progress. A temporary folder created under %TEMP%\ir-rescue-win or /tmp/ir-rescue-nix is used to store runtime data (e.g., memory dump drivers and links to VSS copies) and is deleted upon completion. Data folders are created as placeholders for data during initialization. After collection, empty folders may be deleted if no data was collected (e.g., empty browsers cache). In the end, data is compressed into a password-protected archive and is accordingly deleted afterwards, if set to do so.

Configuration File

The configuration file of each ir-rescue-win and ir-rescue-nix are mostly composed of simple binary directives (true or false) for the general behaviour of the scripts, for which data types to collect and for which advanced tools to run. Lines preceded by a hash sign (#) are considered comments. These are used to briefly describe what each option does, to enumerate folders, files or registry keys important to provide some context, as well as to list relevant tools. The descriptions below applies only to ir-rescue-win, but they serve as an example to understand the overall approach and the configuration file of ir-rescue-nix.

For ir-rescue-win, data is grouped into the types given by the following directives:

On the one hand, the usage of advanced tools set by the sigcheck, density, iconsext and yara options is independent of the configurations made to the collection of data types. On the other hand, directives under the respective main options of the data types are tied to them, meaning that they are disregarded if the main ones are set to false. For example, memory-dump=true, the option that instructs the tool to dump the Random Access Memory (RAM), is ignored if memory=false. The same goes for the <option>-all option, which sets all options of a certain data type to true for convenience, except <option>-vss. The script supports retrieving data from all available VSS copies by creating hard links to the copies via the Windows kernel namespace, a feature that can be turned on with vss=true. Each of the main options has its own <option>-vss option, which enables or disables the acquisition of VSS data for that particular data type. Note that the data collected by the malware-startup and web-(chrome|ie|mozilla) options is password-protected too, with the password being "infected" without quotes. All options not found or commented in the configuration file are set to false during runtime, including the password for the final compressed archive.

Further note that the iconsext option is useful to look for binaries compiled with unusual frameworks that set PE icons (e.g., Python). Moreover, YARA rules need to have a *.yar file extension and to be put in the tools-win\yara\rules\ folder. The output of all advanced tools are stored under the malware resulting folder.

Below is a minimal example of the configuration file setting the collection of the RAM, including the live and historical paged memory, the system registry and Windows event logs in text format, as well as the compression of the final data folder with password "infected" (without quotes). Note that this configuration skips the collection of historical system registry files.

# ir-rescue-win configuration file
# accepted values: 'true' or 'false' (exclusive)

# general
killself=false
sdelete=false
zip=true
zpassword=infected
ascii=false

# modules
events=true
memory=true
registry=true

vss=true

# events
events-all=false
events-txt=true

# memory
memory-all=false
memory-vss=true
memory-dump=true
memory-pagefile=true

# registry
registry-all=false
registry-vss=false
registry-system=true

Third-Party Tool List and References

Windows

Unix

Change History

Author

@dfernan__