Automox Agent Deployer

The Automox Agent Deployer is a locally downloaded and executed client binary that allows you to deploy Automox agents to CrowdStrike managed device estate using the CrowdStrike API for the Real-Time-Response module. After configuring variables via a CLI-based GUI for ease of use, the client will install the Automox agent on endpoints scoped in the configurator step.

Configuring and setting up scripts

Step 1: Download the deployer application 

ax-agent-deployer_linux_amd64

ax-agent-deployer_macos_amd64

ax-agent-deployer_macos_arm64

ax-agent-deployer_windows_amd64.exe

  • Run the application 

Note: For Windows, you must open up a PowerShell window and call the exe directly. For Linux/macOS, a terminal browser opens when you click on the application.

Step 2: Configurator (for first-time use)

After you download and install the Agent Deployer application, select command-config. Now you can set up the configuration including the file path, Automox API key, CrowdStrike Client ID, CrowdStrike secret, the CrowdStrike API region and the platform deployment size. All of these elements are required.

Requirements

  • Automox Access Key
  • Crowdstrike API Client ID
  • Crowdstrike API Client Secret
  • Crowdstrike API Region
  • Crowdstrike API Client Permissions


    • Hosts - read
      • For getting details on hosts being deployed to
    • Host Groups - read
      • For getting available groups and membership details
    • Real time response - read and write
      • For executing the RTR installation scripts. The write permission here is what allows custom scripts to be executed.
    • Response policies
      • For verifying that the selected groups have Real time response capabilities enabled
  • Group Response Policy Configuration
    • All groups selected for deployment will need to have the following Real Time Response Policy settings enabled
      • Real Time Response - enabled
      • Custom scripts - enabled

Once the Automox key and Crowdstrike configuration values are configured, the deployer will use those details to connect to the Crowdstrike API to get a list of available groups and provide them for picking where to deploy. Multiple groups can be selected.

Step 3: Select upload or print custom scripts

The configurator provides an option to upload or print the RTR scripts necessary for deployment of the Automox agent. If opting to upload, the Real time response (admin) - write permission is temporarily required.

The upload route is the easiest and most likely to ensure success when deploying as there is no risk of errors related to formatting/new lines from copying and pasting the printed scripts.

Upload Scripts

  1. Before you continue, confirm that the Real time response (admin) - write permission is enabled for the Crowdstrike API Client being used by the deployer. If it is not configured when attempting to upload, 2 retries are allowed before the configurator exits. 

  2. The deployer then attempts to upload the installation script for each platform.

    • The scripts are uploaded with permissions that allow them to be used by any user with the RTR Active Responder role or API Client with the Real time response - write permission (non-admin).

  3. If successful, the configurator continues. Ensure that the Real time response (admin) - write permission is removed at this point. It is not needed for normal operation of the deployer and provides too much permission.

Print Scripts

(Note: The credentials have been rotated in this example.)

  1. When selecting print, the script for each platform is printed for copying and pasting into the Crowdstrike console under Response Scripts & Files. The names of the scripts need to make those provided by the deployer.

  2. Navigate to Response Scripts & Files and click Create a script.

  3. Enter the name and description and ensure the correct shell type is selected for each OS. Be aware that Real Time Responder roles are required for this action. These can be added via User Management in the Crowdstrike console.

    • OS Shell Types

      • Windows: Powershell

      • Linux: Bash

      • macOS: Zsh

    • Permissions: RTR Active Response and RTR Administrator

      • This permission allows the deployer to use this script without admin permissions.


Repeat the steps for macOS and Linux by pressing any key twice and using the name and script content printed for each. Note: If the user intends to deploy on all OSes, there must be 3 different scripts for each OS uploaded here.  

Step 4: Set up recurring schedule to run the script(s)


  • For the prompt: “Print commands for scheduling the tool to run”, enter ‘Yes’.  
  • Provide path - defaults to the existing path and determine the frequency. This is only available for Linux and Windows.

Scheduler Example - Windows

The application prints the PowerShell script for scheduling when Windows is selected as the scheduling platform.

  • Open PowerShell and run printed script.

PowerShell - Example

Review Task Scheduler


After you run the recurring schedule script, you will see a new automated task in the Task Scheduler. All arguments are pre-populated with necessary flags. You can change any parameters within the Task Scheduler. Note that plain text API secrets are in this scheduled task, which represents a potential security risk.

Step 5: Save configuration and pre-check

You can opt to save the configuration to a file. This file can be referenced using the --config flag when running the deployer. A configuration file is not required if using the schedule task/cron schedulers as the commands are generated with the configuration values as flags

Finally, the deployer will attempt to validate that the selected groups for deployment have Real time response capabilities enabled. Any groups with incorrect settings will be logged.

Deployment

Select command-deploy to see results of your actions.

Deploy command and results. For devices that are not online, the commands are queued up via the ‘queue offline’ flag within CrowdStrike.

Troubleshooting

There are a few known errors to look out for when deploying.

Missing scripts

1 RTR Custom Script 'AutomoxAgentInstaller-<Platform>' is missing, cannot deploy. 
2 Please run configuration to upload or print the required script"

This error message is displayed when the specified RTR Custom Script is not found in the Crowdstrike platform. There are a couple possible reasons for this:

  1. The scripts were not created.

    • In this case, run the config command to upload or print the scripts.

  2. The permissions are not correct on the script.

    • Ensure that the script permissions are set to the RTR Active Responder and Admin

Offline Hosts

1 host 'abc-123' (device-id) was offline, deployment will be performed 
2 by Crowdstrike when the device is online

This message is not necessarily an error. It is printed when a host in the deployment group was offline. Crowdstrike will attempt to run the command when the host is online; however, the deployer does not track these queued commands.

Invalid scripts

1 RTR Custom Script 'AutomoxAgentInstaller-<Platform>' returned an error during deploy. 
2 This is usually due to the script being improperly formatted or invalid. 
3 Please run configuration to upload or print the required script to fix. 
4 If manually uploading, refer to the README for troubleshooting steps.

If the scripts were manually uploaded to the Crowdstrike platform, it is possible that they were not pasted correctly.

The most common reason for this is trailing empty lines at the end of a script. Remove these and try again. If this doesn’t fix the issue or if there are no empty lines, try uploading the scripts via the deployer.

Timeout

The installation commands run during the deployment must succeed within 30 seconds.

If the command takes longer than 30 seconds to complete, you will see an error stating that the command timed out. This could be due to a slow connection or some other error for the host. One thing to try is rebooting the host that failed to install (if that’s an option).

Other deployment error

Other errors may be captured from the deployment. Errors that are not known will return the raw details from the deploy operation. These are usually fairly helpful in understanding what went wrong.