windows AR not working

[Annie s]

Hi all,
This is my active response configuration on centos server:

 <command>
    <name>win_nullroute</name>
    <executable>route-null.cmd</executable>
    <expect>srcip</expect>
    <timeout_allowed>yes</timeout_allowed>
  </command>

  <active-response>
    <disabled>no</disabled>
    <command>win_nullroute</command>
    <location>all</location>
    <level>5</level>
    <timeout>60</timeout>
  </active-response>

I have enabled AR on windows agent, but it is not executed when an event of level>=5 is fired.
I am using wazuh 3.13 version, windows 10

[Manuel Camona Perez]

Hi Annie,

As I can see in the command configuration, you used the expect option with srcip. This means that the alert generated that triggered active response must have a srcip field as the srcip value will be used in the script.

In the active response configuration, you used the level option with value 5. This means that all the alerts with level equal or higher than 5 will trigger the active response script.

Taking these 2 statements into account, the following could be happening: an event with level>=5 but without srcip field is being generated, and therefore, the active response script is not being executed. Could you check this?

Also, note that you are using all in the location option. This means that the active response script will be executed for all agents when AR is triggered. The all option should be used with caution because maybe this is not the use case you are looking for. If you use local, the AR script is executed on the agent that generated the event. If you use server, the AR script is run on the manager the agent is reporting to. You can find more information about this option here.

[Annie s]

Hi Manuel,

In my use case , Centos is the manager. I have only one wazuh agent i.e my windows machine, it is my victim. I have another Windows machine as the attacker. I am trying to RDP the machine with wrong password attempts. So in that case AR should get generated along with scrip field , but it is not. Also I tried using  <location>local</location>  but no success.

--

---
You received this message because you are subscribed to the Google Groups "ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ossec-list+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/4833a5ab-2fce-49e3-9f00-0b2d2755d937n%40googlegroups.com.

[Manuel Camona Perez]

Hi again, could you have a look at the events generated when you are reproducing the use case? Note that if the appropriate events (wrong password attempts) are not being generated, no AR script will be executed. These events can be found at /var/ossec/logs/alerts/alerts.log.

In order to troubleshoot, you could also enable debug mode for the execd daemon of your Wazuh agent. To do this, add the following line:

execd.debug=2

to the agent's local_internal_options.conf file.

Also, have a look at https://documentation.wazuh.com/3.13/learning-wazuh/shellshock.html#ar-scenario-3-make-windows-null-route-the-attacker, this documentation page will help you troubleshoot the possible errors as it explains a very similar use case.

[Annie s]

Hi, I enabled execd.debug = 2. In ossec logs Read 0 lines from active-response\active-response.log, these logs are seen several times. 

Also I checked /var/ossec/logs/alerts/alerts.log file, basic logs for windows are getting generated but logs for wrong password events are not generated.

To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/37ce5346-5191-40d9-813c-ffe25bd03f49n%40googlegroups.com.

[Manuel Camona Perez]

Hi again and sorry for the late response,

As I said, if the appropriate events (wrong password attempts) are not being generated, no AR script will be executed.

Before troubleshooting the possible AR issues, check that the wrong password attempt events are being generated.

This is how the active response use cases work:

Wrong password attempts in the agent -> Event generated -> Rule generates an alert in the manager  -> Alert matches the AR configuration -> Active response script executed 

Right now we are in step 2 or 3, "Event generated" or "Rule generates an alert in the manager". If the event is not generated, the rules will not generate the specific alert needed for active response. And if no rule is matching the events generated, no alert is generated for the AR script execution.

Could you enable the logall option in the manager's ossec.conf file? This will make your logs appear in /var/ossec/logs/archives/archives.log. With the logs corresponding to the wrong password attempts we could see why the rules are not generating the alerts and therefore, executing active response (it could be a lack of rules for these logs).

[Paterson Lali]

Thank you dear.

To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/7b8d32b2-b22c-48b4-9d2a-968460855b9cn%40googlegroups.com.

[Annie s]

Hi,

I was able to generate wrong password events after editing the audit policies of windows.

log all option is enabled

Alert for wrong password is generated in the manager at /var/ossec/logs/alerts/alerts.log
Rule:18130 (level 5)-> 'Windows: Logon Failure - Unknown user or bad password.'
User: (no user)

Logs for audit failure is generated at /var/ossec/logs/archives/archives.log

AUDIT_FAILURE(4625):Microsoft-Windows-Security-Auditing: (no user)

But Active response is not getting triggered. 

To view this discussion on the web visit https://groups.google.com/d/msgid/ossec-list/CAJ5OZk55Y1tcu6Lttdzo%3DJ63-VomARqOV8uogpNO-kbidvh8pA%40mail.gmail.com.