Skip to content

GCP Responder Deployment: Technical Details

This page provides in-depth technical information about how XDR Forensics deploys Responders to Google Cloud Platform assets. For basic GCP setup and configuration, see Cloud Forensics.

When you deploy a Responder to a GCP asset, XDR Forensics generates a unique deployment script and stores it in your GCS bucket. The script filename is generated using a SHA-256 hash (truncated to 16 characters) of key deployment parameters:

  • Console address and version
  • Responder package version
  • Organization ID and deployment token
  • Relay server details (if configured)
  • Connection route information (if applicable)

GCS path format:

gs://<bucketName>/air-responder-deploy-scripts/<hash>.ps1 (Windows)
gs://<bucketName>/air-responder-deploy-scripts/<hash>.sh (Linux)

If a script with identical parameters already exists, it is reused rather than re-uploaded.

The deployment uses GCP OS Config to execute the script on the target VM:

  1. ExecStep Configuration — References the GCS object with bucket name, object path, and generation number
  2. Interpreter Selection — PowerShell for Windows, Shell for Linux
  3. Patch Job Creation — A patch job is created targeting the specific VM instance

Patch job naming:

  • Display name: binalyze-air-responder-deploy-<instanceName>
  • Description: Binalyze AIR Responder deployment on <instanceName>

The patch job is configured with rebootConfig: NEVER to prevent automatic reboots after deployment.

XDR Forensics monitors the patch job via the OS Config API, tracking:

  • Job status (started, patching, succeeded, failed)
  • Error messages
  • Progress percentage

Deployment logs are retrieved from Cloud Logging to surface command output and error details.

ComponentRequirement
OS Config AgentMust be installed and running on target VMs
GCS BucketMust exist and be accessible by service account
IAM RolesService account needs Storage Object Admin on bucket
NetworkVMs must reach GCS and OS Config API endpoints