Responder Tamper Detection
Overview
Tamper Detection is a security feature that protects the integrity and continuous operation of AIR Responders. When enabled, the Responder watchdog actively monitors the agent for interference, modification, or attempts to disable it. If suspicious activity is detected, the watchdog immediately reports the event to the AIR console.
This feature is critical in high‑security environments where maintaining asset visibility and control is essential.
How Tamper Detection Works
Tamper Detection is handled by the agent-watchdog component. When a tamper condition is detected, the watchdog sends an HTTP POST request to:
{ConsoleAddress}/api/endpoints/{EndpointID}/event-logImportant behavior:
The watchdog does not use the current agent configuration for reporting.
It uses a backup configuration saved during installation.
This ensures reporting still succeeds if the current config is missing or maliciously modified.
If reporting fails:
Events are queued on disk.
Retries use exponential backoff.
Maximum retry duration is approximately 1 day.
Reporting supports Relay and proxy configurations if configured.
Where Tamper Events Appear
Tamper Detection events are posted to the AIR console event log endpoint and are visible in Activity > Audit Logs. You can filter by:
EventClass =
TamperDetectionEventCategory =
SystemSource =
agent-watchdog
See Console Audit Logs for details on access, filtering, and retention.
Tamper Detection Event Types
There are three Tamper Detection event types. All share the following common properties:
1) agent-not-found
Title format
Trigger condition
The Responder executable file no longer exists on disk.
Detection logic
The watchdog checks the agent binary path using:
If the check returns fs.ErrNotExist, the event is triggered.
Typical scenarios
Responder was uninstalled.
The agent executable was manually deleted.
The installation directory was removed.
Meaning
The Responder binary is missing from the system.
2) agent-suspended
Title format
Trigger condition
The Responder binary exists on disk, but the agent process is not running.
Detection logic
After confirming the binary exists, the watchdog checks whether the agent holds its single‑instance lock.
Platform-specific behavior
Windows: checks for named mutex
Global\AIRAgentRunningUnix-based systems: checks file lock using
flockon:
If the lock is not held, the agent is considered suspended.
Typical scenarios
Responder service manually stopped using
sc stop,systemctl stop, orlaunchctl unloadAgent process crashed and did not restart
Service disabled
Meaning
The Responder binary exists but the service is not running.
3) agent-config-changed
Title format
Trigger condition
The current agent configuration differs from the watchdog’s backup configuration.
Detection logic
When installed, the watchdog stores a backup copy of the agent configuration. Each time it runs, it compares the current configuration with the backup. If differences are detected in monitored fields, the event is triggered.
Monitored configuration fields
Only the following fields are included in the tamper comparison:
ConsoleAddress
AIR console URL
RegisteredTo
Registration URL
SecurityToken
Authentication token
EndpointID
Unique asset ID
DebugLogging
Debug logging flag
CACert
TLS CA certificate
ProxyEnabled
Proxy enabled flag
OrganizationID
Organization identifier
Excluded from comparison
RelayURL
Typical scenarios
Console address modified to redirect to another server
Security token changed
Asset ID altered
CA certificate modified
Debug logging enabled/disabled outside normal console operations
Meaning
The Responder configuration has been modified outside expected console‑controlled operations.
Additional Watchdog Behavior
Update handling
If the watchdog detects a .update trigger directory, it skips all checks to avoid false positives during updates. If the directory is older than 10 minutes, it is considered stale, removed, and normal checks resume.
Uninstall handling
If a .uninstall trigger directory exists, the watchdog treats the removal as intentional. Process checks are skipped.
Example Event Structure
Example event fields:
Title= Tamper detected (agent-not-found) on asset 110-Win2025-ResponderEventClass= TamperDetectionEventCategory= SystemSeverity= SHeaderEventSource= SystemEventDate= 2026.02.11 15:12:47ID= 7f370182-6a09-4b2f-befd-4a56fcfe05eaTime= 2026-02-11T16:51:55.3001356+04:30Type= agent-not-foundSource= agent-watchdogVersion= 2.85.0Platform= windowsEventLogId= 2050eab7-3278-4085-b84c-38ca2759ee25EventSource= SystemAssetName= 110-Win2025-Responder
This is how a tamper event appears in the AIR console. To view it, go to Activity → Audit Logs and filter for TamperDetectionEvent.

Summary Table
agent-not-found
Agent executable missing
Responder removed or binary deleted
agent-suspended
Binary exists but process not running
Service stopped, disabled, or crashed
agent-config-changed
Configuration differs from backup
Configuration modified outside console
Why Tamper Detection Is Critical
Tamper Detection ensures:
Early detection of malicious interference
Continuous monitoring of asset integrity
Protection against unauthorized configuration changes
Reliable alerting even if the agent is modified or removed
Last updated
Was this helpful?

