Wazuh Malware Detection False Positive

Dig down a Wazuh alert

Table of Contents

Intro

A while after setting up all wazuh agents and flicking trough different types of events, I've noticed some that could indicate not only an intrusion but persistence.

Rule.Id: 510
Title: Trojaned version of file detected
Description: Host-based anomaly detection event (rootcheck)

On the event details there's the file name of the infected binary; /usr/bin/diff

Hands on the shell

Handy! But first, let's check what's the founding of this alert

# details/full_log
Trojaned version of file '/usr/bin/diff' detected. Signature used: 'bash|^/bin/sh|file\.h|proc\.h|/dev/[^n]|^/bin/.*sh' (Generic).

Seems its not a matter of any checksum, but the check for some indicators of compromise in the binary

For each binary there's a rule, in this case the signature is

bash|^/bin/sh|file\.h|proc\.h|/dev/[^n]|^/bin/.*sh

Let's find out what's the binary hiding by using strings to dump readable content and grep to look for any indicator of the signature on the output

:~$ strings $(which diff) | grep -E 'bash|^/bin/sh|file\.h|proc\.h|/dev/[^n]|^/bin/.*sh'
/dev/full

The filter returns /dev/full which is not suspicious at all - so this could be a lack of signature's updates -- furthermore in the worse some ofuscated or suspicious code could have been find but odds are on the other side.

Anyways, looking up at the context for the /dev/full occurrence, nothing too interesting at all its found

~$ strings $(which diff) | grep -B9 -A9 -E 'bash|^/bin/sh|file\.h|proc\.h|/dev/[^n]|^/bin/.*sh'
mbuiter_multi_next
literal
shell
shell-always
shell-escape
shell-escape-always
c-maybe
clocale
/dev/null
/dev/full
mbuiter_multi_next
;*3$"
/usr/lib/debug/.dwz/x86_64-linux-gnu/diffutils.debug
8b2c724ea573d58b7e0fa35e0b41e03b896d27.debug
.shstrtab
.interp
.note.gnu.property
.note.gnu.build-id
.note.ABI-tag

Well, after some researching about this alert with diff, in this github issue on ossec-hid someone comes up with a workaround to fix it without disabling any rule; which indeed does so by updating the rule regular expression --

I think the issue may be due to a reference to /dev/full in the diff executable.

# strings /bin/diff | grep /dev/[^n]
/dev/full

I made a change in /var/ossec/etc/shared/rootkit_trojans.txt to the following line to see if that fixes the issue:

-diff        !bash|^/bin/sh|file\.h|proc\.h|/dev/[^n]|^/bin/.*sh!
+diff        !bash|^/bin/sh|file\.h|proc\.h|/dev/[^nf]|^/bin/.*sh!



The part of the signature that triggers is: /dev/[^n]

Which filters for whatever on /dev/ path that doesn't begin with 'n', perhaps to exclude /dev/null, so in order to fix the alert the regexp has to exclude /dev/full too

After verifying the fix on one host, lets cook an ansible book which updates the rule signature and restart wazuh-agent service

---
- name: Fix diff signature in ossec-hid rootcheck
  hosts: wazuhAgents
  become: yes # to run commands with sudo
  vars:
    file: "/var/ossec/etc/shared/rootkit_trojans.txt"
  tasks:
    - name: Add /dev/f* exclusion to diff signature
      lineinfile:
        path: "{{ file }}"
        regexp: '^diff'
        line: 'diff        !bash|^/bin/sh|file\.h|proc\.h|/dev/[^nf]|^/bin/.*sh!'
        backup: yes
    - name: Restart wazuh-agent
      systemd:
        state: restarted
        name: wazuh-agent




Once ansible runs over all host in the inventory there won't be any alerts triggered by references the special file /dev/full nor any other in /dev/ starting by f.