Responding to Malicious File with AR not working

[sau sau]

Hello all,

I followed exact step mentioned at https://wazuh.com/blog/detecting-and-responding-to-malicious-files-using-cdb-lists-and-active-response/. I got everything right up till the part where you get alert once a malicious file it added to a particular directory.

But for AR part, I get the following in active-responses. But the remove-threat.exe does not get executed.

AR configuration in wazuh manager:

  <command>
    <name>remove-threat</name>
    <executable>remove-threat.exe</executable>
    <timeout_allowed>no</timeout_allowed>
  </command>

  <active-response>
    <disabled>no</disabled>
    <command>remove-threat</command>
    <location>local</location>
    <rules_id>100002</rules_id>
  </active-response>

My wazuh version: 4.0.4

[Mauricio Aguilar]

Hi Sau,

Based on the provided information, it seems like the issue might be related to the configuration of the active response. We suggest checking the path of the executable file and ensuring that it is accessible by the Wazuh manager. Additionally, it might be helpful to check the logs for any errors or warnings related to the active response.

Let me check it.

Regards,

The Wazuh team.

[sau sau]

Hi Mauricio,

I see the following on the ossec-remoted. Looks like AR is executed on the agent. Besides there are no errors or warnings related to AR. Could this be because of my wazuh version ?

[Mauricio Aguilar]

Hi Sau,

Yes, it could be related to the Wazuh version:
* You have v4.0.4.    (Official docs related to active responses: https://documentation.wazuh.com/current/nist/active-response.html?highlight=Active%20Response)
* The guide was written for v4.2.
* The latest version is v4.4.

Anyway, I have been analyzing the guide and your configuration, and It looks like you have an error in your rule_id:

 <active-response>
    <disabled>no</disabled>
    <command>remove-threat</command>
    <location>local</location>
    <rules_id>100002</rules_id>
  </active-response>

Following the guide, the config should be:

 <active-response>
    <disabled>no</disabled>
    <command>remove-threat</command>
    <location>local</location>

    <rules_id>100003</rules_id>
  </active-response>

Please, make this change and restart the manager with:
systemctl restart wazuh-manager

Then, try the process again.

Let me know if it works for you.

Best regards,
The Wazuh team.

[teddy bear]

Hi, sorry for disturbing. I'm also following the same blog, but i'm not so advanced. 

"md5" is the value he added to the key.

How $(file)? where did that come from? 

I went to the decoder  0015-ossec_rules.xml  and looked for 554

From the blog:
=============

<group name="local,malware,">

<rule id="100002" level="5">

<if_sid>554</if_sid>

<list field="md5" lookup="match_key">etc/lists/malware-hashes</list>

<description>A file - $(file) - in the malware blacklist was added to the system.</description>

</rule>

<rule id="100003" level="5">

<if_sid>100002</if_sid>

<field name="file" type="pcre2">(?i)[c-z]:</field>

<description>A file - $(file) - in the malware blacklist was added to the system.</description>

</rule>

</group>

From 0015-ossec_rules.xml :

========================

 <rule id="554" level="5">
    <category>ossec</category>
    <decoded_as>syscheck_new_entry</decoded_as>
    <description>File added to the system.</description>
<group>syscheck,syscheck_entry_added,syscheck_file,pci_dss_11.5,gpg13_4.11,gdpr_II_5.1.f,hipaa_164.312.c.1,hipaa_164.312.c.2,nist_800_53_SI.7,tsc_PI1.4,tsc_PI1.5,tsc_CC6.1,tsc_CC6.8,tsc_CC7.2,tsc_CC7.3,</group>
  </rule>

I can see that the decoder used is called "syscheck_new_entry".

 "But I can't find the decoder called "syscheck_new_entry"

Can someone help explain where to extract $(file) or the blog?

Thanks!

[teddy bear]

I see that the variable comes from the fim module as below

https://documentation.wazuh.com/current/user-manual/capabilities/file-integrity/creating-custom-fim-rules.html

hope this link helps someone.

[Mauricio Aguilar]

Hi, let me tell you a little bit about how it works:

FIM: File Integrity Monitoring: It is the component that detects and alerts when files are created.
$(file): is the file which was downloaded to the specified folder.

syscheck_new_entry:  is the decoder which is not a file, else code as part of FIM, in charge of detect when a new file is created. It is not a configurable file.

But, at the begging of the guide, there is a configuration in which you specify which folder you want to monitor:

<ossec_config>

<syscheck>

<disabled>no</disabled>

<directories check_all="yes" realtime="yes">MONITORED_DIRECTORY_PATH</directories>

</syscheck>

</ossec_config>

Regards,

The Wazuh team.

[Mauricio Aguilar]

Message: Hi Mauricio,

Thanks for your reply, I'm abit clearer now.  Am also monitoring a dir as you mentioned. 

For id 100003 the <field name=file> is trying to match the regex for the same log? Can I change the regex?

Thanks, (Please use the button: "Reply All".)

Yes, once 100002 is executed, 100003 is activated and executed. The regular expression can be modified.

Regards,

[Joseph Yap]

Thanks Mauricio. I'll go try it out.  Have a good night

--
You received this message because you are subscribed to a topic in the Google Groups "Wazuh mailing list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wazuh/6CxknQFhLWw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wazuh+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wazuh/1b550998-fb6e-4340-a895-32b8583868een%40googlegroups.com.

[Mauricio Aguilar]

I mean, this rule 100003 I understand that it checks the md5 in windows, where the regular expression checks the disk letters the C-Z.