Possible kernel level rootkit in /var/log/lastlog and /var/log/tallylog

[Francesc G]

Hi,

I have written an overwrite rule to receive all mails related to rule 521 "Possible kernel level rootkit" so now I'm receiving this notification but I don't understand why.

Rule: 521 fired (level 11) -> "Possible kernel level rootkit"

Portion of the log(s):

 

Anomaly detected in file '/var/log/lastlog'. Hidden from stats, but showing up on readdir. Possible kernel level rootkit.

title: Anomaly detected in file '/var/log/lastlog'.

"ls -l /var/log/lastlog" and "stat /var/log/lastlog" shows the same outtput:

root@rpi:~# ls -lh /var/log/lastlog
-rw-rw-r-- 1 root utmp 129G sep 25 14:08 /var/log/lastlog
root@rpi:~#
root@rpi:~# stat /var/log/lastlog
  Fichero: /var/log/lastlog
  Tamaño: 137532654956  Bloques: 88         Bloque E/S: 4096   fichero regular
Dispositivo: b307h/45831d       Nodo-i: 523279      Enlaces: 1
Acceso: (0664/-rw-rw-r--)  Uid: (    0/    root)   Gid: (   43/    utmp)
      Acceso: 2019-02-28 12:50:42.000000000 +0100
Modificación: 2024-09-25 14:08:01.748253302 +0200
      Cambio: 2024-09-25 14:08:01.748253302 +0200
    Creación: 2019-02-28 12:55:05.129999862 +0100

The only odd thing is the file size (129 GB) when the disk is only 16 GB (it's a Raspberry Pi). On the other hand this is something I've seen countless times over the years. This file has a wrong size. Could this be related to the false positive?

All of the above also happens with the /var/log/tallylog file.

Best regards.

[Leonardo Daniel Sancho]

Hello Francesc G,

Could you provide us with the rule that you modified as well as a sample log to test this?

Additionally, every bit of details that you can provide us with, can be of help when trying to replicate this in a lab environment.

I'll be waiting for your answer.

[Francesc G]

Hi,

Thanks for your help.

I added the following rule in local_rules.xml in order to receive by email this type of event. Since the rule is level 11 I have added "alert_by_email" directive but this is the only difference from the original rule.

<group name="ossec,">

    <rule id="521" level="11" overwrite="yes">
        <if_sid>510</if_sid>
        <options>alert_by_email</options>
        <match>Possible kernel level rootkit</match>
        <description>Possible kernel level rootkit</description>
        <mitre>
                <id>T1014</id>
        </mitre>
        <group>rootcheck,</group>
    </rule>

</group>

I also added the following directive in ossec.conf needed to get notifications by email for this rule:

  <email_alerts>
    <email_to>em...@domain.com</email_to>
    <rule_id>521</rule_id>
    <do_not_delay />
  </email_alerts>

This is a rootcheck rule so the "full_log" field is something like:

"Anomaly detected in file '/var/log/tallylog'. Hidden from stats, but showing up on readdir. Possible kernel level rootkit."

The rule triggers every 12 hours when rootchek runs. As I wrote in my first email, the two files that trigger the rule have the same nature.

1. Are data type:

root@rpi:~# file /var/log/tallylog
/var/log/tallylog: data
root@rpi:~# file /var/log/lastlog
/var/log/lastlog: data

2. They are occupying very huge amount of disk space

root@rpi:~# ls -lh /var/log/tallylog
-rw------- 1 root root 29G feb  1  2023 /var/log/tallylog

root@rpi:~# ls -lh /var/log/lastlog

-rw-rw-r-- 1 root utmp 129G sep 26 13:33 /var/log/lastlog

3. The actual size is only few KB's, if you check with the ls -s command (output of -s is in disk blocks).

root@rpi:~# ls -s /var/log/tallylog
28 /var/log/tallylog
root@rpi:~# ls -s /var/log/lastlog
44 /var/log/lastlog

Thanks for your help.

[Leonardo Daniel Sancho]

Hello Francesc G, after some testing I was able to reproduce a similar error in a lab environment, while it wasn't quite with the file that you mentioned, still a false positive was achieved, with this in mind, when Wazuh detects a file during a directory listing but fails to find it when performing a detailed file check (stat), it might trigger this alert.

There's also an existing GitHub issue that explains this problem which can be viewed here: https://github.com/wazuh/wazuh/pull/25634

A workaround for this could potentially be a rule that silences events related to these particular files which are considered to be false positives, an example of a simple rule that is set to level 0 and uses a regex patter to find the false positives is as follows:

<rule id="100100" level="0">
  <if_group>rootcheck</if_group>
  <match>/var/log/lastlog</match>
  <description>Ignore false positive for /var/log/lastlog file</description>
</rule>

More information about the rootcheck module can be found here: https://documentation.wazuh.com/current/user-manual/capabilities/malware-detection/rootkits-behavior-detection.html#check-hidden-files-using-system-calls

Have a great day!

[Francesc G]

Hi Leonardo,

This is exactly what I did in the end.

Thank you.