Custom Active Response on Windows executes only after Wazuh Agent restart (Wazuh 4.14.6)

[Seeta Rama Raju]

Hi Wazuh Team,

I’m facing an issue with custom Active Response on a Windows agent and would appreciate any guidance.

Environment

• Wazuh Manager: 4.14.6
• Wazuh Windows Agent: 4.14.6
• Windows 10 Enterprise

Issue

I have configured a custom Active Response to automatically kill suspicious processes.

The custom Active Response does not execute immediately when the rule is triggered. It only executes after I manually restart the Wazuh Agent service on the Windows endpoint.

Active Response Configuration:

<command> <name>kill_process</name>
<executable>kill_process.cmd</executable>
<timeout_allowed>no</timeout_allowed></command>

<active-response>
<disabled>no</disabled>
<command>kill_process</command>
<location>local</location>
<level>10</level>
</active-response>

How it works:

• kill_process.cmd is a wrapper script.
• It launches kill_process.exe (compiled from a Python script using PyInstaller).
• The executable reads the Active Response JSON from stdin, extracts newProcessId, converts the hexadecimal PID to decimal, and attempts to terminate the process.

What I have verified

• The detection rule triggers immediately.
• Alerts are generated immediately.
• The manager sends the Active Response successfully.
• The Windows agent is online and connected.
• agent.conf is synchronized correctly.
• merged.mg contains the custom command correctly.
• kill_process.cmd is present in the agent's active-response\bin directory.
• kill_process.exe is present in the same directory.
• When kill_process.cmd is executed, it successfully launches kill_process.exe.
• kill_process.exe receives the complete JSON payload through stdin.
• The executable correctly parses the JSON and extracts the PID.

Built-in Active Response Test

I also tested the built-in Active Response using restart-wazuh.exe.

It executes immediately whenever the rule is triggered, confirming that the Active Response subsystem is working.

Custom Active Response Behavior

The problem is that kill_process.cmd itself is not executed immediately.

Because the CMD file is not triggered, kill_process.exe is also not launched.

However, if I manually restart the Wazuh Agent service, the custom Active Response is executed automatically. The CMD file starts, launches the EXE, and the EXE receives the complete JSON payload successfully.

My Question

Has anyone experienced custom Windows Active Responses only executing after restarting the Wazuh Agent service?

Is there any known issue or additional configuration required for custom Active Response commands on Windows 4.14.6?

Any suggestions or troubleshooting ideas would be greatly appreciated.

Thank you.

[Md. Nazmur Sakib]

Hi Seeta,

I am not familiar with the executable from your example, kill_process.exe, so I would like to understand how it is implemented. Please make sure it follows the documentation:

https://documentation.wazuh.com/current/user-manual/capabilities/active-response/custom-active-response-scripts.html

There are some known cases where the Active Response executable remains running and blocked, typically while waiting to read from STDIN or write to STDOUT. This usually happens when the handshake is not handled correctly or when messages do not end with \n.

Check the active-responses.log file to confirm whether the script runs or not.

If you are seeing this behavior, please check the following:

• Verify in Task Manager whether kill_process.exe is still running as a child process of wazuh-agent.exe.

• Review the implementation and confirm that it follows the documentation.

Let me know if you need any further assistance on this.

[Seeta Rama Raju]

Hi Nazmur,

Thank you for your response.

The kill_process.exe is a custom Active Response executable that I developed by converting a Python script to an executable using PyInstaller, following the Windows custom Active Response approach. The script reads the alert JSON from STDIN, extracts the required fields (such as the process ID), and performs the configured action.

I also reviewed the Active Response documentation you shared.

Regarding the issue, I observed the following behavior:

• After restarting the Wazuh agent, the Active Response executes successfully.
• The executable receives the JSON input from STDIN, processes it correctly, and performs the intended action.
• After some time, however, the Active Response stops executing until the Wazuh agent is restarted again.

I also implemented another custom Active Response (quarantine_file.exe) using the same approach, and it exhibits the exact same behavior. This suggests the issue may not be specific to the kill_process.exe implementation.

I will review my implementation once more to ensure it fully complies with the documentation, particularly the STDIN/STDOUT handling and handshake requirements. I will also check whether the executable remains running as a child process of wazuh-agent.exe and review the active-responses.log during the failure.

I'll share my findings after completing these checks.

Thank you for your guidance.

[Md. Nazmur Sakib]

Can you share the update on this?

Can you check if you can run the executable directly using the active response configuration?


<ossec_config>

  <command>

    <name>windows-custom-ar</name>

    <executable>quarantine_file.exe</executable>

    <timeout_allowed>yes</timeout_allowed>

  </command>

Ref: Windows custom active response configuration

I look forward to your update.

[Seeta Rama Raju]

Now it's working fine after disabling timeout_allowed to 'NO'.

But Why does the wazuh dashboard get very slow after feeding multiple threat intel data to CDB lists, Increasing the ram of the wazuh server can fix it or we should do any changes?

--
You received this message because you are subscribed to the Google Groups "Wazuh | Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wazuh+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wazuh/9a6e55ec-cbd6-49b8-8e2b-b93c0962fe15n%40googlegroups.com.

[Md. Nazmur Sakib]

Increasing the RAM on the Wazuh server can solve this problem.
It's possible to use large CDB list files, but there are some things you should keep in mind:

• The Wazuh manager uses RAM to hold the whole list in memory for quick lookups. Really huge lists can eat a lot of memory.

• If the list gets massive, rule checks might slow down a bit, especially if you have lots of events hitting those rules.

• Uploading or managing super-large files through the dashboard or API can sometimes fail or time out.

Let me know if you need any further information.