How to Fix Wazuh Active-Response Error 1204

Wazuh Active-Response Error 1204 is a runtime execution failure that occurs when the Wazuh active response subsystem is unable to successfully trigger or complete an automated remediation action on an endpoint.

In practical terms, it means Wazuh detected a security-relevant event, but the automated response (for example, blocking an IP or killing a process) did not execute as expected.

What Wazuh Active-Response Error 1204 means

This error typically indicates a breakdown in the active-response pipeline, either at the manager level (triggering the action), or at the agent level (executing the script).

It often surfaces when there are misconfigurations in active-response definitions, permission issues, missing executables, or communication failures between manager and agent.

Common symptoms administrators encounter

• Active response scripts are triggered but no action occurs on endpoints
• “Command not found” or execution failure messages in logs
• IP blocking or remediation actions not taking effect
• Events appear in dashboards, but no corresponding response is executed
• Intermittent failures across multiple agents

Why Error 1204 prevents automated threat response

Active response is designed to reduce mean time to response (MTTR) by automatically executing defensive actions.

When Error 1204 occurs, this automation chain breaks, forcing security teams to manually intervene.

This can significantly increase exposure time during active threats, particularly in high-volume attack scenarios like brute force attempts or lateral movement.

What you’ll learn in this guide

• How Wazuh Active Response works under the hood
• Why Error 1204 occurs in real deployments
• Where to locate and interpret failure signals
• Step-by-step troubleshooting methodology
• Configuration fixes to restore automated response reliability

What Is Wazuh Active Response?

Wazuh Active Response is a built-in orchestration mechanism that executes automated countermeasures when predefined security conditions are met.

It extends detection capabilities into immediate containment actions.

How Active Response Works

Active response operates as a multi-stage pipeline that converts detection signals into executable remediation tasks.

Event detection

Wazuh continuously collects logs, system events, and security telemetry from agents.

These events may include authentication failures, malware signatures, or anomalous behavior.

Rule matching

Incoming events are evaluated against Wazuh rule sets. When a rule matches a defined condition (e.g., repeated failed SSH logins), it generates an alert with a specific rule ID and severity level.

Triggering response scripts

If active response is enabled for that rule, Wazuh maps the alert to a predefined command or script (e.g., firewall-drop, disable-user, kill-process).

Executing actions on agents

The manager sends a command to the agent, which executes the script locally with appropriate privileges. The result is then reported back to the manager.

📘 Related Guide:  How to Configure Wazuh Active Response

Common Active Response Use Cases

Active response is typically deployed for rapid containment scenarios where automated action reduces attacker dwell time.

Blocking malicious IP addresses

Used to automatically block IPs involved in brute force attacks, scanning activity, or exploit attempts. Often implemented via firewall rules (iptables, Windows Firewall, OPNsense integrations).

Disabling compromised accounts

When suspicious authentication patterns are detected, Wazuh can disable user accounts to prevent further access.

Killing malicious processes

If malware or unauthorized binaries are detected, active response can terminate the associated process immediately.

Removing malicious files

In some configurations, Wazuh can remove or quarantine files flagged as malicious by rules or external threat intelligence feeds.

Where Error 1204 Appears

Error 1204 is not isolated to a single interface, it can surface across multiple observability layers.

Wazuh manager logs

The primary source of truth. You may see execution failures or command dispatch errors.

Active response logs

Logs related to script execution, permissions, and command invocation failures.

Dashboard notifications

In some deployments, failed responses are reflected as alert-level warnings or execution errors.

Agent logs

Agents may log issues such as missing scripts, execution permission failures, or invalid parameters.

What Does Wazuh Active-Response Error 1204 Mean?

At a technical level, Error 1204 indicates that the active response command was not executed successfully on the target endpoint.

This usually means the request reached the agent but failed during validation or execution.

Why the Error Occurs

Common root causes include:

• Misconfigured active response command definitions in ossec.conf
• Missing or non-executable scripts on agents
• Incorrect file permissions on response binaries
• Agent-manager communication latency or failure
• Invalid rule-to-command mapping
• Unsupported parameters passed to scripts

📘Reference: Wazuh Active Response documentation

Typical Error Messages

Depending on version and configuration, Error 1204 may appear alongside:

• active response command not found
• AR command execution failed
• unable to execute script
• agent could not run command

Components Involved

Wazuh Manager

Responsible for evaluating rules and dispatching active response commands to agents.

Wazuh Agent

Executes active response scripts locally and reports execution status.

Active-response daemon

Handles orchestration of command execution and ensures proper sequencing of response actions.

Response scripts

Custom or built-in scripts that perform remediation actions (firewall updates, process termination, etc.).

Configuration files

Key files such as ossec.conf define:

• Which rules trigger responses
• Which scripts are executed
• Execution frequency and timeout settings

📘 Related Guides:

• Wazuh Agent Not Connecting to Manager? 12 Proven Fixes
• Fix Wazuh Certificate Errors

Step 1: Review the Exact Error Message

Before making any configuration changes, you need to isolate the precise failure signature of Error 1204.

In Wazuh, active-response failures are often generic at the surface level, but the underlying logs usually expose the exact breakdown (missing script, permission denial, invalid command mapping, etc.).

Locate the Manager Logs

On the Wazuh manager, check the primary active-response log stream:

• /var/ossec/logs/active-responses.log
• /var/ossec/logs/ossec.log

Look for entries containing:

• active-response
• error 1204
• command execution failed

These logs typically show whether the manager successfully dispatched the command or failed before transmission.

Locate Agent Logs

On the affected endpoint:

• /var/ossec/logs/ossec.log

Focus on:

• Script execution attempts
• Permission errors
• Missing file references
• Shell invocation failures

If the agent never receives the command, the issue is upstream (manager-side configuration or connectivity).

Identify the Failing Script

Error 1204 is frequently tied to a specific active-response script (e.g., firewall-drop, disable-account, custom bash/python scripts). Identify:

• Script name referenced in logs
• Command alias used in configuration
• Rule ID triggering the response

This mapping is critical for narrowing the failure domain.

Capture the Full Error Output

Do not rely on truncated dashboard messages. Capture:

• Full stack trace (if present)
• Timestamped log sequence
• Associated rule ID and agent ID

This helps correlate:

• Detection event → rule match → response trigger → execution failure

📘 Related Guide:  How to Test Wazuh Rules

Step 2: Verify Active Response Configuration

Once the failing component is identified, validate the active-response configuration chain from rule to execution.

Review active-response Blocks

Inspect ossec.conf on the manager:

• Ensure <active-response> sections are correctly defined
• Confirm correct <command> and <location> values
• Validate timeout and frequency settings

Even a minor syntax issue can prevent execution entirely.

Validate Script Names

Check consistency between:

• Script filename on disk
• Command definition in Wazuh config
• Reference in active-response block

Mismatch examples:

• firewall-drop.sh vs firewall_drop.sh
• Case sensitivity differences (especially on Linux)

Verify Rule IDs

Active response is often bound to specific rule IDs or groups:

• Ensure rule ID exists in /var/ossec/ruleset/rules/
• Confirm rule is actually firing
• Validate correct <rules_id> or <group> association

A common failure pattern is binding active response to a rule that never triggers.

Check Command Definitions

In ossec.conf, verify:

• <command> name matches script definition
• Path is correct and executable
• Arguments are properly formatted

Example failure: missing argument placeholders or malformed command syntax.

Validate Agent Configuration

On the agent side:

• Ensure active response is enabled
• Confirm logcollector and execd are running
• Verify agent is allowed to execute commands from manager

📘 Related Guide: Wazuh Configuration Guide

Step 3: Confirm the Response Script Exists

Even if configuration is correct, Error 1204 will occur if the script is missing or not properly deployed.

Verify Script Location

Check expected directories:

• /var/ossec/active-response/bin/
• Custom script directories defined in configuration

Ensure the script exists on all relevant agents, not just the manager.

Check File Ownership

Scripts must typically be owned by the Wazuh user:

• Owner: root or wazuh (depending on deployment)
• Group: wazuh

Incorrect ownership can prevent execution.

Confirm Execution Permissions

Ensure the script is executable:

• chmod +x script-name.sh

Common failure mode:

• Script exists but lacks execute bit → triggers Error 1204 silently

Ensure the Correct Script Version Is Installed

Version mismatches can break active response behavior:

• Script updated on manager but not propagated to agents
• Deprecated script syntax after Wazuh upgrade
• Custom scripts incompatible with current Wazuh version

📘 Related Guide: Fix Wazuh Docker Compose Deployment

Step 4: Test the Response Script Manually

Manual validation isolates whether the issue is Wazuh-specific or script-level.

Execute the Script Directly

Run the script on the agent:

/var/ossec/active-response/bin/your-script.sh

Check:

• Immediate execution success/failure
• Console output behavior
• Any dependency errors

Test Required Parameters

Most active-response scripts require parameters such as:

• IP address
• Username
• Process ID

Simulate Wazuh invocation exactly:

your-script.sh <param1> <param2>

Incorrect parameter handling is a frequent cause of Error 1204.

Check Exit Codes

Wazuh interprets script success via exit codes:

• 0 → success
• Non-zero → failure (often triggers Error 1204)

Inspect:

echo $?

Verify Expected Behavior

Confirm the script actually performs the intended action:

• Firewall rule applied
• Process terminated
• File removed or quarantined

If the script “runs” but does nothing, Wazuh will still treat it as a failure depending on output handling.

Step 5: Validate JSON Input

A large percentage of Wazuh Active-Response Error 1204 cases originate from malformed or incomplete JSON payloads passed to response scripts.

Since active response scripts often parse structured input, even minor formatting deviations can cause execution failure.

Inspect the Input Payload

Start by examining the exact payload sent to the script from the manager:

• Look in /var/ossec/logs/active-responses.log
• Identify the JSON object passed to the command
• Confirm whether it includes expected fields (e.g., srcip, user, pid)

A missing or unexpected field often leads to parsing errors inside the script.

Verify Required Fields

Each active-response script expects a strict schema. Common required fields include:

• srcip (source IP address)
• user (username)
• command (action type)
• parameters (optional context data)

If any required field is absent, the script may exit with a non-zero status, triggering Error 1204.

Check JSON Formatting

Ensure the payload is valid JSON:

• No trailing commas
• Proper quoting of keys and values
• No unescaped special characters

Invalid JSON examples:

• Single quotes instead of double quotes
• Missing braces or brackets
• Corrupted payload due to log truncation

Test with Sample Events

Manually simulate payload execution using a known-good event:

• Use wazuh-logtest to reproduce rule triggers
• Feed a controlled test event into the manager
• Observe the resulting JSON payload

📘 Related Guide: Custom Decoder Isn’t Matching: Wazuh Logtest Deep Dive

Step 6: Verify Agent Communication

Active response depends heavily on reliable manager-to-agent communication.

If this channel is degraded, Error 1204 may appear even if scripts are correctly configured.

Confirm Agent Connectivity

Check that the agent is reachable from the manager:

• Ensure TCP connection is stable (default port 1514/1515 depending on setup)
• Verify no firewall rules are blocking communication
• Confirm hostname resolution if DNS is used

Check Agent Status

On the manager:

• Run agent_control -l
• Confirm agent is marked as Active

Inactive or disconnected agents will not execute active-response commands.

Verify Active Response Delivery

Inspect whether commands are actually reaching the agent:

• Look for “command sent” vs “command acknowledged” logs
• Confirm no backlog in manager dispatch queue
• Check for retransmission attempts

A failure at this stage usually indicates transport or encryption issues.

Review Queue Processing

If the system is under load:

• Active-response queue may be delayed
• Commands may expire before execution
• Worker threads may be saturated

This is common in high-ingestion environments with heavy rule firing rates.

📘 Related Guide: Wazuh Agent Not Connecting to Manager? 12 Proven Fixes

Step 7: Check File and Directory Permissions

Incorrect filesystem permissions are one of the most common root causes of Error 1204, especially after upgrades or manual script deployments.

Verify Script Permissions

Ensure the active-response script is executable:

chmod +x /var/ossec/active-response/bin/script-name

Also confirm it is not accidentally restricted:

• No read-only flags
• No ACL restrictions blocking execution

Verify Active Response Directory Permissions

Check the directory containing scripts:

• /var/ossec/active-response/bin/

It should be readable and executable by the Wazuh service user.

Confirm Wazuh User Access

Active response typically runs under the wazuh user context:

• Verify user can execute scripts manually
• Confirm no sudo restrictions block execution
• Ensure group membership is correct

Check Ownership Consistency

Inconsistent ownership can break execution chains:

• Scripts owned by root but executed by wazuh
• Mixed ownership across different agents
• Post-migration permission drift

Consistent ownership across all nodes is required in distributed deployments.

📘Related Guide: Why the Wazuh Windows Agent Service Starts Then Stops (And How to Fix It)

Step 8: Review Security Restrictions

Security layers at the OS level can silently block active response execution, resulting in Error 1204 without obvious Wazuh-side indicators.

Check SELinux Policies

On SELinux-enabled systems:

• Verify enforcement mode (enforcing, permissive)
• Check audit logs for denied executions
• Add appropriate policy exceptions if needed

SELinux can block script execution even if permissions are correct.

Review AppArmor Profiles

On Ubuntu-based systems:

• Check AppArmor confinement for Wazuh binaries
• Inspect /etc/apparmor.d/ profiles
• Ensure scripts are not restricted by profile rules

Inspect Antivirus or Endpoint Protection

Security tools may interfere with:

• Script execution
• File modification (e.g., firewall rules)
• Process termination commands

This is especially common with endpoint protection suites that monitor system-level changes.

Verify Execution Policies

Some environments enforce strict execution controls:

• No-execute mounts (noexec)
• Restricted shell environments
• Hardened CIS benchmarks blocking script execution

Step 9: Verify Version Compatibility

Version mismatches between Wazuh components, scripts, and integrations can lead to subtle failures that manifest as Error 1204.

Confirm Wazuh Version

Check all components:

• Wazuh Manager version
• Wazuh Agent version
• Indexer and dashboard versions

Mismatched versions often introduce API or payload incompatibilities.

Check Script Compatibility

Custom scripts may break after upgrades:

• Deprecated argument formats
• Changed JSON structures
• Modified execution context

Always validate scripts after major version upgrades.

Verify Custom Integration Support

If using integrations (firewall, cloud APIs, SIEM connectors):

• Ensure API versions are still supported
• Confirm authentication mechanisms are valid
• Validate third-party tool compatibility

Review Recent Upgrades

If Error 1204 started after an upgrade:

• Compare pre/post configuration files
• Review changelogs for active response changes
• Roll back test environment if necessary

📘 Related Guide: Fix Wazuh Certificate Errors

/var/ossec/bin/wazuh-control restart

/var/ossec/bin/wazuh-control restart

/var/ossec/active-response/bin/script-name.sh <arguments>