Welcome to Binalyze AIR's Documentation

This document will guide you through all the features of Binalyze AIR.

Binalyze AIR is an Automated Investigation and Response platform that provides the most complete feature set for remotely collecting 680+ different evidential artifact types in minutes across multiple Operating Systems platforms. It’s lightning-fast and extremely easy to use.

AIR accelerates your investigation process via a comprehensive and integrated analyzer called DRONE. DRONE's findings for multiple assets are presented in a single pane of glass or Investigation Hub.

AIR will perform simultaneous 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 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 console is very simple to deploy, and thanks to it being Docker-based, it can easily be deployed on-premise or on a server in AWS or Azure Clouds.

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.

Components

Binalyze 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 triage 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

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:

Primary Communication Channels

• HTTPS (TCP 443) – The main communication channel from assets to the console (e.g., yourcompany.binalyze.io).

• WebSocket over HTTPS (TCP 443) – Used for interACT features.

• NATS (TCP 4222) (Optional) – Supports real-time task pushes to assets. If this port is unavailable, AIR defaults to HTTP(S) polling for task retrieval.

• DNS (UDP/TCP 53) – Required for name resolution services.

External Communication

• HTTPS to responder.cdn.binalyze.com – Used for responder updates and installation packages. If the CDN is unavailable, the AIR console acts as a fallback source.

Evidence Repository Communication (When Configured)

• Cloud Storage: HTTPS communication to services like Amazon S3 and Azure.

• Traditional Storage: Supported via SFTP, FTPS, or SMB.

Proxy Support

If a proxy is configured in your environment, assets can communicate using:

• HTTP

• HTTPS

• SOCKS5

Firewall Rules

• The console installer automatically adds inbound allow rules for the required ports in the Windows Firewall.

• The responder installer does not modify firewall settings. You must ensure that enterprise firewall policies allow assets to communicate with the console over the required ports.

How Does the AIR UI Connect?

The AIR user interface (UI) requires access to the following domains:

• https://binalyze.com

• https://cdn.binalyze.com

• https://one.binalyze.com

• https://kb.binalyze.com

• https://www.googletagmanager.com

Domain Functions:

Data Transmitted:

Acquisition Profile

A group of evidence types, application artifacts, and custom content items. There are acquisition profiles provided 'out-of-box' but you can also create additional ones by visiting "Integrations" in the Main Menu.

AIR Console

AIR has a web-based management interface that allows you to efficiently manage assets and assign tasks. Users can customize their experience by switching between light and dark modes from the main AIR menu, enhancing usability and overall satisfaction.

Asset and Asset Status

In Binalyze 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 Binalyze AIR performs various actions, including evidence collection and task execution, crucial for responding to and hunting cyber threats. Examples of assets encompass 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.

   • Unreachable with No Data: The asset has been disconnected from the AIR console for over 30 days (Unreachable), and there is no stored forensic data from that asset in the AIR console.

3. Off-Network: An asset is classified as Off-Network under two specific scenarios:

   • Data Supplied: The asset has previously provided data through methods such as an Off-Network Acquisition or Triage task.

   • Unreachable with Stored Data: The asset holds forensic data within the console but is currently inaccessible for further data collection or task assignments.

   For both scenarios, investigation of the existing data is possible, and additional data can be manually imported as required.

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 Binalyze 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: The asset is currently isolated from the network apart from communication with the AIR console only.

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.

Evidence Item or Artifact?

Evidence Item:

In the context of Binalyze AIR and cybersecurity generally, an evidence item refers to data extracted from various components of a computer operating system and associated system areas crucial for recording, managing, or operating the system. These items often produce digital evidence that can be analyzed to uncover details of user activity and potential security incidents or anomalies.

Artifact:

On the other hand, in Binalyze AIR, artifacts are files produced by applications during their execution. These files contain valuable information about the activities performed by the application, including logs, configuration files, temporary files, and other artifacts of potential interest for forensic analysis and investigation.

Evidence Repository

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

1. SMB

2. SFTP

3. FTPS

4. Amazon S3

5. Azure Blob

6. Network Shares

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.

Organizations

In Binalyze 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​​.

4. Policies and Evidence Repositories: Policies can be applied either globally or on an organization-by-organization basis. For example, evidence repositories, which store collected data, can be aligned to all organizations (global) or set up uniquely for each organization, allowing for localized data control​.

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

Responder

The AIR responder is a streamlined 40MB standalone package that brings the expertise of level 3 and 4 analysts directly to your digital 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 allows for deploying 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.

Task

Operations that 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 in the future. Scheduled tasks could either be one-time or recurring (daily/weekly/monthly).

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

Triggers (Webhooks)

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

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

Binalyze 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. So in effect, the alert from your security tools can launch AIR into the collection of relevant forensic data, the analysis of that data, and the delivery of any DFIR findings into the Intelligence Hub with no analyst intervention whatsoever.

Triage

Searching for pieces of evidence such as a file hash, process, or malicious domain at scale. AIR provides you with 'out-of-box' examples for YARA, Sigma, and osquery, making it fast and easy to start sweeping your environment.

Introduction

In today's dynamic digital environment, managing tasks efficiently within a software system is crucial for reliability, flexibility, and optimal performance. This guide delves into a sophisticated task management system designed to handle a wide array 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, the assignment of 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 adopts a first-in-first-out (FIFO) queue model for task execution. This model guarantees that tasks are processed in the order received, with special considerations for 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 the management of tasking 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 there is a failure, 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 the efficient cleanup of local data related to completed or failed tasks. This function is integral to maintaining optimal disk space usage and system resource allocation.

System Flexibility and Customer Policies

This guide underscores the necessity of a flexible system capable of adapting to varied 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 provides an in-depth look at the technical underpinnings of the system, including the use 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 like 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.

Investigators and analysts can use the Binalyze AIR DFIR Platform to perform DFIR activities on the machines located in the cloud platforms. Binalyze AIR DFIR Platform supports cloud virtual machines like on-premise and off-network devices. Investigators and analysts can install Binalyze AIR responders on virtual machines located on the cloud infrastructure for investigations and analysis. Amazon Web Services and Microsoft Azure are supported.

With Binalyze, investigators and analysts can easily and quickly deploy Binalyze AIR to their cloud assets and immediately start to make investigations, compromise assessments, and hunting activities. By taking the automation advantages of the cloud platforms, users can easily deploy many responders only using one authorized cloud platform account.

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

Add Authorized User

Since different cloud platforms use different identity and access management infrastructures and have different working mechanisms, their requirements may differ however, ultimately, all we need is an authorized account with list and control permissions on cloud assets.

Investigators and analysts can add a cloud account to the Binalyze AIR Console by using the Assets page:

1. From the Main menu select Assets

2. Click Add New and click Cloud Account

3. Then click the Add Account button according to the cloud platform you want to add on the appearing Cloud Platforms window

The configurations that need to be performed according to the cloud platforms are listed below.

Amazon Web Services Compute EC2

Either of the two different ways mentioned above will redirect investigators and analysts to similar pages, allowing them to enter account details. They can either enter their existing account details, which are given below, or use the cloud formation link provided by Binalyze AIR to create a new account with enough permissions.

Cloud account needs the following permissions to deploy virtual machines Binalyze AIR responder.

The creation of an AWS Account with sufficient permissions flow is explained below.

1. Click on the URL and Create an Account

2. Open AWS Console -> IAM -> Users

3. Select the User -> Security Credentials -> Create Access Key

4. Fill out the Account Details Form

Microsoft Azure Virtual Machines

Either two different ways mentioned above will redirect investigators and analysts to similar pages allowing them to enter account details. They can either enter their existing account details, which are given below or create a new account with enough permissions.

Cloud account needs the following permissions to deploy virtual machines Binalyze AIR responder.

The creation of an Azure Account with sufficient permissions flow is explained below.

1. Azure portal -> App Registrations -> New Registration

2. Assign required roles to the new app registration for the subscription

3. App Registrations -> Open the created App Registration

4. Certificates & Secrets -> Create a new client secret

5. Fill out the Account Details Form

Google Cloud Platform

Coming soon

Synchronization and Enumeration

Binalyze AIR Console immediately starts to enumerate the cloud platform and pulls the assets list and assets details after the cloud account addition. It discovers the assets depending on the permissions and authorizations of the cloud accounts. All discovered assets will be shown under the Amazon AWS category under the associated organization.

The assets and their details are shown on the right side of the Secondary Menu in the Assets page as a list. Assets in which the Binalyze AIR responder is deployed are shown in blue, and the assets in which the Binalyze AIR responder is not deployed are shown in grey in that list.

Responder Deployment

All deployment actions are considered tasks by the Binalyze AIR Console and listed under the Tasks as responder Deployment tasks. Therefore, all responder deployment actions and their status can be seen on the Tasks list.

The primary advantage of responder deployment in a cloud platform is automation. Analysts and investigators don't need to choose the operating systems and their versions. They only assign deployment tasks to the associated devices, and all deployment processes are performed quicker and easier automatically.

Investigators and analysts can deploy Binalyze AIR responders to cloud assets by using the Endpoint page:

1. From Assets in the Main Menu: All cloud assets are listed here in the Secondary Menu. Investigators and analysts can search, filter and see the details of the assets on this page.

2. Investigators and analysts can deploy the responders individually, with multiple selections or all of them with one click.

   1. Individual deploy: Click the assets and then click the Deploy button

   2. Multiple selections: Select the assets in the list by clicking a checkbox at the beginning of the asset line. Then Actions button immediately appears at the top of the page. Click Deploy Responder the under the Actions menu.

   3. Deploy to All Assets: Click the three-dot on the right side of the Amazon AWS or Tag, which includes associated cloud assets. Then click Deploy Responder

Supported Distributions (x64 only)

• Debian Bookworm 12 (stable)

• Debian Bullseye 11 (oldstable)

• Ubuntu Lunar 23.04

• Ubuntu Kinetic 22.10

• Ubuntu Jammy 22.04 (LTS)

• Ubuntu Focal 20.04 (LTS)

• Red Hat Enterprise Linux 7 on s390x (IBM Z)

• Red Hat Enterprise Linux 8 on s390x (IBM Z)

• Red Hat Enterprise Linux 9 on s390x (IBM Z)

• CentOS 7

• CentOS 8 (stream)

• CentOS 9 (stream)

• Fedora 37

• Fedora 38

Deployment Models

You can deploy AIR in one of two models:

Installation

Before you start

• Make sure you have updated package repositories of the Operating System you are using. Please find below the commands for CentOS and Ubuntu:

For CentOS:

For Ubuntu:

• Start and enable docker service by executing the following command:

Single-Tier Deployment

This deployment model installs all components into a single machine.

Method 1: Quick Deployment (preferred method)

1. Run the one-liner below and wait for it to complete

Method 2: Manual Deployment (use only when required)

1. Create a folder for the Binalyze AIR under /opt directory and cd into it
2. Download the docker-compose.yml file and save it
3. Create the directory for the database volume with defined access:
4. Create environment variables:
5. Run the following command to start the Binalyze AIR installation in docker:
6. Wait for the installation to complete. It may take several minutes

2-Tier Deployment

This deployment model requires you to deploy the Database Component first (Step 1) and then start the deployment of the Console Server (Step 2) by pointing to the database server's address.

Method 1: Quick Deployment (preferred method)

1. Run the one-liner below and wait for it to complete (this script will deploy the database component - Step 1)
2. Once the database is deployed, the above script will output the commands that need to be executed on the Console Server machine (Step 2)

3. SSH into the Console Server machine

4. Run the commands provided by the above script and wait for it to complete

Method 2: Manual Deployment (use only when required)

1. SSH into the Database Server

2. Create a folder for the Binalyze AIR DB under /opt directory and cd into it
3. Download the docker compose.yml file and save it
4. Create the directory for the database volume with defined access:
5. Create environment variables
6. Run the following command to start the Binalyze AIR Database component in Docker:
7. Wait for the installation to complete. It may take several minutes.

8. Proceed to the installation of the Console Server

1. SSH into the Console Server

2. Create a folder for the Binalyze AIR under /opt directory and cd into it
3. Download the docker-compose.yml file and save it
4. Create the directory for the volume of the services with defined access:
5. Set the database URI for connecting the Console Server to the DB IMPORTANT: You must fill in the values ​​of the following three variables. We need the passwords created on the DB server and the DB server IP address. You can find the passwords in the /opt/binalyze-air-db/.env file on the DB Server.
6. Run the following command to start Binalyze AIR installation in docker
7. Wait for the installation to complete. It may take several minutes

Finalizing Setup

Regardless of the deployment model you chose, you will be asked for several configurations at the end of the deployment, such as an organization name, the credentials of the first user account, etc.

Once you have completed the above steps successfully, you should:

1. Visit http://IP-ADDRESS for accessing the Console (IP address here is the public IP address of the machine you have deployed Binalyze AIR)

2. Accept EULA and provide the configuration you are asked for in each step

3. Complete the setup and login using the credentials you have provided

4. Enjoy Binalyze AIR!

Minimum Requirements

Below are the minimum hardware requirements for AIR components:

Single Tier Deployment - Server (Console & DB)

2-Tier Deployment

Console Server

Database Server

Cloud Platform Counterparts

Cloud Platform systems that meet the relevant hardware requirements are outlined below:

Single Tier Deployment - Server (Console & DB)

2-Tier Deployment

Console Server

Database Server

Secure and Efficient Setup for AIR Console and Database Servers

1. Assign Static IP Addresses

   • Ensure each server running the AIR Console and Database is assigned a static IP address to maintain a stable network connection.

2. Configure Ports for Initial and Ongoing Access

   • Port 80 (HTTP): Only enabled for initial configuration access through the user interface (UI). This allows for system setup upon installation.

   • Port 443 (HTTPS): After initial setup, use this port permanently for all administrative access. It provides a secure, encrypted connection for managing the AIR Console UI.

3. Additional Port Configuration for Responders

   • Port 443 (HTTPS): Keep open for secure communication and ongoing operations.

   • Port 4222 (NATS.io): Enable to allow inbound traffic for asset responders using NATS.io, facilitating effective communication across distributed systems.

4. 2-Tier Deployment Specific Configuration

   • Allow inbound access from the AIR Console server to the MongoDB Server on:

     • 27017 (MongoDB)

     • 5432 (PostgreSQL)

5. Internet Access for Essential Domains (2-Tier Deployment on AIR Console Server Only)

   • Allow access to the following domains:

     • https://binalyze.com

     • https://license.binalyze.com

     • https://api.binalyze.com

     • https://cdn.binalyze.com

     • https://one.binalyze.com

     • https://cr.binalyze.com

     • *.docker.com

6. Additional Optional Steps

   • If you're using EDR/XDR or EPP software along with Binalyze, please take a look at our exclusion/exception rules page.

   • (Optional) Create an SSL certificate for the provided Static IP Address or FQDN.

   • (Optional) Allow inbound access for alternative secure access to the web UI on the AIR Console server on:

     • 8443 (HTTPS) inbound

   • (Optional) Create a password-protected network share on the server.

   • (Optional) Create an Active Directory user for Binalyze AIR to enumerate LDAP computers on your network. This account should have limited rights, sufficient only to enumerate computers, and not hold privileged status like a Domain Admin.

This structured approach ensures that every step and detail is laid out clearly, making it easier to follow and implement for a secure and efficient server setup.

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.

Considerations for Relay Server Setup:

• Public IP Requirement:

  • The need for a public IP address for the Relay Server depends on its intended use and positioning.

  • If the Relay Server is set up for internet-facing properties, a public IP address or a Fully Qualified Domain Name (FQDN) might be required.

  • For a Relay Server intended for internal network entities, a public IP address is not necessary.

• Use Case for Managed Security Service Providers (MSSPs):

  • In scenarios where the Relay Server is used by MSSPs for external entities, it is likely that a public IP or FQDN will be needed.

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:

• Debian 7 and above

• RHEL (Red Hat Enterprise Linux) 7 and above

• CentOS 7 and above

• Fedora 21 and above

• Ubuntu 14.04 and above

• Pardus 17 and above

Please note that this list may be subject to updates, and you can always refer to the download page and click on "See Supported Versions" for the most up-to-date information on supported systems.

Additionally, for Relay Server to function properly, a responder must be installed and registered. The responder acts as the intermediary between the Relay Server and the AIR Console, which serves as the management interface for controlling Relay Server's operations. The seamless interaction between the responder and AIR Console facilitates efficient management of the Relay Server's functionalities.

1. App Registration

The application registration process creates an identity for your instance in Azure AD, enabling it to authenticate and access resources securely.

1. Go to Microsoft Entra ID Directory and select Overview. Keep the "Tenant ID" information for the field required in the Azure Integration configuration page.

2. Navigate to Manage > App Registrations and click New Registration.

1. Name the application, select the account type, and click the Register button.

2. In the Overview section, note the "Application (client) ID" for the field required in the Azure Integration configuration page.

3. Navigate to Certificates & Secrets and click New client secret.

1. Provide a description, select the expiration period click Add.

1. Note the value for the "Key (Client Secret)" information for the field required in the Azure Integration configuration page.

2. Role Assignment for the Subscription

Assigning roles to the registered application ensures it has the necessary permissions to access and manage the resources within the selected Azure subscription.

1. Go to Subscriptions and select the subscription from the list.

2. In the Overview section, note the "Subscription ID" information for the field required in the Azure Integration configuration page.

3. Navigate to Access control (IAM), click Add, and select Add role assignment.

4. To add Reader roles to the registered application:

   • Select Reader from the job function roles list and click Next.

   • Select Assign access to > User, group, or service principal.

   • Click Select members, search for the registered application's name, and select it.

   • Click Review + Assign.

5. To add Contributor roles to the registered application:

   • Select Contributor from the privileged administrator roles list and click Next.

   • Select Assign access to > User, group, or service principal.

   • Click Select members, search for the registered application's name, and select it.

   • Click Review + Assign.

1. Now make sure that the roles Reader and Contributors are assigned to the application in the Role Assignment list.

3. Final Steps

This final step involves entering the collected information into the AIR Console UI, which will integrate the application with Azure, allowing it to operate within your Azure environment.

1. Go to the AIR Console UI and enter all the required information on the Azure Integration configuration page.

1. Click the Save button.

1. As a final task, make sure that the Account is listed in the Microsoft Azure cloud integrations list.

What is an AIR responder?

The AIR responder, a 40MB standalone package, acts as a virtual incident responder, delivering SOC level 3-4 expertise to your assets for unmatched cyber resilience and readiness. It interfaces with the AIR console for executing precise, user-defined tasks, providing wide-ranging coverage with minimal resource use, bypassing the need for constant monitoring.

The AIR responder maintains regular communication with the AIR Console via what in its simplest form is known as HTTP polling, and what we like to call, ‘a visit’. The visit interval is normally about 30 seconds for environments with fewer than 1000 assets. For larger environments, the interval is calculated using the following formula:

intervalSeconds = MANAGED_ENDPOINT_COUNT / 100

For instance, in a scenario with 5000 assets, the calculated visit interval would be 50 seconds.

The responder sends these visit requests to tell the AIR console that it is online and ready to receive any task assignments that are awaiting actioning.

If the responder does not make a visit at the required interval, it will be shown as offline in the AIR console.

If the responder does not make a visit for 30 days, it will be marked as unreachable. This status will immediately be fixed once the asset is back online.

If a task assignment is not collected by the responder within 30 days of its creation, it will expire and will not be actioned even when the asset reconnects and the responder visits next.

How does the AIR responder work?

Simply put, when the AIR responder collects a task assignment from the AIR console, it carries out the task and provides a report back to the AIR console upon completion. On the other hand, when the AIR responder is in an idle state, it periodically (as discussed above) sends visit requests to the AIR console, checking if any new tasks have been assigned to it. During these visit requests, the AIR responder only checks for task assignments and does not perform any other operations.

The AIR responder is capable of executing various tasks when assigned by the AIR Console. These tasks include:

• Acquisition

• Triage scanning (YARA, Sigma, osquery, MITRE ATT&CK)

• Isolation

• interACT sessions

• Auto Tagging

• Disk/Volume Imaging

• Investigation (Timeline)

• Baseline

• Log Retrieval

• Certificate Authority Update

• Migration

• Reboot

• Shutdown

• Update

• Uninstall

Both the Acquisition and Disk Image tasks support the ability to upload collected evidence to external repositories such as Amazon S3, Azure Blob Storage, FTPS, SFTP, and SMB. These tasks enable the AIR responder to securely transfer the acquired evidence or disk images to the designated repositories for storage and further analysis.

By utilizing the supported protocols and repositories, the AIR responder ensures that the collected evidence or disk images are safely transmitted and stored in the desired locations. This allows for efficient storage, accessibility, and collaboration, making it easier to manage and analyze the acquired data in a secure and scalable manner.

AIR has an option for the Windows, macOS, and Linux AIR responders to transmit evidential collections directly to external evidence repositories, thereby efficiently minimizing the utilization of local disk space:

How is the AIR responder secured?

The AIR responder maintains robust security by implementing a range of measures including:

Encrypted Traffic: The traffic between the AIR responder and the AIR Console, as well as between the AIR responder and any evidence repositories, is encrypted with TLS 1.2 and TLS 1.3 if available on the server. If neither of these two TLS protocols is available, the connection will not be established. This ensures that data in transit is protected against interception and unauthorized access.

Communication: The AIR Console does not initiate the sending of task assignments to the AIR responder; rather, it is the AIR responder that initiates the interaction by asking the AIR Console if it has any tasking assignments ready for it to run. This approach significantly reduces the risk of various security attacks, as it controls the communication flow and reduces the AIR responder's exposure to external threats.

Privileged Account Usage: On macOS and Linux, the AIR responder uses the root account, while on Windows, it uses the system account. This level of access control makes it difficult for other users to tamper with the application, thereby enhancing its security.

Regular Internal Penetration Testing: Before every release, our internal penetration test security team conducts thorough penetration testing. This proactive approach helps identify and mitigate potential vulnerabilities.

Secure Libraries and Third-Party Applications: We consistently use updated and vulnerability-free libraries and third-party applications. This precaution in maintaining up-to-date software components protects against known security vulnerabilities.

Supply Chain Attack Prevention: Measures are in place to protect against supply chain attacks, and these are continuously improved by our DevOps team. This is crucial to prevent threats that could compromise the software development and deployment process.

Continuous Source Code Scanning: The source code is regularly scanned by security tools. This constant monitoring helps to quickly identify and resolve any security issues that arise in the codebase.

Digital Signing: The use of digital signatures adds a layer of security, ensuring the authenticity and integrity of our software. This helps to prevent tampering and to verify that the software has not been altered after it was signed.

Blackbox Analysis: The binary undergoes Blackbox analysis, a method of testing the software’s external functioning without delving into its internal structure. This type of analysis has been performed on the AIR responder. It helps in identifying security vulnerabilities from an outsider’s perspective, providing a critical view of the system's external defenses.

Graybox Analysis: For the AIR responder project, Graybox analysis has been conducted. This testing method combines both the internal and external examination of the software, providing a more comprehensive security overview.

Are databases used by the AIR responder?

Functioning like a server application, the AIR responder does not use databases. Rather, it operates by saving reports as individual files using SQLite. These reports are subsequently forwarded to the AIR Console. This approach simplifies the data handling process, enabling the efficient and secure storage and transfer of information.

What is the Binalyze design process?

We continuously advance our development process by implementing the SCRUM methodology, complemented by unit and integration testing. The use of both unit and integration testing is crucial for maintaining high-quality standards and ensuring that each component of our product functions seamlessly individually and as part of the whole system.

Resource monitoring for the AIR responder

After the initial installation, it is normal to observe a small amount of memory being allocated, typically around 30MB to 40MB, with no significant CPU or disk usage during idle states. This behavior is expected and can be attributed to the necessary resources required for the AIR responder to function properly.

During idle states, the AIR responder remains in standby mode, pending its next call to the Console to collect any new tasking assignments. The allocated memory is utilized to maintain the AIR responder's core functionality and to ensure prompt responsiveness when new tasks are assigned.

When the AIR responder receives an acquisition task, the evidence collection process is carried out by a sub-process called Tactical (or Incident Response Evidence Collector on Windows). During the acquisition process, it is normal to observe increased CPU and memory usage as the Tactical sub-process actively collects and processes the evidence.

The increase in CPU and memory usage is a result of the intensive data gathering and analysis performed by the Tactical sub-process. It utilizes system resources to efficiently capture and process the required evidence, ensuring the integrity and completeness of the collected data.

The extent of CPU and memory usage during the acquisition task may vary depending on factors such as the size and complexity of the evidence being collected. Once the acquisition is completed, the CPU and memory usage will typically return to normal levels, reflecting the completion of the resource-intensive task.

A Triage task does not involve running the Tactical sub-process for evidence collection. Instead, the Triage task is executed within the AIR responder, utilizing its internal capabilities to analyze and evaluate the collected data.

While the CPU usage for a Triage task may typically be low, it is still possible to set a CPU policy for the Triage task.

The log file of the running AIR responder provides valuable information about CPU usage, memory usage, and other system resources. Here is an example of the log entries about system and service resources:

1. INFO 2024-01-04 18:45:25+03:00 2.31.2 triage: resmon: SysStats{GoHeapAlloc: 2.3 MB, GoHeapSys: 12 MB, NumGoroutines: 27, NumCPU: 16} file:pkg/resmon/handlers.go:16 func:resmon.(*LoggingStatsHandler).HandleSysStats

2. INFO 2024-01-04 18:45:26+03:00 2.31.2 triage: resmon: PidStats{PID: 9460, Name: AIR.exe, CPU: 14.7%, AvgCPU: 25.9%, Mem: 56 MB, NumFDs: 341, NumCPU: 16} file:pkg/resmon/handlers.go:21 func:resmon.(*LoggingStatsHandler).HandlePidStats

The log file for the AIR responder can be found at the following location:

C:\Program Files (x86)\Binalyze\AIR\agent\AIR.log.txt

You can navigate this path on your system to access the log file and view the relevant information about CPU usage, memory usage, and other resources as logged by the AIR responder during its operation.

Similar scenarios can be observed on macOS with the built-in Activity Monitor application. To access detailed process information, simply click on the (i) button within the Activity Monitor.

On Linux, an alternative option for resource monitoring is to use htop instead of the built-in app top. The htop option offers enhanced capabilities and can be installed by following these steps:

1. Open the terminal.

2. Run the command: sudo apt-get install htop (for Ubuntu/Debian-based distributions) or sudo yum install htop (for CentOS/Fedora-based distributions).

3. Once installed, type htop in the terminal and press Enter to launch the application.

Using htop provides a more comprehensive and user-friendly interface for monitoring system resources on Linux.

Resource Monitoring with resmon

There is also a CLI tool named resmon specifically developed for internal usage. It can be used to gather resource usage data related to the AIR responder and its subprocesses, storing them in a local database.

By default, resmon will monitor the AIR responder if no flags are given. However, you can monitor other processes by providing a PID flag or a process name flag. For more detailed information on its usage, a usage document for resmon can be provided upon request.

The information collected by resmon is stored in a local database, which includes numerous entries for the monitored process and its subprocesses. Due to the abundance of entries with comprehensive details, reading and interpreting the data can be challenging.

To address this, a script has been developed alongside resmon to visualize these outputs. It displays the CPU and memory usage of the processes (including subprocesses) monitored by resmon in a graphical format.

In the following section, we will share the resmon results as it monitored various task assignments being executed by the AIR responder. Throughout the tasks, resmon will continuously monitor the AIR responder and its subprocesses, generating a comprehensive local database that captures the output of resource monitoring.

For easy visualization, we will utilize a feature of a resmon designed to focus on visualizing its output by presenting the CPU and memory usage in intuitive graphical representations. These visualizations provide valuable insights into the resource utilization of the AIR responder and its subprocesses from the beginning to the end of each tasking assignment.

Analysis of an Acquisition Task

Below, you will find two graphs illustrating the CPU and Memory usage of the AIR responder. These graphs represent the resource utilization from the moment an acquisition task is started through to its completion.

Analysis of an Acquisition Task (with CPU limit of 50%)

In this scenario, we will examine the CPU and Memory usage of the AIR responder while running tasks received from the AIR Console, with a specific condition: the CPU usage of the AIR responder is limited to 50%.

The visualized graphs provided below depict the resource utilization, specifically focusing on the CPU and Memory usage of the AIR responder. These graphs showcase the performance of the AIR responder, highlighting its ability to effectively manage the CPU allocation while carrying out tasks received from the AIR Console.

Analysis of a Triage Task

Let’s examine the resource usage of the AIR responder when a Triage task is received from the AIR Console.

Analysis of a Triage Task (with CPU limit of 50%)

Similar to an acquisition task, a Triage task can also be configured with a CPU limit for executing the AIR responder. The following graphs illustrate the resource usage of a Triage task running with a CPU limit of 50%.

Before deploying a new endpoint 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 endpoints 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.

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:

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.

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:

sudo systemctl start Binalyze.AIR.Relay.service

To stop the service:

sudo systemctl stop Binalyze.AIR.Relay.service

To restart the service:

sudo systemctl restart Binalyze.AIR.Relay.service

Relay Server provides support for reloading its configuration file without the need to restart the service. You can accomplish this by executing the following systemctl command:

sudo systemctl reload Binalyze.AIR.Relay.service

By running this command, any changes made to the Relay Server's configuration file will be applied without requiring a full restart of the service. This allows you to update the configuration manually and have the new settings take effect immediately.

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:

Whitelist:
  - testpage.com
  - test.binalyze.com
  - 10.5.2.1
  - *.google.com
  - 10.2.5.1/24
  - 10.2.5.3-10.2.5.16

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.

• IP range: Indicate the range of IP addresses using a hyphen (-) between the start and end IP addresses.

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:

sudo systemctl reload Binalyze.AIR.Relay.service

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:

sudo systemctl restart Binalyze.AIR.Relay.service

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.

Alternatively, you can refer to the following files located in the Relay Server directory:

• /opt/binalyze/air/relay/air_relay.log.txt

• /opt/binalyze/air/relay/air_relay.process.log.txt

These log files contain valuable information that can assist in diagnosing issues, identifying errors, and understanding the overall behavior of the Relay Server. By reviewing the logs, you can gain insights into the operations and events occurring within the Relay Server environment.

Multiple options can be selected.

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:

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:

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

When deploying a new responder to an asset, you will encounter a new configuration where you can 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 "Relay Server Connection," you will be presented with a list of registered Relay Servers associated with this organization. From this list, you can select one and proceed with the configuration.

The subsequent steps remain the same 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. If you wish to modify the connection routing of your assets, you can do so on 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 (Organization of the assets you want to update) 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.

• 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

• Boss Linux 7

• Boss Linux 8 (failed the off-network tests and is still being worked on. It passed the triage, direct collection, and acquisition tests)

• Boss Linux 9

• Boss Linux 10

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

• macOS 10.15

• macOS 11.0

• macOS 12.0

• macOS 13.0

• macOS 14.0

• macOS 15.0

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

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

It basically cleans some configuration options set during registration and then disables and stops the AIR 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.

Windows:

"C:\Program Files (x86)\Binalyze\AIR\agent\AIR.exe" configure --prepare-golden-image

Linux/macOS:

/opt/binalyze/air/agent/air configure --prepare-golden-image

This flag does the following:

• Stops the service.

• Disables the service.

• Cleans the RegisteredTo, SecurityToken, and EndpointID fields in the config.yml.

• Uninstalls the watchdog (if tamper detection was enabled)

--init-golden-image

This flag activates the responder again after the golden image is up and after the hostname is changed.

Windows:

"C:\Program Files (x86)\Binalyze\AIR\agent\AIR.exe" configure --init-golden-image --deployment-token 769aca0ff45a433a --console-address air-qa.binalyze.com --organization-id 0

Linux/macOS:

/opt/binalyze/air/agent/air configure --init-golden-image --deployment-token 769aca0ff45a433a --console-address air-qa.binalyze.com --organization-id 0

Note: The use of --deployment-token is required. Because the deployment token is clean after the registration of the AIR responder. The use of --console-address and --organization-id is optional. They are used to overwrite the console address and organization ID, which are already set in the configuration file at the first installation before the image was taken.

This flag does the following:

• Updates the DeploymentToken, ConsoleAddress, and OrganizationID values entered as a command in the config.yml.

• Starts the service.

• Enables the service.

• Watchdog is installed automatically after registration if it is enabled by AIR Console.

Troubleshooting

Exit code other than 0 (zero) means an error occurred while executing commands. The terminal will print the error messages, and the log file will contain the error messages.

If something goes wrong, the first option is to re-run the same command.

If a re-run of the command doesn’t succeed, the user should perform the same steps manually.

Chrome 90+

• Minimum of 2 GB of RAM.

• Minimum of 2 GB of free disk space.

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. Limitation and Requests:

   • As of now, AIR does not support querying or installing Responders directly at specific OU levels (e.g., SecurityTesting.Binalyze.local) beyond the root AD level (e.g., binalyze.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.

Binalyze AIR Watchdog Folder:

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

The Binalyze AIR Watchdog Folder (C:\ProgramData\.binalyze-air\ or %ProgramData%\.binalyze-air\) is a critical directory used by the Binalyze 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 Binalyze 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 Binalyze 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 is continuously running and can self-correct when issues arise. Blocking access to or deleting files from this folder could disrupt the AIR responder's ability to perform its monitoring tasks, leading to downtime and delayed investigations.

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 Binalyze AIR remains resilient and responsive, even in the event of unexpected issues.

Why Create Exception Rules for Binalyze AIR in EDR/AV Systems

Binalyze AIR operates by collecting and analyzing extensive forensic data from assets. This process involves the execution of binaries, the creation of temporary files, and access to sensitive directories—activities that can trigger alarms in EDR or AV solutions, potentially disrupting or slowing down forensic investigations. If these tools block AIR components, it could lead to incomplete evidence acquisition or delays in incident response, thereby compromising the effectiveness of your cybersecurity activities.

Allow-listing Binalyze AIR components ensure that AIR can perform its essential tasks without interference, enabling fast, efficient investigations. By setting up proper exception rules in your security systems, you guarantee uninterrupted access to all evidence and forensic capabilities that AIR offers.

How to Configure EDR and AV Exceptions for Binalyze AIR

For optimal performance, configure your EDR and AV systems to exclude specific AIR folders and binary files. The paths and binaries to exclude vary by operating system:

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

• %ProgramData%.binalyze-air\WATCHDOG.exe

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

• C:\Program Files (x86)\Binalyze\AIR\agent\utils\osqueryi.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

• /opt/binalyze/air/agent/utils/osqueryi

• /opt/binalyze/air/agent/utils/curl

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

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

• /opt/binalyze/air/agent/utils/osqueryi

• /opt/binalyze/air/agent/utils/curl

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

Are you encountering security warnings when accessing AIR? Let's demystify the process of changing SSL certificates in Binalyze AIR to ensure seamless and secure connections.

Understanding Self-Signed Certificates:

Many users wonder why they receive security warnings when accessing AIR. These warnings often stem from the use of self-signed certificates, which are SSL certificates created without a certificate authority. While self-signed certificates offer convenience, they lack the validation provided by certificate authorities, leading to "untrusted" status in browsers.

Navigating CSR and Certificate Authorities:

To obtain SSL/TLS certificates, organizations generate Certificate Signing Requests (CSRs) and submit them to certificate authorities (CAs) for validation. However, Binalyze AIR does not handle CSRs due to identity verification complexities and associated fees. Instead, users are encouraged to create CSRs using tools like OpenSSL and obtain certificates from trusted CAs.

Importing Certificates into Binalyze AIR:

To import corporate or self-signed certificates into Binalyze AIR, users must establish the certificate chain, including the certificate itself, intermediate certificate, and root certificate. This process can be accomplished using a text editor and imported via the user interface.

Clarifying Common Queries:

Properly posed questions, such as "How can I import my corporate certificate to AIR?" or "How can I upload my self-signed certificate to AIR?" help streamline the process. The answer lies in establishing the certificate chain and ensuring inclusion in clients' trusted root-certificates section for self-signed certificates.

Final Thoughts:

While SSL certificate management may seem complex, the tasks involved are straightforward. Support engineers need not possess extensive SSL knowledge, and consulting system administrator is always recommended for SSL-related tasks. By understanding these fundamentals, users can navigate SSL certificate changes with confidence in Binalyze AIR.

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.

Installation of the AIR Responder on your assets is managed via the Assets button in the Main Menu:

The AIR Responder installer is a zero-configuration package that contains the console address already embedded in it.

You can deploy the AIR Responder in multiple ways:

1. Downloading an installation package (Windows, macOS, Linux, Chrome and ESXi)

2. Copying a PowerShell Command (Windows)

3. Copying a CURL Command (macOS and Linux)

4. Copying a WGET Command (macOS and Linux)

5. Downloading a PowerShell Script (Windows)

6. Downloading the Asset installer (macOS and Linux)

7. Manual installation via Active Directory/SCCM.

8. Generation of a shareable Deployment Link (Windows, macOS, Linux, Chrome and ESXi)

In the sections that follow, we will look at the deployment of AIR Responders to Windows, Linux and Mac operating systems.

The AIR Responder is a ‘zero-config’ deployment as the file name has all the information you need for quickly deploying a Responder.

This level of detail in the filename provides all the information needed as a digitally signed binary - this prevents issues with security solutions and to date, not one issue has arisen.

The file name example shown here has 4 main components:

AIR.Responder_2.38.7_air-demo.binalyze.com_176_9df51c56a73341f4_386_.msi

1. 2.38.7 - is the Responder version number.

2. air-demo.binalyze.com - is the address of the console with which the Responder will be communicating

3. 176 - is the console's internal organization number ID.

4. And the apparently random mixture of letters and numbers, 9df51c56a73341f4, is the - Deployment Token.

5. 386 - describes the processor architecture of the machine on which the Responder will run.

There are multiple ways of deploying the Responder all of which are designed to be quick and scalable. Let's take a look at the different ways in which you can deploy the AIR Responder to your assets:

From the Main Menu select 'Assets' and then 'All Assets' from the Secondary Menu. Now you will see the page name 'Assets' and next to that is the Action Button which for the Assets page is labeled '+ Add New.'

When this '+ Add New' button is selected three deployment options are offered in a drop-down menu:

Each one of the options will present the user with a wizard that will walk through the options needed for the chosen deployment method:

1. Deploy New - For assets that are attached to a network that is visible to the AIR console

2. Cloud Account - For assets that reside in AWS EC2, and Virtual Machines in Microsoft Azure.

3. Off-Network - To generate triage and collection packages for assets that are not connected to a visible network.

Deploy Responder to New Asset Wizard

1. When you choose 'Deploy New', you'll be prompted via a wizard to determine if the Responder should establish a direct connection to the AIR console or if utilizing a Relay Server connection would be more suitable for your environment. Relay Server is explained here.

1. The second step of the deployment wizard provides distinct deployment options for all of the currently supported, network-attached operating systems; Windows, Linux, and macOS:

Windows PowerShell Command:

• The command varies based on the Organization affiliation. An example PowerShell command to copy is provided below:

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
(New-Object System.Net.WebClient).DownloadFile("https://air-demo.binalyze.com/api/endpoints/download/0/deploy/windows?deployment-token=d297145XXXXXXXX", "$PWD\deploy-responder.ps1")
.\deploy-responder.ps1

Windows PowerShell Script:

• This script can be downloaded from your AIR Console. Ensure you select or are working in the appropriate Organization before downloading.

<#
2022-2024 (c) Binalyze
AIR Responder Powershell Script for Windows
PLEASE DO NOT EDIT! This file is automatically generated at 2024-05-02T13:49:58
VERSION 2.39.9
#>

<#
.SYNOPSIS
    This script installs the AIR Responder using given parameters or default values are used.
    This script requires administrator privileges!
    MSI file is temporarily stored in %LOCALAPPDATA%\binalyze\air\agent
.DESCRIPTION
    Powershell script to deploy the AIR Responder.
.PARAMETER Version
    The version of the AIR Responder to be deployed.
.PARAMETER ConsoleAddress
    The address of the AIR Console without https:// prefix, only domain address.
.PARAMETER OrganizationId
    The organization id to register the AIR Responder.
.PARAMETER DeploymentToken
    A Valid deployment token to deploy the AIR Responder.
.PARAMETER ConnectionRouteID
    Set Connection Route Id for the AIR Responder.
.PARAMETER ConnectionRouteAddress
    Set Connection Route Address for the AIR Responder.
.PARAMETER AllowInsecureTlsVersion
    Allow insecure TLS version for the AIR Responder.
#>

Param ([string]$Version="2.39.9", 
       [string]$ConsoleAddress="air-demo.binalyze.com",
       [string]$OrganizationId="0",
       [string]$DeploymentToken="d297145dXXXXXXXX",
       [string]$ConnectionRouteID="{{.AIR_CONNECTION_ROUTE_ID}}",
       [string]$ConnectionRouteAddress="{{.AIR_CONNECTION_ROUTE_ADDRESS}}",
       [switch]$AllowInsecureTlsVersion)

$downloadDir = "$env:LOCALAPPDATA\binalyze\air\agent"

Remove-Item $downloadDir -Force -Recurse -ErrorAction Ignore
New-Item -Path $downloadDir -ItemType Directory
Push-Location
Set-Location -Path $downloadDir

$arch = "386"
if ([Environment]::Is64BitProcess) {
    $arch = "amd64"
}

if ($ConnectionRouteID -like '{*') {
    $ConnectionRouteID = ""
}
if ($ConnectionRouteAddress -like '{*') {
    $ConnectionRouteAddress = ""
}

$fileSuffix = ""
if ($ConnectionRouteID) {
    $fileSuffix = "{0}_{1}_" -f $arch,$ConnectionRouteID
    if ($ConnectionRouteAddress) {
        $fileSuffix = "{0}{1}_" -f $fileSuffix,$ConnectionRouteAddress
    }
}

$file = "{0}\AIR.Responder_{1}_{2}_{3}_{4}_{5}.msi" -f $downloadDir,$Version,$ConsoleAddress,$OrganizationId,$DeploymentToken,$fileSuffix
$url = "https://{0}/api/endpoints/download/{1}/windows/msi/{2}?deployment-token={3}" -f $ConsoleAddress,$OrganizationId,$arch,$DeploymentToken

Write-Debug "file: $file"
Write-Debug "url:  $url"

if ($AllowInsecureTlsVersion) {
    Write-Host "Allowed insecure TLS versions for the AIR Responder. If this flag is set, the AIR Responder will connect to the AIR Console with system default TLS version"
} else {
    try {
        [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12 -bor [System.Net.SecurityProtocolType]::Tls13
    } catch {
        Write-Host "TLS1.3 and TLS1.2 is not supported on this operating system, please try to use AllowInsecureTlsVersion flag."
    }
}

[System.Net.ServicePointManager]::ServerCertificateValidationCallback = {$true}
(New-Object system.net.webclient).DownloadFile($url,$file)

$process = Start-Process C:\Windows\System32\msiexec.exe -ArgumentList "/i $file /quiet /norestart" -PassThru -Wait
$process.WaitForExit()
if ($process.ExitCode -eq 0) {
    Write-Debug "AIR Responder is installed successfully."
    Remove-Item -Path $file -ErrorAction Ignore
} else {
    Write-Debug "MSI failed. ExitCode: $($process.ExitCode)"
    Pop-Location
    exit $process.ExitCode
}
Pop-Location

SCCM Deployment for Windows Responder:

• If you prefer, the Windows responder can be deployed using SCCM with the following command:

msiexec /i AIR.responder_2.24.2_air-demo.binalyze.com_0_d297145XXXXXXXX_.msi /qn /norestart

For a silent installation you can use the following command:

msiexec /i AIR.responder_2.26.4_air-demo.binalyze.com_176_9df51c56XXXXXXXX_.msi /qn /norestart

Windows Responder MSI Download:

• The MSI for the Windows Responder can be downloaded directly from the page, as depicted in the screenshot below:

Shareable Deployment Link for Windows/Linux/macOS:

• All three operating systems support the Shareable deployment link available in the console. This method is often the most straightforward—simply share the link with your client, allowing them to download and install the Responder. An example link is shown below:

https://air-demo.binalyze.com/#/shareable-deploy?token=d297145dXXXXXXXX

macOS and Linux Deployments:

• Unlike Windows, macOS and Linux do not utilize PowerShell commands or scripts. Instead, they can employ CURL or WGET commands. Alternatively, you can use the Shareable deployment page link mentioned above.

Example of CURL deployment command:

sudo curl -kfsSL "https://air-demo.binalyze.com/api/endpoints/download/176/deploy/darwin?deployment-token=9df51c56XXXXXXXX" | sudo sh

Example of WGET deployment command:

sudo wget --no-check-certificate -O- "https://air-demo.binalyze.com/api/endpoints/download/176/deploy/darwin?deployment-token=9df51c56XXXXXXXX" | sudo sh

Granting Full Disk Access for Responder on macOS

After installing Responder on macOS, users need to grant Full Disk Access permission. To guide users through this process, a popup will appear after installation:

If Full Disk Access permission is not granted when starting any Acquisition, this will be shown in the Acquisition logs:

After toggling on the FDA on this page, select the /opt/binalyze/air/agent/air file in the file manager that opens. Once this is done, our responder will appear in the list under the name 'air' ready for the user to toggle 'on'.

Why is there no logo next to AIR on the Full Disk Access page in macOS?

The AIR Responder operates as an executable binary running as a service rather than a traditional macOS application. This approach ensures consistency across platforms like Linux and macOS.

Since AIR is not packaged as a macOS app, it does not include a .plist file, which typically contains the application icon metadata. Consequently, it cannot display a logo on the Full Disk Access page.

This design choice does not affect the functionality or performance of Binalyze AIR.

Problem with MDM Installation

While the popup effectively guides users in manually installed scenarios, it presents challenges for enterprise environments where macOS devices are managed via Mobile Device Management (MDM). MDM allows remote application installation and security policy enforcement, including granting Full Disk Access.

Customers prefer silent installations for MDM-deployed Responder without the popup, as permissions are already set through security policies. However, our current setup cannot distinguish between user-initiated and MDM-initiated installations, causing the popup to appear in all cases.

We are actively working on a solution to address this issue for seamless enterprise deployments.

Updating the AIR responder is discussed on this page

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

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

• Bookmarks

• Cookies

• Downloads

• Extensions

• Platform Keys

• Privacy Settings

• Proxy Settings

• Sessions

• Storage

• Top Sites

• Windows & Tabs

Add the extension to your Chrome.

To address a security vulnerability involving Host header injection, we have (with AIR v4.33) implemented more stringent controls on AIR Console access.

This update enhances security protocols and provides administrators with better control over access settings:

Key Points:

• Access Restriction: The AIR Console will now only be accessible through the specific address registered during the initial setup, ensuring that only legitimate requests are processed.

• Technical Enforcement: This measure counters manipulations of the Host header that could potentially allow unauthorized access.

• Configuration Flexibility: For legitimate access needs from multiple domains or IP addresses, users can specify allowable entries via the AIR_CONSOLE_ADDRESSES environment variable.

• Enhanced Security: This change prevents unauthorized access and aligns with best practices for secure network management.

(1) - Taking a System Backup

1. Login to the AIR Console Web UI using a Global Admin Account.

2. Navigate to the Backup Management section by selecting the Gear Button and then "Backup History" from the drop-down list.

3. Make a backup of the system by clicking the "Backup Now" button on the top right corner.

4. Download the backup file by clicking the Vertical Ellipsis Button under the "Actions" column and clicking Download from the drop-down list.

   • This will download a zip file with the ABF extension (AIR Backup File).

(2) - Stop AIR Systems

NOTE: You must stop AIR System first.

1. Use a terminal emulator, such as PuTTY to connect to the CLI of the AIR Server via SSH.

2. Navigate to the AIR folder (/opt/binalyze-air by default) by executing the following command:

   • cd /opt/binalyze-air

3. Stop containers by executing the following command:

   • docker compose down -v

(3) - Stop DB System

1. Navigate to the AIR DB folder (/opt/binalyze-air-db by default) by executing the following command:

   • cd /opt/binalyze-air-db

2. Stop containers by executing the following command:

   • docker compose down -v

(4) - Updating the DB System

NOTE: You must upgrade DB first.

1. Use a terminal emulator, such as PuTTY to connect to the CLI of the DB Server via SSH.

2. Navigate to the AIR DB folder (/opt/binalyze-air-db by default) by executing the following command:

   • cd /opt/binalyze-air-db

3. Pull the latest images by executing the following command:

   • docker compose pull

4. Start containers by executing the following command:

   • docker compose up -d

(5) - Updating the AIR System

1. Use a terminal emulator, such as PuTTY to connect to the CLI of the AIR Server via SSH.

2. Navigate to the AIR folder (/opt/binalyze-air by default) by executing the following command:

   • cd /opt/binalyze-air

3. Pull the latest images by executing the following command:

   • docker compose pull

4. Start containers by executing the following command:

   • docker compose up -d

Taking a System Backup

1. Login to the AIR Console Web UI using a Global Admin Account.

2. Navigate to the Backup management section by selecting the Gear Button and then "Backup History" from the drop-down list.

3. Make a backup of the system by clicking the "Backup Now" button in the top right corner.

4. Download the backup file by clicking the Vertical Ellipsis Button under the "Actions" column and clicking Download from the drop-down list.

   • This will download a zip file with the ABF extension (AIR Backup File).

Updating the System

• Use a terminal emulator, such as PuTTY to connect to the CLI of the AIR Console & DB Server via SSH.

• Navigate to the AIR folder (/opt/binalyze-air by default) by executing the following command:

  • cd /opt/binalyze-air

• Stop containers by executing the following command:

  • docker compose -p binalyze-air down -v

  (NB: If you are using AIR v3.4 or older, change 'docker compose' to 'docker-compose' in all commands)

• Pull latest images by executing the following command:

  • docker compose pull

• Start containers by executing the following command:

  • docker compose -p binalyze-air up -d

Follow these commands to restore your AIR backup using the CLI.

This procedure applies to both Single-tier and 2-tier systems and is performed on the Console server.

1. Pre-Restore Setup

• Install a fresh AIR Console (choose Single-tier or 2-tier based on your needs).

2. Transfer and Copy the Backup File

• Use your preferred file transfer tool to transfer your backup file to the new server.

• Ensure the file has the .abf extension (e.g., 23-8-14_16.43.5.216_v3.abf).

• Copy the backup file from the host system to the APP container: docker cp <backup_file.abf> binalyze-air-app-1:/binalyze-air/

3. Retrieve AIR DB URIs (For Two-Tier Installations Only)

• If using a 2-tier system, retrieve the AIR DB connection strings by running: cat /opt/binalyze-air/.env

• These URIs will be needed for validation in the next step.

4. Run the AIR-CLI to Restore the Backup

Execute the CLI tool with: sudo docker exec -ti binalyze-air-app-1 /air-cli

In the AIR-CLI interface, select:

"1) Restore using a backup file"

When prompted, enter the directory and filename where the backup file was copied, for example: /binalyze-air/23-8-14_16.43.5.216_v3.abf

Press Enter through the default options until you see the confirmation message: "This operation will drop your current database and restore the provided backup. Are you sure to continue?" Type 'y' and press Enter to continue.

5. Finalize the Restore Process

Once the restore completes successfully, a confirmation message will appear.

Exit the container by typing: Exit

Restart the containers by running: cd /opt/binalyze-air

docker compose down && docker compose up -d

Don't hesitate to get in touch with [email protected] if you have any problems or questions about the restoration process

The AIR standalone collector currently provides support for execution on ESXi 6.5+ systems.

VMware ESXi is a type of hypervisor, which is software that creates and runs virtual machines (VMs). It is a part of VMware's vSphere product suite and is used for enterprise-level virtualization. ESXi is popular due to its stability, performance, and extensive feature set for managing and running virtual machines.

Binalyze AIR offers a robust approach for evidence collection from ESXi platforms. DRONE is not currently supported for ESXi systems. This is achieved through a standalone ESXi collector, available for download on the Assets page of your AIR console:

Assets>Add New>Deploy New>Direct connection to AIR Console >ESXi

After running Responder using your chosen method, the collected evidence should be converted into a PPC file. This PPC file can then be imported into the AIR Console. Once imported, the asset will be displayed alongside all other assets in AIR, ensuring seamless integration and visibility within the platform.

After ingestion into AIR the ESXi evidence is parsed and pesented in the Investigation Hub in the normal way:

However, you can if required decompress the tar.gz file to independently access and examine the evidence. Typically, the evidence will include the following: :

• System Info: Basic system information about the ESXi machine.

• Bash History: Command history executed on the Bash shell.

• Collect Bash Files: Gathering files associated with the Bash shell.

• Environment Variables: Variables defined in the system environment.

• Collect /etc Files: Gather files under the /etc directory.

• Log Files: Collecting various log files.

• SSH Config: Retrieves the configuration settings related to the SSH (Secure Shell) protocol.

• SSH Authorized Keys: Collects information about authorized SSH keys, which are used for secure authentication.

• SSH Known Hosts: Gathers details about known hosts in the context of SSH.

• File System Enumeration: Involves enumerating and collecting information about the file system on the ESXi machine.

A full list of ESXi collected items is shown here

Having run the binary the progress will be displayed in the user's terminal/shell:

Full list of ESXi collected items

File Collectors:

Triage Collectors