Custom Active Response

[Mgc Labs]

Hi, I'm trying to set up a custom Active Response that will trigger if too many attacks happen against a particular site.

I am able to limit it to a site based on the log location.

I used 

<group name="XSiteMaliciousTraffic">

  <rule id="150000" level="12">
    <location>loglocation</location>
    <if_group>MaliciousTraffic</if_group>
    <description>Malicious Traffic directed at X Site</description>
  </rule>

  <rule id="150001" level="13" frequency="5" timeframe="300">
    <if_matched_sid>150000</if_matched_sid>
    <description>Possible DDOS attack against X site</description>
  </rule>
</group>

The goal is, if too many attacks happen against this site, it will send a custom AR that will set CloudFlare to under attack mode. However when I put the above in local_rules.xml auditd refuses to come up. What am I doing wrong?

Thanks!

[Manuel Camona Perez]

Hi Mgc Labs,

The rules you posted seem to be correct, I have added them to my environment and no error came up when restarting.

You said that when you added the rules to the local_rules.xml, auditd refused to come up, could you explain more details about this error?

The workaround you are following appears to be OK. You have created custom rules that will trigger an active response script. Have a look at the following pages to know more about custom active response scripts and use cases:

- Custom Active Response 
- Blocking a malicious actor (default AR script) 
- Detect and remove malware, VirusTotal integration 
- Detect malware using Yara integration


For your case, you will need a proper active response configuration and a bash script (for instance) that edits the CloudFlare configuration.

[Mgc Labs]

Well now that I discovered the auditd issue was due to the known bug with overriding rules, that's no longer an issue.

However, my custom active response is not firing still.

It seems to get loaded into ar.conf just fine, and I see my rule that is supposed to trigger it has fired many times, but no luck.

The main thing I think I did different is that the active response is in a subfolder in the active response folder so I put the command executable as

cloudflare/flare

Can the executable be in a subfolder in active-response?

I don't see any reference to it trying to execute the custom active response in the logs, but again no error either.

The script is basically the example python ar script kindly provided by Wazuh, + functions to call cloudflare api

[Manuel Camona Perez]

Hi Mgc Labs, how are you?

I am afraid to say that the active response script cannot be in a subfolder of /var/ossec/active-response/bin.

Also, note that the script must be in the agent in which you are trying to execute the active response, with the appropriate permissions and ownership.

In order to troubleshoot your active response issue, you can set the execd daemon in debug mode. To do it, add the following line to the manager's /var/ossec/etc/local_internal_options.conf:

execd.debug=2

After this addition, restart the manager and each time you try your active response use case, you will see extra messages from the wazuh-execd daemon in the manager's ossec.log. These messages could help you find errors.

If you don't see anything, please send me your active response configuration so I can troubleshoot this better.

I also suggest that you start with a less complex use case, this way we can discard possible errors. For instance, try executing the active response in the manager first, and then try the use case in the agents.

[Mgc Labs]

Cool, so now that I have it not using a subdirectory I see in the logs it is attempting the Active Response. Great progress!

It appears though that it is getting a JSON not formatted properly error but I don't see why it doesn't like the alert json. Any way I can attempt it with test json and see what it does?

I have also added the debug per your suggestion so maybe it will give me more info about what it doesn't like

[Manuel Camona Perez]

Hi Mgc Labs,

From Wazuh 4.2 on, the full alerts are passed to the AR scripts via STDIN within a JSON object, and each AR is responsible for extracting the information necessary for its execution. So in order to troubleshoot a JSON not formatted error, you can execute the active response script and include the alert via STDIN (as you said, a test JSON).

For instance, if I use the Python active response script example found at https://documentation.wazuh.com/current/user-manual/capabilities/active-response/custom-active-response.html#custom-active-response-linux-example.

# python3 python_script.py
{"command":"add","parameters":{"alert":{"rule":{"id":"123"}}}}    <---- STDIN
{"version": 1, "origin": {"name": "python_script.py", "module": "active-response"}, "command": "check_keys", "parameters": {"keys": ["123"]}}    <---- STDOUT
{"command":"continue"}    <---- STDIN

This script example is used to create a file containing the rule ID that triggered the AR. In this case, the ID is 123 (JSON example I used).

The file was created and this is its content:

# cat ar-test-result.txt
Active response triggered by rule ID: <['123']>


Logs were also writen to active-responses.log:

# cat /var/ossec/logs/active-responses.log
2022-06-27 07:22:27 python_script.py: Started
2022-06-27 07:30:56 python_script.py: {"command":"add","parameters":{"alert":{"rule":{"id":"123"}}}}

2022-06-27 07:30:56 python_script.py: {"version": 1, "origin": {"name": "python_script.py", "module": "active-response"}, "command": "check_keys", "parameters": {"keys": ["123"]}}
2022-06-27 07:31:38 python_script.py: {"command":"continue"}

2022-06-27 07:31:38 python_script.py: Ended

You can find the JSON used that gave the error in the ossec.log file.

I hope this helps, if you cannot solve that JSON not formatted error, please send me the custom active response script you are using for better assistance.

[Manuel Camona Perez]

Answering your private message here:

Thanks, I just tried that and got

2022/06/28 01:10:53 wazuh-analysisd[6848] json_decoder.c:390 at JSON_Decoder_Exec(): DEBUG: Decoding JSON: ‘{“version”:1,”origin”:{“name”:”n’
2022/06/28 01:10:53 wazuh-analysisd[6848] json_decoder.c:390 at JSON_Decoder_Exec(): DEBUG: Decoding JSON: ‘Starting’
2022/06/28 01:10:53 wazuh-analysisd[6848] json_decoder.c:395 at JSON_Decoder_Exec(): DEBUG: Malformed JSON string ‘Starting’
2022/06/28 01:10:53 wazuh-analysisd[6848] json_decoder.c:390 at JSON_Decoder_Exec(): DEBUG: Decoding JSON: ‘{“version”:1,”origin”:{“name”:”f’
2022/06/28 01:10:53 wazuh-analysisd[6848] json_decoder.c:390 at JSON_Decoder_Exec(): DEBUG: Decoding JSON: ‘{“version”:1,”origin”:{“name”:”n’
2022/06/28 01:10:53 wazuh-analysisd[6848] json_decoder.c:390 at JSON_Decoder_Exec(): DEBUG: Decoding JSON: ‘Ended’
2022/06/28 01:10:53 wazuh-analysisd[6848] json_decoder.c:395 at JSON_Decoder_Exec(): DEBUG: Malformed JSON string ‘Ended’

I just loading the str with json loads by itself and it still gets a json error, here’s the JSON:

{“version”:1,”origin”:{“name”:”node01”,”module”:”wazuh-execd”},”command”:”add”,”parameters”:{“extra_args”:[],”alert”:{“timestamp”:”2022-06-26T19:09:49.663+0000”,”rule”:{“level”:12,”description”:”Excessive CMS (WordPress or Joomla) brute force attempt against site.”,”id”:”140007”,”mitre”:{“id”:[“T1110”],”tactic”:[“Credential Access”],”technique”:[“Brute Force”]},”frequency”:8,”firedtimes”:1,”mail”:true,”groups”:[“MaliciousTrafficpci_dss_6.5”],”pci_dss”:[“11.4”,”6.5.10”,”10.2.4”,”10.2.5”],”gdpr”:[“IV_35.7.d”,”IV_32.2”],”hipaa”:[“164.312.b”],”nist_800_53”:[“SA.11”,”SI.4”,”AU.14”,”AC.7”],”tsc”:[“CC6.6”,”CC7.1”,”CC8.1”,”CC6.1”,”CC6.8”,”CC7.2”,”CC7.3”]},”agent”:{“id”:”003”,”name”:”wordpress.pdgoserver.com”,”ip”:”67.43.12.142”},”manager”:{“name”:”security”},”id”:”1656270589.270293259”,”previous_output”:”154.6.26.66 - - [26/Jun/2022:15:09:45 -0400] \”POST /wp-login.php HTTP/2.0\” 302 - \”-\” \”Mozilla/5.0\”\n154.6.26.66 - - [26/Jun/2022:15:09:45 -0400] \”POST /wp-login.php HTTP/2.0\” 302 - \”-\” \”Mozilla/5.0\”\n154.6.26.66 - - [26/Jun/2022:15:09:45 -0400] \”POST /wp-login.php HTTP/2.0\” 302 - \”-\” \”Mozilla/5.0\”\n154.6.26.66 - - [26/Jun/2022:15:09:45 -0400] \”POST /wp-login.php HTTP/2.0\” 302 - \”-\” \”Mozilla/5.0\”\n154.6.26.66 - - [26/Jun/2022:15:09:45 -0400] \”POST /wp-login.php HTTP/2.0\” 302 - \”-\” \”Mozilla/5.0\”\n154.6.26.66 - - [26/Jun/2022:15:09:45 -0400] \”POST /wp-login.php HTTP/2.0\” 302 - \”-\” \”Mozilla/5.0\”\n154.6.26.66 - - [26/Jun/2022:15:09:45 -0400] \”POST /wp-login.php HTTP/2.0\” 302 - \”-\” \”Mozilla/5.0\””,”full_log”:”154.6.26.66 - - [26/Jun/2022:15:09:47 -0400] \”POST /wp-login.php HTTP/2.0\” 302 - \”-\” \”Mozilla/5.0\””,”decoder”:{“name”:”web-accesslog”},”data”:{“protocol”:”POST”,”srcip”:”154.6.26.66”,”id”:”302”,”url”:”/wp-login.php”},”location”:”/var/log/apache2/domlogs/thesite.org-ssl_log”},”program”:”active-response/bin/flare”}}

I have tested this JSON with the Python script example given in the documentation and it works, could you share your active response script so I can see why there is a JSON decode error? Also, please send the output of the script when the error is raised.

Please post messages in this thread so it is useful for other users having similar issues or issues related to this topic.

​

[Mgc Labs]

As a sanity check I copied again from that example AR from your link and did the following:

    root@security:/var/ossec/active-response/bin# python3 python_script.py {"command":"add","parameters":{"alert":{"rule":{"id":"123"}}}}

(no output)  

    {"command":"continue"}

Check ar log

root@security:/var/ossec/active-response/bin# tail  /var/ossec/logs/active-responses.log

2022-06-30 00:55:33 python_script.py: Started
2022-06-30 00:55:44 python_script.py: {"command":"continue"}

2022-06-30 00:55:44 python_script.py: Not valid command: continue

Check ossec log

2022/06/30 00:55:37 wazuh-analysisd[1607] json_decoder.c:390 at JSON_Decoder_Exec(): DEBUG: Decoding JSON: 'Starting'
2022/06/30 00:55:37 wazuh-analysisd[1607] json_decoder.c:395 at JSON_Decoder_Exec(): DEBUG: Malformed JSON string 'Starting'
2022/06/30 00:55:37 wazuh-analysisd[1607] json_decoder.c:390 at JSON_Decoder_Exec(): DEBUG: Decoding JSON: '{"version":1,"origin":{"name":"n'
2022/06/30 00:55:37 wazuh-analysisd[1607] json_decoder.c:390 at JSON_Decoder_Exec(): DEBUG: Decoding JSON: '{"version":1,"origin":{"name":"f'
2022/06/30 00:55:37 wazuh-analysisd[1607] json_decoder.c:390 at JSON_Decoder_Exec(): DEBUG: Decoding JSON: '{"version":1,"origin":{"name":"n'
2022/06/30 00:55:37 wazuh-analysisd[1607] json_decoder.c:390 at JSON_Decoder_Exec(): DEBUG: Decoding JSON: 'Ended'
2022/06/30 00:55:37 wazuh-analysisd[1607] json_decoder.c:395 at JSON_Decoder_Exec(): DEBUG: Malformed JSON string 'Ended'

[Mgc Labs]

I copied verbatim to try to get to a place where a simple custom active response works, since if the simple one works I can figure out how to get my more complex one working.

Do you see anything wrong with what I copied from your prior message?

    root@security:/var/ossec/active-response/bin# python3 python_script.py {"command":"add","parameters":{"alert":{"rule":{"id":"123"}}}}

(no output)  

    {"command":"continue"}

Looking forward to your reply,

[Manuel Camona Perez]

You are not testing the script properly, the JSON is not a script argument. 

When you execute the script:

# python3 python_script.py

The script waits for input. This input must be the JSON message

# python3 python_script.py
{"command":"add","parameters":{"alert":{"rule":{"id":"123"}}}}    <---- STDIN

After that the script writes to STDOUT

# python3 python_script.py
{"command":"add","parameters":{"alert":{"rule":{"id":"123"}}}}    <---- STDIN
{"version": 1, "origin": {"name": "python_script.py", "module": "active-response"}, "command": "check_keys", "parameters": {"keys": ["123"]}}    <---- STDOUT

And then waits again for you to send the last message:

# python3 python_script.py
{"command":"add","parameters":{"alert":{"rule":{"id":"123"}}}}    <---- STDIN
{"version": 1, "origin": {"name": "python_script.py", "module": "active-response"}, "command": "check_keys", "parameters": {"keys": ["123"]}}    <---- STDOUT
{"command":"continue"}    <---- STDIN