Evidence Repositories
Where to save your collected data
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).
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)
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:
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:
Bucket Name
Target GCS bucket
evidence-storage-prod
Project ID
GCP project ID
my-project-123
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
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.comorsudo timedatectl set-ntp trueWindows:
w32tm /resync /forcemacOS: Enable "Set time and date automatically" in System Preferences
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+)

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.
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.
Last updated
Was this helpful?

