MS SQLServer Monitoring and active response

[Ivan Martinez]

Hi All...

I'm trying to configure Wazuh to monitor and apply an active response to brute force attacks.

Wazuh Version: 4.14.2

I put this rules in the local_rules.xml file:

<group name="windows,authentication_failed,">

  <rule id="100100" level="6">
    <if_sid>18180</if_sid>
    <description>18180 - MSSQL: Intento de login detectado - IP: $(srcip)</description>
  </rule>

  <rule id="100101" level="13" frequency="3" timeframe="120">
    <if_matched_sid>100100</if_matched_sid>
    <description>18180 - MSSQL: ATAQUE DE FUERZA BRUTA (3 fallos) - IP: $(srcip)</description>
  </rule>
</group>

And work fine!!!

I can see in the alert in the dashboard.

But the active response don´t work.

In the ossec.conf (manager) file i have this configuration:

  <active-response>
    <disabled>no</disabled>
    <command>netsh</command>
    <location>local</location>
    <rules_id>100101</rules_id>
    <timeout>300</timeout>
  </active-response>

In the ossec.conf (windows agent): 

  <!-- Log analysis - Windows Defender -->
  <localfile>
    <location>Microsoft-Windows-Windows Defender/Operational</location>
    <log_format>eventchannel</log_format>
  </localfile>

  <!-- Log analysis - Windows Defender Firewall -->
  <localfile>
    <location>Microsoft-Windows-Windows Firewall With Advanced Security/Firewall</location>
    <log_format>eventchannel</log_format>
  </localfile>

  <!-- Log analysis - Terminal Service RDP -->
  <localfile>
    <location>Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational</location>
    <log_format>eventchannel</log_format>
  </localfile>
  <localfile>
    <location>Application</location>
    <log_format>eventlog</log_format>
    <!--<log_format>eventchannel</log_format>-->
  </localfile>

With that configuration I should see rule.id 657 where the netsh.exe command is triggered and then the rule where the IP is added to the firewall.

In this case... i don´t understand way in the  /var/ossec/etc/shared/ar.conf file i have this config:

restart-ossec0 - restart-ossec.sh - 0
restart-ossec0 - restart-ossec.cmd - 0
restart-wazuh0 - restart-ossec.sh - 0
restart-wazuh0 - restart-ossec.cmd - 0
restart-wazuh0 - restart-wazuh - 0
restart-wazuh0 - restart-wazuh.exe - 0
netsh300 - netsh.exe - 300

# sudo /var/ossec/bin/agent_control -L

Wazuh agent_control. Available active responses:

   Response name: netsh300, command: netsh.exe

Why wazuh use the 300 tag in the RA name??? This is normal?

Any idea what could be happening? 

Thanks to everyone...

[Isaiah Daboh]

Hello,

Please note that I am taking a look and I will revert shortly.

Regards,

[Isaiah Daboh]

Hello,

Having reviewed all the configuration shared, everything looks good from the manager, however there is the need to verify the following:

• The active response is enabled on the agent as well. Ensure that the config below is not set to 'yes' in the agent's ossec.conf.

<active-response>
<disabled>no</disabled>
</active-response>

• Verify that the manager is able to communicate the Active Response to the agent by checking the following logs; 

Agent - C:\Program Files (x86)\ossec-agent\active-response\active-responses.log

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

• If there is no logs, then it is means there is a communication problem or active response is not enabled at all.
• You can check the manager logs too for errors or warning: 

grep -Ei "error|warn|active-response|exec" /var/ossec/logs/ossec.log

• If the logs suggest that the active response command was executed, then it could be a filter on the dashboard.

Response name: netsh300, command: netsh.exe

Why wazuh use the 300 tag in the RA name??? This is normal?

The 300 is like an ID or tag associated with the set timeout - 300s.

Please let me know if the outlined steps was helpful in figuring out what the issue is.

Reference: 

• https://documentation.wazuh.com/current/user-manual/capabilities/active-response/how-to-configure.html
• https://documentation.wazuh.com/current/proof-of-concept-guide/block-malicious-actor-ip-reputation.html
• https://documentation.wazuh.com/current/user-manual/capabilities/active-response/default-active-response-scripts.html

Regards,

[Ivan Martinez]

Hello Isaiah...

Thank you for your prompt response...

In the ossec.conf file of the Windows Server 2016 agent, I have the following configuration:

<!-- Active response -->
  <active-response>
    <disabled>no</disabled>
    <ca_store>wpk_root.pem</ca_store>
    <ca_verification>yes</ca_verification>
  </active-response>

This is the default configuration.
Do you recommend changing it to:

<active-response>
<disabled>no</disabled>
</active-response>

Regarding the communication issue, I did a test with:

# /var/ossec/bin/agent_control -b 1.2.3.4 -f netsh300 -u 002

And it works fine, I can see rule.id 657 in the dashboard and the rule.id related to the firewall rules.

Thanks for your answer!!!

[Ivan Martinez]

Hello Isaiah... 

Thank you for your prompt response... 

In the ossec.conf file of the Windows Server 2016 agent, I have the following configuration:

  <!-- Active response -->
  <active-response>
    <disabled>no</disabled>
    <ca_store>wpk_root.pem</ca_store>
    <ca_verification>yes</ca_verification>
  </active-response>

The default configuration .

Do you recommend me changing it to:

<active-response>
<disabled>no</disabled>
</active-response>

Regarding the communication issue, I did a test with:

# /var/ossec/bin/agent_control -b 1.2.3.4 -f netsh300 -u 002

And it works fine, I can see rule.id 657 in the dashboard and the rule.id related to the firewall rules. With this command i can see the C:\Program Files (x86)\ossec-agent\active-response\active-responses.log entry.

Thanks for your help!

El martes, 10 de febrero de 2026 a las 9:18:20 UTC-6, Isaiah Daboh escribió:

[Isaiah Daboh]

Hello Ivan,

Good to know that there is no communication issue.

While I do not think that the current agent config you shared is the issue, please let's keep it simple for troubleshooting sake until everything works fine.

<active-response>
<disabled>no</disabled>
</active-response>

Please verify that the manager and agent were restarted after the Active Response configuration changes were made. If yes an the issue is the same, please update the <command> on the manager as netsh300:

  <active-response>
    <disabled>no</disabled>
    <command>netsh300</command>

    <location>local</location>
    <rules_id>100101</rules_id>
    <timeout>300</timeout>
  </active-response>

Restart the manager - very important
# systemctl restart wazuh-manager

Try to trigger the rule_id 100101 again.

Please let me know if this helps, If not, kindly inspect the ossec.log and  /var/ossec/logs/active-responses.log as described earlier and share findings.

Regards,

[Ivan Martinez]

Hi Isaiah,

Thanks for your answer.

I have the same result.

I made the recommended change in the agent and in the manager:

The manager has been restarted and the agent too...

First test:

The rule.id 1001001 work fine,  but rule.id 657 is not activated automatically.

Second test:

The rule.id 657 can be manually activated and blocks the IP address in the firewall.

The log file in the agent show this lines:

I have attached the following files to this email:

ossec.conf manager config file: case_manager_ossec.conf.txt

ossec.conf agent config file: case_agent_ossec.conf.txt

active response agent log file: case_agent_active_response.log.txt

agent log file: case_agent_ossec.log.txt

I know it must be some silly setting I've forgotten to configure. Wazuh is pretty stable software.

Thank you very much for your help.

[Isaiah Daboh]

Hi Ivan,

Thanks for sharing the config and logs.

I will try to reproduce this behavior in my local environment and revert.

Regards,