Evidence Repositories

By default, AIR supports saving collected evidence locally on the asset with paths set as Binalyze\AIR for Windows, /opt/binalyze/air for Linux, and /opt/binalyze/air for macOS. Alternatively, users can opt to send their collections to Evidence Repositories, such as network shares, SMB, FTPS, SFTP, or to cloud storage, including AWS S3 buckets, Azure Blob Storage, and Google Cloud Storage (GCS).

Note

Defining exact system resource requirements for the Evidence Repository is challenging due to variations in environments, asset counts, and the types of acquisition tasks performed. Disk space, CPU, and memory requirements can vary significantly, influenced by factors such as the size of disk images, log files generated during acquisitions, and the volume of evidence collected from each asset. As a result, it’s impractical to offer a one-size-fits-all recommendation for resource allocation.

The term Evidence Repository describes a remote location, separate from the actual asset subject to the tasking assignment, whether it is one of the six currently supported storage options.

You can create Evidence Repositories in three different ways:

• From the “Evidence Repositories” page
• During Policy creation
• During the Acquisition task creation

A common query from our customers concerns the configuration of the Evidence Repository and its interaction with the AIR Console, particularly regarding evidence uploads and the required network permissions. Here’s what you need to know:

Evidence Upload Process

When configuring the Evidence Repository, it’s essential to understand the pathway through which evidence files are uploaded. Specifically, there might be confusion about whether these uploads occur directly from the assets to the Evidence Repository or if they go through the AIR console.

To clarify: Evidence files are uploaded directly from the assets to the Evidence Repository. This process necessitates configuring your firewall to permit traffic from the asset to the Evidence Repository on the relevant ports. For example, if using SMB for evidence transfer, you must allow access through port 445.

AIR Console Access

For the File Explorer feature within the AIR console to function correctly, the AIR console requires access to the Evidence Repository. This setup ensures that users can seamlessly browse and interact with the stored evidence directly through the AIR console interface.

Configuring Your Firewall

Given these operational details, it’s necessary to adjust your firewall settings accordingly:

• Allow traffic from your assets to the Evidence Repository, particularly if you are using specific protocols, such as SMB on port 445.
• Ensure the AIR Console has access to the Evidence Repository to enable full functionality of the File Explorer feature.

Creating an evidence repository from “Evidence Repositories”

1. Navigate to the Evidence Repositories section by clicking the Settings button in the Main Menu and then select “Evidence Repositories” from the Secondary Menu.

2. Click the “+Add New” button at the top of the page.

3. From the New Evidence Repository window, provide a name to the repository and then select the relevant repository.

4. Depending on the type of evidence repository you choose, the required fields are adjusted accordingly:

SMB

• Path: The location that is polled for evidence. If the IP address of the repository is “172.16.1.1”, and the folder name is “Share”, the path will be “\\172.16. 1.1\Share” without quotes.
• Username (if required)
• Password (if required)

SFTP

• Host: Hostname or IP address of the SFTP server.
• Port: The port on which the SFTP server is listening to. The default port for SFTP is 22.
• Path: The location directory that is polled for evidence.
• Username (if required)
• Password (if required)

FTPS

• Host: Hostname or IP address of the FTPS server.
• Port: The port on which the FTPS server is listening. The default port for FTPS is 21.
• Path: The location directory that is polled for evidence.
• Username (if required)
• Password (if required)

Note

NB: Implicit SSL/TLS is not supported

Amazon S3

• Region: Region name for the bucket that was created in.
• Bucket: Name of the bucket
• Access Key ID
• Secret Access Key

Note: IAM users must have proper rights and permissions to access the S3 bucket.

Azure Blob

• Shared Access Signature (SAS) URL &#xNAN; See https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview for details.
• To generate a SAS URL, please refer to this link: Generating a SAS URL

Google Cloud Storage (GCS) (AIR 5.11+)

Prerequisites:

Requirement	Description
GCP Account	Active Google Cloud Platform project
GCS Bucket	Bucket for evidence storage
Service Account	Service account with JSON key credentials
IAM Role	Storage Object Creator: Sufficient for Evidence Repository when used for acquisition, interACT get, and image tasks (upload only). Storage Object Admin (Recommended): Required for both Evidence Repository and Repository Explorer operations.

Configuration Fields:

Field	Description	Example
Bucket Name	Target GCS bucket	evidence-storage-prod
Project ID	GCP project ID	my-project-123
Service Account Email	Service account email	[email protected]
Private Key	RSA private key (PEM format)	Must include BEGIN/END markers

The Console validates the configuration by testing the GCS connection before saving.

Supported Tasks:

AIR Responders can perform the following actions with GCS:

• Acquisition tasks (including direct collection)
• Acquire image tasks
• interACT get command
• interACT image command

Caution

Troubleshooting: Invalid JWT Token – System Clock Out of Sync

If you receive the error oauth2: cannot fetch token: 400 Bad Request with message about “Invalid JWT”, the system clock on the asset is not synchronized with Google’s servers.

Solution:

• Linux: sudo ntpdate -u time.google.com or sudo timedatectl set-ntp true
• Windows: w32tm /resync /force
• macOS: Enable “Set time and date automatically” in System Preferences

Note

Permission Denied (403 Forbidden)

If you receive a 403 error, verify the service account has the appropriate IAM role:

• Storage Object Creator for upload operations
• Storage Object Admin for Repository Explorer access

Also check that bucket-level IAM policies include the service account.

Creating an evidence repository during Policy creation

1. Select the Settings button in the Main Menu and then select “Policies” from the Secondary Menu.

Click the “+Add New” button at the top of the page

2. Provide a name to the repository and then select the relevant repository type:

3. Select the relevant repository type by clicking on it.

4. Click the “Save” button.

5. The newly created repository will appear in the drop-down list. Select the relevant repository and finalize the process.

Creating an evidence repository during the acquisition task creation

1. From the “Acquire Evidence” pane, click on the Evidence Repository radio button under the “Save Collected Evidence To” section.

2. Click in the “Repository” box and then select “+ Add new repository”:

3. From the window ‘New Repository’, complete the mandatory fields and select the type of repository you wish to add. There are six options:

• SMB
• SFTP
• FTPS
• Amazon S3
• Azure Blob
• Google Cloud Storage (GCS) (AIR 5.11+)

Evidence Repositories: New Repository Wizard

4. The newly created repository will appear in the drop-down list. Select the repository you want for this particular acquisition and finalize your Acquisition Task via the wizard.

Note

To improve task reliability and prevent failed uploads, a connection check for evidence repositories will take place when starting acquisition tasks (both scheduled and immediate). Here’s how it works:

• When creating tasks like Acquisition or Acquire Image, AIR automatically checks the connection to the selected repository (SFTP, FTPS, Azure, or AWS).
• If the connection check takes longer than 10 seconds, it will be canceled, and a warning message will appear. However, task creation is not blocked—you can choose to proceed or cancel the task if the repository is inaccessible.

UI Warning Message: If the repository is inaccessible, you’ll see this warning: &#xNAN; “The following evidence repositories are currently inaccessible. If responders cannot access these repositories, they will not be able to send the collected evidence. Please note that access to these repositories is managed through the AIR server. If the responders have access, evidence transmission will proceed without issues. Do you still want to continue?”

This feature ensures you’re aware of potential access issues before initiating a task, helping you avoid wasted time on failed uploads. It’s important to note that this connection check occurs between the AIR console and the repository, not between the responders and the repository. While it’s impractical to check every responder in large-scale tasks, a successful console check significantly reduces the likelihood of connection issues for responders.