Deploying Custom Active Response Script to all Agents

[Mithun Haridas]

Hi Team,

I have developed a custom Active Response script and have successfully tested it. My concern is regarding deployment in the production environment. There are multiple specific Windows agents where this script needs to be placed.

Is there a way to centrally push or deploy the script to the required agents from the manager server, so that the deployment process becomes easier? It would be quite challenging and time-consuming to manually access each agent and copy the script individually.

Could you please let me know if there is any alternative or recommended approach to achieve this?

Thanks in advance.

[diego...@wazuh.com]

Mithun Haridas

Before we dive into deployment options for your custom Active Response script, could you share a bit more context so we can point you to the most accurate approach:

• What version of Wazuh are you running (manager and agents)?
• What is your deployment architecture (single-node manager, cluster, number of Windows agents involved)?
• Is the Active Response script currently placed manually via the `active-response/bin` folder on each agent, or through another method?
• Have you looked into centralized configuration via the Wazuh manager (e.g. shared agent groups, `agent.conf`, or the `WPK`/agent upgrade mechanism), and if so, what happened when you tried?
• Any errors or unexpected behavior you've run into so far?

While you gather that information, we're already looking into the best way to handle this on our side and will follow up with a more complete answer soon.

[diego...@wazuh.com]

Mithun Haridas

Short answer: Wazuh does not have an out of the box mechanism to push a custom Active Response script file to agents. The script has to physically exist in the agent's active-response/bin folder (see the documentation on custom active response scripts: https://documentation.wazuh.com/current/user-manual/capabilities/active-response/custom-active-response-scripts.html), and there is no built in way to copy an arbitrary file there from the manager. This is intentional: allowing the manager to push and run arbitrary code on agents would mean a compromised manager could remotely control every connected endpoint, so that capability is disabled by default.

That said, there is a workaround that centralizes the script content and only requires one manual step per agent (not per deployment). It combines centralized configuration (https://documentation.wazuh.com/current/user-manual/reference/centralized-configuration.html) with the command monitoring module (https://documentation.wazuh.com/current/user-manual/capabilities/command-monitoring/configuration.html):

1. Create a dedicated agent group for these Windows agents and place your custom AR script inside that group's shared folder on the manager, for example:
/var/ossec/etc/shared/<group>/custom-ar.cmd

2. In that group's agent.conf, add a command wodle that periodically checks the script in the local shared folder and copies it into active-response/bin whenever it changes:

<agent_config os="^Windows">
  <wodle name="command">
    <disabled>no</disabled>
    <tag>ar-sync</tag>
    <command>powershell.exe -ExecutionPolicy Bypass -Command "$b='C:\Program Files (x86)\ossec-agent'; $s=Join-Path $b 'shared\custom-ar.cmd'; $d=Join-Path $b 'active-response\bin\custom-ar.cmd'; if (Test-Path $s) { if (-not (Test-Path $d) -or (Get-FileHash $s).Hash -ne (Get-FileHash $d).Hash) { Copy-Item $s $d -Force } }"</command>
    <interval>1h</interval>
    <run_on_start>yes</run_on_start>
    <ignore_output>yes</ignore_output>
    <timeout>60</timeout>
  </wodle>
</agent_config>

3. On each agent, add the following two lines to local_internal_options.conf once, then restart the agent:

wazuh_command.remote_commands=1
logcollector.remote_commands=1

We tested this end to end and confirmed the script does get copied into active-response/bin with the correct permissions once the wodle runs.

The important caveat: step 3 cannot be pushed remotely, and there is no way around it. It is a deliberate security boundary (this is by design, not a missing feature), so it has to be done once on every endpoint. If you are already rolling out these Windows agents through a deployment tool like GPO, Intune, or SCCM, the simplest approach is to include that local_internal_options.conf change as part of the same deployment package, so it is not an extra manual pass, it just rides along with the initial agent installation. After that one time step, any update to the script only requires editing the file once in the group's shared folder on the manager.

[diego...@wazuh.com]

Follow-up on the workaround above, a few important things before you implement it:

1. Fix to the wodle example

The os attribute in the <agent_config os="^Windows"> block needs to be os="Windows" (without the ^ anchor). Windows agents report their OS starting with "Microsoft Windows Server ...", not "Windows ...", so the anchored regex silently fails to match and the wodle never runs (no error is logged, it is just skipped). We validated this end to end on an actual Windows Server 2019 agent and confirmed the anchored version never triggers. Corrected block:

<agent_config os="Windows">

  <wodle name="command">
    <disabled>no</disabled>
    <tag>ar-sync</tag>
    <command>powershell.exe -ExecutionPolicy Bypass -Command "$b='C:\Program Files (x86)\ossec-agent'; $s=Join-Path $b 'shared\custom-ar.cmd'; $d=Join-Path $b 'active-response\bin\custom-ar.cmd'; if (Test-Path $s) { if (-not (Test-Path $d) -or (Get-FileHash $s).Hash -ne (Get-FileHash $d).Hash) { Copy-Item $s $d -Force } }"</command>
    <interval>1h</interval>
    <run_on_start>yes</run_on_start>
    <ignore_output>yes</ignore_output>
    <timeout>60</timeout>
  </wodle>
</agent_config>

2. Is the wodle worth it for your fleet?

The one-time manual step to enable remote_commands on each agent costs about the same effort as copying the script itself once. The wodle only pays off if you expect to update the script content again in the future. For a large Windows fleet, it is usually simpler to do that one-time step (or distribute the script directly) through the same tool you already use to deploy the agent: GPO, SCCM, Intune, Ansible, etc. That also lets you skip enabling remote_commands entirely if the script rarely changes.

3. Security trade-off if you enable it fleet-wide

If you do decide to enable remote_commands across the whole fleet, keep in mind the trade-off you are accepting: the manager gains the ability to run arbitrary commands on every agent with that setting enabled. This is the same security boundary described in the centralized configuration security precautions: https://documentation.wazuh.com/current/user-manual/reference/centralized-configuration.html

4. About newer versions (5.x)

The mechanism is unchanged in the current 5.x branch (merged.mg via remoted + active-response). There is no dedicated feature for pushing custom active-response scripts, and nothing planned that we are aware of. If this is a recurring need for you, the right path is to open a feature request in the wazuh/wazuh repository so it can be evaluated through the normal process.

Let me know if you have any questions.

[Mithun Haridas]

Hi,

Thank you for your valuable response. I will try the methods you mentioned above and will get back to you if I encounter any issues.