3.2. Cyber Triage Collector Tool

This chapter outlines how to collect data with a focus on the Cyber Triage Collector. You should understand the Collector even if you have your own collection tool because:

  • Using the Cyber Triage Collector will provide the most amount of data in your investigation and will give you the best results.

  • The Cyber Triage Collector is used to extract data from disk images and other data sets you import

NOTE: The Cyber Triage Collector will give you the best results because it collects more than other tools do. It will resolve artifacts and collect files that are referenced, which results in more executables and file content. See our adaptive vs static blog post for details.

The next chapter of this manual focuses on importing already collected data into Cyber Triage.

3.2.1. What is it

The Cyber Triage Collector is a separate program that will extract the key files and artifacts from a live system or data source (it is used behind the scenes on many of the 3rd party collections).

  • Is a single file, command line executable

  • Runs on Windows XP and above

  • Has no dependencies, such as .NET

  • Can write results to a local JSON file, over the network to Cyber Triage, or to cloud storage (S3-compatible or Azure).

  • Can encrypt the output using public key encryption.

  • Uses The Sleuth Kit to parse the file system so that on a live system, it can bypass rootkits and access locked files. It can also access logical file sets and disk images.

  • Is adaptive and parses artifacts on the live system so that it can resolve additional files, such as collecting the EXE files associated with an AutoRuns Triggered Task item.

3.2.2. What Does It Collect

The Collector gathers the files and artifacts behind Cyber Triage’s Information Artifact Types. You choose which types to collect (and whether to run a full file system scan) via Specifying Data Collection Types.

3.2.3. How Can You Launch It

In some situations, Cyber Triage will run the Collector automatically. In others, you will need to manually launch it or configure IT infrastructure to do so. See Getting Data Into Cyber Triage for help deciding which approach fits your situation. The options are:

3.2.4. Where Can It Send Data To

There are three main locations that the Collector can save data to:

  • A local file (this is the default behavior)

  • Over the network and directly to the Cyber Triage application

  • A cloud storage provider (S3-compatible or Azure)

See Collector Output Options below for details on each.

3.2.5. Configuration

Before you extract and launch the Collector, you may want to configure:

Details for each are below.

3.2.6. Extracting the Collector

If you are going to directly launch the Collector on a live system, then you must first extract it from the main application. This is required for the following scenarios:

  • Configuring an EDR to copy the Collector and launch it

  • Putting the Collector on a network share and launch it

  • Sending the Collector to a client for them to launch

Before you extract the Collector, configure things like custom file collection rules, cloud storage, and public key encryption - see Configuration above.

To extract the Collector:

  • Choose the menu icon (☰) from the upper right of the opening Cyber Triage window, then Download Collector.

../../_images/import_collector_download_menu.png

Download Collector menu item

../../_images/import_collector_extract.png

Download Collector

This will give you a ZIP file with a CyberTriageCollector folder with the command line and graphic interface programs inside of it. It will also have a configuration file if cloud storage credentials were specified.

NOTE: This version of the Collector will not process an E01 disk image. There are rare scenarios where people can’t simply import the disk image into Cyber Triage and instead want to run the Collector on it to get the JSON file. To do this, follow the instructions in Using The Collector on Disk Images.

3.2.6.1. Files in the Collector Folder

You technically need only a single EXE when you launch the Collector, but you may notice that there are other files in the folder when you extract it. This section outlines what the other files are and if you need to copy them to a remote system.

Collector Executable: You will have one of the following depending on what you picked in the UI:

  • CyberTriageCollector.exe: This is the primary tool, however different versions exist for XP and Vista.

  • CyberTriageCollector_Vista.exe: Collector that runs on Vista.

  • CyberTriageCollector_XP.exe: Collector that runs on XP.

Collector GUI: GUI Wrapper that ultimately calls the above Collector.

  • CyberTriageCollectorGUI.exe:

../../_images/import_collector_gui_manual.png

Configuration files may include:

  • CollectorConfig.yaml: Contains settings such as cloud storage credentials and public encryption keys.

  • filesets.yaml: Contains custom file collection rules.

  • config.conf: Contains settings that CyberTriageCollectorGUI.exe uses to pre-populate fields (such as the server name).

Here are some scenarios and which files you need:

  • You can use only the CyberTriageCollector.exe program if it’s a modern Windows system and all options can be specified on the command line (no configuration files required).

  • You can use CyberTriageCollector.exe and the YAML configuration files if you do not need the GUI, but do need some configuration (such as public encryption keys).

  • You can use CyberTriageCollector.exe, YAML configuration files, CyberTriageCollectorGUI.exe, and config.conf if you are sending it to someone who will want to launch the GUI version.

3.2.7. Collector Output Options

Each of the three output locations introduced in Where Can It Send Data To is covered in more detail below.

3.2.7.1. Save To a File

The default behavior is to save the results to a file. You can then copy that file around and import it into Cyber Triage using the “Cyber Triage File” method.

You can choose to encrypt the file, see Configure Collector Output Encryption.

When the Collector has finished, there will be a directory called CyberTriageOutput with a uniquely named JSON file in it.

3.2.7.2. Send Over Port 443 to Cyber Triage

You can also have the Collector make a connection to Cyber Triage and send data directly over the network. The data is encrypted and the server certificate will be validated.

This approach is used for the following methods (which are covered in more detail in the next chapter):

  • Network - PsExec: Cyber Triage will use PsExec to copy the Collector onto the target host, launch it, and data is sent back directly into Cyber Triage.

  • Network - Manual: You will launch Cyber Triage and it will reach out to the configured Cyber Triage server.

  • EDR/WMI/Powershell: You can configure your IT infrastructure to launch the Collector and have it reach out to the server. See Launch via PowerShell, WMI, etc..

This approach requires command line arguments to specify:

  • Server name

  • Server token and certificate hash

3.2.7.3. Send To Cloud Storage

You can also have the Collector upload the results to cloud storage (S3-compatible or Azure). This is much like saving results to a file, except the file is copied up into the cloud when the process completes.

Some special notes:

  • The cloud credentials are saved to a configuration file. You need to configure this when you extract the collector. If you included the cloud credentials in the extraction, the tool will automatically upload to that cloud resource.

  • The Collector will save the artifacts to a file first and then upload. So, you will need space to store the output locally.

  • The Collector will use a unique file name with the host name and collection time stamp in it. It will also break it up into smaller files. You should not get collisions in a single bucket with other collections that are happening at the same time on other hosts.

  • If you configured a profile with reader permissions, you can directly import the file from the “Cyber Triage File” feature.

  • You can either use public key encryption or a password if you want the file to be encrypted in the cloud.

See Cloud Storage for details on configuring your storage.

3.2.8. Command Line Arguments

3.2.8.1. Collector Command Line Arguments

The Collector is a command line program with various optional arguments that allow you (or other applications) to control what it will collect. To see the options, you can choose to supply the —help option.

If you supply no arguments, the Collector will collect from the live running system using default settings:

CyberTriageCollector.exe [-i input_source] [-o output_file] [<other options>]
File Output Options:
  -o: Specify the full path and name of the output JSON file. Default is in CyberTriageOutput folder
  --encrypt_outfile password password : Encrypt the output file with a password (specify the password twice)
  --split_output_file : Split output files into segments of approximately 1.5 GB.

Network Output Options:
  --server host : Stream data back to the given Cyber Triage server hostname/IP instead of to a file
  --cert_hash hash : Hash (full or short) of the server cert. Use 'nohash' to skip verification. Req'd with --server.
  --port port : Port number to connect to the Cyber Triage server. Optional. Default is 443.
  --sessionid sessionID : Session ID to add host to. Required for Live Manual and Live Automatic
  --serverkey serverkey : Key used to authenticate with the Team server. Can be found in the options panel
  --incident name : Specify an incident name to add the host to. Use with --serverkey

Cloud Options:
S3 Options: The first four options below must be set to upload to S3
  --s3_Region region: Region (ex: us-east-2)
  --s3_Bucket bucketName : The name of the bucket to save the results to
  --s3_AccessKeyID accessKeyID : Access key ID
  --s3_AccessKey accessKey : Secret access key
  --s3_SessionToken sessionToken : Required only if using a temporary access key
  --s3_EndpointOverride url : Used to specify the Service URL if using a non-AWS provider
Azure Options: Either the first option alone (azure_SasUrl) or all three of the other options must be set to upload to Azure
  --azure_SasUrl SAS URL : Shared access signature token. Should start with https://
  --azure_ContainerName containerName : Container name
  --azure_StorageAccount storageAccount : Storage account name
  --azure_AccessKey accessKey : Access Key

Collection Options:
  --fast : Skips full file system scan. Faster but less comprehensive triage
  --dtypes : Comma list of data types. Use '--dtypes list' to get list of options
  --mft : Collect $MFT
  --usnjrnl : Collect $UsnJrnl:$J
  --ruleset_file ruleset_file : Path to file with rules of additional files to collect
  --request_rule_sets: Indicates that the server should be contacted to get a file collection rule set
  --skip_file_contents : Report only hashes and not content for files of interest.
  --skip_source_file_contents : Report only hashes and not content for source files (registry hives, prefetch, etc..)
  --set_max_source_file_size_mb size_in_mb: Set the maximum file size (in MB) for collected source files. Only affects files larger than 150MB.
  --tempdir : Path where temp files are written to

Input Options:
  -i: Specify the input. Must be an OS device. Default is \\.\PhysicalDrive0
  --logical_dir : Indicates that the input is the path to a logical directory
  --kape : Indicates that the image/logical dir was created by KAPE
  --uac : Indicates that the logical dir is a UAC output folder
  --analyze_offline : Indicates that the input is not from the system currently running this collector
  --os : Specify operating system for input. Will auto-detect if option is not used. Currently supported: 'win', 'linux'
  --image_password : Specify password for image (Only BitLocker is currently supported)

General Options:
  --ct_config ct_config_file : Specify path to the config file (typically named CollectorConfig.yaml)
  --reference_date date : Specify the date (YYYY-MM-DD) to use for time-based collection decisions. Interpreted as the start of selected day (12:00 AM UTC).
  --reference_timestamp timestamp : Specify the timestamp (Unix epoch) to use for time-based collection decisions
  --hostname_override hostname : Override the hostname used in the output file name and sent to the Cyber Triage server

If you want to specify the list of data types to collect, the list is below. Note that if you just want to skip the full scan, you should use ‘–fast’:

F:\>CyberTriageCollector.exe --dtypes list
Specify the following 2-letter codes separated by commas, to indicate the data types to collect:
    lo - Logons
    ns - Network shares
    wb - Web artifacts
    sc - Triggered tasks
    pr - Processes
    nw - Network
    nc - Network caches
    co - Config settings
    ud - User accessed data
    fs - Full file system scan

The program will return 0 if successful or non-zero if an error occurred or the program was terminated by an EDR.

3.2.8.2. Command Line Examples

Collect from local system and save output to a file in the default location:

F:\>CyberTriageCollector

Collect from local system, send data to server (for Network - Manual):

F:\>CyberTriageCollector --server 192.168.0.1 --sessionid 12345 --cert_hash 4a781abe

Collect from local system, save to encrypted file, and skip the full scan (NOTE: We recommend you use the public key encryption instead):

F:\>CyberTriageCollector --fast --encrypt_outfile passw0rd passw0rd

Collect from local system and copy only processes to a local file:

F:\CyberTriageCollector --dtypes pr

Collect from local system, send data to S3 using arguments (and not a config file):

F:\>CyberTriageCollector --s3_Region us-east-2 --s3_Bucket xyz --s3_AccessKeyID IWLAS383819AWAQ. --s3_AccessKey s8li209sjha33au34y3u4ysuyds7

Collect from local system, send data to Azure using presigned (SAS) URL arguments (and not a config file):

F:\>CyberTriageCollector --azure_SasUrl https://myaccount.blob.core.windows.net/mycontainer/myblob.txt?sv=2021-06-08&st=2025-05-09T14:00:00Z&se=2025-05-10T14:00:00Z&=sr=b&=sp=r&sig=vp229Zp38YroruUvpeHOfkoF5i9iyuZnhe2c8lTYUMA

Collect from local system, send data to Azure using access key arguments (and not a config file):

F:\>CyberTriageCollector --azure_ContainerName Test123 --azure_AccessKey "N7oR3eE1bU0uV1wX2yZ3aB4/wU5eF6g==" --azure_StorageAccount mystorageaccount123

3.2.9. Output Files and Naming Conventions

3.2.9.1. Collector Error Log

The Collector will maintain a log file in the same folder that its writing the artifacts to. The log file will have a “.log” extension and have the same base name as the artifact JSON file. For example, “cttout_host1_20250424_19_37_02.log”.

If the collection is successful, this file will be deleted. If it is not, then it will be retained (and uploaded to S3/Azure). You can refer to this if you are remotely launching the program and need to debug why it is having problems.

3.2.9.2. Output Manifest File

If you save the output to a file or upload it to cloud storage, you will find a manifest file that has the same base name as the output, but it has a ‘.txt’ extension. This contains information about:

  • Arguments you used to launch the program

  • Size and hash values of output files

  • If it ended with an error

3.2.9.3. Output File Names (In Progress, Error, etc.)

To help debug issues and give insight about the progress of background collections, Cyber Triage edits the file names based on stages of the collection.

While the collection is happening, the output files will have IN_PROGRESS in the name.

When the collection is done, that phrase will be removed.

If the collection ends with an error, it will have ERROR in the name.

You can use these names as follows:

  • If the files have neither ERROR or IN_PROGRESS, the files should be ready to use.

  • If the files have ERROR, then look at the logs and see what you need to do in order to get a full collection.

  • If the files have IN_PROGRESS, then check if the Collector is still running. If it is, then wait. If it is not, then this indicates the Collector abruptly terminated from either it being killed by an EDR or a crash. Check your EDR logs first. Otherwise, make sure you get the log file and manifest file and contact support.

3.2.10. Launching Details

The following sections cover how to launch the Collector yourself, outside of the normal Add Host workflow, including the niche case of running it against an already-acquired disk image.

3.2.10.1. Launching The Collector Manually

If you are going to manually interact with a system to launch the Collector, you have three options:

  • If you want to use the default settings and save to a file, you can right click on CyberTriageCollector.exe and choose “Run as Administrator”.

  • Launch the GUI Wrapper (CyberTriageCollectorGUI.exe) by double clicking on it.

  • Open an Administrator command prompt, navigate to the Collector folder, and specify the needed arguments (see Collector Command Line Arguments).

The basic approach would be to:

  • Extract the Collector to a folder (see Extracting the Collector)

  • Copy the folder to the target system

  • Launch with one of the above listed approaches and deciding if the output will go to a file, S3/Azure, or over port 443.

  • If the output was saved to a local file, then copy the folder back to the computer running Cyber Triage.

3.2.10.2. Launch via EDR

We recommend that you use the Cyber Triage Deployer Powershell script (see Configure the Collector Deployer Powershell Script) to run Cyber Triage from an EDR. If that doesn’t work for your EDR, then you simply need to copy the collector and launch it using your EDR capabilities.

3.2.10.3. Launch via PowerShell, WMI, etc.

If you have a Team deployment, you can launch the Collector via IT infrastructure that allows you to remotely run programs.

There are two phases of configuration:

  1. If you will send data back over the network, you’ll need to configure the Cyber Triage server to accept connections that are not initiated by Cyber Triage. Refer to Allow Collector To Initiate Ingests for details. Or, if you want to use cloud storage, then you’ll need to set that up.

  2. Configure the infrastructure to copy and launch the collector.

Details for various systems (such as WMI and Powershell Remote) are given in the subsections, but here are the common elements:

  1. If you plan to upload the data to cloud storage, configure that first (Configure Cloud Storage Profiles).

  2. Extract the Collector as outlined in Extracting the Collector

  3. Identify what command line arguments you want to use based on what you want to collect and where you want data saved to. See Collector Command Line Arguments for the list of arguments.

If you are going to send data directly to a Cyber Triage server, then you’ll ultimately need to specify at least:

  • The hostname of your server

  • The server key (from the “Team Settings” section of the options panel, see Allow Collector To Initiate Ingests)

  • The certificate hash of the server (from the “System” / “Certificates” section of the options panel)

Something like:

CyberTriageCollector.exe --server cybertriage.acme.com --server-key 123456 --cert_hash 3241eabd

If the server is at capacity when the collection starts, it will accept the data, but queue it up for later processing.

If you are uploading the cloud storage, then you’ll need to either supply the needed keys as arguments or just also copy the CollectorConfig.yaml file.

If the collection was successful, CyberTriageCollector will return 0 for its exit code. A non-zero value indicates an error or that it was killed by an EDR or other anti-virus program.

One challenge with most of these methods is that they can be hard to debug when they do not work. If they launch the process, but you don’t get data back, then you can debug by saving the STDERR (Standard Error) messages to a file and then looking at them. You can do this by adding “2>Errors.txt” to the end of the command and then copying the file off. For example:

CyberTriageCollector.exe --server [...] 2> C:\windows\temp\errors.txt”

You can then log into the system and look at this file. This is obviously more useful while testing your environment than during a real incident.

3.2.10.3.1. Collect with WMI

If your environment is configured to run remote software with WMI, you can use that to copy the collector and launch it. This section assumes you read the parent section (Launch via PowerShell, WMI, etc.) on enabling the server to listen for connections.

  1. On your “trusted” system, open a command prompt that runs as an account that has administrator access on the target machine you want to collect from.

  2. You next need to copy the collector to the target machine. One way to do that is to copy by UNC paths if file sharing is enabled on the target system, such as:

    copy CyberTriageCollector.exe “\\192.168.3.10\ADMIN$\Temp”
    
  3. If needed for cloud upload, repeat the above for the CollectorConfig.yaml file.

  4. Run the collector by executing the following WMI command from the command prompt. You’ll need to specify the Cyber Triage server address:

    wmic.exe /node:192.168.3.10 process call create ”c:\windows\temp\CyberTriageCollector.exe --server cybertriage.acme.com --server-key 123456 --cert_hash 3241eabd”
    
  5. If it was successful, wmic will print the process ID. Though, the process could have not collected data if it could not connect to the server or if invalid arguments were given.

WMI-specific Troubleshooting Steps:

3.2.10.3.2. Collect with Powershell (PSRemote)

This section provides an example for deploying the collector using Powershell Remote. It assumes you read the parent section (Launch via PowerShell, WMI, etc.) about the basic steps of getting the collector and what arguments to specify.

3.2.10.3.2.1. Prerequisites
  • An Administrator-level user account on the target system

  • Powershell v5 or higher

  • PS-Remoting enabled on local and target system. It is enabled by default only on Servers. See below for steps.

3.2.10.3.2.2. Collection Steps
  1. Open up PowerShell prompt on your trusted analysis system. Optionally, open it as the same user that has admin rights on the target system.

  2. Copy the Collector to the target system:

    Copy-Item -Path <Path To CyberTriageCollector.exe> -Destination C:\Windows\Temp\CybertriageCollector.exe -ToSession $(New-PSSession <target_hostname> -Cred $(Get-Credential))
    
  • Update ‘Path’ with where you extracted the Collector to.

  • Update ‘<target_hostname>’ with the target host.

  • This will prompt you for the username and password to use on the target system. You can skip the ‘-Cred’ argument if you run this Powershell prompt as the same user that has admin access on the target system.

  • Repeat for the CollectorConfig.yaml file if you are uploading to cloud storage.

  1. Create a remote session:

    Enter-PSSession <target_hostname> -Cred $(Get-Credential)
    
  • ‘<target_hostname>’ is the same as the copy-item command.

  • You can skip ‘-Cred’ if this shell is running as a user with admin rights on the target system.

  1. Start the copied CybertriageCollector within the remote session. If you are sending data back over to a server, the command would look like:

    Start-Process -Filepath "C:\Windows\Temp\CybertriageCollector.exe" -Wait -ArgumentList "--server cybertriage.acme.com --server-key 123456 --cert_hash 3241eabd"
    

Or, if you are saving to a file on the target system, it would look like:

Start-Process -Filepath "C:\Windows\Temp\CybertriageCollector.exe" -Wait -ArgumentList "-o c:\Windows\Temp\Cybertriage"
  • Update ‘-ArgumentList’ with any other arguments that you want to use.

  • The ‘-Wait’ argument will force Powershell to wait until the program has been completed. You can also skip this if data is being sent back and you do not need to wait.

  1. After completion, you can exit the remote session using:

    Exit-PSSession
    
  2. If you sent data back to the server over the network, you are done. If you saved it to a file (i.e. ‘-o’), you’ll need to copy the output back with something like:

    Copy-Item -Path “c:\Windows\Temp\*.json.gz” -Destination <local_path> -FromSession $(New-PSSession <target_hostname> -Cred $(Get-Credential))
    
  • Update ‘-Path’ with where you specified in the Start-Process command.

  • ‘<local_path>’ is a place on your system to copy the data to

  • ‘<target_hostname>’ is the same as the previous two commands.

3.2.10.3.2.3. Enable PS-Remoting

PS-Remoting is enabled by default on Servers, but not other Windows systems. It must be enabled on the source and target systems for the above process to work.

Microsoft has documentation to enable this.

The basic idea is to:

  • Open an Administrator PowerShell command prompt on the system to enable.

  • Type in: ‘Enable-PSRemoting -Force’

If you get an error to the effect of “WinRM firewall exception will not work since one of the network connection types on this machine is set to Public. Change the network connection type to either Domain or Private and try again.”. If so, then use ‘Enable-PSRemoting -SkipNetworkProfileCheck -Force’

3.2.10.4. Using The Collector on Disk Images

There are a few (rare) scenarios where you may have limited access to a disk image and you want to run the Collector on it. The Collector that you get from Extracting the Collector does not support E01, VMDKs, and other disk image formats. You’ll need to configure your own setup for this.

Here are the steps for manually extracting and executing the ‘library’ version of the Collector:

  1. Copy the ‘C:\Program Files\Cyber Triage\cybertriage\collector’ folder to a new location (and you may want to rename it)

  2. Copy the following directories into the new collector folder you copied in the previous step:
    • ‘C:\Program Files\Cyber Triage\cybertriage\evtexport’

    • ‘C:\Program Files\Cyber Triage\cybertriage\evtx_dump’

  3. At this point, you should have a folder with a file named ‘CyberTriageCollector_Libs.exe’ and it has subfolders named ‘evtexport’ and ‘evtx_dump’.

To run this on a disk image:

  • Open a command prompt with admin privileges

  • Type in a variation of: ‘CyberTriageCollector_Libs.exe -i <disk_image> –skip_live_analysis’
    • Where you replace ‘<disk_image>’ with the path of your disk image

    • The ‘–skip_live_analysis’ is important because otherwise processes and network connections from your analysis computer will be saved in the JSON output

  • After the program runs, you’ll have a json.gz file in the ‘CyberTriageOutput’ folder.

  • You can then import this via Collector Output.

3.2.11. Configuration Details

The following settings are introduced in Configuration above; details for each are below.

3.2.11.1. Customize File Collection

You can collect additional files beyond what Cyber Triage already collects. This is useful when you want to make sure you get logs from a certain application or from indicators of a recent attack.

The following terms are used in this process

  • File Rule: A set of criteria that, when matched, will cause the file to be collected.

  • File Rule Set: A set of file rules. The file will be collected when any rule matches. You can organize rules in any way that makes sense for you.

3.2.11.1.1. Adding Custom File Collection Rules

To add a rule, go to the Options panel and choose “Collection” / “File Collection Rules”. Rules need to be in a set, so create a set if none exist or you want to organize the new rule differently than the others.

../../_images/config_file_collection_rules.png

File Collection Rules panel

Create a new set with New Set. You need to give it a unique name and can optionally give it a description.

../../_images/fileset_newset.png

Add New File Set

Once the set is selected, you can add a rule to it with New Rule.

There are different types of rules, which have different performance impacts.

  • Exact Match: If the full path is specified (parent folder and file name), these are fast lookups since the Collector knows where to look.

  • Fuzzy Match: If only part of the parent folder or file name are specified, then the rule will be applied to each file in the system. This requires the full file system scan to occur.

A rule has the following fields:

  • A unique display name

  • File Name: Can be full name, empty, or have wild cards. Details are below.

  • Folder Name: Can be full name, empty, or have wild cards. Details are below.

  • Max File Size: Allows you to ignore files that are too big to collect.

  • Max File Age: Allows you to optionally ignore files that are old and likely not relevant to a recent attack. This field is number of days and is applied to the file’s creation date.

../../_images/fileset_newrule.png

Add New File Rule

The following are more detailed requirements for file name:

  • This field is required if folder name is not specified

  • Comparison is case-insensitive.

  • Can not include any of the symbols that are not allowed in files: ‘:’, ‘>’, ‘<’, ‘:’, ‘”’, ‘/’, ‘', ‘?’

  • Can include one or more ‘*’ wild cards, which will match 0 or more of any character.

  • If no file name is given, all files in any directory matching the folder name will be collected (non-recursive).

The following are more detailed folder requirements:

  • This field is required if file name is not specified

  • Comparison is case-insensitive

  • Forward slash is used to separate folder names.

  • Can not include any of the symbols that are not allowed in files: ‘>’, ‘<’, ‘:’, ‘”’, ‘', ‘?’

  • Can start with %USER_DIR% to match the standard Windows user folders or any non-standard user folders extracted from the registry (if present).

  • If not using %USER_DIR% the path must start with a forward slash

  • Folder names should not end with a slash (unless using a single slash for the root folder)

  • A ‘*’ wildcard that is not surrounded by forward slashes, will match 0 or more characters within a folder name.
    • /windows/system* will match /windows/system32

  • A single ‘*’ wildcard surrounded by forward slashes will match any full folder name, but not recursively:
    • /Windows/*/notepad.exe will match /Windows/System32/notepad.exe

    • /Windows/*/notepad.exe will not match /Windows/System32/foo/notepad.exe

  • A double ‘*’ wildcard surrounded by forward slashes will match any number of folder names:
    • /Windows/**/notepad.exe will match /Windows/System32/notepad.exe and /Windows/System32/foo/notepad.exe

  • If no folder name is given, all files with the specified file name will be collected.

Any wild card character will require the full file system scan. If you specify the full file name and the full folder path, then a targeted collection can be performed without the full file system scan.

Examples:

  • To collect a specific log file (fast collection):
    • File Name: ‘logfile.txt’

    • Folder Name: ‘/ProgramData/ApplicationName/Logs’

  • To collect all files in a specific folder newer than 60 days:
    • File Name: <Not specified>

    • Folder Name: ‘/ProgramData/ApplicationName’

    • Max File Age: 60

  • To collect all executables in AppData:
    • File Name: ‘*.exe’

    • Folder Name: ‘%USER_DIR%/AppData/**’

  • To collect the $MFT:
    • File Name: ‘$MFT’

    • Folder Name: ‘/’

3.2.11.1.2. Using Custom File Collection Rules

After you update or create rules, you may need to take additional steps to ensure the collections use them.

  • Network - PsExec: The Collector will download the latest version of the rules when the collection starts.

  • Network - Manual, Cyber Triage File: The rules are copied to the extracted folder. You’ll need to extract the Collector again to get the latest version of the rules.

  • KAPE, Disk Image, Logical Files: Local copies of the latest rules are used.

3.2.11.2. Configure Cloud Storage Profiles

Cyber Triage can use cloud storage in two ways:

  • The Collector can automatically upload to these locations

  • The main application can directly download from these locations

Cyber Triage supports:

  • S3-compatible providers, including AWS, BackBlaze, and others.

  • Microsoft Azure

You should configure the cloud storage profiles before you extract the Collector so that it will have the proper configuration data.

3.2.11.2.1. Basic Cloud Storage Approach

Every organization uses cloud storage differently and has different requirements for how to manage cloud resources. With that in mind:

  • Cyber Triage will not create buckets, but we do provide guidance for how to do so. It is ultimately up to you to ensure they are secure and meet your organization’s requirements. You can encrypt the Collector output using public key encryption or a password.

  • Cyber Triage assumes there is a single bucket that all Collectors will upload to.

  • Cyber Triage is designed for credentials with minimal permissions. It uses two roles:
    • Collector Upload: This identity should be able to write to the bucket, but not read. If the threat actor compromises these credentials, they should not be able to read what else is in the bucket.

    • Bucket Manager: This identity can read the bucket. It will be used by the application to read data that was uploaded.

Refer to Cloud Storage for guidelines on configuring your service and these account types.

3.2.11.2.2. Cloud Storage Profiles

A Cloud Storage Profile defines a bucket with a set of credentials to access it. Namely:

  • The location and name of the bucket

  • “Upload” Credentials

  • “Manager” Credentials, which are optional

3.2.11.2.3. Adding a Cloud Storage Profile

To add a profile, go to the Options panel and choose “Collection” / “Cloud Storage”. You should make a profile for each set of credentials, buckets, and regions.

../../_images/config_cloud_storage_list.png

Cloud Storage profile list

  • Choose “New Profile” and get the following dialog:

../../_images/cloud_new_profile_s3.png
  • Pick if it is S3-compatible or Azure

For S3 buckets, configure:

  • Provider: Amazon AWS or another S3-compatible

  • Region: If using AWS, you’ll need to pick the region your bucket is in.

  • Service URL: If using a non-AWS provider, you’ll need to specify the Service URL. It should have the region in the URL.
    • For example: S3.us-east-2.wasabisys.com

  • Bucket: The name of the bucket to save the results to. You will need to manually create this bucket. It should not be public.

  • Collector Upload: This identity is used to write data. It should NOT be able to read.
    • Access Key ID and Key: You will need to get an access key from the provider. These will be saved unencrypted in the configuration file.

    • Session Token: Optional. Required only if you are using a temporary access key. You can generate this via the AWS Command Line Tool:

  • Bucket Manager: This identity is used to read data and browse the bucket. It is optional. Choose “Do not use” if you are interested in only having Cyber Triage upload to the bucket.

  • Press the “Test Connection” button so that Cyber Triage can verify the data and check the scope of the identities.

For Azure buckets, you’ll see this dialog:

../../_images/cloud_new_profile_azure.png

Configure:

  • Container Name: You are responsible for making this. It should not be public.

  • Collector Upload Credentials: Used by the Collector to upload collections. Should only have write permissions. Choose either a SAS URL (recommended, due to the limited security controls available with an Access Key) or an Access Key with a Storage Account Name and Storage Account Access Key.

  • Bucket Manager Credentials: This account should be able to read and browse the container. It is optional.

  • Press the “Test Connection” button so that Cyber Triage can verify the data and check the scope of the accounts.

3.2.11.3. Configure Collector Output Encryption

Cyber Triage can use public key encryption to protect the output of the Collector.

Note that there are two ways to protect the output of the Collector:

  • Configure a public key so that the Collector can encrypt, but not decrypt the data. Only people with access to the private key (which stays with the Cyber Triage application) can decrypt it. This is the safest.

  • Supply a password at the time of collection. Anyone with this password can decrypt it and any typos when entering the password could result in the data being unrecoverable.

This section outlines the public key approach.

The basic process is:

  • Create a key pair within the Cyber Triage application

  • When you export the Collector from the main application, the ‘CollectorConfig.yaml’ file will include the public key

  • When the Collector runs, it will use the public key to encrypt its output file (as long as the ‘CollectorConfig.yaml’ file exists)

  • When you import that file using “Cyber Triage File”, Cyber Triage will use its private key to decrypt it

To generate the key pair, go to the Options panel and choose “Collection” / “Collector Encryption”.

../../_images/config_collector_encrypt_panel.png

Select “Create Key Pair”. You’ll be shown a Private Key Warning that you must acknowledge - Cyber Triage cannot recover lost keys or decrypt your data if they are lost, so keep a safe backup copy. After you press OK, a file save dialog opens for you to choose where to save the backup copy. You can later import that backup into another Cyber Triage instance if you need to.

You can also explicitly export and import the keys (both private and public). A Cyber Triage instance can have multiple private keys to import data from multiple sources.

When you export the Collector, you will have the choice to include the public key in the configuration file.

Note

  • CollectorConfig.yaml must be in the same folder as the Collector when it runs for the key to be used.

The resulting file format is Cyber Triage-specific. It has a header with Cyber Triage information, the encrypted symmetric key, and then the encrypted Collector output. See Encryption for details on the encryption algorithms.