4. Collecting Host Data¶

Cyber Triage supports a variety of ways of getting host data into it. Nearly all of the methods have two basic steps:

Collect host-based data, either using the Cyber Triage Collector or a 3rd party tool
Ingest the collected data into Cyber Triage

Within Cyber Triage, the collect and ingest steps are often distinct. There is one exception, which is when Cyber Triage deploys the Collector out via PsExec.

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.

The next chapter will focus on importing the collected data into Cyber Triage.

4.1. Supported Collection Methods¶

Cyber Triage will import data from a variety of collection methods. This includes:

Output from the Cyber Triage Collector. This is JSON data that can be saved to a file or transmitted over the network.
Output from file collection tools that copied the registry hive, event logs, and other files. An example of this is KAPE or Velociraptor.
Output from a disk imaging tool that bit for bit copy of a storage device.
Copy of a virtual disk.

4.2. The Cyber Triage Collector¶

The Cyber Triage Collector is a separate program that will extract the key files and artifacts from a live system or data set. It is used on all imported data sets.

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 or Azure).
Uses The Sleuth Kit to by 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.

In many situations, Cyber Triage will run the Collector automatically. In others, you will need to manually launch it or configure IT infrastructure to do so.

4.3. Data Collection Types¶

When adding data into Cyber Triage, you will at some point be prompted for what kinds of data to extract and import. For example:

The Cyber Triage application may show you a dialog such as this:

../../_images/import_data_types_wizard.png

You can specify types as command line arguments to the Collector
You can pick types from the GUI wrapper that can run on the target host

../../_images/import_collector_gui_manual.png

All of them group the types based on the concepts in the Divide and Conquer DFIR Process:

Users

Accounts: Collects information about all users on the system and who is actively logged in.
Logins: Collects user login information from event logs and the registry.
Network Shares: Collects information about mounted network shares.
Programs Run: Collects information about what programs were executed by users and collects the corresponding executable file.
Web Artifacts: Collects Firefox, Chrome, IE and Edge databases and analyzes them for downloads, cookies, and history. Also collects downloaded files from the Download and Temp folders.
Data Accessed: Collects information about what files a user opened or created.

Process

Triggered Tasks: Collects Autoruns, Schedule Task information, WMI, BitsJobs and the associated executable files.
Processes: Collects information about running processes. Includes executable files being used by processes.
Network: Collects information about active network connections and open ports
Network Caches: Collects DNS cache, ARP cache, and routing tables.

System Configuration

System Configuration: Collects information about the system, such as audit and security settings.

Full File System Scan: Scans each file on the system and collects the file content if they are suspicious. This is the most time intensive step of the collection process.

Collect hash instead of file content: This will calculate the hash values for EXE and DLL files and save those instead of the full file content. This makes the collection smaller, but also means that the file can not be uploaded for full malware analysis.

The Collector will also make copies of various application-specific logs and configuration files, if they exist.

The default is Full Scan, which includes all of the types listed above. You can also skip the most time intensive process and choose Skip File Scan.

If time is very limited and you what you are looking for, you can choose Custom and select only certain types.

4.4. Using The Collector on a Live System¶

The remainder of this chapter is about how to directly use the Cyber Triage Collector. If your primary use case is to import disk images, outputs of other tools, or use the builtin “Live - PsExec” method, then you can skip ahead to :ref:ADD_HOST_SECTION.

The remainder of this chapter is on how to directly use and configure the Cyber Triage Collector.

4.4.1. Custom File Collection Rules¶

The Cyber Triage Collector has a set of files that it always collects, but you can customize it to also copy files that are unique to your environment. This needs to happen within the Cyber Triage application before you extract the Collector so that the collection rules are also extracted.

Refer to Customize File Collection.

4.4.2. Extracting the Collector¶

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

You are going to configure an EDR to copy the Collector and launch it
You are going to put the Collector on a network share and launch it
You are going to send the Collector to a client for them to launch

To extract the Collector:

Choose the Extract Collector feature from the upper right of the opening Cyber Triage windows.
Choose a folder to copy the files to (a subfolder will be created inside of it).
Optionally configure S3 or Azure information

../../_images/import_collector_extract.png — *Extract Collector*¶

This process will make a CyberTriageCollector folder with the command line and graphic interface programs inside of it.

4.4.2.1. Configuring S3 Bucket Uploads¶

If the Collector is going to automatically upload data to an S3 bucket (on AWS or some other provider), then you will need to configure those settings before you extract it.

The settings will be saved to a configuration file. The intended use case is that the Cyber Triage^® user will configure the S3 details and pass off the extracted folder to an end user.

You will need to pick:

Provider: Amazon AWS or another S3-equivalent
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. The bucket will be created if it does not already exist. There are limits on bucket names, so please be mindful of them. For example, no spaces or capital letters.
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:

../../_images/import_collector_s3.jpg — *S3 Configuration*¶

After these settings are entered, you need to press Test Connection to verify they are correct.

Note

Testing with proxies does not work. So, the test may fail if your network has a proxy.

4.4.2.2. S3 Access Control¶

The extracted Collector will have S3 credentials in a configuration file. We recommend:

You create access keys that have only write (not read) permissions for objects in the target bucket.
The collector will create a bucket if it does not already exist
Consider using temporary credentials (see above) that last for only the duration of the incident.

With this design, if the S3 credentials are compromised, the data already uploaded cannot be accessed.

The minimum set of actions needed by the Collector are:

s3:PutObject
s3:CreateBucket

Note that as of 3.9, the main application will also use the following actions to test that the passed in credentials have permissions. If the credentials you use do not have them, then the test will fail, but the collector will ultimately be able to upload. This will be fixed in a future version.

The application also uses:

s3:ListBuckets
s3:ListAllMyBuckets

4.4.2.3. Configure Azure Blob Upload¶

You can also configure the collector to upload to Azure blob storage. To do so:

Select “Azure Blob” as the upload option
Enter the “Account Name” that you configured along with its access key
Choose an optional container name. If you do not specify one, generic one will be created for you.

../../_images/import_collector_azure.png

These settings will be saved to a configuration file in the collector folder.

4.4.3. Getting the Collector to the Host¶

You can use any means necessary to get the Collector to the target system.

At a minimum, you need to copy over CyberTriageCollector.exe. If you are uploading to cloud storage or using custom file rules, you will also need to copy over configuration files.

There is also a CyberTriageCollectorGUI.exe program that is a wrapper around the command line tool. You can copy this as well if you intend to use it instead of specifying command line arguments.

See Deploy via EDR, PowerShell, WMI, etc. for steps on using IT infrastructure.

4.4.4. Manual Launch Options¶

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

Launch the GUI Wrapper (CyberTriageCollectorGUI.exe) by double clicking on it.
Launch CyberTriageCollector.exe with default options by right clicking on it and choosing “Run as Administrator”. This will collect all data and save the results to a file.
Open an Administrator command prompt, navigate to the Collector folder, and specify the needed arguments (see Collector Command Line Arguments).

4.4.5. Collector Output Options¶

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

A local file (this is the default behavior)
The Cyber Triage application
A cloud storage provider (S3 or Azure)

Each of these will now be covered in more detail.

4.4.5.1. Saving Artifacts 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.

There are run-time options to specify:

A password for the file
If hashes instead of file content should be stored to save space
Where to save the file to

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

4.4.5.2. Sending Artifacts 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 Deploy via EDR, PowerShell, WMI, etc..

This approach requires command line arguments to specify:

Server name
Server token and certificate hash

4.4.5.3. Sending Artifacts to Cloud Storage¶

You can also have the Collector upload the results to S3 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.
The Collector will save the artifacts to a file first and then upload. So, you will need space to store the output locally.
You will need to manually download the file from the cloud storage afterwards and then import it using the “Cyber Triage File” method.
You can specify a password if you want the file to be encrypted in the cloud.

4.4.6. 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 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)

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 Network - Manual and Network - PsExec.
   --serverkey serverkey : Key used to authenticate with the Team server. Can be found on the server options panel
   --incident name: Specify an incident name to add the host to. Use with --serverkey
   --cloud_upload_config cloud_config_file : Upload output file to cloud storage, S3 or Azure, using supplied configuration

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
  --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..)
  --tempdir : Path where temp files are written to

Input Options:
  -i: Specify the input. Can be a disk image, OS device, or logical folder. 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

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.

4.4.7. 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:

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

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

F:\CyberTriageCollector --dtypes pr

4.5. Deploy via EDR, PowerShell, WMI, etc.¶

If you have a Team deployment, you can launch the Collector via an EDR or other IT infrastructure that allows you to remotely run programs. Organizations do this if they can’t use PsExec.

There are two phases of configuration:

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.
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:

Extract the Collector as outlined in Extracting the Collector
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.

Most users will send data to a waiting server and therefore you’ll ultimately need to specify at least:

The hostname of your server
The server key (from the Deployment Mode on options panel)
The certificate hash of the server (from Certificate Info on 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 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.

4.5.1. Collect with EDR¶

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

4.5.2. 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 (Deploy via EDR, PowerShell, WMI, etc.) on enabling the server to listen for connections.

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.
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”
```

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”

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:

Ensure winmgmt (WMI), DCOM, RPC, and RPC Endpoint Mapper services are running. These services are normally enabled by default.
Ensure WMI is allowed through firewall (https://learn.microsoft.com/en-us/windows/win32/wmisdk/connecting-to-wmi-remotely-starting-with-vista)
Ensure that you are using domain users. If you are using a local user you’ll need to disable token filtering on the remote endpoint (https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/user-account-control-and-remote-restriction)

4.5.3. Collect with Powershell (PSRemote)¶

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

4.5.3.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.

4.5.3.2. Collection Steps¶

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

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.

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.

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.

After completion, you can exit the remote session using:
```
Exit-PSSession
```
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.

4.5.3.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’