Evidence Acquisition Data Flow in AIR

This article explains the end-to-end evidence acquisition data flow in AIR, covering how evidence moves from asset collection through to the Investigation Hub. Understanding this flow helps administrators plan network configurations, storage capacity, and firewall rules for their self-hosted deployments.

Architecture Overview

The evidence acquisition data flow involves four main components:

Component	Role
AIR Console	Central management server that creates tasks, coordinates Responders, and hosts the Investigation Hub
Responder	Lightweight agent installed on assets that executes acquisition tasks and collects evidence
Evidence Repository	Remote storage destination (SMB, SFTP, FTPS, AWS S3, Azure Blob, or GCS) for collected evidence
DRONE	Automated analysis engine that processes collected evidence and generates findings

Data Flow Stages

1. Task Creation

An investigator creates an acquisition task through the AIR Console. The task definition includes:

• Target assets — one or more assets with an installed Responder
• Acquisition profile — defines which evidence types to collect (e.g., Quick, Full, Compromise Assessment, or a custom profile)
• Policy — determines where evidence is stored (local or Evidence Repository), resource limits (CPU, bandwidth, disk), and compression/encryption settings
• DRONE analysis — whether to enable automated analysis during or after collection

2. Task Distribution

The Console distributes the task to each target asset’s Responder:

• Primary channel (TCP 443): Responders maintain a persistent connection to the Console on port 443 (or 8443 if configured) and poll for new task assignments.
• Real-time push (TCP 4222): For immediate task delivery, the Console pushes task notifications to Responders via NATS on port 4222. This ensures assets receive tasks without waiting for the next polling interval.
• Relay Server: In segmented network environments, a Relay Server acts as an intermediary between Responders and the Console, forwarding task assignments and evidence metadata across network boundaries.

Tip

If an asset is offline when a task is assigned, the Responder automatically receives and executes the task upon its next connection to the Console.

3. Evidence Collection

Once the Responder receives the task, it executes the acquisition on the asset:

1. The Responder parses the task details and acquisition profile to determine which evidence types to collect.
2. Evidence is collected from the asset’s file system, memory, network state, event logs, applications, and other sources as defined by the profile.
3. Collected data is organized into a directory structure under the Cases folder on the asset.
4. SHA-256 hashes are generated for all collected files to maintain chain of custody integrity.
5. Evidence is packaged into a compressed archive (.zip) containing a .ppc (Protected Package Container) file.
6. If encryption is enabled in the policy, the archive is encrypted with AES-256.
7. An RFC 3161 timestamp certificate is obtained from a Trusted Timestamp Authority (TSA) to cryptographically prove the exact time of collection.

4. Evidence Transfer

After collection, evidence is transferred according to the storage destination configured in the policy:

Option A — Local Storage

Evidence remains on the asset in the Cases folder. The default paths are:

Platform	Default Path
Windows	C:\Binalyze\AIR\Cases
Linux	/opt/binalyze/air/Cases
macOS	/opt/binalyze/air/Cases

Investigators can retrieve evidence using interACT or any remote management tool.

Option B — Evidence Repository

Evidence is uploaded directly from the asset to the Evidence Repository. The upload does not route through the AIR Console. The supported repository types are:

Repository Type	Default Port
SMB	445
SFTP	22
FTPS	21
AWS S3	443 (HTTPS)
Azure Blob Storage	443 (HTTPS)
Google Cloud Storage	443 (HTTPS)

After a successful upload, evidence is removed from the asset’s local storage.

Caution

Firewall rules must allow direct traffic from each asset to the Evidence Repository on the relevant port. The Console also needs access to the Evidence Repository for features such as File Explorer and Repository Explorer.

Option C — Direct Collection

When Direct Collection is enabled in the policy, the Responder streams evidence directly to the Evidence Repository during collection, minimizing local disk usage. Approximately 100 MB of temporary data is stored in the Cases folder during the upload process and is automatically deleted upon completion.

5. DRONE Analysis

If DRONE is enabled for the task, automated analysis runs against the collected evidence:

• Responder-side analysis: DRONE analyzers execute on the asset during or immediately after evidence collection. This includes live-asset analyzers such as the MITRE ATT&CK Analyzer, which scans running processes and filesystem locations.
• Server-side analysis: DRONE processors run on the AIR Console against the stored evidence (PPC files). This mode does not require a live connection to the asset and can be triggered at any time after collection, including for imported off-network evidence.

DRONE classifies each finding with a severity level — High, Medium, Low, or Matched — based on its analysis pipelines, YARA rules, Sigma rules, and keyword logic.

6. Investigation Hub

All collected evidence and DRONE findings are presented in the Investigation Hub, which serves as the unified workspace for investigation:

• Parsed evidence is displayed in a structured, human-readable format.
• DRONE findings are prioritized by severity to accelerate triage.
• Hash values for all collected files are available for export.
• RFC 3161 timestamp certificates can be downloaded to verify chain of custody.
• Evidence can be browsed using File Explorer (for assets with local storage) or Repository Explorer (for Evidence Repositories).

Network Flow Summary

The following table summarizes the key network communication paths involved in the acquisition data flow:

Source	Destination	Port	Purpose
Responder	Console	TCP 443	Task polling, status reporting, metadata
Console	Responder	TCP 4222	Real-time task push (NATS)
Responder	Evidence Repository	Varies by type	Direct evidence upload
Console	Evidence Repository	Varies by type	File Explorer / Repository Explorer access
User	Console	TCP 443 / 8443	Web UI access, task creation, Investigation Hub
Console	TSA Server	TCP 443	RFC 3161 timestamp requests

Note

For complete port configuration details, see Understanding Port Usage.

Key Considerations for Self-Hosted Deployments

• Storage planning: Estimate storage capacity based on the number of assets, acquisition frequency, and the evidence types collected. Full acquisition profiles generate significantly more data than Quick profiles.
• Network bandwidth: Evidence uploads from assets to Evidence Repositories can be bandwidth-intensive, especially during large-scale acquisitions. Use the bandwidth limit setting in Policies to control upload rates.
• Firewall rules: Ensure that assets can reach both the Console (TCP 443 and 4222) and the Evidence Repository (on the relevant protocol port). The Console must also access the Evidence Repository for File Explorer functionality.
• DRONE resource usage: Server-side DRONE analysis runs on the Console and may increase CPU and memory usage during processing. Plan Console hardware capacity accordingly.