Welcome to AIR's Documentation

This Knowledge Base will guide you through all the features of AIR.

AIR is an Automated Investigation and Response platform that delivers deep forensic visibility and end-to-end investigation capabilities at speed.

AIR combines the rapid remote acquisition of 737 evidence types with intelligent, efficiency-driven automation to drastically reduce investigation time, simplify workflows, and empower SOC and incident responders with accurate, collaborative insights, thereby boosting long-term cyber resilience.

AIR further accelerates investigations through DRONE—a powerful suite of integrated analyzers that automatically assess collected evidence. DRONE's findings across multiple assets are consolidated and visualized in a single pane of glass: the AIR Investigation Hub.

AIR will perform simultaneous hunt and triage on thousands of assets using YARA, Sigma, and osquery rules.

AIR protects employee privacy with targeted collections when required. It also captures the 'forensic state' of multiple assets and presents this information in an Investigation Hub.

The Investigation Hub serves as an all-encompassing, user-friendly DFIR intelligence resource. This unifying Investigation Hub consolidates Acquisition and Hunt/Triage data from all assets, presenting it in an easily digestible format. It also integrates DRONE analyzer findings through intuitive graphical visualizations, thereby identifying the most critical machines that warrant further immediate, focused investigation or remediation. The Investigation Hub streamlines the investigative process by:

• Providing actionable findings to prioritize and guide investigators,

• Offering comprehensive listings of all evidential artifacts,

• Including a range of advanced filtering options, and

• Featuring a powerful global search capability.

The AIR platform integrates with your existing SIEM, SOAR solutions, and many EDR products. This is done via Webhooks and an open API that empowers analysts to automate the response phase of IR.

So, all forensic collections can be scheduled, automated, remote, and scalable.

With evidence hashing, AES256 encryption, and RFC3161 time-stamping, the Chain of Custody for evidence handling by AIR is completely secure.

Other key features include our patent-pending Baseline Comparison technology. This allows you to be more proactive and focused in the way you target your efforts. Here, you can compare acquisitions against one another and easily identify additions, changes, and deletions to key system areas often exploited by attackers.

AIR helps you cut through the noise of security data with live YARA, Sigma, and osquery scanning combined with rapid keyword searching, automated post-acquisition analysis, and Event Scoring.

These features all combine to enable most digital forensics investigations to be concluded in less than 4 hours - which is a dramatic improvement over what is commonly achieved today with other solutions.

You can view our support terms and conditions here.

Killswitch: Cancel All Running Tasks

The Killswitch is a powerful administrative control available under Settings > Danger Zone in the AIR Console. It allows Global Admins to immediately cancel all currently running cancellable tasks across the entire platform, without needing to select individual assets or tasks.

Safety Confirmation

To safeguard against accidental activation, a case-sensitive confirmation is required. You must, before the operation can proceed. Type the exact phrase:Cancel All Tasks

Note: This action cannot be reversed.

Only tasks that are in a cancellable state will be affected.

Use this feature carefully, particularly during large-scale investigations or scheduled operations.

Chrome 90+

In AIR, the Global Admin has full control over managing 109 specific privileges, allowing the creation of highly customized user roles. This granular access control ensures that each user or group has permissions tailored to their specific needs, such as handling evidence acquisition, interACT sessions, or audit log management.

A useful feature within this setup is the tooltips provided alongside each privilege. These tooltips highlight any dependencies that may exist between privileges, helping administrators configure roles accurately without unintentionally restricting necessary functions.

For example, an admin could create a role that enables a user to access interACT for remote evidence collection while restricting access to audit logs or system-wide settings. The tooltips ensure that admins are aware of any required privileges to avoid misconfigurations.

This approach provides both flexibility and clarity, empowering admins to manage user roles effectively.

Relay Server serves these metrics produced by Prometheus from a Unix socket.

To retrieve metrics from the Relay Server's Unix socket, you can use the curl command to make a request to the following endpoint: http://localhost/metrics on the Unix socket /var/run/Binalyze.AIR.Relay.sock. Here's an example command:

sudo curl --unix-socket /var/run/Binalyze.AIR.Relay.sock http://localhost/metrics

Executing this command will provide you with a response containing various metrics related to the Relay Server. The response will include information such as the number of active connections, request duration, request errors, reload count, and more.

Please note that you need to run this command on the same system where the Relay Server is running, as it communicates via the Unix socket.

Here's a sample response:

# HELP air_relay_info Information about the Relay Server environment.
# TYPE air_relay_info gauge
air_relay_info{arch="aarch64", build_time="2023-06-14T07:22:01", commit="f064c83645e1901d421714b8bd1dbec274425551", goarch="arm64", goos="linux", hostname="halilonay.ubuntu", os="Ubuntu 22.04.2 LTS (Jammy Jellyfish)", version="2.23.0"} 1
# HELP air_relay_proxy_active_connections Number of active connections to the Relay Server.
# TYPE air_relay_proxy_active_connections gauge
air_relay_proxy_active_connections 0
# HELP air_relay_proxy_request_duration_seconds Duration of each request handled by the Relay Server.
# TYPE air_relay_proxy_request_duration_seconds histogram
air_relay_proxy_request_duration_seconds_bucket{le="0.005"} 0
air_relay_proxy_request_duration_seconds_bucket{le="0.01"} 0
air_relay_proxy_request_duration_seconds_bucket{le="0.025"} 0
air_relay_proxy_request_duration_seconds_bucket{le="0.05"} 0
air_relay_proxy_request_duration_seconds_bucket{le="0.1"} 0
air_relay_proxy_request_duration_seconds_bucket{le="0.25"} 1
air_relay_proxy_request_duration_seconds_bucket{le="0.5"} 1
air_relay_proxy_request_duration_seconds_bucket{le="1"} 1
air_relay_proxy_request_duration_seconds_bucket{le="2.5"} 1
air_relay_proxy_request_duration_seconds_bucket{le="5"} 1
air_relay_proxy_request_duration_seconds_bucket{le="10"} 1
air_relay_proxy_request_duration_seconds_bucket{le="+Inf"} 1
air_relay_proxy_request_duration_seconds_sum 0.149310392
air_relay_proxy_request_duration_seconds_count 1
# HELP air_relay_proxy_request_errors_total Total number of request errors encountered by the Relay Server.
# TYPE air_relay_proxy_request_errors_total counter
air_relay_proxy_request_errors_total 1
# HELP air_relay_proxy_requests_total Total number of requests received by the Relay Server.
# TYPE air_relay_proxy_requests_total counter
air_relay_proxy_requests_total 1
# HELP air_relay_reload_count Number of times the Relay Server has been reloaded.
# TYPE air_relay_reload_count counter
air_relay_reload_count 0
# ...

These metrics provide insights into the Relay Server's performance, resource utilization, and various other statistics related to its operations.

Introduction

In today's dynamic digital environment, managing tasks efficiently within a software system is crucial for reliability, flexibility, and optimal performance. This guide explores a sophisticated task management system designed to handle a wide range of operational scenarios, focusing on task retrieval, execution, prioritization, and system resilience against failures and network disruptions.

Task Retrieval and Execution

The Role of the AIR Console

The AIR platform features an intuitive web-based console designed to orchestrate and dispatch tasks to designated remote AIR responders effectively. Serving as the nerve center for task allocation, this console guarantees that each task is accurately assigned for execution, optimizing operational efficiency. Within this ecosystem, assigning a specific task to a particular asset is termed a 'task assignment,' ensuring a clear, one-to-one correspondence between tasks and assets for precise management and tracking.

Mechanisms for Task Checking

To accommodate diverse operational needs and customer network policies, the system employs two primary mechanisms for task checking:

1. Regular Interval Checks: Tasks are checked at predefined intervals, which can be dynamically adjusted based on the system's current configuration and operational demands.

2. The NATS Protocol: For immediate task fetching or near real-time communications with assets, the system incorporates a specialized protocol named "NATS." This protocol is designed to bypass the standard checking intervals, allowing for urgent tasks to be retrieved and executed with minimal delay

Task Checking Intervals

Task-checking intervals are not static; they vary dynamically from seconds to hours, influenced by the system's configuration. This flexibility ensures the system can adapt to changing workloads and priorities efficiently.

Task Prioritization and Execution Order

Prioritization of Critical Tasks

Certain tasks, such as "cancel tasks," receive priority in the execution queue. This prioritization is crucial to prevent delays in the cancellation process, ensuring tasks are halted promptly when required.

Execution Order and FIFO Queue Model

The system employs a first-in, first-out (FIFO) queue model for task execution. This model ensures that tasks are processed in the order received, with special consideration given to tasks that might block or delay subsequent operations unnecessarily.

Handling of Failed Tasks and Network Disruptions

Tasking Assignment interruptions

If a Tasking Assignment has been collected by the Responder but is interrupted before the completion of collection, triage, or analysis, the task will not resume where it left off. Instead, this interruption will result in a task failure. Such failures are automatically recorded within the console's tasking details.

When this occurs, the status of the task in the AIR console will reflect the failure, and it will be necessary to manually restart or initiate a new task to ensure that the intended data collection and analysis are completed. This approach ensures clarity and accuracy in managing task assignments, even in cases of unexpected interruptions.

Retry Mechanisms for File Uploads

For tasks that require file uploads, such as uploading to an evidence repository, the system includes built-in retry mechanisms. These mechanisms are activated to re-attempt uploads if network issues interrupt the process. The number of retries and the specific procedures for handling these retries vary depending on the task type and the destination of the file.

Additionally, if "direct collection" is enabled for an acquisition task and a failure occurs, the user must restart the acquisition process from the beginning. This ensures that all necessary data is properly collected without partial or corrupt files.

Data Purging and Task Cancellation

A specialized "purge local" task type exists for efficiently cleaning up local data related to completed or failed tasks. This function is crucial for maintaining optimal disk space utilization and efficient system resource allocation.

System Flexibility and Customer Policies

This guide emphasizes the importance of a flexible system that can adapt to diverse customer policies, including specific network configurations and security requirements. The choice of protocols and mechanisms for task management is influenced by these diverse operational needs.

Documentation and System Improvements

Continuous improvement is a cornerstone of system development. The commitment to updating documentation reflects ongoing efforts to refine task management processes and system functionalities based on operational insights and technical advancements.

Technical Implementation Details

The guide offers an in-depth examination of the system's technical underpinnings, including the utilization of the "NATS" protocol, dynamic adjustment of task-checking intervals, and the logic behind task prioritization and queue management. These details offer a comprehensive understanding of the system's operational logic and its capability to handle various scenarios efficiently.

Conclusion

Efficient task management is pivotal in ensuring the reliability and performance of software systems. Through innovative mechanisms, such as the air console and NATS protocol, alongside dynamic task-checking intervals and a robust FIFO queue model, the system outlined in this guide represents a state-of-the-art solution for managing tasks in complex software environments. The emphasis on flexibility, resilience, and continuous improvement underscores the system's readiness to meet the evolving demands of modern digital operations.

To add the proxy configuration to Relay Server, you can modify the /etc/profile file by following these steps:

1. Open a terminal or command line session.

2. Open the /etc/profile file in your favorite editor with administrative privileges:

sudo vim /etc/profile

1. Scroll to the end of the file and add the following lines:

Alternatively, you can use the following method to set proxy settings, but be aware that it will impact the proxy behavior of other programs.

Save the changes and exit the text editor.

1. To apply the changes, restart your system:

By adding these lines to the /etc/profile file, the specified proxy settings will be exported as environment variables.

Like the responder, the Relay Server has the capability to proxy connections through a proxy server when communicating with responders or AIR Console. This provides flexibility in terms of configuring proxies for the responder, which connects through a Relay Server, or setting a proxy specifically for the Relay Server. Additionally, it is also possible to set proxies for both the responder and the Relay Server simultaneously. The diagram below illustrates all the possibilities for proxying the Relay Server and the responder.

Before deploying a new asset through Relay Server, you need to choose the IP address of the Relay Server to which the endpoints will connect. This chosen IP address will serve as the connection route for the assets that will be routed through this Relay Server.

You can change the address of the Relay Server by accessing the "Relay Server Details" section, which can be found in the "Organization Detail" page.

Investigators and analysts can use the AIR platform to conduct investigations on machines located in cloud platforms. Our platform supports cloud-based virtual machines, as well as on-premise and off-network devices. Investigators and analysts can install responders on virtual machines located on the cloud infrastructure for investigations and analysis. Amazon Web Services and Microsoft Azure are both supported.

We understand the unique challenges of investigating cloud-based attacks, such as Business Email Compromise (BEC). That’s why we have introduced the Tornado preview version, a standalone desktop application designed to simplify evidence collection from Google Workspace and Microsoft Office 365. Learn all about Tornado .

Investigators and analysts can easily and quickly deploy responders to their cloud assets and immediately initiate investigations, compromise assessments, and threat-hunting activities. By leveraging the automation advantages of cloud platforms, users can easily deploy multiple responders using a single authorized cloud platform account.

After adding the authorized account to the Console, it enumerates the cloud platform to discover and list assets. Then, investigators and analysts can deploy responders to individual or multiple cloud assets with one click.

AIR Relay Server is a specialized SOCKS5 proxy server specifically designed to facilitate communication between AIR responders and the AIR console. Its primary function is to act as an intermediary, enabling the seamless proxying of connections between the responders and the console.

With Relay Server, you can enhance the security of both responders and the console by only granting access via the Relay Server, eliminating the requirement for direct access to the AIR console from the responder environment.

This indirect access approach adds an extra layer of protection to the overall system architecture.

To run the Relay Server correctly, the responder must be running to manage tasks received from the AIR Console. Any modification or removal of these requirements will cause the Relay Server to fail to operate.

If responders attempting to connect through the Relay Server cannot establish a connection, they will fallback to a direct connection. Alternatively, if a proxy connection is configured, they will fallback to using the proxy for the connection.

If connections through the Relay Server are experiencing failures, you can try resolving the issue by restarting the service using the following systemctl command:

This command will initiate a restart of the Relay Server service, which may help in resolving any connectivity issues.

Modifying the config file manually can introduce several problems, particularly due to the YAML format. Therefore, if you intend to make changes to the config file, such as adding whitelist addresses, it is crucial to adhere to the correct YAML format.

Ensure that you follow the YAML syntax rules while making any alterations to the config file. This includes correctly indenting elements, using appropriate punctuation, and maintaining the structure specified by the YAML format.

Relay Server logs all incoming connections and other operational activities for the purpose of troubleshooting and investigating any failures. To access these logs, you can retrieve by clicking on "Log Retrieval" on the "Relay Server Details" page.

To ensure a successful installation of Relay Server, it is necessary to have a Linux operating system based on either Debian or Redhat, with a minimum kernel version of 3.9.0. This requirement guarantees compatibility and optimal performance.

Currently, the supported versions for Relay Server are as follows:

Policies serve to define how evidence is collected and managed, providing fine-grained control over resources and processes.

Policies in AIR provide central configuration management and support global configurations that can be overridden at the Organisation level when required.

This overriding is only possible when the user has the “Override Policy” privilege allocated to their role.

Key Components:

Data acquisition is the collection of forensically sound data from any computer system (disk, external storage, memory, etc.). This data generally varies based on the operating system installed on the computer or server. Acquired data often needs to be parsed, stored, and presented in a human-readable format for further analysis and investigation.

Data acquisition is the primary activity of most digital investigations. Before data acquisition, the investigators generally identify the data they’ll need. Since data or evidence is an essential element of any investigation, investigators tend to take as much as they can in the first instance to avoid, if possible, a second acquisition. Therefore, the power of the digital investigation and DFIR solution is often proportional to the acquisition capability and the features associated with it.

AIR provides easy-to-deploy and fast data acquisition capabilities with a wide range of operating systems supported for the collection of 600+ forensically sound data types. AIR provides remote data acquisition for on-premise, cloud, and off-network devices. Thus, investigators can remotely investigate multiple devices at speed and scale.

AIR supports a growing number of operating systems, including Windows, Linux, macOS, ChromeOS, ESXi, and IBM AIX.

The results of AIR's Acquisition and Hunt/Triage processes can be further analyzed using DRONE's automated Post Acquisition Analyzers. DRONE's findings, along with all collected artifacts, are then presented within the Investigation Hub.

The AIR responder needs to be deployed first to acquire data. All data acquisition is performed according to the Data Acquisition Profile created before the acquisition is started.

The AIR responder can be installed on Microsoft Windows, Linux, and Apple macOS operating systems. All supported operating systems and associated versions are listed below.

To update Relay Server, you can initiate an update task for the Relay Server from the AIR Console.

Follow these steps from AIR Console:

1. Locate the Relay Server from the “Organization Detail” page.

2. Select the relay server and click “Update” button from “Relay Server Details” page.

By running the update task from the AIR Console, the Relay Server installed on the asset and the responder itself will be updated to the latest version.

Similarly, if you wish to uninstall Relay Server from an asset, you can click to red button next to the “Update” in “Relay Server Details” page from AIR Console. This will remove Relay Server and responder from the system.

Overview

Evidence: Brave Extensions Description: Collect Brave Extensions Category: Applications Platform: windows Short Name: bext Is Parsed: Yes Sent to Investigation Hub: Yes Collect File(s): No

Overview

Evidence: Action1 RMM Logs Description: Collect Action1 RMM Logs Category: Applications Platform: windows Short Name: action1rmmlgs Is Parsed: No Sent to Investigation Hub: No Collect File(s): Yes

As Relay Server operates as a service/daemon managed by systemd, you can utilize the following systemctl commands to start, stop, restart and reload the service:

To start the service:

To stop the service:

To restart the service:

Overview

Evidence: Avast Logs Description: Collect Avast Logs Category: Applications Platform: windows Short Name: avstls Is Parsed: No Sent to Investigation Hub: No Collect File(s): Yes

• macOS 10.15

• macOS 11.0

• macOS 12.0

• macOS 13.0

Overview

Evidence: AVG Logs Description: Collect AVG Logs Category: Applications Platform: windows Short Name: avgls Is Parsed: No Sent to Investigation Hub: No Collect File(s): Yes

Overview

Evidence: Active Directory Logs Description: Collect Active Directory Logs Category: Applications Platform: windows Short Name: adl Is Parsed: No Sent to Investigation Hub: No Collect File(s): Yes

Overview

Evidence: Avira Logs Description: Collect Avira Logs Category: Applications Platform: windows Short Name: avrals Is Parsed: No Sent to Investigation Hub: No Collect File(s): Yes

The Account Settings section in AIR allows users to manage personal preferences and session details. This section is accessible via the user icon located in the top-right corner of the AIR interface toolbar.

What You Can Do in Account Settings

• View Account Details: Includes your registered name, surname, email address, and username.

• Change Password: Locally authenticated users can update their password directly from here.

• Sign Out: Securely log out of your AIR session.

• Customize Theme Preferences: Switch between Light and Dark Mode or set the UI to follow system time-based settings.

Dark Mode

The AIR interface supports a Dark Mode UI theme, providing a modern, eye-friendly visual style that is ideal for use in low-light conditions or during extended periods of use. This feature:

• Enhances usability and reduces eye strain.

• Can be toggled manually between Light and Dark modes.

• Includes an Auto mode that adapts the UI based on your machine's time zone and daylight saving hours, ensuring a seamless experience.

Dark Mode aligns with current UI standards and user expectations, supporting a comfortable and productive working environment.

User Profile Photos

Users can upload their own profile images. These will be displayed across the AIR console UI in user-facing areas, such as the user menu, case history, and activity logs. Supported for both regular and SSO-authenticated users, although not synced from the identity provider.

This page summarizes the capabilities and current limitations of Responder for Organization Units (OUs) within an Active Directory (AD) environment.

Key Points:

1. Current Capability:

   • Once Active Directory integration is complete, the AIR will display the domain on the Assets page.

   • Users can filter assets by clicking on their Organization Unit on the Assets page. Further filtering for "Managed Status in Managed" will show assets where the Responder is installed.

2. Limitations and Requests:

   • As of now, AIR does not support querying or installing Responders directly at specific OU levels (e.g., SecurityTesting.AIR.local) beyond the root AD level (e.g., AIR.local).

   • A feature request has been submitted to allow integration directly at the OU level to enhance targeted management within the domain structure.

3. Installation Note:

   • The AIR Responder will report on systems where it is installed. It does not automatically install on systems within an AD environment where it is not already installed.

Conclusion: Efforts to extend AIR's integration capabilities to specific OUs are ongoing, following feedback and feature requests. This enhancement aims to provide more granular control and efficiency in managing cybersecurity operations across different organizational units.

• Windows 7 SP1 (with latest updates)

• Windows 8

• Windows 8.1

• Windows 10

• Windows 11

• Windows Server 2008 R2 (with latest updates)

• Windows Server 2012

• Windows Server 2012 R2

• Windows Server 2016

• Windows Server 2019

• Windows Server 2022

• Windows Server 2025

• Centos 7

• Centos 8

• Centos 9

• Fedora 21

• Fedora 22

• Fedora 24

• Fedora 26

• Fedora 34

• Fedora 36

• Amazon Linux 1 Latest

• Amazon Linux 2 Latest

• Redhat 7

• Redhat 8

• Redhat 9

• Pardus 17

• Pardus 21

• Rockylinux 9

• Rockylinux 8

• Debian 7

• Debian 8

• Debian 10

• Debian 11

• Debian 12

• Ubuntu 12.04

• Ubuntu 14.04

• Ubuntu 16.04

• Ubuntu 18.04

• Ubuntu 20.04

• Ubuntu 22.10

• Ubuntu 23.04

• Ubuntu 24.04

• Boss Linux 7

• Boss Linux 8

• Boss Linux 9

• Boss Linux 10

All Linux distros can run on 32/64 bit and ARM64 architectures.

AIR Watchdog Folder:

C:\ProgramData\.binalyze-air\ or %ProgramData%\.binalyze-air\*

The AIR Watchdog Folder (C:\ProgramData\.binalyze-air\ or %ProgramData%\.binalyze-air\) is a critical directory used by the AIR responder for storing internal data required to maintain and monitor the health and proper functioning of the AIR responder agent. This folder contains temporary files, logs, and configuration data that help the Watchdog component of the AIR platform ensure that the responder agent is running correctly and automatically restarts the agent if any issues arise.

Purpose of the Watchdog Folder

1. Health Monitoring: The Watchdog monitors the responder agent's status. If the agent stops unexpectedly or malfunctions, the Watchdog uses this folder to store diagnostic data and trigger the necessary actions (e.g., restarting the agent).

2. Temporary Storage: The folder stores temporary files used by the AIR responder during its forensic and investigative processes. These may include logs, process monitoring data, or execution-related files.

3. Configuration Data: The directory can also house configuration and state files that help the agent track its operational state, ensuring that it maintains continuity of processes even in the event of interruptions.

Exception Configuration

When configuring EDR (Endpoint Detection and Response) or AV (Antivirus) software, it is essential to exclude this folder from being scanned or interfered with. Failure to do so may cause unnecessary alerts or interruptions to the operations of the AIR responder, potentially halting the forensic collection process or causing data collection to fail.

Folder Path Variations

• Absolute Path: C:\ProgramData\.binalyze-air\* This is the standard path used by the AIR Watchdog on Windows systems.

• Environment Variable Path: %ProgramData%\.binalyze-air\* This variation uses the %ProgramData% environment variable, which points to the C:\ProgramData\ folder. It's a more dynamic way of referencing the same location in different system configurations.

Importance of Allow-Listing This Folder

For AIR to function seamlessly, especially during critical incident response tasks, excluding this folder from AV/EDR scans or interference is vital. The Watchdog service ensures that the responder remains operational and recovers automatically if disrupted.

To ensure uninterrupted operation, follow these allow-listing rules in your security setup:

• Windows AV/EDR Systems: Allow-list the folder C:\ProgramData\.binalyze-air\*

• Linux/macOS Equivalents: Similar watchdog components may exist in those environments within paths like /usr/share/.binalyze-air/ or /opt/binalyze/air/agent/ (adjust based on OS).

By allowing the Watchdog folder, you ensure AIR remains resilient and responsive, even in the event of unexpected issues.

This feature empowers users to manage Investigation Hub data storage effectively and is fully explained here: Investigation Hub – Data Usage Statistics Dashboard.

Overview

Evidence: Bitdefender Logs Description: Collect Bitdefender Logs Category: Applications Platform: windows Short Name: btfndrls Is Parsed: No Sent to Investigation Hub: No Collect File(s): Yes

Background

Bitdefender is an enterprise-grade security solution that maintains detailed logs of endpoint protection, firewall activities, malware detections, and system events. Logs include XML-formatted system events, firewall logs, and database files containing threat intelligence.

Data Collected

This collector gathers structured data about bitdefender logs.

Collection Method

This collector gathers Bitdefender logs from multiple locations including Endpoint Security logs, Desktop profile logs, system XML files, firewall logs, and database files containing security event data.

Forensic Value

Bitdefender logs are critical for investigating security incidents, tracking malware detections, analyzing firewall blocks, and understanding endpoint protection events. They provide comprehensive visibility into threats, network traffic controls, and security posture over time.

Overview

Evidence: Apache Logs Description: Collect Apache Logs Category: Applications Platform: windows Short Name: apcl Is Parsed: No Sent to Investigation Hub: No Collect File(s): Yes

Background

Apache HTTP Server and Tomcat logs record web server activity including access logs, error logs, and application-specific logs. These logs are critical for understanding web server operations and detecting web-based attacks.

Data Collected

This collector gathers structured data about apache logs.

Collection Method

This collector gathers Apache and Tomcat log files from standard installation directories in Program Files, collecting access logs, error logs, and other server activity logs.

Forensic Value

Apache logs are essential for detecting web attacks, unauthorized access attempts, data exfiltration, and command injection. They reveal attacker IP addresses, requested URLs, user agents, and exploitation attempts against web applications.

Overview

Evidence: AnyDesk Logs Description: Collect AnyDesk Logs Category: Applications Platform: windows Short Name: nydskl Is Parsed: No Sent to Investigation Hub: No Collect File(s): Yes

Background

AnyDesk is a widely-used remote desktop application frequently leveraged by both legitimate users and threat actors. It stores trace logs, configuration files, connection traces, and recorded sessions. The software is commonly abused for initial access and persistence in cyber attacks.

Data Collected

This collector gathers structured data about anydesk logs.

Collection Method

This collector gathers AnyDesk trace files, configuration files, connection trace logs, and recorded session files from user and system directories.

Forensic Value

AnyDesk artifacts are critical for investigating unauthorized remote access, as the tool is frequently used in ransomware attacks, tech support scams, and remote access trojans. Logs reveal connection IDs, session times, file transfers, and can link to specific AnyDesk addresses used by attackers.

Components

AIR is an on-premise or cloud-based, client-server solution that allows you to remotely perform various tasks on assets such as collecting forensic evidence and performing threat hunts with YARA, Sigma, or osquery.

1. Management Console

Management Console is a web-based application that can be viewed from any device with an up-to-date browser.

2. AIR Responders

Assets are connected to the management console via a lightweight "passive" responder that can be deployed manually or via other mechanisms such as SCCM.

2.1. Passive Responder Explained

AIR responders;

• DO NOT scan anything on the asset that may cause slowdowns (e.g. your Antivirus),

• DO NOT block anything on the asset that may cause false positives (e.g. your DLP),

• DO NOT create any alerts that may cause "alert fatigue".

3. Communication with the Binalyze Domain

What data is sent or received by Binalyze domains

To ensure proper installation of the Relay Server, the responder must be installed and registered within the same organization and on the same system. If you plan to install the responder beforehand, you should select a direct connection as the Relay Server will be located on the same system.

From the "Organizations" page, when you create a new organization or select an existing one, it will bring you to a page where you can deploy a new Relay Server.

By clicking "New Relay", a deployment page brings up for the Relay Server:

As you can see, there are packages available based on Debian or Redhat distributions. You can select either the 64-bit or ARM64 version by clicking the arrow next to the "Download" button.

Once the package is downloaded, you will need to configure the environment settings for the Relay Server to register with the AIR Console. To simplify this process, you can easily copy the necessary commands by clicking the "copy" button located in the right corner of the command.

export AIR_DEPLOYMENT_TOKEN=dce4e59125c545a2
sudo -E dpkg -i ./binalyze-air-relay-server_2.22.0_*.deb

After copying the commands, open a terminal and navigate to the directory where you have downloaded the package. If the directory is "Downloads" in your home folder, you can go to that folder by executing the following commands in the terminal:

As part of the Relay Server installation process, it performs a check to verify the availability of the responder. Additionally, it configures the responder to manage the newly installed Relay Server.

Upon successful installation, you will be able to view your newly deployed Relay Server on the "Organization Detail" page.

When deploying a new responder to an asset, you will encounter a configuration option that allows you to choose a connection route. This allows you to deploy a responder that either directly connects to the AIR Console or utilizes a connection route via a Relay Server.

By selecting the "Relay Server Connection" radio button, you will be presented with a list of registered Relay Servers associated with this organization. From this list, select one option and proceed with the configuration.

The subsequent steps remain the same as when deploying a new responder, regardless of the connection route chosen (Relay Server). Once you have successfully installed a new asset using the Relay Server connection, you will observe the newly deployed asset associated with the Relay Server on the "Organization Detail" page.

After selecting the installed Relay Server from the list on the "Organization Detail" page, you can access your associated assets by clicking on the "Assets" tab. Additionally, you can view comprehensive details of your Relay Server on this page by clicking on the "Information" tab.

Updating the Connection Route address

Furthermore, you can view and manage assets that are connected through this Relay Server. To modify the connection routing of your assets, navigate to the "Assets" tab. Simply select the asset that you would like to view or edit.

Within the "Connection Route" setting, you have the option to choose between a direct connection to the AIR Console or selecting another Relay Server for your asset to connect to. This action will bring up the same settings page for connection routing that you encountered when deploying a new asset.

Updating Connection Route addresses for multiple assets

To update the connection route addresses for multiple assets in the same organization, follow these steps:

1. Go to the organization's page (the organization where you want to update the assets) or the Assets page.

2. Selected the desired assets within the same organization.

3. Edit the connection route by selecting the icon at the end of the connection route row.

4. Modify the connection route addresses or choose a Direct connection.

By following these steps, you can easily update the connection route addresses for multiple assets in the same organization.

Updating the responder’s connection route address using the command line

To manually update the connection route of your responder, you can run the responder with the "configure" flag. Follow these steps:

1. Open a Terminal.

2. Navigate to the directory where the responder is located.

3. Run the configure command as shown below:

Upon running the configuration command, the responder service will automatically restart with the updated configuration, including the new connection route that has been set. This ensures that the responder incorporates the changes and operates according to the new configuration.

Relay Server is designed to facilitate communication between the AIR Console and the responder. As a result, Relay Server carefully examines all connection attempts to ensure they are directed towards AIR Console and blocks any connection requests to other destinations. This strict enforcement guarantees that only connections to AIR Console are permitted, thereby providing a secure environment and ensuring that no undesired connections to other addresses occur.

To enable connections to addresses other than the AIR Console, a configuration called "Whitelist" is utilized. By specifying addresses or IP/FQDN patterns in the whitelist, the Relay Server allows communication between clients and the whitelisted addresses. In such cases, the Relay Server acts as a proxy between the client and the whitelisted address, ensuring seamless communication while still maintaining the necessary security measures.

To add or modify the whitelist in the configuration file, you can follow these steps:

1. Locate the config.yml file: /opt/binalyze/air/relay/config.yml

2. If the Whitelist field is not present in the file, add it as a YAML array in the following format:

In the Whitelist array, you can include various elements such as IP addresses, fully qualified domain names (FQDNs), FQDNs with wildcards, CIDR notations, IP ranges, or use an asterisk (*) to allow all connections.

The Whitelist elements support the following formats:

• IP address: Enter the specific IP address.

• FQDN: Provide the fully qualified domain name.

• FQDN with wildcard: Use an asterisk (*) as a wildcard character in the domain name.

• CIDR: Specify the IP range using CIDR notation.

By configuring the whitelist, you can specify the allowed addresses or domains that Relay Server will permit connections to.

After modifying the config file for Relay Server, it is essential to reload the configuration if Relay Server is already running. To accomplish this, you can use the following systemctl command:

SSL Certificate

Enable secure connections between AIR Console and users/assets by using SSL encryption.

• Certificate: This displays the SSL certificate details used by AIR for secure HTTPS communication. In this case, the certificate is issued by Let's Encrypt (Issuer: Let's Encrypt, Common Name: R3) and is valid for a specific period (e.g., from 2022.09.18 to 2022.12.17).

• Subject: The Common Name (CN) field shows the domain (e.g., air-demo.ACME.com) to which the certificate applies.

• Having an SSL certificate ensures that all communications between users and the AIR Console are encrypted, preventing unauthorized access to sensitive information.

SSL Root CA

Acts as the root certificate authority (CA) for issuing certificates if a custom SSL certificate is not provided.

• AIR generates an SSL Root CA for each instance when a custom certificate isn’t supplied. This certificate is used to create secure communication channels within the system.

• Issuer and Subject: Both are BINALYZE R1, ensuring that the root certificate is tied to the Binalyze platform.

• Validity: The root CA certificate is valid from 2017.10.14 until 2100.10.14, ensuring long-term use and security.

Console Port

Define the port over which the AIR Console is accessible.

• The AIR Console is configured to be accessed on port 8443, which is a secure port typically used for HTTPS traffic.

• Meanwhile, responders will continue to communicate with the console over the default secure port 443. This setup ensures that assets and users can access the platform via separate but secure ports, enhancing security and flexibility.

IP Restriction

Restrict access to the AIR Console based on IP addresses.

• This feature allows administrators to restrict access to the AIR Console to a specific range of IP addresses, limiting who can interact with the console.

• Important: This restriction does not affect communication between the AIR Console and the assets themselves. It only controls who can access the console’s user interface.

• The current IP address of the user accessing the system (e.g., 172.71.122.69) is displayed for reference.

Authentication

Configure user authentication security settings.

You can enforce Two-Factor Authentication (2FA) for all users, adding an extra layer of security by requiring a second form of verification (e.g., a mobile app code) when logging in. (SSO will override this option)

• This setting enhances overall security by ensuring that only authenticated and verified users can access the system.

Single Sign-On (SSO)

Enable and configure Single Sign-On (SSO) for AIR.

• SSO allows users to log in to AIR using their organization’s existing identity provider (e.g., Azure AD, Okta) without needing separate credentials. This simplifies the login process and enhances security by centralizing authentication management.

• Tenant ID and Client ID: These are provided by the SSO identity provider (e.g., Azure, Okta) and uniquely identify the organization’s SSO configuration.

• Client Secret: A secure key used for authenticating the connection between AIR and the SSO provider (shown as encrypted in the system).

SSO improves user management and security by centralizing login credentials with your existing identity provider, simplifying the user experience while ensuring strong authentication practices.

AIR Responder is now capable of functioning in Safe Mode, allowing forensic acquisition and remote tasking on machines operating in a restricted state. However, to maintain full functionality and allow task execution via the AIR Console, specific registry modifications must be applied before entering Safe Mode.

Enabling AIR Responder in Safe Mode

Before booting into Safe Mode, execute the following Registry modifications to register the AIR Agent Service:

REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Network\Binalyze.AIR.Agent.Service" /VE /T REG_SZ /D "Service" /F

REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\SafeBoot\Minimal\Binalyze.AIR.Agent.Service" /VE /T REG_SZ /D "Service" /F

These registry changes can also be enforced via the Windows UI by running msconfig to get to the System Configuration window where in the Boot tab, the user can select Safe Boot with the Network button active:

These registry entries ensure the AIR Agent Service is recognized and loaded in Safe Mode.

Behavioral Scenarios

Safe Mode with Networking

• If a machine enters Safe Mode with Networking, the AIR Agent will continue operating as expected, maintaining communication with the AIR Console.

Safe Mode (Without Networking)

• The AIR Agent cannot communicate with the console if networking is unavailable unless an off-network package is used for forensic acquisitions.

Remote Task Execution

• Without the registry modifications, the AIR Console cannot issue remote tasks to the endpoint in Safe Mode.

• Adding the registry keys before booting into Safe Mode ensures that Responder and interACT remain functional.

Manual Execution in Safe Mode (Not Recommended)

• If the registry modifications are not applied and the AIR Agent does not load, users can manually execute AIR.exe after entering Safe Mode to establish a temporary connection.

• However, this approach is not recommended due to potential inconsistencies and administrative overhead.

By proactively applying the recommended registry changes, organizations can ensure seamless forensic investigations even when endpoints are booted in Safe Mode.

Overview

Allow-listing is required for AIR responders to run acquisition tools, write temporary artifacts, and access protected areas of the file system. Without explicit exclusions in your Endpoint Protection Platform (EPP), Endpoint Detection and Response (EDR), or antivirus solution, these routine activities can trigger false positives and interrupt evidence collection.

Use the tables below to add the recommended folder and binary exclusions for each supported operating system. Choose the entries that match your deployment to keep responders running without false positives.

Windows

Folders to Exclude:

• C:\Program Files (x86)\Binalyze\AIR\agent\

• C:\ProgramData\.binalyze-air

Binaries to Exclude:

• C:\Program Files (x86)\Binalyze\AIR\agent\AIR.exe

• C:\Program Files (x86)\Binalyze\AIR\agent\DRONE.exe

• C:\Program Files (x86)\Binalyze\AIR\agent\TACTICAL.exe

Linux

Folders to Exclude:

• /opt/binalyze/air/agent/

• /usr/share/.binalyze-air/

Binaries to Exclude:

• /opt/binalyze/air/agent/air

• /opt/binalyze/air/agent/drone

• /opt/binalyze/air/agent/tactical

macOS

Folders to Exclude:

• /opt/binalyze/air/agent/

• /usr/local/share/.binalyze-air/

Binaries to Exclude:

• /opt/binalyze/air/agent/air

• /opt/binalyze/air/agent/drone

• /opt/binalyze/air/agent/tactical

AIR allows you to set up various Evidence Repositories for storing and managing collected data securely. The supported repository types are:

1. SMB: Ideal for sharing files across network devices.

2. SFTP: Utilizes SSH for encrypted data transfer.

3. FTPS: Combines FTP with SSL/TLS for secure transfers.

4. Amazon S3: Provides scalable cloud-based storage, perfect for large-scale investigations.

Key Features:

• Global or Organization-Level Setup: Repositories can be defined at both global and organizational levels, providing flexibility in evidence management across multiple AIR instances or within a single organization.

• Secure Data Management: Protocols like SFTP and FTPS ensure that data transfers are encrypted, safeguarding sensitive information during uploads and downloads.

• Automatic and Manual Uploads: Evidence can be automatically uploaded to repositories based on configured tasks, or users can manually upload files as needed.

This setup ensures secure, scalable, and efficient management of evidence within AIR, accommodating various infrastructure needs.

The AIR API facilitates seamless communication with the AIR console, enabling users to collect information or execute tasks with precision and efficiency.

We provide sample requests in various programming languages, including Go, Python, and Java, as well as sample cURL requests to equip users with comprehensive integration resources. These samples serve as practical guides, showcasing the seamless implementation of our API functionalities across different development environments.

To access detailed documentation and unlock the full potential of our API, we invite developers to explore our comprehensive resource at docs.binalyze.com. Here, you can find in-depth explanations, tutorials, and reference materials that guide you through the integration process seamlessly.

Our API documentation, which includes detailed endpoint descriptions, authentication guidelines, and practical code examples, offers invaluable insights for developers at every stage. Leverage the power of our API at docs.binalyze.com to empower your development journey and unlock new possibilities.

Enhanced API Token Management with Role-Based Access Control

API Token Management supports role-based access control (RBAC), which enhances security and flexibility while reducing the need for excessive permissions.

• Global Admins can only create and modify API tokens.

• Granular Permissions: Tokens inherit only the privileges of their assigned role (e.g., read-only or custom roles), preventing over-permissioning.

• Post-Creation Role Updates: Token permissions can be modified after creation, allowing for dynamic access control.

• Governance & Security:

API token management in AIR has role-based limitations, allowing API usage to be tailored according to the selected role. This capability refines automation workflows and strengthens access control policies.

Overview

Evidence: ARP Table Description: Collect ARP Table Category: Network Platform: windows Short Name: arpt Is Parsed: Yes Sent to Investigation Hub: Yes Collect File(s): No

Background

The ARP (Address Resolution Protocol) table maps IP addresses to physical MAC addresses on the local network. Windows maintains this cache for performance, storing recent IP-to-MAC mappings from network communication.

ARP cache can reveal devices the system has recently communicated with on the local network, including routers, file servers, and other workstations.

Data Collected

This collector gathers structured data about arp table.

ARP Table Data

Collection Method

This collector uses Windows API to enumerate ARP cache:

• GetIpNetTable to retrieve all ARP entries

• Parses MAC addresses into readable format

• Records adapter associations

ARP entry types: Other (1), Invalid (2), Dynamic (3), Static (4).

Forensic Value

ARP cache reveals local network communication patterns. Investigators use this data to identify devices on the local network, detect ARP spoofing attacks, track lateral movement targets, identify network infrastructure devices, correlate with network connections, and detect man-in-the-middle attacks.

Overview

Evidence: Brave Thumbnails Description: Collect Brave Thumbnails Category: Applications Platform: windows Short Name: bthmb Is Parsed: Yes Sent to Investigation Hub: Yes Collect File(s): No

Background

Browser thumbnails are cached preview images of visited websites. This visual data supplements browsing history by providing screenshots of accessed pages, useful for recovering deleted history and identifying visited content.

Data Collected

This collector gathers structured data about brave thumbnails.

Brave Thumbnails Data

Collection Method

This collector extracts cached thumbnail images from browser storage.

Forensic Value

Thumbnail analysis provides visual evidence of visited websites, can recover evidence after history deletion, and helps identify phishing pages, malicious sites, or sensitive internal resources accessed by users through visual inspection.

All console settings can be accessed via the gear icon in the top-right corner of the header bar. This page provides a complete guide to configuring and managing settings across AIR, including:

• General Settings: Platform-wide configurations.

• Assets: Managing asset inventories.

• Security: Setting up security features.

• Features: Customizing AIR’s core functionalities.

• Evidence Repositories: Configuring storage for collected evidence.

• Policies: Defining evidence collection rules.

• User Management:

  • Users

  • Groups

  • UserRoles

• Backup and Backup History: Managing backups and retention schedules.

• Investigation Hub Disk Usage: Empowers users to manage Investigation Hub data storage effectively.

• Danger Zone.

Each section ensures optimal setup for your AIR environment.

Overview

Evidence: $Secure:$SDS Description: Dump Contents of $Secure:$SDS Category: DiskFilesystem Platform: windows Short Name: securesds Is Parsed: No Sent to Investigation Hub: Yes Collect File(s): Yes

Background

The $Secure file contains security descriptors for all files and directories on the NTFS volume. These descriptors include access control lists (ACLs), ownership information, and audit settings. The $SDS alternate data stream stores the actual security descriptor data, which is referenced by file entries to avoid duplication.

Data Collected

This collector gathers structured data about $secure:$sds.

$Secure:$SDS Data

Collection Method

This collector uses kernel driver NTFS raw access to read $Secure:$SDS from each fixed NTFS drive.

Forensic Value

Security descriptors provide critical information about file permissions, ownership, and access control. This data can reveal unauthorized access, privilege escalation attempts, and security policy violations. Essential for investigating insider threats and understanding who had access to sensitive files.

Overview

Evidence: WMI Active Script Description: Dump WMI Active Script Event Consumers Category: System Platform: windows Short Name: wmiasc Is Parsed: Yes Sent to Investigation Hub: Yes Collect File(s): No

Background

WMI ActiveScript Event Consumers execute VBScript or JScript code when specific WMI events occur. This is a powerful persistence mechanism that allows attackers to run arbitrary scripts with SYSTEM privileges in response to system events.

ActiveScript consumers are particularly dangerous because they don't require a file on disk (fileless persistence) and run with high privileges.

Data Collected

This collector gathers structured data about wmi active script.

WMI Active Script Data

Collection Method

This collector queries WMI for ActiveScriptEventConsumer instances in multiple namespaces:

• ROOT\Subscription

• ROOT\DEFAULT

• ROOT\CIMV2

Forensic Value

ActiveScript consumers are a common advanced persistence technique. Investigators use this data to detect WMI script-based persistence, identify malicious VBScript/JScript payloads, and track fileless malware techniques.

AIR > Settings > Backup:

The AIR Backup feature allows users to back up system data securely and flexibly through the UI or Command Line Interface (CLI). Backups can be stored locally, on SFTP, or in Amazon S3, and encrypted using AES256 with a password.

Backups can be performed immediately or scheduled at intervals of every 4 hours, daily, weekly, or monthly. Users can set the number of backups to retain and the scheduled start time. CLI backup options are available, with detailed instructions in the Knowledge Base.

AIR > Settings > Backup History:

This page displays the Backup History available to the AIR console.

AIR Backup File Naming Convention

AIR backup files use a structured naming format that embeds timestamp and version information directly into the .abf filename. This makes it easy to identify when a backup was created and which internal backup schema and AIR console version were used.

Example Filename

Filename Components

Date Component: 25-11-17

• 25 = Year (2025)

• 11 = Month

• 17 = Day

Time Component: 6-6-0-026

Represents the exact creation time of the backup:

• 6 = Hour

• 6 = Minute

• 0 = Second

• 026 = Millisecond

Backup File Format Version: v4

Indicates the internal backup schema/version used by AIR. This ensures compatibility between console versions and the expected backup structure.

AIR Console Version: AIRv5.5.1

Shows which AIR version generated the backup.

File Extension: .abf

AIR Backup File.

Summary

~25-11-17_6-6-0-026_v4_AIRv5.5.1.abf means the backup was created on 17 November 2025 at 06:06:00.026, using the v4 backup format, from an AIR 5.5.1 console.

How Do Assets Communicate with the Console?

All routine communication between assets and the AIR console is initiated by the assets—they do not receive incoming requests from external sources. Communication occurs through various protocols and channels:

Overview

Relay Server Pro is a fundamental architectural evolution in secure relay operations for Binalyze AIR. It replaces the legacy SOCKS5-based relay server with a fully authenticated HTTPS proxy that implements JWT-based two-step verification for Responders connecting through constrained or segmented networks.

AIR > Settings > User Management > Users:

This section enables administrators to view existing users and their attributes. It also allows for the addition of new users to the AIR platform, where key details such as name, organization, role, and login credentials are specified during setup.

For organizations needing to onboard multiple users simultaneously, the Import Users button provides bulk user import capability via CSV file upload or email list. Optional metadata such as organization, role, or group can be included for automatic assignment. A preview step allows validation before changes are applied, expediting onboarding for large enterprise security operations teams while reducing human error and maintaining consistent access structures.

Mandatory fields are marked with an asterisk (*).

In AIR (Settings > Security > Authentication), two-factor authentication (2FA) is a security feature designed to enhance user account protection by requiring two forms of verification when logging in. This adds an additional layer of security beyond the traditional username and password combination, significantly reducing the risk of unauthorized access.

Some key points about 2FA in AIR:

• LDAP User Compatibility with 2FA: AIR supports two-factor authentication (2FA) for LDAP users. You can easily configure 2FA directly from the account settings within AIR, making the setup process straightforward and efficient for centralized user management systems.

• Administrators can enforce two-factor authentication (2FA) for all users. This uniform security policy enhances overall security by requiring all users to authenticate with an additional method, such as a one-time password (OTP) sent to a mobile device or generated by an authenticator app.

Overview

Evidence: Antivirus Information Description: Collect information about installed antivirus Category: System Platform: windows Short Name: avi Is Parsed: Yes Sent to Investigation Hub: Yes Collect File(s): No

Overview

Evidence: $Boot Description: Dump Raw Contents of $Boot File Category: DiskFilesystem Platform: windows Short Name: ntfsboot Is Parsed: No Sent to Investigation Hub: Yes Collect File(s): Yes

Organizational Controls

From the top bar, the drop-down allows the user to select:

• Organization Settings

Overview

Evidence: $TxfLog $Tops:$T Description: Dump Contents of $TxfLog$Tops:$T Category: DiskFilesystem Platform: windows Short Name: txflogtops Is Parsed: No Sent to Investigation Hub: Yes Collect File(s): Yes

Overview

Evidence: $Log File Description: Dump raw contents of $LogFile Category: DiskFilesystem Platform: windows Short Name: ntfslog Is Parsed: No Sent to Investigation Hub: Yes Collect File(s): Yes

Overview

Evidence: AppCompactCache Description: Enumarate AppCompatCache (aka ShimCache) Category: System Platform: windows Short Name: appcc Is Parsed: Yes Sent to Investigation Hub: Yes Collect File(s): No

Overview

Evidence: AppPaths Description: Enumerate AppPaths Category: System Platform: windows Short Name: apppaths Is Parsed: Yes Sent to Investigation Hub: Yes Collect File(s): No

Overview

Evidence: Brave Favicons Description: Collect Brave Favicons Category: Applications Platform: windows Short Name: bfico Is Parsed: Yes Sent to Investigation Hub: Yes Collect File(s): No

Why Using the API in AIR is Likely to be More Effective

APIs and webhooks both serve as methods for integrating systems and enabling communication between applications, but they are suited for different use cases. In many scenarios, using APIs is recommended over webhooks due to the control, flexibility, and broader operational capabilities they offer.

The AIR responder standalone collector currently provides support for execution on Chrome v90+ operating systems.

AIR For Chrome is the evidence collector extension for Chrome and ChromeOS. AIR For Chrome extension allows investigators and analysts to capture forensically sound data with a single click at machine speed. All data is collected into a well-organized HTML report that is accompanied by individual CSV files. Investigators and analysts can use AIR For Chrome Extension to collect forensically sound data from Google Chrome and ChromeOS.

AIR For Chrome is the fastest and easiest way of capturing forensically sound data from Google Chrome browsers. The forensically sound data collected by AIR For Chrome are listed below.

• Browser History

Overview

Evidence: AmmyAdmin Logs Description: Collect AmmyAdmin Logs Category: Applications Platform: windows Short Name: aammyadmnlg Is Parsed: No Sent to Investigation Hub: No Collect File(s): Yes

In AIR a Golden Image is for customers who want to use the same Operating System image files to generate new machines with a responder already installed. As AIR use the computer name/hostname of the machine/asset as a unique identifier for the machine/asset, customers cannot use the exact same image in which AIR Responder is already installed without newly introduced golden image support.

It basically cleans some configuration options set during registration and then disables and stops the Responder service before the image of the operating system is taken. To do this, we use `--prepare-golden-image' flag that is explained below. This must be called before the imaging process takes place.

After the image is prepared, the user must use --init-golden-image flag, which is explained below before the image is used to create a new instance.

--prepare-golden-image

The user must use this flag before creating a golden image.

Acquisition Profile

A collection of evidence types, application artifacts, network captures, and custom content items grouped into reusable sets known as Acquisition Profiles. While several profiles are provided out-of-the-box, users can also create and customize their own, adding them to the Acquisition Profile Library, accessible via the Main Menu.

AIR Console

The AIR Console is a web-based management interface that enables users to efficiently manage assets, assign tasks, and oversee the entire investigation lifecycle. From evidence acquisition to in-depth analysis, report generation, and case management, all activities are streamlined through the Investigation Hub. Users can also personalize their experience by switching between light and dark modes via the main menu, enhancing usability and visual comfort.

Asset and Asset Status

In AIR, an asset is defined as any entity, whether a device or system, physical or virtual, that operates on a supported operating system such as Windows, macOS, Linux, Chrome, IBM AIX, and ESXi. Assets are the foundational elements on which AIR performs various actions, including evidence collection and task execution, crucial for responding to and hunting cyber threats. Examples of assets include computers, servers, hosts, cloud accounts, and disk images.

In AIR, an Asset can be in one of 3 states:

1. Managed: The asset's responder has been successfully deployed to the device and is ready to collect tasking assignments from the console.

2. Unmanaged: An asset is categorized as Unmanaged under two specific conditions:

   • Discovery without Deployment: The asset is identified through Active Directory or Cloud Account scans, but does not have the AIR responder installed.

The Assets Summary window on the home page can also report the asset as:

1. Unreachable: The asset's responder is currently unreachable. If an Asset's Responder fails to connect to the AIR console for over 30 days, its status changes to "unreachable." Until then, its status will be managed as online or offline.

2. Update Required: The responder on the asset requires an update to function correctly.

3. Update Advised: The responder is still functional, but for full functionality, an update is recommended.

4. Isolated:

Asset Management - Using Persistent Saved Filters

Persistent Saved Filters enable users to create and store custom asset filters, making it easier to locate and manage assets without having to reapply filter conditions in each session.

A Case

In AIR, a Case — can often be thought of simply as an 'investigation' — as it is where all related activity and evidence are grouped together. By collecting acquisitions, DRONE findings, timelines, interACT sessions and hunt results within a single case, AIR automatically builds a unified view of all of that activity in the Investigation Hub. This case-based approach gives investigators a clear, consolidated picture of their entire investigation in one place — the single pane of glass.

Evidence Item

In Binalyze AIR, evidence refers to any data collected from an asset during acquisition or triage that supports forensic investigation and incident response. This may include system metadata, logs, configuration information, user-activity traces, or other information useful in reconstructing events.

AIR organizes all collectible data into evidence items, each of which belongs to one of the defined evidence categories in the acquisition profile. An evidence item represents a specific data source with a clear description of what it contains and why it is relevant for investigation.

The current evidence categories are:

1. System - Core operating system information, including system configuration, environment details, and fundamental OS state.

2. Memory - Volatile memory sources such as RAM snapshots, memory sections, and other data that reflect live system state at the time of acquisition.

3. Network - Network-related evidence including connections, configurations, interface details, and network activity indicators.

4. Event Logs - Structured logs generated by the operating system that record authentication events, system changes, service activity, and other audit information.

5. Disk & File System - File system metadata, mount points, directory information, file activity indicators, and other disk-level sources that reflect how data is organized and accessed.

6. Applications - Evidence produced by installed or active applications, including logs, caches, configuration files, usage traces, and other application-specific data sources.

7. Custom Content - Items defined directly by the user based on file paths or directories of interest. This allows investigators to collect additional files or folders that fall outside the standard evidence set.

8. osquery - Items collected by executing osquery queries on the asset. These provide structured, table-driven insights into system and application state using the osquery framework.

Evidence Repository

A remote location for saving evidence collected as a result of an AIR tasking. These include:

1. SMB

2. SFTP

3. FTPS

4. Amazon S3

To create a New Repository, go to Settings in the Main Menu and select Evidence Repositories from the secondary Menu. From the window 'New Repository' complete the mandatory fields and select the type of repository you wish to add.

Read more details about

Organizations

In AIR, an organization is a structural entity that allows for the separation of assets, users, and cases within a multi-tenant environment. The multi-tenancy capability of AIR enables a single console to manage multiple organizations, each with its own isolated environment. Here's how it works:

1. Asset Management: An asset (e.g., a device or endpoint) can belong to only one organization, ensuring clear boundaries between different organizational environments. However, within that organization, the same asset can be assigned to multiple cases.

2. Case Management: Cases could perhaps also be called 'investigations' or 'incidents', and they are also aligned to a specific organization. Access to cases can be restricted based on user privileges within that organization.

3. Global and Organization-Specific Settings: Certain settings, such as policies and evidence repositories, can be configured globally across all organizations or individually for each organization. This flexibility allows administrators to enforce global standards while still providing the ability to customize configurations at the organizational level when required.

This multi-tenant architecture in AIR enables organizations to operate independently within the same platform, benefiting from both shared resources and isolated environments, depending on their specific needs.

Real-Time User Online Status Indicators

User real-time status is shown throughout the AIR via colored dots—green for online, gray for offline—helping teams coordinate more effectively across the platform.

This live collaboration capability extends to the Investigation Hub where investigators can see real-time user presence, track comment updates, and observe evidence flag changes as they happen. These live updates allow multiple investigators to work simultaneously on the same evidence without needing to refresh the view. Every action—whether adding notes, updating findings, or adjusting flags—appears instantly for all connected users, creating a fully synchronized collaborative workspace within the Investigation Hub.

In the Investigation Hub screenshot above, you can see that three users are currently active in this case. Their profile icons indicate not only who is present, but also where each person is working in real time. In this example, one user is viewing the Findings page, another is focused on the System Info evidence, and a third is examining the Amcache File evidence. This provides instant visibility into team activity and helps avoid duplication of effort during collaborative investigations.

Responder

The AIR responder is a compact, cross-platform, zero-dependency, and zero-configuration package that functions as a virtual incident responder, delivering Level 3–4 SOC expertise directly to your assets.

Unlike 'agents' that constantly monitor systems and consume significant resources, AIR responders only activate to perform precise, user-defined DFIR tasks on demand. This approach enables the deployment of thousands of virtual responders across your IT ecosystem, ready to execute proactive and reactive incident response activities, such as evidence collection, threat hunting, and forensic-level analysis, as needed.

Binalyze's approach prioritizes efficient security enhancement, marrying minimal asset impact with maximum readiness and incident response capability. Read more here:

Task

Operations are assigned to the assets by the AIR console, either manually or automatically via a trigger. A task can be assigned to multiple assets, and this is managed through 'task assignments.' Each individual assignment, known as a 'task assignment,' creates a one-to-one correspondence between the task assigned by the console and the specific asset on which the task assignment is executed, ensuring precise management and tracking across all assigned tasks.

Tasks could be either:

1. Manual: Assigned manually by users,

2. Scheduled: Created by users to start at a future date. Scheduled tasks can be either one-time or recurring (daily, weekly, or monthly).

3. Triggered: Assigned to the assets as a response to a trigger request, which is sent by a SIEM/SOAR/EDR solution.

Triggers (Webhooks)

Triggers are the primary extensibility mechanism for AIR to receive alerts from other security suites, such as SIEM, SOAR, and EDRs.

A trigger is the combination of a parser, an acquisition profile, and a destination for saving the collected evidence (either local or remote).

AIR takes this to the next level by allowing the trigger to further automate the post-acquisition analysis by leveraging DRONE and MITRE&CK scanners. In effect, the alert from your security tools can launch AIR into the collection of relevant forensic data, facilitate the analysis of that data, and deliver any DFIR findings into the Intelligence Hub with no analyst intervention required.

Hunt/Triage

Hunt/Triage in AIR refers to searching for indicators of compromise—such as file hashes, processes, or malicious domains—across assets at scale. AIR provides built-in YARA, Sigma, and osquery capabilities, enabling analysts to detect anomalies in live systems, memory, and logs. Users can write their own rules or import large rule sets for rapid deployment, all of which are centrally stored and managed in the AIR Libraries to ensure consistency and collaboration across investigations.

Version Information

This section provides details on the versions of various components of the AIR platform, helping administrators ensure that all parts of the system are up to date.

1. AIR: The main application version (e.g., 4.41.1). This represents the core platform's release and includes the latest features and security updates.

2. DB (Database): The version of the database used by AIR (e.g., 6.0.7), which stores all data related to the platform’s tasks and configuration settings.

3. Responder: The version of the AIR responder (e.g., 2.50.5) installed on assets for data acquisition and remote interaction.

4. DRONE: The version of the DRONE analysis engine (e.g., 3.11.0), which processes collected evidence to deliver findings and insights on this and some live artifacts through automated analyzers.

5. TACTICAL: These versions indicate the status of various responders for different operating systems, including Linux, macOS, Windows, and the legacy version for older Windows systems. For example, the latest responders are at version 3.12.1, ensuring compatibility with the latest operating system environments.

6. MITRE ATT&CK Analyzer: This version (e.g., 7.0.0) refers to the built-in mapping against the MITRE ATT&CK framework, which helps identify adversary tactics, techniques, and procedures during investigations.

7. Disk Image Explorer: This component (e.g., version 1.0.0) provides functionality for exploring disk and volume images acquired during investigations.

Logging

1. Log Level: Determines the level of verbosity in logging within AIR. Adjusting the log level can help with debugging or tracking system activity.

2. Log Files: Provides access to the system's log files, which are helpful for auditing, troubleshooting, and reviewing system performance and security events.

License

This section provides details about the current licensing status of the AIR installation.

1. License Key: Displays the license key currently in use (e.g., TEST-LICENSE).

2. Valid Until: The expiration date of the license (e.g., 2025.09.29), indicating the duration for which the platform is licensed.

3. Max Client: The maximum number of assets (clients) that can be managed under this license (e.g., 1,000,000 assets).

4. In Use: The number of assets currently being monitored by AIR (e.g., 447,908 assets).

Connection

1. Console Address: This is the current address of the AIR Console (e.g., air-demo.ACME.com), where asset responders poll to check for any tasking assignments that require execution.

   • Important: Changing this address will trigger a migration process, which will cause all assets to connect to the new address while they are deregistered from the old one.

2. Console Proxy: Settings for configuring an internet proxy that AIR can use to connect to external services, such as updates or external evidence storage.

System Resources

Displays information about the system where AIR is installed, helping monitor and optimize performance.

1. CPU:

   • Cores: The number of processor cores (e.g., 8), indicating the processing power available for handling AIR tasks.

   • CPU Type: Details of the CPU model (e.g., Intel Xeon Processor, Skylake architecture).

   • Flags: A list of supported CPU features (e.g., SSE, HT, etc.), indicating hardware capabilities relevant to performance.

AIR provides a controlled and predictable update process for SaaS tenants by using maintenance windows. These windows allow you to define exactly when updates may occur, helping you align upgrades with organisational change-control processes and minimise operational impact.

All update settings are available from:

Settings → Update

Update Methods

Auto Update (Recurring Maintenance Window)

Auto Update allows AIR to automatically install new versions during a recurring update window that you configure.

When Auto Update is enabled, you can define:

Time Window

Select a 30-minute update window (e.g., 02:00–02:30 or 14:00–14:30 (Europe/Istanbul – UTC +03:00)).

Updates will only run within this defined window.

Days of the Week

Choose one or more days on which updates are permitted (e.g., Monday–Friday, Saturday only, or Wednesday).

At least one day must be selected.

How it works:

When a new version becomes available, AIR identifies the next selected day and applies the update during the time window you have configured.

One-time Scheduled Update

Use a One-time Scheduled Update when you want to apply the next update at a specific upcoming window outside your normal recurring schedule.

• When selected, AIR displays the next available maintenance windows.

• Choose your preferred window and save the configuration.

• The system will update once during that window and then revert to your existing Auto Update settings.

This option is ideal for:

• Alignment with a formal change-control event

• Situations where you want to temporarily override your regular update pattern

• Urgent updates that cannot wait for the next recurring window

Disabling Automatic Updates

If you wish to temporarily halt updates:

• Set Auto Update to off

• Ensure One-time Scheduled Update is not selected

Your tenant will not update until a new maintenance window is configured.

Update Status Information

The Update Settings page displays your current version, for example:

If an update has been scheduled, the page will show:

• The update version

• The scheduled maintenance window

• Any relevant notifications

Summary

AIR's SaaS update management offers:

• Controlled and predictable updates

• Recurring and one-time maintenance window options

• Full alignment with change-control practices

• Built-in automatic backups for safety

These controls ensure uninterrupted operation while keeping your environment consistently up-to-date.

Overview

Evidence: Brave Local Storage Description: Collect Brave Local Storage Category: Applications Platform: windows Short Name: bls Is Parsed: Yes Sent to Investigation Hub: Yes Collect File(s): No

Background

Browser local storage contains persistent key-value data stored by websites. This data includes user preferences, session state, cached data, and potentially authentication tokens or sensitive information.

Data Collected

This collector gathers structured data about brave local storage.

Brave Local Storage Data

Collection Method

This collector extracts local storage data from browser storage databases and files.

Forensic Value

Local storage analysis reveals stored credentials, session tokens, tracking identifiers, and application state that can indicate compromised accounts, persistent tracking, or malicious website activity. Analysts can identify credential theft, session hijacking, and data exfiltration attempts.

Responder Updates

Manage updates for the AIR responders installed on assets.

• This feature enables or disables automatic updates for responders. If enabled, the responders will automatically update to the latest version when a new release is available. This ensures that responders are always running the most current version, complete with all the latest features and security patches.

• Deployment Tokens: These tokens are used to securely install and register responders on new assets, ensuring the responders communicate correctly with the AIR Console upon installation.

Tamper Detection

Enable alerts for tampering attempts on responders.

• When Tamper Detection is enabled, the responder will actively monitor its own operation for any interference or attempts to disable it.

• Functionality: If there is an attempt to modify or interfere with the responder (e.g., by disabling it or altering its files), the responder will notify the AIR Console, ensuring that any malicious attempts are flagged immediately.

• This feature is critical for ensuring the integrity and continuous operation of responders in high-security environments.

Uninstallation Password

Prevent unauthorized uninstallation of responders by requiring a password.

• When this feature is enabled, users must enter a protection password to uninstall the responder from an asset. This prevents unauthorized personnel from removing the responder, which could otherwise leave the asset vulnerable or unmonitored.

• Uninstallation Method: The uninstallation process will be restricted to shell commands, meaning it can't be removed via a simple GUI or file system manipulation, adding an extra layer of security.

Active Directory (AD) Integration

Synchronize assets from Active Directory with AIR.

• This feature allows AIR to integrate with your Active Directory (AD) environment. You can specify the AD server (e.g., 10.0.0.1) and the domain (e.g., company.local) to automatically synchronize information about computers and users from AD into AIR.

• LDAP Synchronization: By manually starting the LDAP synchronization, you can query Active Directory for specific objects such as computers, ensuring that AIR can discover and manage assets from your organization's AD.

• The Query For Computers field (e.g., (&(objectCategory=computer))) uses an LDAP filter to query and sync only computer objects from the directory.

Jamf is a software company that supplies one of the most well-known and popular Mobile Device Management (MDM) software solutions used to manage Apple devices. Using Jamf, and following the steps below, you can silently grant full disk access to AIR responder's remotely.

Full Disk Access (FDA) on macOS can be activated by importing a Privacy Preferences Policy Control (PPPC) config file instead of manually providing permission options via the Jamf UI.

Why is FDA required?

AIR (and all other platforms) will only achieve complete macOS data acquisitions if FDA is enabled. Typically some of the artifacts that will give partial or no results if FDA is not active include:

• App Usage

• Bluetooth Connections

• Document Revisions

• Downloads

• DS_Store

• Notification Info

• TCC

A PPPC config file in macOS manages permissions for apps to access sensitive data and system features like Full Disk Access, camera, and microphone. It's used by organizations to pre-configure these permissions, often through MDM, ensuring necessary apps run without user prompts. These files are in .mobileconfig (XML) format and help balance security with convenience by automating privacy settings for applications.

Steps to follow:

1. Download and open the Jamf PPPC Utility:

2. From a MacBook where AIR is already installed, go to the path /opt/binalyze/air/agent, drag the "air" binary to PPPC Utility, and you will be able to see identifier details

3. In properties - "Full Disk Access" -> Choose "Allow"

4. Bottom right, Click "Save", and provide a Payload Name, for example, "AIR"

Now you can Import the saved config file into Jamf - Configuration Profiles.

Identifier and Identifier Type for importing the config created using PPPC utility to achieve FDA:

Verification of Full Disk Access:

• An entry is created in /Library/Application Support/com.apple.TCC/TCC.db for all the applications that were assigned FDA (Manual Install)

• For remote deployments, an entry is created in /Library/Application Support/com.apple.TCC/MDMOverrides.plist

• For practical verification, users should try to collect KnowledgeC evidence. Successful collection confirms that the responder has Full Disk Access.

• Reference:

Overview

Evidence: Brave Form History Description: Collect Brave Form History Category: Applications Platform: windows Short Name: bfh Is Parsed: Yes Sent to Investigation Hub: Yes Collect File(s): No

Background

Browser form history stores previously entered form data including search queries, usernames, and other input fields. This data reveals user search patterns, account information, and potential data leakage through autofill.

Data Collected

This collector gathers structured data about brave form history.

Brave Form History Data

Collection Method

This collector queries the browser's form history database to extract saved form field data, search queries, and associated timestamps.

Forensic Value

Form history exposes reconnaissance activities, credential enumeration attempts, search queries revealing attacker intent, and potentially sensitive information entered into web forms. Analysts can identify data exfiltration, account compromise indicators, and targeted search patterns.

Overview