Active Response not working with Windows agents

[Kevin]

Hello,

currently I'll try to setup active response but can't get it to work on Windows agents (Windows 10 Pro and Server in this case). When I use a Linux agent everything works just fine.

For the Linux agent I configured the following active response:

<active-response>
  <command>firewall-drop</command>
  <location>local</location>
  <rules_id>5715</rules_id>
  <timeout>10</timeout>
  <level>4</level>
</active-response>

When I try to login via ssh with a wrong password, I get blocked for 10 seconds and can see the following lines in the ossec logs of the manager:
wazuh-master_1            | 2021/06/09 13:17:41 ossec-remoted[442] ar-forward.c:44 at AR_Forward(): DEBUG: Active response request received: (agentname) any->/var/log/auth.log NRN (null) firewall-drop10 - X.X.X.X 1623244661.81660412 5503 (agentname) any->/var/log/auth.log - -
wazuh-master_1            | 2021/06/09 13:17:41 ossec-remoted[442] ar-forward.c:119 at AR_Forward(): DEBUG: Active response sent: #!-execd firewall-drop10 - X.X.X.X 1623244661.81660412 5503 (agentname) any->/var/log/auth.log - -


For the Windows agent I configured the following active responses:

<active-response>
  <command>win_route-null</command>
  <location>local</location>
  <rules_id>60122</rules_id>
  <timeout>10</timeout>
</active-response>

<active-response>
  <command>win_route-null</command>
  <location>local</location>
  <rules_id>60204</rules_id>
  <timeout>10</timeout>
</active-response>

The first one should fire when someone tries to login via RDP with a wrong password and the second one should fire when someone tries to login via RDP with a wrong password multiple times.
When I now try to login with wrong credentials via RDP to the Windows agent I can see the alert in the webinterface but the active response is not triggered.

Jun 9, 2021 @ 13:21:02.916    Logon Failure - Unknown user or bad password    5    60122

No log entry about ar on the manager nor the agent.
I also tried different commands (win_route-null-2012, netsh) and with disabled firewall but with the same result.

When I trigger the active response manually with the command "agent-control -b 1.2.3.4 -f win_route-null10 -u 001" the agent receives the command and blocks the ip 1.2.3.4. I can also see the ar log entry on the agent.
The active response is configured on the master and woker nodes. I have enabled debug logs for execd, analysisd and remoted. I also double checked that active response is enabled on the agent and tried different ones.

I am using the wazuh docker-compose stack with the wazuh-odfe:4.1.2 image (I also tried version 4.1.5 and the standalone version (without docker)).

Can anyone help me with this problem?


Kind regards,

Kevin

[Juan Carlos]

Hello Kevin,

This because the Active Response is expecting the srcip field but starting from Wazuh 3.8.0 logs are collected with Windows EventChannel by default instead of being decoded from the EventLog, this means that the source IP information is stored in win.eventdata.ipAddress instead. More information on these types of logs can be found here: https://documentation.wazuh.com/current/user-manual/capabilities/log-data-collection/how-to-collect-wlogs.html

The next version of Wazuh (v4.2.0) will have a reworked Active Response capability which provide the AR script with the full alert instead of only one of four possible static fields currently supported.

A workaround is to configure Windows machines to collect logs using eventLog instead of EventChannel or execute an integration in the manager that will tigger the active response with the information from the field provided by EventChannel. An example of a similar script can be found here: https://github.com/wazuh/wazuh/wiki/Proof-of-concept-guide#configuring-active-response-to-remove-malicious-files where a field from a JSON event is used to trigger an active response that expects a filename to delete.

Please let us know if you have any other questions,

Best Regards,

Juan Carlos Tello

[Kevin]

Hello Juan Carlos,

thank  you for your response. Since I can see that version 4.2.0 is already in testing, I will wait for the update.

Best Regards,

Kevin